From lzang at openjdk.java.net  Mon Feb  1 06:19:39 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Mon, 1 Feb 2021 06:19:39 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump
In-Reply-To: <cHsGHKQrSqSUKJJ2OIRVUYuKUVOJGH-Pch-aDmoPj64=.88025b63-b0bb-401a-a749-57089ebea3aa@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
 <crJcuaqSgYZQCEw2lqGaLpRmCVOXr99P1i5bcnSFpQc=.cb824923-e649-4ecd-ba5b-8d26cb93b265@github.com>
 <esex_demB2ZT0CsAp2WrzNGC_gieM9USGg_fYgmFCAE=.1911dd08-7dcc-4d88-9532-5d670399dd62@github.com>
 <ztN32xTk5joNRB7MhfYMl9zHCfGA1j8bQNu-ke975qc=.4c7ff2a9-2af8-495d-8f22-83e98c2e3221@github.com>
 <oQe3_j7vewkS8wlIuYXRCa_86pI215cFIceztTf5jX0=.d6d6201b-ec15-418e-a73b-e907d9d02607@github.com>
 <oPJ9OfKdD8CTbihLREww1QM2hc3Ckiai0-1OSpkq830=.87c4f119-07c9-471f-8c25-99dcfaad8d11@github.com>
 <ngMsS8jp0GTuqLVGD5k2ZL5AckbFwh8CBj5ec_GaBes=.0c51dacf-b158-4e62-874d-5e9c5a7b5f8e@github.com>
 <JDsbDqJRQ0V_s1SvGBhr3FLu98T2-X51kpkCs8s8vxQ=.fdb2242c-8706-4057-b4aa-084cfcb24166@github.com>
 <cHsGHKQrSqSUKJJ2OIRVUYuKUVOJGH-Pch-aDmoPj64=.88025b63-b0bb-401a-a749-57089ebea3aa@github.com>
Message-ID: <gnDO9moDHlyHgJCEdcILr-MauRQgQP7I6QE38XZHus0=.4e488aca-8206-4db5-acec-5c029a6328ca@github.com>

On Fri, 29 Jan 2021 00:36:54 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> I think if you can avoid the 4th argument by just enabling parallel by default sounds like a good idea. Is there any reason not to use parallel heap dump? Also, I'm not familiar with the terms "compression backends" and "active workers". Can you explain them.
>
>> I think if you can avoid the 4th argument by just enabling parallel by default sounds like a good idea. Is there any reason not to use parallel heap dump? Also, I'm not familiar with the terms "compression backends" and "active workers". Can you explain them.
> 
> For parallel heap dump, I think expose the "parallel" option is useful when user want to control the number of threads that works on parallel dumping. One reason is to control the CPU load to not affect too much on other processes on system. 
> 
> The "active workers" is the value that returned by gang->active_workers(). And I think "active workers" is the number of available threads that could be used for parallally working on something. my understanding is that this value could be dynamically changed at runtime, but it is limited by the JVM option "-XX:ParallelGCThreads".
> 
> The "compression backend" is introduced by "gz=" option, it is actually a "backend" that write heap dump data to file, and if there is compression level specified, the "backend" will do compression first and then write to file. The whole "backend" works parallelly, before this PR, the backend thread number is dicided by "active workers".
> 
> With this PR,  the relation of parallel heap iteration threads (parallel dumper),  the file writing threads (compression backend) and the "active_works" is like following:
>           num_of_dumper_threads + num_of_compression_backend = active_workers.
> 
> BRs,
> Lin

Hi All,
As discussed in this PR, it is reasonable to enable parallel heap dump by default rather than introducing a new "parallel" option. I would like to close the CSR at https://bugs.openjdk.java.net/browse/JDK-8260424.

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

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

From github.com+4146708+a74nh at openjdk.java.net  Mon Feb  1 09:34:47 2021
From: github.com+4146708+a74nh at openjdk.java.net (Alan Hayward)
Date: Mon, 1 Feb 2021 09:34:47 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v6]
In-Reply-To: <A2D8hAuv2S3R1jr0w8WpqNl-JfEDkT_ZpAMpYhBG-Ao=.95043299-5f1d-4198-b5aa-a9907f43fed2@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <PMUYint7pX2wmQ5wONMdgL7GclrxCnolwttyJC7BzTg=.ca680fa2-5b08-491f-9c1c-8253ffa2bbb4@github.com>
 <LCUqjT2-6eTqN1RVGbHJQY1XBzUNRWlwDOj-ZCXDGfI=.949076d9-4311-4e7d-a95f-e59ea8e3b5e1@github.com>
 <A2D8hAuv2S3R1jr0w8WpqNl-JfEDkT_ZpAMpYhBG-Ao=.95043299-5f1d-4198-b5aa-a9907f43fed2@github.com>
Message-ID: <GrbBUs_4Yegb96adhYoJqJUus65ss52pcFqlYC89O_Y=.ae014145-08ba-46a0-8eb7-4c8109dfdea3@github.com>

On Wed, 27 Jan 2021 14:58:27 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

>> Build changes per se now looks okay. However, I agree with Erik that unless this PR can wait for the JNF removal, at the very least the build docs needs to be updated to explain how to successfully build for this platform. (I can live with the configure command line hack, since it's temporary -- otherwise I'd have requested a new configure argument.) This can be done in this PR or a follow-up PR.
>
>> Build changes per se now looks okay. However, I agree with Erik that unless this PR can wait for the JNF removal, at the very least the build docs needs to be updated to explain how to successfully build for this platform. (I can live with the configure command line hack, since it's temporary -- otherwise I'd have requested a new configure argument.) This can be done in this PR or a follow-up PR.
> 
> I believe it's better be done under separate PR/bugfix, so it can be completely reverted once JNF removed.

You need add macos arm64 to hsdis. Having it working is fairly essential for debugging.

Inside src/utils/hsdis, After cloning binutils
make; make demo; ./build/macosx-arm64/hsdis-demo
Results in:
Hello, world!
...And now for something completely different:

Decoding from 0x1046e31a4 to 0x1046e3664...with decode_instructions_virtual
hsdis: bad native mach=architecture not set in Makefile!; please port hsdis to this platform
hsdis output options:

I fixed it by changing the makefile to force the build flags:
ARCH=aarch64
CFLAGS/aarch64    += -m64
Resulting in:
Hello, world!
...And now for something completely different:

Decoding from 0x10012719c to 0x10012765c...with decode_instructions_virtual
Decoding for CPU 'aarch64'
main:
 0x10012719c	sub	sp, sp, #0x60
 0x1001271a0	stp	x29, x30, [sp, #80]
...etc

Putting the library in the right place then made disassembly in java work for me.

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

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

From ihse at openjdk.java.net  Mon Feb  1 11:14:59 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 1 Feb 2021 11:14:59 GMT
Subject: [jdk16] RFR: 8258378: Final nroff manpage update for JDK 16
Message-ID: <2nAapGYDGTih_WWtZngNa0s8ZBc3ZKOSgz1MEZMHGYg=.a80e96ee-dd5a-42bd-80d7-1f83e72b9686@github.com>

Before RC phase we need to ensure we have the final set of manpage updates published in OpenJDK.

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

Commit messages:
 - 8258378: Final nroff manpage update for JDK 16

Changes: https://git.openjdk.java.net/jdk16/pull/142/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=142&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8258378
  Stats: 238 lines in 27 files changed: 98 ins; 111 del; 29 mod
  Patch: https://git.openjdk.java.net/jdk16/pull/142.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/142/head:pull/142

PR: https://git.openjdk.java.net/jdk16/pull/142

From vkempik at openjdk.java.net  Mon Feb  1 11:22:47 2021
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Mon, 1 Feb 2021 11:22:47 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v6]
In-Reply-To: <GrbBUs_4Yegb96adhYoJqJUus65ss52pcFqlYC89O_Y=.ae014145-08ba-46a0-8eb7-4c8109dfdea3@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <PMUYint7pX2wmQ5wONMdgL7GclrxCnolwttyJC7BzTg=.ca680fa2-5b08-491f-9c1c-8253ffa2bbb4@github.com>
 <LCUqjT2-6eTqN1RVGbHJQY1XBzUNRWlwDOj-ZCXDGfI=.949076d9-4311-4e7d-a95f-e59ea8e3b5e1@github.com>
 <A2D8hAuv2S3R1jr0w8WpqNl-JfEDkT_ZpAMpYhBG-Ao=.95043299-5f1d-4198-b5aa-a9907f43fed2@github.com>
 <GrbBUs_4Yegb96adhYoJqJUus65ss52pcFqlYC89O_Y=.ae014145-08ba-46a0-8eb7-4c8109dfdea3@github.com>
Message-ID: <-iXh6ikIWdG2YM4G3ZE33bE_bflntM9JZ0JWd1vSMKU=.7c380f16-0e1f-4fa8-8b47-f0e9e56fdba3@github.com>

On Mon, 1 Feb 2021 09:31:31 GMT, Alan Hayward <github.com+4146708+a74nh at openjdk.org> wrote:

> You need add macos arm64 to hsdis. Having it working is fairly essential for debugging.
> 
> Inside src/utils/hsdis, After cloning binutils
> 
> ```
> make; make demo; ./build/macosx-arm64/hsdis-demo
> ```
> 
> Results in:
> 
> ```
> Hello, world!
> ...And now for something completely different:
> 
> Decoding from 0x1046e31a4 to 0x1046e3664...with decode_instructions_virtual
> hsdis: bad native mach=architecture not set in Makefile!; please port hsdis to this platform
> hsdis output options:
> ```
> 
> I fixed it by changing the makefile to force the build flags:
> 
> ```
> ARCH=aarch64
> CFLAGS/aarch64    += -m64
> ```
> 
> Resulting in:
> 
> ```
> Hello, world!
> ...And now for something completely different:
> 
> Decoding from 0x10012719c to 0x10012765c...with decode_instructions_virtual
> Decoding for CPU 'aarch64'
> main:
>  0x10012719c	sub	sp, sp, #0x60
>  0x1001271a0	stp	x29, x30, [sp, #80]
> ...etc
> ```
> 
> Putting the library in the right place then made disassembly in java work for me.

Hello, hsdis is a separate out-of-tree project and is not part of this jep.
support for looking for proper hsdis dylib library was added as part of this jep.

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

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

From github.com+4146708+a74nh at openjdk.java.net  Mon Feb  1 12:37:45 2021
From: github.com+4146708+a74nh at openjdk.java.net (Alan Hayward)
Date: Mon, 1 Feb 2021 12:37:45 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v6]
In-Reply-To: <-iXh6ikIWdG2YM4G3ZE33bE_bflntM9JZ0JWd1vSMKU=.7c380f16-0e1f-4fa8-8b47-f0e9e56fdba3@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <PMUYint7pX2wmQ5wONMdgL7GclrxCnolwttyJC7BzTg=.ca680fa2-5b08-491f-9c1c-8253ffa2bbb4@github.com>
 <LCUqjT2-6eTqN1RVGbHJQY1XBzUNRWlwDOj-ZCXDGfI=.949076d9-4311-4e7d-a95f-e59ea8e3b5e1@github.com>
 <A2D8hAuv2S3R1jr0w8WpqNl-JfEDkT_ZpAMpYhBG-Ao=.95043299-5f1d-4198-b5aa-a9907f43fed2@github.com>
 <GrbBUs_4Yegb96adhYoJqJUus65ss52pcFqlYC89O_Y=.ae014145-08ba-46a0-8eb7-4c8109dfdea3@github.com>
 <-iXh6ikIWdG2YM4G3ZE33bE_bflntM9JZ0JWd1vSMKU=.7c380f16-0e1f-4fa8-8b47-f0e9e56fdba3@github.com>
Message-ID: <1S0Z45oJKy8oesCN0k6SIHhZLzDYW9j-M_yfWZoHEzI=.2694c382-6613-4cd1-a917-16147bb00a9e@github.com>

On Mon, 1 Feb 2021 11:19:34 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

> Hello, hsdis is a separate out-of-tree project and is not part of this jep.

Unless there's something I'm missing it only requires a few lines of change to src/utils/hsdis/makefile (it already has support for macos x86_64)

>support for looking for proper hsdis dylib library was added as part of this jep.

I'm a little confused. Are you planning on adding a new disassembler?

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

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

From ihse at openjdk.java.net  Mon Feb  1 14:09:51 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 1 Feb 2021 14:09:51 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v6]
In-Reply-To: <1S0Z45oJKy8oesCN0k6SIHhZLzDYW9j-M_yfWZoHEzI=.2694c382-6613-4cd1-a917-16147bb00a9e@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <PMUYint7pX2wmQ5wONMdgL7GclrxCnolwttyJC7BzTg=.ca680fa2-5b08-491f-9c1c-8253ffa2bbb4@github.com>
 <LCUqjT2-6eTqN1RVGbHJQY1XBzUNRWlwDOj-ZCXDGfI=.949076d9-4311-4e7d-a95f-e59ea8e3b5e1@github.com>
 <A2D8hAuv2S3R1jr0w8WpqNl-JfEDkT_ZpAMpYhBG-Ao=.95043299-5f1d-4198-b5aa-a9907f43fed2@github.com>
 <GrbBUs_4Yegb96adhYoJqJUus65ss52pcFqlYC89O_Y=.ae014145-08ba-46a0-8eb7-4c8109dfdea3@github.com>
 <-iXh6ikIWdG2YM4G3ZE33bE_bflntM9JZ0JWd1vSMKU=.7c380f16-0e1f-4fa8-8b47-f0e9e56fdba3@github.com>
 <1S0Z45oJKy8oesCN0k6SIHhZLzDYW9j-M_yfWZoHEzI=.2694c382-6613-4cd1-a917-16147bb00a9e@github.com>
Message-ID: <V6vVtDmtzcULcxWgKZUo4f-5MNuPgqEwIpcyQtovi4I=.c12c553b-dacd-4044-a412-8ebbdbef3514@github.com>

On Mon, 1 Feb 2021 12:35:05 GMT, Alan Hayward <github.com+4146708+a74nh at openjdk.org> wrote:

> > Hello, hsdis is a separate out-of-tree project and is not part of this jep.
> 
> Unless there's something I'm missing it only requires a few lines of change to src/utils/hsdis/makefile (it already has support for macos x86_64)

I agree with Alan that it makes sense to add this trivial change as part of this PR, if it allows the current hsdis solution to continue working on mac/aarch64.

> 
> > support for looking for proper hsdis dylib library was added as part of this jep.
> 
> I'm a little confused. Are you planning on adding a new disassembler?

@a74nh I think Vladimir is referring to https://github.com/openjdk/jdk/pull/392. The hsdis "component" has been left behind for a long time, and there are several requests to add new backends, which require a modernized build of hsdis. This is undfortunately not a high-priority project, and has been postponed several times already. :(

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

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

From aph at openjdk.java.net  Mon Feb  1 18:49:58 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Mon, 1 Feb 2021 18:49:58 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v8]
In-Reply-To: <ugV_PtxgaQkJQw3i1cwYiaKZ46--TZfgdVsuhQd5_3Y=.5b39eb44-1398-41b1-8bdf-2e6a3149e865@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <ugV_PtxgaQkJQw3i1cwYiaKZ46--TZfgdVsuhQd5_3Y=.5b39eb44-1398-41b1-8bdf-2e6a3149e865@github.com>
Message-ID: <cpf_Q2rM76sr9dlOexk27XKGxtOK41AJxugL6Le19Mo=.d77cc563-81b2-4d14-8ed4-f34d97a7b75a@github.com>

On Sun, 31 Jan 2021 20:14:01 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 62 commits:
> 
>  - Merge branch 'master' into jdk-macos
>  - Update copyright year for BsdAARCH64ThreadContext.java
>  - Fix inclusing of StubRoutines header
>  - Redo buildsys fix
>  - Revert harfbuzz changes, disable warnings for it
>  - Little adjustement of SlowSignatureHandler
>  - Partially bring previous commit
>  - Revert "Address feedback for signature generators"
>    
>    This reverts commit 50b55f6684cd21f8b532fa979b7b6fbb4613266d.
>  - Refactor CDS disabling
>  - Redo builsys support for aarch64-darwin
>  - ... and 52 more: https://git.openjdk.java.net/jdk/compare/8a9004da...b421e0b4

src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp line 84:

> 82: // on stack. Natural alignment for types are still in place,
> 83: // for example double/long should be 8 bytes alligned
> 84: 

This comment is a bit confusing because it's no longer #ifdef APPLE. Better move it up to Line 41.

src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp line 352:

> 350: 
> 351: #ifdef __APPLE__
> 352:   virtual void pass_byte()

Please remove ```#ifdef __APPLE__``` around this region.

src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 839:

> 837:           // The code unable to handle this, bailout.
> 838:           return -1;
> 839: #endif

This looks like a bug to me. The caller doesn't necessarily check the return value. See CallRuntimeNode::calling_convention.

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

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

From andrew at openjdk.java.net  Mon Feb  1 20:29:39 2021
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Mon, 1 Feb 2021 20:29:39 GMT
Subject: RFR: 8254001: [Metrics] Enhance parsing of cgroup interface files
 for version detection
In-Reply-To: <Mat51HIuUYISDvMtuz4R7LJ2R1aBeGASWCyBWAXFlAI=.f3329041-9c29-4b4b-ba66-163233764fb9@github.com>
References: <52vN8j9B_6s6amMHb8b_1QKyhwjCvThIz5T17aNix28=.31113ef4-61d0-4525-a3df-9aa20d408935@github.com>
 <Ynmw17EfEzNeUK5w2ABmHkXqqXo98GTcYTnZFGoAYIk=.1079ee11-c9e7-443f-b74b-d94838206a2a@github.com>
 <eFFokFwfdmu0YTyAhvPJ7xBFo0ypjHw3MyC_9-aTS6g=.80ad5876-3ae3-4ca3-96b5-08db53ed6627@github.com>
 <COWzygAauFzmvgYYP6DVjIg0MH6EDyIMx0ZzeTRHol0=.8a01079b-6e40-4b1b-bb75-e693f89d8871@github.com>
 <iT7Ltrm52E9skv98tAKIYPB1ZCaXw8ep-YSegjEnhxc=.68635047-f51c-4c60-9731-0da103e56a39@github.com>
 <m1iurC4l1M904NY7lj5eVIB8jgCfBLR2sh8XrQzhJUM=.c2c5c01f-c29a-4b22-922b-e56472e951ec@github.com>
 <Mat51HIuUYISDvMtuz4R7LJ2R1aBeGASWCyBWAXFlAI=.f3329041-9c29-4b4b-ba66-163233764fb9@github.com>
Message-ID: <oGVjtCZ-VkXvuxH0oR8BWwE09Q2r3z6vM1j6YPwwRvE=.30e018b1-2b96-484e-b2e7-fcafb36c13f2@github.com>

On Tue, 12 Jan 2021 14:29:28 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Anybody willing to review this?

I can have a go.

I have two main concerns:

1. There seems to be little documentation on the new additions. I'm particularly concerned about things like CgroupV1Subsystem.java where a big chunk of documentation on the formats being read is removed and I don't see it being moved elsewhere. Documentation on the new getInstance methods would be helpful too.
2. With the new volatile fields, I think it would be better if the lock being held to initialise them was only held when necessary to perform the assignment. Holding it while performing an extensive process of parsing multiple files that could potentially fail seems a little dangerous. i.e. something like:
if (INSTANCE == null) { CGroupV1Subsystem tmp = initSubSystem(infos); synchronized (CgroupV1Subsystem.class) { if (INSTANCE == null) { INSTANCE = tmp; } } }

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

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

From jiefu at openjdk.java.net  Tue Feb  2 03:51:52 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Tue, 2 Feb 2021 03:51:52 GMT
Subject: RFR: 8260878: com/sun/jdi/JdbOptions.java fails without jfr
Message-ID: <URFTQH96EQ_wHpBLl2UWDuYj5cXEWt1dMpU6uui2Pcw=.889d9f0d-4ba1-4c71-8d4d-0d8a99e53a2b@github.com>

Hi all,

com/sun/jdi/JdbOptions.java fails in our ci/cd when jfr is disabled.
It would be better to fix it.

Thanks.
Best regards,
Jie

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

Commit messages:
 - 8260878: com/sun/jdi/JdbOptions.java fails without jfr

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

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

From cjplummer at openjdk.java.net  Tue Feb  2 04:12:42 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 2 Feb 2021 04:12:42 GMT
Subject: RFR: 8260878: com/sun/jdi/JdbOptions.java fails without jfr
In-Reply-To: <URFTQH96EQ_wHpBLl2UWDuYj5cXEWt1dMpU6uui2Pcw=.889d9f0d-4ba1-4c71-8d4d-0d8a99e53a2b@github.com>
References: <URFTQH96EQ_wHpBLl2UWDuYj5cXEWt1dMpU6uui2Pcw=.889d9f0d-4ba1-4c71-8d4d-0d8a99e53a2b@github.com>
Message-ID: <l2u80ptM9JZNOIKXZSWUgTMm9yym9NRsPr6_WNxGoIw=.fe001962-1e20-4cd5-82c0-e91db4f98c6a@github.com>

On Tue, 2 Feb 2021 03:43:29 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> com/sun/jdi/JdbOptions.java fails in our ci/cd when jfr is disabled.
> It would be better to fix it.
> 
> Thanks.
> Best regards,
> Jie

test/jdk/com/sun/jdi/JdbOptions.java line 99:

> 97:         test("-connect",
> 98:                 "com.sun.jdi.CommandLineLaunch:vmexec=java,options=\"-client\" \"-XX:+PrintVMOptions\""
> 99:                 + " -XX:+IgnoreUnrecognizedVMOptions"

You need to be careful when using `-xx:+IgnoreUnrecognizedVMOptions`, because it can result in not detecting typos in the option names, which could happen with this test in the future if any other mods are made. Other options here are to skip this part of the test if JFR is not present, or better yet don't make the test rely on JFR. I don't think there is a reason that it needs to. It seems other options could have been used for the testing. Perhaps @alexmenkov can comment on why it was done this way.

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

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

From jiefu at openjdk.java.net  Tue Feb  2 04:20:44 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Tue, 2 Feb 2021 04:20:44 GMT
Subject: RFR: 8260878: com/sun/jdi/JdbOptions.java fails without jfr
In-Reply-To: <l2u80ptM9JZNOIKXZSWUgTMm9yym9NRsPr6_WNxGoIw=.fe001962-1e20-4cd5-82c0-e91db4f98c6a@github.com>
References: <URFTQH96EQ_wHpBLl2UWDuYj5cXEWt1dMpU6uui2Pcw=.889d9f0d-4ba1-4c71-8d4d-0d8a99e53a2b@github.com>
 <l2u80ptM9JZNOIKXZSWUgTMm9yym9NRsPr6_WNxGoIw=.fe001962-1e20-4cd5-82c0-e91db4f98c6a@github.com>
Message-ID: <_bj2OMujuHAe-AL9MexB2gZfaCBa0FIae5lAuoXHk28=.84c23328-3a24-4bbe-9a08-28cd10f740c9@github.com>

On Tue, 2 Feb 2021 04:09:24 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Hi all,
>> 
>> com/sun/jdi/JdbOptions.java fails in our ci/cd when jfr is disabled.
>> It would be better to fix it.
>> 
>> Thanks.
>> Best regards,
>> Jie
>
> test/jdk/com/sun/jdi/JdbOptions.java line 99:
> 
>> 97:         test("-connect",
>> 98:                 "com.sun.jdi.CommandLineLaunch:vmexec=java,options=\"-client\" \"-XX:+PrintVMOptions\""
>> 99:                 + " -XX:+IgnoreUnrecognizedVMOptions"
> 
> You need to be careful when using `-xx:+IgnoreUnrecognizedVMOptions`, because it can result in not detecting typos in the option names, which could happen with this test in the future if any other mods are made. Other options here are to skip this part of the test if JFR is not present, or better yet don't make the test rely on JFR. I don't think there is a reason that it needs to. It seems other options could have been used for the testing. Perhaps @alexmenkov can comment on why it was done this way.

Thanks @plummercj for your review.

Let's wait for @alexmenkov 's comments.
Thanks.

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

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

From yumin.qi at oracle.com  Tue Feb  2 06:10:22 2021
From: yumin.qi at oracle.com (Yumin Qi)
Date: Mon, 1 Feb 2021 22:10:22 -0800
Subject: CSR: 8259798: Add jcmd option to dump CDS
In-Reply-To: <fda42788-5083-7cb3-f8e9-52ba37c98781@oracle.com>
References: <fda42788-5083-7cb3-f8e9-52ba37c98781@oracle.com>
Message-ID: <92ef46f4-f381-f11f-3290-d89500f7b46b@oracle.com>

Hi, Thomas and all


 ? I have updated the CSR ( https://bugs.openjdk.java.net/browse/JDK-8259798). During the code/debug, I have found some information in the CSR needs revision. Please take a look and give your comment.

 ? I am working on newly added test case failures found by mach5 tests, will send codereview after the problems fixed.


Thanks

Yumin


On 1/14/21 12:03 PM, Yumin Qi wrote:
> Hi, All
>
> ? I have created bug and CSR for this issue and wish have your comments on it:
>
> ? BUG: https://bugs.openjdk.java.net/browse/JDK-8259070
>
> ? CSR: https://bugs.openjdk.java.net/browse/JDK-8259798
>
> ?? The added jcmd option gives users an option to dump a shared archive in one step at any time when the java application is running. Please check the CSR for more detail description for it.
>
>
> ??? Thanks for your comment.
>
>
> Yumin
>
>

From stuefe at openjdk.java.net  Tue Feb  2 08:54:52 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 2 Feb 2021 08:54:52 GMT
Subject: RFR: JDK-8260707:
 java/lang/instrument/PremainClass/InheritAgent0100.java times out
Message-ID: <u_FpgUkMo0kSuyjiGVjOh9a4NvhxtfeRBZU5YtGYjJk=.c135ef9c-657a-4709-85ae-9ed034a40607@github.com>

Hi,

may I please have reviews for this trivial fix.

We see timeouts with this test on slow large (memory wise) AIX machines, as well as large core files.

This test is a negative test which tests that the VM corectly recognizes an error condition and aborts. Code goes through jni_FatalError()->os::abort(), writes a core and aborts the process.

No parameters are given for that VM invocation, so heap size depends on machine size. On my Linux box, the generated core takes about 500m. On AIX we see cores of 16G and more.

The difference between AIX and other platforms is that AIX does not have the notion of "committing" memory (we have no MAP_NORESERVE flag), so all mmapped memory counts toward the commit charge from the moment it is mapped. That makes core files on AIX annoyingly large. I'd expect a similar behavior on other platforms with overcommit disabled.

The fix is to run the test without CreateCoredumpOnCrash. For good measure, I also reduced the heap size to 128m.

Thanks to @ArnoZeller for figuring that one out.


-----
Tests: manual jtreg tests, verifying that no cores are written.

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

Commit messages:
 - Initial

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

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

From dholmes at openjdk.java.net  Tue Feb  2 10:21:41 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 2 Feb 2021 10:21:41 GMT
Subject: RFR: JDK-8260707:
 java/lang/instrument/PremainClass/InheritAgent0100.java times out
In-Reply-To: <u_FpgUkMo0kSuyjiGVjOh9a4NvhxtfeRBZU5YtGYjJk=.c135ef9c-657a-4709-85ae-9ed034a40607@github.com>
References: <u_FpgUkMo0kSuyjiGVjOh9a4NvhxtfeRBZU5YtGYjJk=.c135ef9c-657a-4709-85ae-9ed034a40607@github.com>
Message-ID: <ADHaTo5hKzmckmMKGCUJUuo0sX6fite9z5FvWgtwO6c=.05f85157-c2a9-4541-9955-0584d88b7f57@github.com>

On Mon, 1 Feb 2021 10:38:30 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Hi,
> 
> may I please have reviews for this trivial fix.
> 
> We see timeouts with this test on slow large (memory wise) AIX machines, as well as large core files.
> 
> This test is a negative test which tests that the VM corectly recognizes an error condition and aborts. Code goes through jni_FatalError()->os::abort(), writes a core and aborts the process.
> 
> No parameters are given for that VM invocation, so heap size depends on machine size. On my Linux box, the generated core takes about 500m. On AIX we see cores of 16G and more.
> 
> The difference between AIX and other platforms is that AIX does not have the notion of "committing" memory (we have no MAP_NORESERVE flag), so all mmapped memory counts toward the commit charge from the moment it is mapped. That makes core files on AIX annoyingly large. I'd expect a similar behavior on other platforms with overcommit disabled.
> 
> The fix is to run the test without CreateCoredumpOnCrash. For good measure, I also reduced the heap size to 128m.
> 
> Thanks to @ArnoZeller for figuring that one out.
> 
> 
> -----
> Tests: manual jtreg tests, verifying that no cores are written.

Hi Thomas,

This seems fine. Some of the tests that use NegativeAgentRunner already add -XX:-CreateCoreDumpOnCrash (somewhat pointlessly I think) on their @run lines - so these could be removed. (They could all be converted to driver mode as well AFAICS but that may be asking a bit much for this change. :))
Thanks,
David

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

Marked as reviewed by dholmes (Reviewer).

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

From sspitsyn at openjdk.java.net  Tue Feb  2 11:44:52 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Tue, 2 Feb 2021 11:44:52 GMT
Subject: RFR: JDK-8260707:
 java/lang/instrument/PremainClass/InheritAgent0100.java times out
In-Reply-To: <u_FpgUkMo0kSuyjiGVjOh9a4NvhxtfeRBZU5YtGYjJk=.c135ef9c-657a-4709-85ae-9ed034a40607@github.com>
References: <u_FpgUkMo0kSuyjiGVjOh9a4NvhxtfeRBZU5YtGYjJk=.c135ef9c-657a-4709-85ae-9ed034a40607@github.com>
Message-ID: <2shhHcuMVLZya39loXVKlVP8j-FNe6z7-Y4U0n-MNZM=.f099ddc1-8501-4f8f-ac6c-0b7b6e320e6e@github.com>

On Mon, 1 Feb 2021 10:38:30 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Hi,
> 
> may I please have reviews for this trivial fix.
> 
> We see timeouts with this test on slow large (memory wise) AIX machines, as well as large core files.
> 
> This test is a negative test which tests that the VM corectly recognizes an error condition and aborts. Code goes through jni_FatalError()->os::abort(), writes a core and aborts the process.
> 
> No parameters are given for that VM invocation, so heap size depends on machine size. On my Linux box, the generated core takes about 500m. On AIX we see cores of 16G and more.
> 
> The difference between AIX and other platforms is that AIX does not have the notion of "committing" memory (we have no MAP_NORESERVE flag), so all mmapped memory counts toward the commit charge from the moment it is mapped. That makes core files on AIX annoyingly large. I'd expect a similar behavior on other platforms with overcommit disabled.
> 
> The fix is to run the test without CreateCoredumpOnCrash. For good measure, I also reduced the heap size to 128m.
> 
> Thanks to @ArnoZeller for figuring that one out.
> 
> 
> -----
> Tests: manual jtreg tests, verifying that no cores are written.

Hi Thomas,
The fix looks good. Thank you fixing it.
I've submitted mach5 test job with 40 runs of the java/lang/instrument/PremainClass tests.
All are passed while they were failing before.
Also, David is right, the option -XX:-CreateCoreDumpOnCrash can be removed from tests:
 test/jdk/java/lang/instrument/PremainClass/NoPremainAgent.java
 test/jdk/java/lang/instrument/PremainClass/ZeroArgPremainAgent.java
 
 But I can file a separate bug on it.
 Also, I've closed bug https://bugs.openjdk.java.net/browse/JDK-8260469 as a dup of this one.
  
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

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

From vkempik at openjdk.java.net  Tue Feb  2 11:45:04 2021
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Tue, 2 Feb 2021 11:45:04 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v6]
In-Reply-To: <V6vVtDmtzcULcxWgKZUo4f-5MNuPgqEwIpcyQtovi4I=.c12c553b-dacd-4044-a412-8ebbdbef3514@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <PMUYint7pX2wmQ5wONMdgL7GclrxCnolwttyJC7BzTg=.ca680fa2-5b08-491f-9c1c-8253ffa2bbb4@github.com>
 <LCUqjT2-6eTqN1RVGbHJQY1XBzUNRWlwDOj-ZCXDGfI=.949076d9-4311-4e7d-a95f-e59ea8e3b5e1@github.com>
 <A2D8hAuv2S3R1jr0w8WpqNl-JfEDkT_ZpAMpYhBG-Ao=.95043299-5f1d-4198-b5aa-a9907f43fed2@github.com>
 <GrbBUs_4Yegb96adhYoJqJUus65ss52pcFqlYC89O_Y=.ae014145-08ba-46a0-8eb7-4c8109dfdea3@github.com>
 <-iXh6ikIWdG2YM4G3ZE33bE_bflntM9JZ0JWd1vSMKU=.7c380f16-0e1f-4fa8-8b47-f0e9e56fdba3@github.com>
 <1S0Z45oJKy8oesCN0k6SIHhZLzDYW9j-M_yfWZoHEzI=.2694c382-6613-4cd1-a917-16147bb00a9e@github.com>
 <V6vVtDmtzcULcxWgKZUo4f-5MNuPgqEwIpcyQtovi4I=.c12c553b-dacd-4044-a412-8ebbdbef3514@github.com>
Message-ID: <NOkBXyJL-tRfDUv6PbPhZ1uV9SB8IhfF712QYivtl1A=.aba04145-14d3-4e7a-95a9-ab3e8506d483@github.com>

On Mon, 1 Feb 2021 14:06:32 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>>> Hello, hsdis is a separate out-of-tree project and is not part of this jep.
>> 
>> Unless there's something I'm missing it only requires a few lines of change to src/utils/hsdis/makefile (it already has support for macos x86_64)
>> 
>>>support for looking for proper hsdis dylib library was added as part of this jep.
>> 
>> I'm a little confused. Are you planning on adding a new disassembler?
>
>> > Hello, hsdis is a separate out-of-tree project and is not part of this jep.
>> 
>> Unless there's something I'm missing it only requires a few lines of change to src/utils/hsdis/makefile (it already has support for macos x86_64)
> 
> I agree with Alan that it makes sense to add this trivial change as part of this PR, if it allows the current hsdis solution to continue working on mac/aarch64.
> 
>> 
>> > support for looking for proper hsdis dylib library was added as part of this jep.
>> 
>> I'm a little confused. Are you planning on adding a new disassembler?
> 
> @a74nh I think Vladimir is referring to https://github.com/openjdk/jdk/pull/392. The hsdis "component" has been left behind for a long time, and there are several requests to add new backends, which require a modernized build of hsdis. This is undfortunately not a high-priority project, and has been postponed several times already. :(

> > > Hello, hsdis is a separate out-of-tree project and is not part of this jep.
> > 
> > 
> > Unless there's something I'm missing it only requires a few lines of change to src/utils/hsdis/makefile (it already has support for macos x86_64)
> 
> I agree with Alan that it makes sense to add this trivial change as part of this PR, if it allows the current hsdis solution to continue working on mac/aarch64.
> 
> > > support for looking for proper hsdis dylib library was added as part of this jep.
> > 
> > 
> > I'm a little confused. Are you planning on adding a new disassembler?
> 
> @a74nh I think Vladimir is referring to #392. The hsdis "component" has been left behind for a long time, and there are several requests to add new backends, which require a modernized build of hsdis. This is undfortunately not a high-priority project, and has been postponed several times already. :(

Sorry I was under impression hsdis is not part of openjdk tree.

Alan, could you please share with us the version of binutils you were using in your test ?

Regards, Vladimir

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

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

From akozlov at openjdk.java.net  Tue Feb  2 11:59:08 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 2 Feb 2021 11:59:08 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
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: <aw_4oHl25elIZ1oM85G6EpWJqswUyBTZRW8qI4UIw44=.d92335ad-c72c-4044-9ca5-cdb046f43697@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:

  support macos_aarch64 in hsdis

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2200/files
  - new: https://git.openjdk.java.net/jdk/pull/2200/files/b421e0b4..3c705ae5

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

  Stats: 8 lines in 1 file changed: 6 ins; 0 del; 2 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  Tue Feb  2 11:59:09 2021
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Tue, 2 Feb 2021 11:59:09 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v6]
In-Reply-To: <NOkBXyJL-tRfDUv6PbPhZ1uV9SB8IhfF712QYivtl1A=.aba04145-14d3-4e7a-95a9-ab3e8506d483@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <PMUYint7pX2wmQ5wONMdgL7GclrxCnolwttyJC7BzTg=.ca680fa2-5b08-491f-9c1c-8253ffa2bbb4@github.com>
 <LCUqjT2-6eTqN1RVGbHJQY1XBzUNRWlwDOj-ZCXDGfI=.949076d9-4311-4e7d-a95f-e59ea8e3b5e1@github.com>
 <A2D8hAuv2S3R1jr0w8WpqNl-JfEDkT_ZpAMpYhBG-Ao=.95043299-5f1d-4198-b5aa-a9907f43fed2@github.com>
 <GrbBUs_4Yegb96adhYoJqJUus65ss52pcFqlYC89O_Y=.ae014145-08ba-46a0-8eb7-4c8109dfdea3@github.com>
 <-iXh6ikIWdG2YM4G3ZE33bE_bflntM9JZ0JWd1vSMKU=.7c380f16-0e1f-4fa8-8b47-f0e9e56fdba3@github.com>
 <1S0Z45oJKy8oesCN0k6SIHhZLzDYW9j-M_yfWZoHEzI=.2694c382-6613-4cd1-a917-16147bb00a9e@github.com>
 <V6vVtDmtzcULcxWgKZUo4f-5MNuPgqEwIpcyQtovi4I=.c12c553b-dacd-4044-a412-8ebbdbef3514@github.com>
 <NOkBXyJL-tRfDUv6PbPhZ1uV9SB8IhfF712QYivtl1A=.aba04145-14d3-4e7a-95a9-ab3e8506d483@github.com>
Message-ID: <s98Q5JbKi1ue0G2VxdgPC4ykZH33CBVHmJSaQxXKUXM=.c6ab28e3-8914-44a2-b3bb-3e73b9f6d478@github.com>

On Tue, 2 Feb 2021 11:14:12 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

> > > > Hello, hsdis is a separate out-of-tree project and is not part of this jep.
> > > 
> > > 
> > > Unless there's something I'm missing it only requires a few lines of change to src/utils/hsdis/makefile (it already has support for macos x86_64)
> > 
> > 
> > I agree with Alan that it makes sense to add this trivial change as part of this PR, if it allows the current hsdis solution to continue working on mac/aarch64.
> > > > support for looking for proper hsdis dylib library was added as part of this jep.
> > > 
> > > 
> > > I'm a little confused. Are you planning on adding a new disassembler?
> > 
> > 
> > @a74nh I think Vladimir is referring to #392. The hsdis "component" has been left behind for a long time, and there are several requests to add new backends, which require a modernized build of hsdis. This is undfortunately not a high-priority project, and has been postponed several times already. :(
> 
> Sorry I was under impression hsdis is not part of openjdk tree.
> 
> Alan, could you please share with us the version of binutils you were using in your test ?
> 
> Regards, Vladimir

I have updated PR with patch for hsdis, one thing to notice, LP64 is not defined for arm64 in Makefile

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

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

From stuefe at openjdk.java.net  Tue Feb  2 12:00:00 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 2 Feb 2021 12:00:00 GMT
Subject: RFR: JDK-8260707:
 java/lang/instrument/PremainClass/InheritAgent0100.java times out [v2]
In-Reply-To: <u_FpgUkMo0kSuyjiGVjOh9a4NvhxtfeRBZU5YtGYjJk=.c135ef9c-657a-4709-85ae-9ed034a40607@github.com>
References: <u_FpgUkMo0kSuyjiGVjOh9a4NvhxtfeRBZU5YtGYjJk=.c135ef9c-657a-4709-85ae-9ed034a40607@github.com>
Message-ID: <Y9JLbNkSDKHrzCYO0hqN92mbU9L8Xt6LjVS59PPULl8=.96e78c49-1527-4a96-a805-994cdb624547@github.com>

> Hi,
> 
> may I please have reviews for this trivial fix.
> 
> We see timeouts with this test on slow large (memory wise) AIX machines, as well as large core files.
> 
> This test is a negative test which tests that the VM corectly recognizes an error condition and aborts. Code goes through jni_FatalError()->os::abort(), writes a core and aborts the process.
> 
> No parameters are given for that VM invocation, so heap size depends on machine size. On my Linux box, the generated core takes about 500m. On AIX we see cores of 16G and more.
> 
> The difference between AIX and other platforms is that AIX does not have the notion of "committing" memory (we have no MAP_NORESERVE flag), so all mmapped memory counts toward the commit charge from the moment it is mapped. That makes core files on AIX annoyingly large. I'd expect a similar behavior on other platforms with overcommit disabled.
> 
> The fix is to run the test without CreateCoredumpOnCrash. For good measure, I also reduced the heap size to 128m.
> 
> Thanks to @ArnoZeller for figuring that one out.
> 
> 
> -----
> Tests: manual jtreg tests, verifying that no cores are written.

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

  Remove unnecessary CreateCoredumpOnCrash

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2332/files
  - new: https://git.openjdk.java.net/jdk/pull/2332/files/74697207..15cf3325

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

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

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

From stuefe at openjdk.java.net  Tue Feb  2 12:00:01 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 2 Feb 2021 12:00:01 GMT
Subject: RFR: JDK-8260707:
 java/lang/instrument/PremainClass/InheritAgent0100.java times out [v2]
In-Reply-To: <2shhHcuMVLZya39loXVKlVP8j-FNe6z7-Y4U0n-MNZM=.f099ddc1-8501-4f8f-ac6c-0b7b6e320e6e@github.com>
References: <u_FpgUkMo0kSuyjiGVjOh9a4NvhxtfeRBZU5YtGYjJk=.c135ef9c-657a-4709-85ae-9ed034a40607@github.com>
 <2shhHcuMVLZya39loXVKlVP8j-FNe6z7-Y4U0n-MNZM=.f099ddc1-8501-4f8f-ac6c-0b7b6e320e6e@github.com>
Message-ID: <l29oZrDSVILsKbK3eNMvFMMTKK2f2bjqCR10lKT8PaY=.c56f777f-5ff8-4d95-9d71-8773216136cf@github.com>

On Tue, 2 Feb 2021 11:20:30 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unnecessary CreateCoredumpOnCrash
>
> Hi Thomas,
> The fix looks good. Thank you fixing it.
> I've submitted mach5 test job with 40 runs of the java/lang/instrument/PremainClass tests.
> All are passed while they were failing before.
> Also, David is right, the option -XX:-CreateCoreDumpOnCrash can be removed from tests:
>  test/jdk/java/lang/instrument/PremainClass/NoPremainAgent.java
>  test/jdk/java/lang/instrument/PremainClass/ZeroArgPremainAgent.java
>  
>  But I can file a separate bug on it.
>  Also, I've closed bug https://bugs.openjdk.java.net/browse/JDK-8260469 as a dup of this one.
>   
> Thanks,
> Serguei

David, Serguei,

thanks for the reviews! I removed the superfluous options and re-ran the affected tests locally, all seemed fine. No cores popped up either. I will wait the 24hrs, then integrate.

Cheers, Thomas

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

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

From github.com+4146708+a74nh at openjdk.java.net  Tue Feb  2 12:17:47 2021
From: github.com+4146708+a74nh at openjdk.java.net (Alan Hayward)
Date: Tue, 2 Feb 2021 12:17:47 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v6]
In-Reply-To: <s98Q5JbKi1ue0G2VxdgPC4ykZH33CBVHmJSaQxXKUXM=.c6ab28e3-8914-44a2-b3bb-3e73b9f6d478@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <PMUYint7pX2wmQ5wONMdgL7GclrxCnolwttyJC7BzTg=.ca680fa2-5b08-491f-9c1c-8253ffa2bbb4@github.com>
 <LCUqjT2-6eTqN1RVGbHJQY1XBzUNRWlwDOj-ZCXDGfI=.949076d9-4311-4e7d-a95f-e59ea8e3b5e1@github.com>
 <A2D8hAuv2S3R1jr0w8WpqNl-JfEDkT_ZpAMpYhBG-Ao=.95043299-5f1d-4198-b5aa-a9907f43fed2@github.com>
 <GrbBUs_4Yegb96adhYoJqJUus65ss52pcFqlYC89O_Y=.ae014145-08ba-46a0-8eb7-4c8109dfdea3@github.com>
 <-iXh6ikIWdG2YM4G3ZE33bE_bflntM9JZ0JWd1vSMKU=.7c380f16-0e1f-4fa8-8b47-f0e9e56fdba3@github.com>
 <1S0Z45oJKy8oesCN0k6SIHhZLzDYW9j-M_yfWZoHEzI=.2694c382-6613-4cd1-a917-16147bb00a9e@github.com>
 <V6vVtDmtzcULcxWgKZUo4f-5MNuPgqEwIpcyQtovi4I=.c12c553b-dacd-4044-a412-8ebbdbef3514@github.com>
 <NOkBXyJL-tRfDUv6PbPhZ1uV9SB8IhfF712QYivtl1A=.aba04145-14d3-4e7a-95a9-ab3e8506d483@github.com>
 <s98Q5JbKi1ue0G2VxdgPC4ykZH33CBVHmJSaQxXKUXM=.c6ab28e3-8914-44a2-b3bb-3e73b9f6d478@github.com>
Message-ID: <vBuQJs9YZgZGw7AT9Fg3vf2RS9IwqDhZh1TtZE2PKIY=.b09cac1b-611c-4685-ba51-da9877ec7ff1@github.com>

On Tue, 2 Feb 2021 11:56:12 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

> > > > Hello, hsdis is a separate out-of-tree project and is not part of this jep.
> > > 
> > > 
> > > Unless there's something I'm missing it only requires a few lines of change to src/utils/hsdis/makefile (it already has support for macos x86_64)
> > 
> > 
> > I agree with Alan that it makes sense to add this trivial change as part of this PR, if it allows the current hsdis solution to continue working on mac/aarch64.
> > > > support for looking for proper hsdis dylib library was added as part of this jep.
> > > 
> > > 
> > > I'm a little confused. Are you planning on adding a new disassembler?
> > 
> > 
> > @a74nh I think Vladimir is referring to #392. The hsdis "component" has been left behind for a long time, and there are several requests to add new backends, which require a modernized build of hsdis. This is undfortunately not a high-priority project, and has been postponed several times already. :(
> 
> Sorry I was under impression hsdis is not part of openjdk tree.
> 
> Alan, could you please share with us the version of binutils you were using in your test ?
> 

I was just using the latest HEAD:
git clone git://sourceware.org/git/binutils-gdb.git src/utils/hsdis/build/binutils

A slightly safer approach would be to grab the latest release:
https://ftp.gnu.org/gnu/binutils/binutils-2.36.tar.gz


Once hsdis-demo was working for me, for only other oddity I had was that the library needed renaming when copying/linking into the build dir:    jdk/lib/server/libhsdis-aarch64.dylib

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

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

From dcubed at openjdk.java.net  Tue Feb  2 14:56:44 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 2 Feb 2021 14:56:44 GMT
Subject: RFR: JDK-8260707:
 java/lang/instrument/PremainClass/InheritAgent0100.java times out [v2]
In-Reply-To: <Y9JLbNkSDKHrzCYO0hqN92mbU9L8Xt6LjVS59PPULl8=.96e78c49-1527-4a96-a805-994cdb624547@github.com>
References: <u_FpgUkMo0kSuyjiGVjOh9a4NvhxtfeRBZU5YtGYjJk=.c135ef9c-657a-4709-85ae-9ed034a40607@github.com>
 <Y9JLbNkSDKHrzCYO0hqN92mbU9L8Xt6LjVS59PPULl8=.96e78c49-1527-4a96-a805-994cdb624547@github.com>
Message-ID: <u13KaNwkyXnSWqjcNY1D31gkTHeckBQhrBuOPGp9gto=.9560f602-bed6-410b-a988-d0222561bd85@github.com>

On Tue, 2 Feb 2021 12:00:00 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Hi,
>> 
>> may I please have reviews for this trivial fix.
>> 
>> We see timeouts with this test on slow large (memory wise) AIX machines, as well as large core files.
>> 
>> This test is a negative test which tests that the VM corectly recognizes an error condition and aborts. Code goes through jni_FatalError()->os::abort(), writes a core and aborts the process.
>> 
>> No parameters are given for that VM invocation, so heap size depends on machine size. On my Linux box, the generated core takes about 500m. On AIX we see cores of 16G and more.
>> 
>> The difference between AIX and other platforms is that AIX does not have the notion of "committing" memory (we have no MAP_NORESERVE flag), so all mmapped memory counts toward the commit charge from the moment it is mapped. That makes core files on AIX annoyingly large. I'd expect a similar behavior on other platforms with overcommit disabled.
>> 
>> The fix is to run the test without CreateCoredumpOnCrash. For good measure, I also reduced the heap size to 128m.
>> 
>> Thanks to @ArnoZeller for figuring that one out.
>> 
>> 
>> -----
>> Tests: manual jtreg tests, verifying that no cores are written.
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unnecessary CreateCoredumpOnCrash

Thumbs up! Thanks for taking care of this.

test/jdk/java/lang/instrument/NegativeAgentRunner.java line 39:

> 37:         String excepClassName = argv[1];
> 38:         ProcessBuilder pb = ProcessTools.createJavaProcessBuilder(
> 39:                 "-javaagent:" + agentClassName + ".jar", "-Xmx128m", "-XX:-CreateCoredumpOnCrash",

Thanks for also reducing the stack size.

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

Marked as reviewed by dcubed (Reviewer).

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

From dcubed at openjdk.java.net  Tue Feb  2 14:56:45 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 2 Feb 2021 14:56:45 GMT
Subject: RFR: JDK-8260707:
 java/lang/instrument/PremainClass/InheritAgent0100.java times out [v2]
In-Reply-To: <u13KaNwkyXnSWqjcNY1D31gkTHeckBQhrBuOPGp9gto=.9560f602-bed6-410b-a988-d0222561bd85@github.com>
References: <u_FpgUkMo0kSuyjiGVjOh9a4NvhxtfeRBZU5YtGYjJk=.c135ef9c-657a-4709-85ae-9ed034a40607@github.com>
 <Y9JLbNkSDKHrzCYO0hqN92mbU9L8Xt6LjVS59PPULl8=.96e78c49-1527-4a96-a805-994cdb624547@github.com>
 <u13KaNwkyXnSWqjcNY1D31gkTHeckBQhrBuOPGp9gto=.9560f602-bed6-410b-a988-d0222561bd85@github.com>
Message-ID: <OmFLCm9hEjcKuP-5Bsx1ZnXvUcGY7IyG4RXDwzWTeRU=.2e330709-80a4-454f-8911-6c9f82a7dc6c@github.com>

On Tue, 2 Feb 2021 14:52:50 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unnecessary CreateCoredumpOnCrash
>
> Thumbs up! Thanks for taking care of this.

I think this is a trivial fix and does not need to wait 24 hours.

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

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

From sspitsyn at openjdk.java.net  Tue Feb  2 17:39:43 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Tue, 2 Feb 2021 17:39:43 GMT
Subject: RFR: JDK-8260707:
 java/lang/instrument/PremainClass/InheritAgent0100.java times out [v2]
In-Reply-To: <Y9JLbNkSDKHrzCYO0hqN92mbU9L8Xt6LjVS59PPULl8=.96e78c49-1527-4a96-a805-994cdb624547@github.com>
References: <u_FpgUkMo0kSuyjiGVjOh9a4NvhxtfeRBZU5YtGYjJk=.c135ef9c-657a-4709-85ae-9ed034a40607@github.com>
 <Y9JLbNkSDKHrzCYO0hqN92mbU9L8Xt6LjVS59PPULl8=.96e78c49-1527-4a96-a805-994cdb624547@github.com>
Message-ID: <Q0KqN-9apV9ga3yO14MqFlqVP8lwXFPZDbYUEagF7vw=.5a64aadf-be2e-42f6-8130-cdb4486728c6@github.com>

On Tue, 2 Feb 2021 12:00:00 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Hi,
>> 
>> may I please have reviews for this trivial fix.
>> 
>> We see timeouts with this test on slow large (memory wise) AIX machines, as well as large core files.
>> 
>> This test is a negative test which tests that the VM corectly recognizes an error condition and aborts. Code goes through jni_FatalError()->os::abort(), writes a core and aborts the process.
>> 
>> No parameters are given for that VM invocation, so heap size depends on machine size. On my Linux box, the generated core takes about 500m. On AIX we see cores of 16G and more.
>> 
>> The difference between AIX and other platforms is that AIX does not have the notion of "committing" memory (we have no MAP_NORESERVE flag), so all mmapped memory counts toward the commit charge from the moment it is mapped. That makes core files on AIX annoyingly large. I'd expect a similar behavior on other platforms with overcommit disabled.
>> 
>> The fix is to run the test without CreateCoredumpOnCrash. For good measure, I also reduced the heap size to 128m.
>> 
>> Thanks to @ArnoZeller for figuring that one out.
>> 
>> 
>> -----
>> Tests: manual jtreg tests, verifying that no cores are written.
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unnecessary CreateCoredumpOnCrash

The update looks good.

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

Marked as reviewed by sspitsyn (Reviewer).

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

From stuefe at openjdk.java.net  Tue Feb  2 17:56:54 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 2 Feb 2021 17:56:54 GMT
Subject: RFR: JDK-8260926: Trace resource exhausted events unconditionally
Message-ID: <-LuicM5vRHrcchY00NJhTTgngnNKX3ZkbKZVM_pmHpE=.372c1b6a-120c-460d-a168-76f200408efd@github.com>

Analyzing out-of-resource situations in cloud scenarios is no fun. With CloudFoundry, a JVMTI agent (jvmkill) is hooked up intercepting the jvmti "resource exhausted" event, then attempts to write up a heap report. That may fail, e.g. due to bugs in the agent [1], but also because that report runs java code and may suffer from the same resource exhaustion. Successful or not, it unceremoniously kills the VM when done, often leaving us with no information about the actual resource.

It would be very helpful if we had unconditional tracing here. We do have tracing, but it requires a non-product build and is triggered with TraceJVMTI. Also, it traces at trace level which is way to fine granular.

I'd like to introduce another, unconditional trace line here. Arguably, resource exhausted is fatal enough that it justifies unconditional tracing.

This is a bit of a coin toss. Tracing unconditionally would help in most scenarios, where it would be either difficult or even impossible to specify a trace command line switch. OTOH it may trip up scripts parsing the VM output, or some of our tests (which can be fixed).

Thoughts?

..Thomas

[1] https://github.com/cloudfoundry/jvmkill/issues/18

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

Commit messages:
 - Add trace

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

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

From stuefe at openjdk.java.net  Tue Feb  2 17:59:42 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 2 Feb 2021 17:59:42 GMT
Subject: RFR: JDK-8260707:
 java/lang/instrument/PremainClass/InheritAgent0100.java times out [v2]
In-Reply-To: <Q0KqN-9apV9ga3yO14MqFlqVP8lwXFPZDbYUEagF7vw=.5a64aadf-be2e-42f6-8130-cdb4486728c6@github.com>
References: <u_FpgUkMo0kSuyjiGVjOh9a4NvhxtfeRBZU5YtGYjJk=.c135ef9c-657a-4709-85ae-9ed034a40607@github.com>
 <Y9JLbNkSDKHrzCYO0hqN92mbU9L8Xt6LjVS59PPULl8=.96e78c49-1527-4a96-a805-994cdb624547@github.com>
 <Q0KqN-9apV9ga3yO14MqFlqVP8lwXFPZDbYUEagF7vw=.5a64aadf-be2e-42f6-8130-cdb4486728c6@github.com>
Message-ID: <jkRxPY_nl4twQjBKwQxXvqu1Pqo5KO_nsccwyhQdPpw=.3f70db37-b227-4147-a9e4-41de504cb069@github.com>

On Tue, 2 Feb 2021 17:36:32 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unnecessary CreateCoredumpOnCrash
>
> The update looks good.

> I think this is a trivial fix and does not need to wait 24 hours.

Thanks!

> The update looks good.

Thanks!

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

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

From stuefe at openjdk.java.net  Tue Feb  2 17:59:43 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 2 Feb 2021 17:59:43 GMT
Subject: Integrated: JDK-8260707:
 java/lang/instrument/PremainClass/InheritAgent0100.java times out
In-Reply-To: <u_FpgUkMo0kSuyjiGVjOh9a4NvhxtfeRBZU5YtGYjJk=.c135ef9c-657a-4709-85ae-9ed034a40607@github.com>
References: <u_FpgUkMo0kSuyjiGVjOh9a4NvhxtfeRBZU5YtGYjJk=.c135ef9c-657a-4709-85ae-9ed034a40607@github.com>
Message-ID: <Udl1-ItmnJM1XdZ0DvChKoBAP2DtE2-YPZPykOJtKtg=.c8113722-bafc-42fe-9b8b-67ee4345be4e@github.com>

On Mon, 1 Feb 2021 10:38:30 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Hi,
> 
> may I please have reviews for this trivial fix.
> 
> We see timeouts with this test on slow large (memory wise) AIX machines, as well as large core files.
> 
> This test is a negative test which tests that the VM corectly recognizes an error condition and aborts. Code goes through jni_FatalError()->os::abort(), writes a core and aborts the process.
> 
> No parameters are given for that VM invocation, so heap size depends on machine size. On my Linux box, the generated core takes about 500m. On AIX we see cores of 16G and more.
> 
> The difference between AIX and other platforms is that AIX does not have the notion of "committing" memory (we have no MAP_NORESERVE flag), so all mmapped memory counts toward the commit charge from the moment it is mapped. That makes core files on AIX annoyingly large. I'd expect a similar behavior on other platforms with overcommit disabled.
> 
> The fix is to run the test without CreateCoredumpOnCrash. For good measure, I also reduced the heap size to 128m.
> 
> Thanks to @ArnoZeller for figuring that one out.
> 
> 
> -----
> Tests: manual jtreg tests, verifying that no cores are written.

This pull request has now been integrated.

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

8260707: java/lang/instrument/PremainClass/InheritAgent0100.java times out

Co-authored-by: Arno Zeller <azeller at openjdk.org>
Reviewed-by: dholmes, sspitsyn, dcubed

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

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

From gziemski at openjdk.java.net  Tue Feb  2 18:55:48 2021
From: gziemski at openjdk.java.net (Gerard Ziemski)
Date: Tue, 2 Feb 2021 18:55:48 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
In-Reply-To: <aw_4oHl25elIZ1oM85G6EpWJqswUyBTZRW8qI4UIw44=.d92335ad-c72c-4044-9ca5-cdb046f43697@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <aw_4oHl25elIZ1oM85G6EpWJqswUyBTZRW8qI4UIw44=.d92335ad-c72c-4044-9ca5-cdb046f43697@github.com>
Message-ID: <MlC0k95KyLxJCu7ZSluQlSdVrGTPolMjYG_rX3lpebU=.9ccf1fac-6fec-4479-80d7-9ee89d3bbb54@github.com>

On Tue, 2 Feb 2021 11:59:08 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:
> 
>   support macos_aarch64 in hsdis

Changes requested by gziemski (Committer).

src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp line 390:

> 388:       store_and_inc(_to, from_obj, NativeStack::intSpace);
> 389: 
> 390:       _num_int_args++;

`pass_byte()` and  `pass_short()` use only one `_num_int_args++;` after the `if else` but other methods use 2 of them inside `if else` branches.

We should be consistent.

src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp line 404:

> 402:     } else {
> 403:       store_and_inc(_to, from_obj, NativeStack::longSpace);
> 404:       _num_int_args++;

`pass_byte()` and  `pass_short()` use only one `_num_int_args++;` after the `if else` but other methods use it 2 of them inside `if else`

We should be consistent.

src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp line 418:

> 416:     } else {
> 417:       store_and_inc(_to, (*from_addr == 0) ? (intptr_t)NULL : (intptr_t) from_addr, wordSize);
> 418:       _num_int_args++;

`pass_byte()` and  `pass_short()` use only one `_num_int_args++;` after the `if else` but other methods use it 2 of them inside `if else`

We should be consistent.

src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp line 433:

> 431:       store_and_inc(_to, from_obj, NativeStack::floatSpace);
> 432: 
> 433:       _num_fp_args++;

`pass_byte()` and  `pass_short()` use only one `_num_int_args++;` after the `if else` but other methods use it 2 of them inside `if else`

We should be consistent.

src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp line 448:

> 446:     } else {
> 447:       store_and_inc(_to, from_obj, NativeStack::doubleSpace);
> 448:       _num_fp_args++;

`pass_byte()` and  `pass_short()` use only one `_num_int_args++;` after the `if else` but other methods use it 2 of them inside `if else`

We should be consistent.

src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5271:

> 5269: //
> 5270: void MacroAssembler::get_thread(Register dst) {
> 5271:   RegSet saved_regs = RegSet::range(r0, r1) + BSD_ONLY(RegSet::range(r2, r17)) + lr - dst;

The comment needs to be updated, since on BSD we also seem to clobber r2,r17 ?

src/hotspot/os/posix/signals_posix.cpp line 1297:

> 1295:   kern_return_t kr;
> 1296:   kr = task_set_exception_ports(mach_task_self(),
> 1297:                                 EXC_MASK_BAD_ACCESS | EXC_MASK_BAD_INSTRUCTION | EXC_MASK_ARITHMETIC,

Could someone elaborate on why we need to add `EXC_MASK_BAD_INSTRUCTION` to the mask here?

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?

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

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

From gziemski at openjdk.java.net  Tue Feb  2 19:00:56 2021
From: gziemski at openjdk.java.net (Gerard Ziemski)
Date: Tue, 2 Feb 2021 19:00:56 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
In-Reply-To: <MlC0k95KyLxJCu7ZSluQlSdVrGTPolMjYG_rX3lpebU=.9ccf1fac-6fec-4479-80d7-9ee89d3bbb54@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>
Message-ID: <nk4oFkB0qkwb4FfV7xw3HIGzRMMjzHF3aBibM5d_yQk=.8a333ebe-43f6-4b8e-ad40-af6e5f24fc7a@github.com>

On Tue, 2 Feb 2021 18:52:29 GMT, Gerard Ziemski <gziemski 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
>
> Changes requested by gziemski (Committer).

There were bunch of assembly code that I couldn't review. I also shallow reviewed the brand new files that were copies of the existing BSD x86_64 files - I hope I can get back to those when I figure out how to build/run these changes.

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

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

From burban at openjdk.java.net  Tue Feb  2 19:25:49 2021
From: burban at openjdk.java.net (Bernhard Urban-Forster)
Date: Tue, 2 Feb 2021 19:25:49 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
In-Reply-To: <MlC0k95KyLxJCu7ZSluQlSdVrGTPolMjYG_rX3lpebU=.9ccf1fac-6fec-4479-80d7-9ee89d3bbb54@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>
Message-ID: <gdmSyDFlKNJfjwP2R9NL99cuUnJvVlNAVSuTGXX1aGI=.5ae84a36-aaf7-44d5-968f-594d09c71683@github.com>

On Tue, 2 Feb 2021 18:23:04 GMT, Gerard Ziemski <gziemski 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/posix/signals_posix.cpp line 1297:
> 
>> 1295:   kern_return_t kr;
>> 1296:   kr = task_set_exception_ports(mach_task_self(),
>> 1297:                                 EXC_MASK_BAD_ACCESS | EXC_MASK_BAD_INSTRUCTION | EXC_MASK_ARITHMETIC,
> 
> Could someone elaborate on why we need to add `EXC_MASK_BAD_INSTRUCTION` to the mask here?

See comment above about `gdb`, the same applies to `lldb` today. The AArch64 backend uses `SIGILL` (~= `EXC_MASK_BAD_INSTRUCTION`) to initiate a deoptimization. Without this change you cannot continue debugging once you the debuggee receives `SIGILL`. This wasn't needed before as x86 doesn't use `SIGILL`.

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

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

From cjplummer at openjdk.java.net  Tue Feb  2 19:51:50 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 2 Feb 2021 19:51:50 GMT
Subject: RFR: 8247514: Improve clhsdb 'findpc' ability to determine what
 an address points to by improving PointerFinder and PointerLocation classes
In-Reply-To: <GVBd94FVWLPPpJ13q7169cdRWKNmAyYFWidkvYCbRKs=.72809310-0eb6-4cc1-a24d-c5b7cd78a324@github.com>
References: <4YKNpyXQ9QGrLhR61tkh71Q3A7VvCj5Ete_4OvzAA-o=.28b7be8c-6f05-42d4-892b-87ebea907b24@github.com>
 <GVBd94FVWLPPpJ13q7169cdRWKNmAyYFWidkvYCbRKs=.72809310-0eb6-4cc1-a24d-c5b7cd78a324@github.com>
Message-ID: <p7pqIzbdv_NYUd0XsWCmGQdfNK0E13w5rl7IopT1wyw=.8697b99e-477b-4b98-8122-e6c2b52d3d5f@github.com>

On Mon, 25 Jan 2021 20:00:41 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> See the bug for most details. A few notes here about some implementation details:
>> 
>> In the `PointerLocation` class, I added more consistency w.r.t. whether or not a newline is printed. It used to for some address types, but not others. Now it always does. And if you see a comment something like the following:
>> 
>> `         getTLAB().printOn(tty); // includes "\n" `
>> 
>> That's just clarifying whether or not the `printOn()` method called will include the newline. Some do and some don't, and knowing what the various `printOn()` methods do makes getting the proper inclusion of the newline easier to understand.
>> 
>> I added `verbose` and `printAddress` boolean arguments to `PointerLocation.printOn()`. Currently they are always `true`. The false arguments will be used when I complete [JDK-8250801](https://bugs.openjdk.java.net/browse/JDK-8250801), which will use `PointerFinder/Location` to show what each register points to.
>> 
>> The CR mentions that the main motivation for this work is for eventual replacement of the old clhsdb `whatis` command, which was implemented in javascript. It used to resolve DSO symbols, whereas `findpc` did not. The `whatis` code did this with the following:
>> 
>>   var dso = loadObjectContainingPC(addr);
>>   if (dso == null) {
>>     return ptrLoc.toString();
>>   }
>>   var sym = dso.closestSymbolToPC(addr);
>>   if (sym != null) {
>>     return sym.name + '+' + sym.offset;
>>   }
>> And now you'll see something similar in the PointerFinder code:
>> 
>>         loc.loadObject = cdbg.loadObjectContainingPC(a);
>>         if (loc.loadObject != null) {
>>             loc.nativeSymbol = loc.loadObject.closestSymbolToPC(a);
>>             return loc;
>>         } 
>> Note that now that `findpc` does everything that `whatis` used to (and more), we don't really need to add a java version of `whatis`, but I'll probably do so anyway just help out people who are used to using the `whatis` command. That will be done using [JDK-8244670](https://bugs.openjdk.java.net/browse/JDK-8244670)
>
> Ping!

Ping again.

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

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

From cjplummer at openjdk.java.net  Tue Feb  2 20:15:42 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 2 Feb 2021 20:15:42 GMT
Subject: RFR: 8260431: com/sun/jdi/JdbOptions.java failed with
 "RuntimeException: 'prop[boo] = >foo<' missing from stdout/stderr"
In-Reply-To: <yJAqWSrjL-E2p_2vZUEcmwznaodNn-KsbGOntHWwkZs=.5ac1e125-8932-4c09-b3a6-d7838b28e5dd@github.com>
References: <yJAqWSrjL-E2p_2vZUEcmwznaodNn-KsbGOntHWwkZs=.5ac1e125-8932-4c09-b3a6-d7838b28e5dd@github.com>
Message-ID: <MmNcVz3yoIPrcWtyQItjE-STuYnzQNDsX6G1DBmYtWU=.6ceb9d53-bcc5-429c-b81e-b8dd4308922f@github.com>

On Sat, 30 Jan 2021 00:15:04 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The test expects debuggee output in jdb output stream.
> But jdb redirects debuggee output asynchronously so sometimes it's incomplete or mixed with jdb output.
> The fix updates debuggee to print output to file and read/analyze it after jdb (and debuggee) exits.

test/jdk/com/sun/jdi/JdbOptions.java line 85:

> 83:     private static final String outFilename = UUID.randomUUID().toString() + ".out";
> 84:     private static final Path outPath = Paths.get(outFilename);
> 85:     private static final String targ = JbdOptionsTarg.class.getName() + " " + outFilename;

Is there a reason you added `outFilename` to `targ` rather than just add `outFilename` when you pass the argument string to `test()`.

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

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

From amenkov at openjdk.java.net  Tue Feb  2 20:36:41 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Tue, 2 Feb 2021 20:36:41 GMT
Subject: RFR: 8260878: com/sun/jdi/JdbOptions.java fails without jfr
In-Reply-To: <_bj2OMujuHAe-AL9MexB2gZfaCBa0FIae5lAuoXHk28=.84c23328-3a24-4bbe-9a08-28cd10f740c9@github.com>
References: <URFTQH96EQ_wHpBLl2UWDuYj5cXEWt1dMpU6uui2Pcw=.889d9f0d-4ba1-4c71-8d4d-0d8a99e53a2b@github.com>
 <l2u80ptM9JZNOIKXZSWUgTMm9yym9NRsPr6_WNxGoIw=.fe001962-1e20-4cd5-82c0-e91db4f98c6a@github.com>
 <_bj2OMujuHAe-AL9MexB2gZfaCBa0FIae5lAuoXHk28=.84c23328-3a24-4bbe-9a08-28cd10f740c9@github.com>
Message-ID: <iRWUiRax89b6_5VKRoIj4Fi0wcZ2YqeAvDe3cR2EJII=.7db0f1c6-49bc-44e3-9745-a4e892cfaa97@github.com>

On Tue, 2 Feb 2021 04:17:39 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> test/jdk/com/sun/jdi/JdbOptions.java line 99:
>> 
>>> 97:         test("-connect",
>>> 98:                 "com.sun.jdi.CommandLineLaunch:vmexec=java,options=\"-client\" \"-XX:+PrintVMOptions\""
>>> 99:                 + " -XX:+IgnoreUnrecognizedVMOptions"
>> 
>> You need to be careful when using `-xx:+IgnoreUnrecognizedVMOptions`, because it can result in not detecting typos in the option names, which could happen with this test in the future if any other mods are made. Other options here are to skip this part of the test if JFR is not present, or better yet don't make the test rely on JFR. I don't think there is a reason that it needs to. It seems other options could have been used for the testing. Perhaps @alexmenkov can comment on why it was done this way.
>
> Thanks @plummercj for your review.
> 
> Let's wait for @alexmenkov 's comments.
> Thanks.

Special handling for options with commas, quotes and single quotes was added many years ago for JFR (as it uses commas inside). The logic there is a bit tricky and I didn't want to brake existing functionality when I made some changes there, so I used "live" examples of JRF options in the test.
I don't know other VM options which use commas inside.

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

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

From cjplummer at openjdk.java.net  Tue Feb  2 20:47:43 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 2 Feb 2021 20:47:43 GMT
Subject: RFR: 8257988: Remove JNF dependency from
 libsaproc/MacosxDebuggerLocal.m
In-Reply-To: <cUes5jnPfmVPzfl9a6CeLDL3m34aLsa1oIoetgnANzI=.d9440b4c-9c8e-48f8-b573-6cb5c35242d7@github.com>
References: <cUes5jnPfmVPzfl9a6CeLDL3m34aLsa1oIoetgnANzI=.d9440b4c-9c8e-48f8-b573-6cb5c35242d7@github.com>
Message-ID: <F9DwpPI9FudOqRU7VmGGnD_YajHiw_QN1n4Sy5WDOgQ=.ea3e8531-d345-45c0-9372-2f8cec9a2763@github.com>

On Thu, 28 Jan 2021 22:40:57 GMT, Phil Race <prr at openjdk.org> wrote:

> This removes the JNF dependency from the jdk.hotspot.agent module.
> The macro expansions are the same as already used in the Java desktop module - which actually uses a macro
> still but there there are hundreds of uses.
> The function of this macro code is to prevent NSExceptions escaping to Java and also to drain the auto-release pool.
> What test group would be good for verifying this change ?

src/jdk.hotspot.agent/macosx/native/libsaproc/MacosxDebuggerLocal.m line 294:

> 292: 
> 293:   NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
> 294:   @try {

Although there are only 3 places where the `JNF_COCOA_ENTER/EXIT` macros are used, it seems it would still be worth taking the same approach you did for `java.desktop` and add the replacement macros instead of inlining them. So just copy what you added to `src/java.desktop/macosx/native/libosxapp/JNIUtilities.h`, and replace `JNF_COCOA_ENTER` with `JNI_COCOA_ENTER/EXIT`. Otherwise the `JNF_COCOA_ENTER/EXIT` changes look fine to me, but I'm just basing this on a comparison with what you've done with `java.desktop`. I'm no expert in this area.

src/jdk.hotspot.agent/macosx/native/libsaproc/MacosxDebuggerLocal.m line 296:

> 294:   @try {
> 295: 
> 296:   NSString *symbolNameString = JavaStringToNSString(env, symbolName);

Is there a reason why `java.desktop` continues to use `JNFJavaToNSString`? I was looking to see how this was handled in other places, but I couldn't find an example where `JNFJavaToNSString` was converted to call a newly implemented `JavaStringToNSString`.

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

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

From amenkov at openjdk.java.net  Tue Feb  2 20:48:41 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Tue, 2 Feb 2021 20:48:41 GMT
Subject: RFR: 8260878: com/sun/jdi/JdbOptions.java fails without jfr
In-Reply-To: <URFTQH96EQ_wHpBLl2UWDuYj5cXEWt1dMpU6uui2Pcw=.889d9f0d-4ba1-4c71-8d4d-0d8a99e53a2b@github.com>
References: <URFTQH96EQ_wHpBLl2UWDuYj5cXEWt1dMpU6uui2Pcw=.889d9f0d-4ba1-4c71-8d4d-0d8a99e53a2b@github.com>
Message-ID: <D5-Cf_XhhvxhOmEiTsln-Y7fUlrp9FypO1f9-CfB8TA=.6efe3144-498b-4b66-bcf0-c7478f298113@github.com>

On Tue, 2 Feb 2021 03:43:29 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> com/sun/jdi/JdbOptions.java fails in our ci/cd when jfr is disabled.
> It would be better to fix it.
> 
> Thanks.
> Best regards,
> Jie

Marked as reviewed by amenkov (Reviewer).

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

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

From amenkov at openjdk.java.net  Tue Feb  2 20:48:42 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Tue, 2 Feb 2021 20:48:42 GMT
Subject: RFR: 8260878: com/sun/jdi/JdbOptions.java fails without jfr
In-Reply-To: <iRWUiRax89b6_5VKRoIj4Fi0wcZ2YqeAvDe3cR2EJII=.7db0f1c6-49bc-44e3-9745-a4e892cfaa97@github.com>
References: <URFTQH96EQ_wHpBLl2UWDuYj5cXEWt1dMpU6uui2Pcw=.889d9f0d-4ba1-4c71-8d4d-0d8a99e53a2b@github.com>
 <l2u80ptM9JZNOIKXZSWUgTMm9yym9NRsPr6_WNxGoIw=.fe001962-1e20-4cd5-82c0-e91db4f98c6a@github.com>
 <_bj2OMujuHAe-AL9MexB2gZfaCBa0FIae5lAuoXHk28=.84c23328-3a24-4bbe-9a08-28cd10f740c9@github.com>
 <iRWUiRax89b6_5VKRoIj4Fi0wcZ2YqeAvDe3cR2EJII=.7db0f1c6-49bc-44e3-9745-a4e892cfaa97@github.com>
Message-ID: <6C8vEbcGLYzpng8n1t2jPXp7kCkBjhoIpVr-8zF0uzs=.bbab7d85-d34a-4439-bce8-f090fe0b612c@github.com>

On Tue, 2 Feb 2021 20:34:14 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Thanks @plummercj for your review.
>> 
>> Let's wait for @alexmenkov 's comments.
>> Thanks.
>
> Special handling for options with commas, quotes and single quotes was added many years ago for JFR (as it uses commas inside). The logic there is a bit tricky and I didn't want to brake existing functionality when I made some changes there, so I used "live" examples of JRF options in the test.
> I don't know other VM options which use commas inside.

As the test verifies correct parsing of "options", I think it's ok to use IgnoreUnrecognizedVMOptions here

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

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

From cjplummer at openjdk.java.net  Tue Feb  2 20:48:43 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 2 Feb 2021 20:48:43 GMT
Subject: RFR: 8260878: com/sun/jdi/JdbOptions.java fails without jfr
In-Reply-To: <6C8vEbcGLYzpng8n1t2jPXp7kCkBjhoIpVr-8zF0uzs=.bbab7d85-d34a-4439-bce8-f090fe0b612c@github.com>
References: <URFTQH96EQ_wHpBLl2UWDuYj5cXEWt1dMpU6uui2Pcw=.889d9f0d-4ba1-4c71-8d4d-0d8a99e53a2b@github.com>
 <l2u80ptM9JZNOIKXZSWUgTMm9yym9NRsPr6_WNxGoIw=.fe001962-1e20-4cd5-82c0-e91db4f98c6a@github.com>
 <_bj2OMujuHAe-AL9MexB2gZfaCBa0FIae5lAuoXHk28=.84c23328-3a24-4bbe-9a08-28cd10f740c9@github.com>
 <iRWUiRax89b6_5VKRoIj4Fi0wcZ2YqeAvDe3cR2EJII=.7db0f1c6-49bc-44e3-9745-a4e892cfaa97@github.com>
 <6C8vEbcGLYzpng8n1t2jPXp7kCkBjhoIpVr-8zF0uzs=.bbab7d85-d34a-4439-bce8-f090fe0b612c@github.com>
Message-ID: <imgj4V8_Tf0mM0O45wfgIr95WpMKoqsQRrdXH94ygl0=.34826314-6138-468a-916e-63aa6f9f339d@github.com>

On Tue, 2 Feb 2021 20:45:37 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Special handling for options with commas, quotes and single quotes was added many years ago for JFR (as it uses commas inside). The logic there is a bit tricky and I didn't want to brake existing functionality when I made some changes there, so I used "live" examples of JRF options in the test.
>> I don't know other VM options which use commas inside.
>
> As the test verifies correct parsing of "options", I think it's ok to use IgnoreUnrecognizedVMOptions here

ok

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

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

From cjplummer at openjdk.java.net  Tue Feb  2 20:53:46 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 2 Feb 2021 20:53:46 GMT
Subject: RFR: 8260878: com/sun/jdi/JdbOptions.java fails without jfr
In-Reply-To: <URFTQH96EQ_wHpBLl2UWDuYj5cXEWt1dMpU6uui2Pcw=.889d9f0d-4ba1-4c71-8d4d-0d8a99e53a2b@github.com>
References: <URFTQH96EQ_wHpBLl2UWDuYj5cXEWt1dMpU6uui2Pcw=.889d9f0d-4ba1-4c71-8d4d-0d8a99e53a2b@github.com>
Message-ID: <9uvrcMppf4iBopBGyZub29I9xepA2vtjdfvkl_-ly_4=.ffff0fae-a8af-4350-bad5-45e58b069a72@github.com>

On Tue, 2 Feb 2021 03:43:29 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> com/sun/jdi/JdbOptions.java fails in our ci/cd when jfr is disabled.
> It would be better to fix it.
> 
> Thanks.
> Best regards,
> Jie

Marked as reviewed by cjplummer (Reviewer).

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

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

From amenkov at openjdk.java.net  Tue Feb  2 21:06:43 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Tue, 2 Feb 2021 21:06:43 GMT
Subject: RFR: 8260431: com/sun/jdi/JdbOptions.java failed with
 "RuntimeException: 'prop[boo] = >foo<' missing from stdout/stderr"
In-Reply-To: <MmNcVz3yoIPrcWtyQItjE-STuYnzQNDsX6G1DBmYtWU=.6ceb9d53-bcc5-429c-b81e-b8dd4308922f@github.com>
References: <yJAqWSrjL-E2p_2vZUEcmwznaodNn-KsbGOntHWwkZs=.5ac1e125-8932-4c09-b3a6-d7838b28e5dd@github.com>
 <MmNcVz3yoIPrcWtyQItjE-STuYnzQNDsX6G1DBmYtWU=.6ceb9d53-bcc5-429c-b81e-b8dd4308922f@github.com>
Message-ID: <cIFbsrpmdTpR6_kv6u67_JjUOH9nG9pAznrenWJxG1s=.a4e14271-fc06-4677-8f7e-15c21dd18114@github.com>

On Tue, 2 Feb 2021 20:12:27 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> The test expects debuggee output in jdb output stream.
>> But jdb redirects debuggee output asynchronously so sometimes it's incomplete or mixed with jdb output.
>> The fix updates debuggee to print output to file and read/analyze it after jdb (and debuggee) exits.
>
> test/jdk/com/sun/jdi/JdbOptions.java line 85:
> 
>> 83:     private static final String outFilename = UUID.randomUUID().toString() + ".out";
>> 84:     private static final Path outPath = Paths.get(outFilename);
>> 85:     private static final String targ = JbdOptionsTarg.class.getName() + " " + outFilename;
> 
> Is there a reason you added `outFilename` to `targ` rather than just add `outFilename` when you pass the argument string to `test()`.

Just to minimize the changes as outFilename is required argument for target app.

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

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

From cjplummer at openjdk.java.net  Tue Feb  2 21:42:39 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 2 Feb 2021 21:42:39 GMT
Subject: RFR: 8260431: com/sun/jdi/JdbOptions.java failed with
 "RuntimeException: 'prop[boo] = >foo<' missing from stdout/stderr"
In-Reply-To: <cIFbsrpmdTpR6_kv6u67_JjUOH9nG9pAznrenWJxG1s=.a4e14271-fc06-4677-8f7e-15c21dd18114@github.com>
References: <yJAqWSrjL-E2p_2vZUEcmwznaodNn-KsbGOntHWwkZs=.5ac1e125-8932-4c09-b3a6-d7838b28e5dd@github.com>
 <MmNcVz3yoIPrcWtyQItjE-STuYnzQNDsX6G1DBmYtWU=.6ceb9d53-bcc5-429c-b81e-b8dd4308922f@github.com>
 <cIFbsrpmdTpR6_kv6u67_JjUOH9nG9pAznrenWJxG1s=.a4e14271-fc06-4677-8f7e-15c21dd18114@github.com>
Message-ID: <-s8bPhnvXZp8ZxWWpCpgw4mqQ3oLJ3jDvczQkQIx3eE=.1d4721b5-2343-4f19-a073-6f7de635d71d@github.com>

On Tue, 2 Feb 2021 20:43:29 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> test/jdk/com/sun/jdi/JdbOptions.java line 85:
>> 
>>> 83:     private static final String outFilename = UUID.randomUUID().toString() + ".out";
>>> 84:     private static final Path outPath = Paths.get(outFilename);
>>> 85:     private static final String targ = JbdOptionsTarg.class.getName() + " " + outFilename;
>> 
>> Is there a reason you added `outFilename` to `targ` rather than just add `outFilename` when you pass the argument string to `test()`.
>
> Just to minimize the changes as outFilename is required argument for target app.

I think `targ` is typically the classfile name of the target debuggee, so I think it would be best to keep the output filename separate from it to avoid confusion.

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

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

From dcubed at openjdk.java.net  Tue Feb  2 23:13:00 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 2 Feb 2021 23:13:00 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
In-Reply-To: <aw_4oHl25elIZ1oM85G6EpWJqswUyBTZRW8qI4UIw44=.d92335ad-c72c-4044-9ca5-cdb046f43697@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <aw_4oHl25elIZ1oM85G6EpWJqswUyBTZRW8qI4UIw44=.d92335ad-c72c-4044-9ca5-cdb046f43697@github.com>
Message-ID: <RPm5SnkwuGvrhCQxjnsSrdYPjnD4davqtqvkqYKE-tU=.3d4e4c80-0b71-489e-8ba0-2c4a6668e9c4@github.com>

On Tue, 2 Feb 2021 11:59:08 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:
> 
>   support macos_aarch64 in hsdis

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.

make/autoconf/flags.m4 line 140:

> 138:     else
> 139:       MACOSX_VERSION_MIN=10.12.0
> 140:     fi

Not something that needs to be addressed here, but these changes
illustrate that our collective use of macOSX/MACOSX/MacOSX names
are tied to the fact that the macOS major version number was at 10
for a very long time.

@magicus - Do we have an RFE to rename MACOSX or are we sticking
with it and evolving our interpretation of the 'X' from '10' to */splat/asterik?

make/common/NativeCompilation.gmk line 1178:

> 1176:                 endif
> 1177:                 # This only works if the openjdk_codesign identity is present on the system. Let
> 1178:                 # silently fail otherwise.

Might want to add a comment here:
    #  The '-f' option will replace an existing signature if one exists.

src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp line 41:

> 39: #define __ _masm->
> 40: 
> 41: //describe amount of space in bytes occupied by type on native stack

nit - needs a space after `//`

src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp line 83:

> 81: // On macos/aarch64 native stack is packed, int/float are using only 4 bytes
> 82: // on stack. Natural alignment for types are still in place,
> 83: // for example double/long should be 8 bytes alligned

nit typo: s/alligned/aligned/
And sentence should end with a period.

src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 323:

> 321:   str(zr, Address(rthread, JavaThread::last_Java_pc_offset()));
> 322: 
> 323:   str(zr, Address(rthread, JavaFrameAnchor::saved_fp_address_offset()));

I don't think this switch from `JavaThread::saved_fp_address_offset()`
to `JavaFrameAnchor::saved_fp_address_offset()` is correct since
`rthread` is still used and is a JavaThread*. The new code will give you:

    `rthread` + offset of the `saved_fp_address` field in a JavaFrameAnchor

The old code gave you:

    `rthread` + offset of the `saved_fp_address` field in the JavaFrameAnchor field in the JavaThread

Those are not the same things.

src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp line 31:

> 29: #include "asm/assembler.inline.hpp"
> 30: #include "oops/compressedOops.hpp"
> 31: #include "runtime/vm_version.hpp"

It's not clear why this include needed to be added.

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.

src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 837:

> 835: #ifdef __APPLE__
> 836:           // Less-than word types are stored one after another.
> 837:           // The code unable to handle this, bailout.

Perhaps: // The code is unable to handle this so bailout.

src/hotspot/os/aix/os_aix.cpp line 69:

> 67: #include "runtime/sharedRuntime.hpp"
> 68: #include "runtime/statSampler.hpp"
> 69: #include "runtime/stubRoutines.inline.hpp"

It is not clear why this include to inline-include change was made.

src/hotspot/os/linux/gc/z/zPhysicalMemoryBacking_linux.cpp line 37:

> 35: #include "runtime/init.hpp"
> 36: #include "runtime/os.hpp"
> 37: #include "runtime/stubRoutines.inline.hpp"

It is not clear why this include to inline-include change was made.

src/hotspot/os/windows/os_windows.cpp line 65:

> 63: #include "runtime/sharedRuntime.hpp"
> 64: #include "runtime/statSampler.hpp"
> 65: #include "runtime/stubRoutines.inline.hpp"

It is not clear why this include to inline-include change was made.

src/hotspot/os_cpu/bsd_aarch64/atomic_bsd_aarch64.hpp line 59:

> 57: }
> 58: 
> 59: // __attribute__((unused)) on dest is to get rid of spurious GCC warnings.

Is the GCC comment appropriate? Does this file get built
with GCC or just Apple compilers?

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

> 90: # define DEFAULT_MAIN_THREAD_STACK_PAGES 2048
> 91: # define OS_X_10_9_0_KERNEL_MAJOR_VERSION 13
> 92: #endif

Does this work around for Maveriks (10.9.0) need to be here?

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

> 101:   // 10.5 UNIX03 member name prefixes
> 102:   #define DU3_PREFIX(s, m) __ ## s.__ ## m
> 103: # else

Does this work around for macOS 10.5 need to be here?

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?

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

> 219:     assert(sig == info->si_signo, "bad siginfo");
> 220:   }
> 221: */

Should this code be deleted? From here and from where it was copied
from if it is also commented out there...

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

> 361:     address pc = os::Posix::ucontext_get_pc(uc);
> 362: 
> 363:     if (pc != addr && uc->context_esr == 0x9200004F) { //TODO: figure out what this value means

Is this TODO going to be resolved by this port?

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

> 372: 
> 373:       last_addr = (address) -1;
> 374:     } else if (pc == addr && uc->context_esr == 0x8200000f) { //TODO: figure out what this value means

Is this TODO going to be resolved by this port?

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

> 433: //    |                        |\  Java thread created by VM does not have glibc
> 434: //    |    glibc guard page    | - guard, attached Java thread usually has
> 435: //    |                        |/  1 glibc guard page.

Is this code going to be built by GCC (with glibc) or will only
macOS compilers and libraries be used?

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?

src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.hpp line 45:

> 43:   // Atomically copy 64 bits of data
> 44:   static void atomic_copy64(const volatile void *src, volatile void *dst) {
> 45:     *(jlong *) dst = *(const jlong *) src;

Is this construct actually atomic on aarch64?

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?

src/hotspot/os_cpu/aix_ppc/os_aix_ppc.hpp line 43:

> 41: 
> 42: private:
> 43: 

'private' usually has once space in front of it.
Also why the blank line after it?

src/hotspot/os_cpu/aix_ppc/os_aix_ppc.hpp line 46:

> 44:   static void current_thread_enable_wx_impl(WXMode mode) { }
> 45: 
> 46: public:

'public' usually has one space in front of it.

src/hotspot/os_cpu/bsd_x86/os_bsd_x86.hpp line 41:

> 39: 
> 40: private:
> 41: 

'private' usually has one space in front of it.
Also, why the blank line after it?

src/hotspot/os_cpu/bsd_x86/os_bsd_x86.hpp line 44:

> 42:   static void current_thread_enable_wx_impl(WXMode mode) { }
> 43: 
> 44: public:

'public' usually has one space in front of it.

src/hotspot/os_cpu/bsd_zero/os_bsd_zero.hpp line 57:

> 55: 
> 56: private:
> 57: 

'private' usually has one space in front of it.
Also, why the blank line after it?

src/hotspot/os_cpu/bsd_zero/os_bsd_zero.hpp line 60:

> 58:   static void current_thread_enable_wx_impl(WXMode mode) { }
> 59: 
> 60: public:

'public' usually has one space in front of it.

src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.hpp line 43:

> 41: 
> 42: private:
> 43: 

'private' usually has one space in front of it.
Also, why the blank line after it?

src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.hpp line 46:

> 44:   static void current_thread_enable_wx_impl(WXMode mode) { }
> 45: 
> 46: public:

'public' usually has one space in front of it.

src/hotspot/os_cpu/linux_arm/os_linux_arm.hpp line 74:

> 72: 
> 73: private:
> 74: 

'private' usually has one space in front of it.
Also, why the blank line after it?

src/hotspot/os_cpu/linux_arm/os_linux_arm.hpp line 77:

> 75:   static void current_thread_enable_wx_impl(WXMode mode) { }
> 76: 
> 77: public:

'public' usually has one space in front of it.

src/hotspot/os_cpu/linux_ppc/os_linux_ppc.hpp line 36:

> 34: 
> 35: private:
> 36: 

'private' usually has one space in front of it.
Also, why the blank line after it?

src/hotspot/os_cpu/linux_ppc/os_linux_ppc.hpp line 39:

> 37:   static void current_thread_enable_wx_impl(WXMode mode) { }
> 38: 
> 39: public:

'public' usually has one space in front of it.

src/hotspot/os_cpu/linux_s390/os_linux_s390.hpp line 35:

> 33: 
> 34: private:
> 35: 

'private' usually has one space in front of it.
Also, why the blank line after it?

src/hotspot/os_cpu/linux_s390/os_linux_s390.hpp line 38:

> 36:   static void current_thread_enable_wx_impl(WXMode mode) { }
> 37: 
> 38: public:

'public' usually has one space in front of it.

src/hotspot/os_cpu/linux_x86/os_linux_x86.hpp line 54:

> 52: 
> 53: private:
> 54: 

'private' usually has one space in front of it.
Also, why the blank line after it?

src/hotspot/os_cpu/linux_x86/os_linux_x86.hpp line 57:

> 55:   static void current_thread_enable_wx_impl(WXMode mode) { }
> 56: 
> 57: public:

'public' usually has one space in front of it.

src/hotspot/os_cpu/linux_zero/os_linux_zero.hpp line 94:

> 92: 
> 93: private:
> 94: 

'private' usually has one space in front of it.
Also, why the blank line after it?

src/hotspot/os_cpu/linux_zero/os_linux_zero.hpp line 97:

> 95:   static void current_thread_enable_wx_impl(WXMode mode) { }
> 96: 
> 97: private:

I think this should 'public' (with one space in front of it).

src/hotspot/os_cpu/windows_aarch64/os_windows_aarch64.hpp line 37:

> 35: 
> 36: private:
> 37: 

'private' usually has one space in front of it.
Also, why the blank line after it?

src/hotspot/os_cpu/windows_aarch64/os_windows_aarch64.hpp line 40:

> 38:   static void current_thread_enable_wx_impl(WXMode mode) { }
> 39: 
> 40: public:

'public' usually has one space in front of it.

src/hotspot/os_cpu/windows_x86/os_windows_x86.hpp line 47:

> 45: 
> 46: private:
> 47: 

'private' usually has one space in front of it.
Also, why the blank line after it?

src/hotspot/os_cpu/windows_x86/os_windows_x86.hpp line 50:

> 48:   static void current_thread_enable_wx_impl(WXMode mode) { }
> 49: 
> 50: public:

'public' usually has one space in front of it.

src/hotspot/share/gc/shared/oopStorage.cpp line 40:

> 38: #include "runtime/os.hpp"
> 39: #include "runtime/safepoint.hpp"
> 40: #include "runtime/stubRoutines.inline.hpp"

The reason for switching from include to inline-include is not clear.

src/hotspot/share/logging/logStream.hpp line 35:

> 33: class LogStream : public outputStream {
> 34:   // see test/hotspot/gtest/logging/test_logStream.cpp
> 35:   friend class LogStreamTest;

It's not clear why this change is made for this port.

src/hotspot/share/prims/jni.cpp line 3930:

> 3928: 
> 3929:   // Go to the execute mode, the initial state of the thread on creation.
> 3930:   // Use os interface as the thread is not a java one anymore.

Perhaps: s/not a java one anymore./not a JavaThread anymore./

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?

src/hotspot/share/runtime/globals.hpp line 1855:

> 1853:                                                                             \
> 1854:   product(intx, UnguardOnExecutionViolation, 0,                             \
> 1855:           "Unguard page and retry on no-execute fault "                     \

Taking away the "(Win32 only)" and not replacing it with new text feels wrong.
I can't imagine that this flag works on any additional platforms except for
macos-aarch64.

src/hotspot/share/runtime/os.cpp line 58:

> 56: #include "runtime/osThread.hpp"
> 57: #include "runtime/sharedRuntime.hpp"
> 58: #include "runtime/stubRoutines.inline.hpp"

The reason for switching from include to inline include is not clear.

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

> 50: #include "runtime/safepointMechanism.inline.hpp"
> 51: #include "runtime/sharedRuntime.hpp"
> 52: #include "runtime/stubRoutines.inline.hpp"

The reason for switching from include to inline include is not clear.

src/hotspot/share/runtime/stubRoutines.cpp line 34:

> 32: #include "runtime/timerTrace.hpp"
> 33: #include "runtime/sharedRuntime.hpp"
> 34: #include "runtime/stubRoutines.inline.hpp"

The reason for switching from include to inline include is not clear.

src/hotspot/share/runtime/stubRoutines.inline.hpp line 1:

> 1: /*

NOW I understand the reason for switching from include to inline-include.
Is there a reason that this change is part of this project and not extracted
into a separate RFE. That would reduce the number of files touched by
this project.

src/hotspot/share/runtime/thread.cpp line 3991:

> 3989:       JavaThread* thread = JavaThread::current();
> 3990:       ThreadToNativeFromVM ttn(thread);
> 3991:       Thread::WXExecFromWriteSetter wx_exec;

I saw somewhere in this review a comment about why this new
WXExecFromWriteSetter helper isn't folded into ThreadToNativeFromVM
and I understand that not every current ThreadToNativeFromVM needs
the new helper. If the vast majority of the ThreadToNativeFromVM
locations need WXExecFromWriteSetter, then perhaps those locations
that currently have a ThreadToNativeFromVM followed by the new
WXExecFromWriteSetter should use a new helper:

    ThreadToNativeWithWXExecFromVM

so we'll see changes from:

    ThreadToNativeFromVM -> ThreadToNativeWithWXExecFromVM

where we need them and hopefully a short comment can be added
at the same time to explain the need for WXExec. This will allow us
to easily distinguish ThreadToNativeFromVM locations that DO NOT
need WXExec from those that DO need it.

src/java.base/macosx/native/libjli/java_md_macosx.m line 210:

> 208:     if (preferredJVM == NULL) {
> 209: #if defined(__i386__)
> 210:         preferredJVM = "client";

#if defined(__i386__)
        preferredJVM = "client";
Not your bug, but Oracle/OpenJDK never supported 32-bit __i386__ on macOS.

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

Changes requested by dcubed (Reviewer).

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

From ysuenaga at openjdk.java.net  Tue Feb  2 23:24:40 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Tue, 2 Feb 2021 23:24:40 GMT
Subject: RFR: 8247514: Improve clhsdb 'findpc' ability to determine what
 an address points to by improving PointerFinder and PointerLocation classes
In-Reply-To: <4YKNpyXQ9QGrLhR61tkh71Q3A7VvCj5Ete_4OvzAA-o=.28b7be8c-6f05-42d4-892b-87ebea907b24@github.com>
References: <4YKNpyXQ9QGrLhR61tkh71Q3A7VvCj5Ete_4OvzAA-o=.28b7be8c-6f05-42d4-892b-87ebea907b24@github.com>
Message-ID: <-09XRqbxFbZGkzqDVewiXrJjVNjuLMdZqfxjnxJf3Oc=.2da660b7-a5c1-40e1-81af-8dc814e199ca@github.com>

On Sun, 17 Jan 2021 03:57:59 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> See the bug for most details. A few notes here about some implementation details:
> 
> In the `PointerLocation` class, I added more consistency w.r.t. whether or not a newline is printed. It used to for some address types, but not others. Now it always does. And if you see a comment something like the following:
> 
> `         getTLAB().printOn(tty); // includes "\n" `
> 
> That's just clarifying whether or not the `printOn()` method called will include the newline. Some do and some don't, and knowing what the various `printOn()` methods do makes getting the proper inclusion of the newline easier to understand.
> 
> I added `verbose` and `printAddress` boolean arguments to `PointerLocation.printOn()`. Currently they are always `true`. The false arguments will be used when I complete [JDK-8250801](https://bugs.openjdk.java.net/browse/JDK-8250801), which will use `PointerFinder/Location` to show what each register points to.
> 
> The CR mentions that the main motivation for this work is for eventual replacement of the old clhsdb `whatis` command, which was implemented in javascript. It used to resolve DSO symbols, whereas `findpc` did not. The `whatis` code did this with the following:
> 
>   var dso = loadObjectContainingPC(addr);
>   if (dso == null) {
>     return ptrLoc.toString();
>   }
>   var sym = dso.closestSymbolToPC(addr);
>   if (sym != null) {
>     return sym.name + '+' + sym.offset;
>   }
> And now you'll see something similar in the PointerFinder code:
> 
>         loc.loadObject = cdbg.loadObjectContainingPC(a);
>         if (loc.loadObject != null) {
>             loc.nativeSymbol = loc.loadObject.closestSymbolToPC(a);
>             return loc;
>         } 
> Note that now that `findpc` does everything that `whatis` used to (and more), we don't really need to add a java version of `whatis`, but I'll probably do so anyway just help out people who are used to using the `whatis` command. That will be done using [JDK-8244670](https://bugs.openjdk.java.net/browse/JDK-8244670)

LGTM

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

Marked as reviewed by ysuenaga (Reviewer).

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

From jiefu at openjdk.java.net  Wed Feb  3 01:21:40 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 3 Feb 2021 01:21:40 GMT
Subject: RFR: 8260878: com/sun/jdi/JdbOptions.java fails without jfr
In-Reply-To: <D5-Cf_XhhvxhOmEiTsln-Y7fUlrp9FypO1f9-CfB8TA=.6efe3144-498b-4b66-bcf0-c7478f298113@github.com>
References: <URFTQH96EQ_wHpBLl2UWDuYj5cXEWt1dMpU6uui2Pcw=.889d9f0d-4ba1-4c71-8d4d-0d8a99e53a2b@github.com>
 <D5-Cf_XhhvxhOmEiTsln-Y7fUlrp9FypO1f9-CfB8TA=.6efe3144-498b-4b66-bcf0-c7478f298113@github.com>
Message-ID: <ZpgdbtmZVmMTSwWHd8EHJxBtX65r-RACQywJWqtGrBc=.5785dc57-2e68-40ae-88e3-56c4857f25f5@github.com>

On Tue, 2 Feb 2021 20:46:08 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Hi all,
>> 
>> com/sun/jdi/JdbOptions.java fails in our ci/cd when jfr is disabled.
>> It would be better to fix it.
>> 
>> Thanks.
>> Best regards,
>> Jie
>
> Marked as reviewed by amenkov (Reviewer).

Thanks @alexmenkov and @plummercj .

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

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

From jiefu at openjdk.java.net  Wed Feb  3 01:21:41 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 3 Feb 2021 01:21:41 GMT
Subject: Integrated: 8260878: com/sun/jdi/JdbOptions.java fails without jfr
In-Reply-To: <URFTQH96EQ_wHpBLl2UWDuYj5cXEWt1dMpU6uui2Pcw=.889d9f0d-4ba1-4c71-8d4d-0d8a99e53a2b@github.com>
References: <URFTQH96EQ_wHpBLl2UWDuYj5cXEWt1dMpU6uui2Pcw=.889d9f0d-4ba1-4c71-8d4d-0d8a99e53a2b@github.com>
Message-ID: <anjREnlhdCTP_1qPWuBKPiOTZWSSSaLRiZ9KLkocxkQ=.af401901-4fc0-4ccc-9e5f-f153e86e732d@github.com>

On Tue, 2 Feb 2021 03:43:29 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> com/sun/jdi/JdbOptions.java fails in our ci/cd when jfr is disabled.
> It would be better to fix it.
> 
> Thanks.
> Best regards,
> Jie

This pull request has now been integrated.

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

8260878: com/sun/jdi/JdbOptions.java fails without jfr

Reviewed-by: amenkov, cjplummer

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

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

From dholmes at openjdk.java.net  Wed Feb  3 01:45:42 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 3 Feb 2021 01:45:42 GMT
Subject: RFR: JDK-8260926: Trace resource exhausted events unconditionally
In-Reply-To: <-LuicM5vRHrcchY00NJhTTgngnNKX3ZkbKZVM_pmHpE=.372c1b6a-120c-460d-a168-76f200408efd@github.com>
References: <-LuicM5vRHrcchY00NJhTTgngnNKX3ZkbKZVM_pmHpE=.372c1b6a-120c-460d-a168-76f200408efd@github.com>
Message-ID: <-ZUFjDD0KRceDLzTEHDuyfhPq47VOKzZAtPXECxwNMI=.a4b9069a-30a8-4aed-9625-94ee854531ba@github.com>

On Tue, 2 Feb 2021 11:02:18 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Analyzing out-of-resource situations in cloud scenarios is no fun. With CloudFoundry, a JVMTI agent (jvmkill) is hooked up intercepting the jvmti "resource exhausted" event, then attempts to write up a heap report. That may fail, e.g. due to bugs in the agent [1], but also because that report runs java code and may suffer from the same resource exhaustion. Successful or not, it unceremoniously kills the VM when done, often leaving us with no information about the actual resource.
> 
> It would be very helpful if we had unconditional tracing here. We do have tracing, but it requires a non-product build and is triggered with TraceJVMTI. Also, it traces at trace level which is way to fine granular.
> 
> I'd like to introduce another, unconditional trace line here. Arguably, resource exhausted is fatal enough that it justifies unconditional tracing.
> 
> This is a bit of a coin toss. Tracing unconditionally would help in most scenarios, where it would be either difficult or even impossible to specify a trace command line switch. OTOH it may trip up scripts parsing the VM output, or some of our tests (which can be fixed).
> 
> Thoughts?
> 
> ..Thomas
> 
> [1] https://github.com/cloudfoundry/jvmkill/issues/18

Hi Thomas,

Approval in principle, but changes suggested.

Thanks,
David

src/hotspot/share/prims/jvmtiExport.cpp line 1509:

> 1507:   JavaThread *thread  = JavaThread::current();
> 1508: 
> 1509:   log_error(os)("Resource Exhausted (%s)", description != nullptr ? description : "no info");

Shouldn't that be `log_error(jvmti)`?
I'd also suggest the text "Posting Resource Exhausted event: %s" with "unknown" for a null description.

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

Changes requested by dholmes (Reviewer).

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

From lzang at openjdk.java.net  Wed Feb  3 02:22:40 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Wed, 3 Feb 2021 02:22:40 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump
In-Reply-To: <gnDO9moDHlyHgJCEdcILr-MauRQgQP7I6QE38XZHus0=.4e488aca-8206-4db5-acec-5c029a6328ca@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
 <crJcuaqSgYZQCEw2lqGaLpRmCVOXr99P1i5bcnSFpQc=.cb824923-e649-4ecd-ba5b-8d26cb93b265@github.com>
 <esex_demB2ZT0CsAp2WrzNGC_gieM9USGg_fYgmFCAE=.1911dd08-7dcc-4d88-9532-5d670399dd62@github.com>
 <ztN32xTk5joNRB7MhfYMl9zHCfGA1j8bQNu-ke975qc=.4c7ff2a9-2af8-495d-8f22-83e98c2e3221@github.com>
 <oQe3_j7vewkS8wlIuYXRCa_86pI215cFIceztTf5jX0=.d6d6201b-ec15-418e-a73b-e907d9d02607@github.com>
 <oPJ9OfKdD8CTbihLREww1QM2hc3Ckiai0-1OSpkq830=.87c4f119-07c9-471f-8c25-99dcfaad8d11@github.com>
 <ngMsS8jp0GTuqLVGD5k2ZL5AckbFwh8CBj5ec_GaBes=.0c51dacf-b158-4e62-874d-5e9c5a7b5f8e@github.com>
 <JDsbDqJRQ0V_s1SvGBhr3FLu98T2-X51kpkCs8s8vxQ=.fdb2242c-8706-4057-b4aa-084cfcb24166@github.com>
 <cHsGHKQrSqSUKJJ2OIRVUYuKUVOJGH-Pch-aDmoPj64=.88025b63-b0bb-401a-a749-57089ebea3aa@github.com>
 <gnDO9moDHlyHgJCEdcILr-MauRQgQP7I6QE38XZHus0=.4e488aca-8206-4db5-acec-5c029a6328ca@github.com>
Message-ID: <vN4ZxgYOLsOQLqwyX4fXMJsQ-LM-S5JqeZoWdMXzmqc=.dfdc97a5-4838-4f09-9082-e5562c4691e0@github.com>

On Mon, 1 Feb 2021 06:16:34 GMT, Lin Zang <lzang at openjdk.org> wrote:

>>> I think if you can avoid the 4th argument by just enabling parallel by default sounds like a good idea. Is there any reason not to use parallel heap dump? Also, I'm not familiar with the terms "compression backends" and "active workers". Can you explain them.
>> 
>> For parallel heap dump, I think expose the "parallel" option is useful when user want to control the number of threads that works on parallel dumping. One reason is to control the CPU load to not affect too much on other processes on system. 
>> 
>> The "active workers" is the value that returned by gang->active_workers(). And I think "active workers" is the number of available threads that could be used for parallally working on something. my understanding is that this value could be dynamically changed at runtime, but it is limited by the JVM option "-XX:ParallelGCThreads".
>> 
>> The "compression backend" is introduced by "gz=" option, it is actually a "backend" that write heap dump data to file, and if there is compression level specified, the "backend" will do compression first and then write to file. The whole "backend" works parallelly, before this PR, the backend thread number is dicided by "active workers".
>> 
>> With this PR,  the relation of parallel heap iteration threads (parallel dumper),  the file writing threads (compression backend) and the "active_works" is like following:
>>           num_of_dumper_threads + num_of_compression_backend = active_workers.
>> 
>> BRs,
>> Lin
>
> Hi All,
> As discussed in this PR, it is reasonable to enable parallel heap dump by default rather than introducing a new "parallel" option. I would like to close the CSR at https://bugs.openjdk.java.net/browse/JDK-8260424.

Dear All,
I have updated the patch and remove the introduction of new "parallel" option. So there can be no backward-compatibility issue for jmap -dump command.  May I ask your help to remove the CSR label if agreed? 

BRs,
Lin

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

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

From lzang at openjdk.java.net  Wed Feb  3 02:34:01 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Wed, 3 Feb 2021 02:34:01 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v4]
In-Reply-To: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
Message-ID: <_Y8raftlsu1vZWgCb15-i8Us346BytZnIJyr549plL8=.ca18f185-7820-46de-a9af-bc217763c870@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 incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:

 - Merge branch 'master' into par-dump
 - fix buffer queue issue
 - code refine
 - Do not expose parallel thread number to user
 - fix white space trailing issue
 - 8252842: Extend jmap to support parallel heap dump

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2261/files
  - new: https://git.openjdk.java.net/jdk/pull/2261/files/fb28c13e..06719159

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

  Stats: 25865 lines in 665 files changed: 9292 ins; 6222 del; 10351 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 Feb  3 04:31:53 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Wed, 3 Feb 2021 04:31:53 GMT
Subject: RFR: 8248876: LoadObject with bad base address created for exec file
 on linux
Message-ID: <R53sQGWiJHl8JzP_wmXoupayROl3DVu0l0rBCzYurWY=.4d6762e8-1de6-4b7d-805f-0a9b977950fb@github.com>

We could see NPE on `LinuxCDebugger::loadObjectContainingPC` which is used mainly by the clhsdb `findpc` command. (See [JDK-8248876](https://bugs.openjdk.java.net/browse/JDK-8248876) for more details)

It is caused by PIE executable handling.

Currently we use virtual address of top of PT_LOAD in executable as base address - it is valid for ET_EXEC binary.
However, in case of ET_DYN binary (PIE binary), we should handle it like a shared library.
In GDB, base address of executable would be calculated by dynamic section. SA should also do so.

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

Commit messages:
 - Remove unnecessary label from debug message
 - Calculate base address of ET_DYN executable

Changes: https://git.openjdk.java.net/jdk/pull/2366/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2366&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8248876
  Stats: 21 lines in 2 files changed: 8 ins; 4 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2366.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2366/head:pull/2366

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

From iignatyev at openjdk.java.net  Wed Feb  3 05:42:52 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Wed, 3 Feb 2021 05:42:52 GMT
Subject: RFR: 8260296: SA's dumpreplaydata fails [v3]
In-Reply-To: <N4znCSiBMzQSv2T9Nn42nKEmmfVw59SZoc6fZVq7lgw=.1c87d509-70f1-4ddb-a1aa-eda427d8e259@github.com>
References: <dbCVL_PF2kTQaXwi_ss4MX87d4wO2jPo-j7mn8Hrtao=.94bd9abc-2143-4306-ada0-0d7d09684ed2@github.com>
 <N4znCSiBMzQSv2T9Nn42nKEmmfVw59SZoc6fZVq7lgw=.1c87d509-70f1-4ddb-a1aa-eda427d8e259@github.com>
Message-ID: <0M7K991qRJQOhQfLlm--GlAwOzO8I77h51gWG4Frk28=.73b8361c-1673-4a09-8e08-7752a3ba5363@github.com>

On Wed, 27 Jan 2021 08:07:04 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> I noticed that the SA's dumpreplaydata command fails with:
>> 
>> java.lang.AssertionError: CLHSDB wasn't run successfully: Opening core file, please wait...
>> hsdb> Exception in thread "main" java.lang.InternalError: ciMetadata does not appear to be polymorphic
>> 
>> with a simple test program. This happens because the SA can't find the
>> vtable symbol for ciMetadata (build produced by gcc 9.2.1). AFAIU,
>> there's nothing in our build system that hides that symbol. I had to
>> move one method's definition from the header file to the cpp file for
>> the symbol to be visible again.
>> 
>> We have a test that checks dumpreplaydata but it doesn't catch that
>> problem. The test produces a replay file from a core file with the SA
>> by running a simple test with -Xcomp and CICrash=1. So the replay data
>> has very little or no profile data (which is what causes the problem
>> above). I propose running a slightly more complicated test method and
>> crashing after the method has had time to run for long enough to
>> collect profile data.
>> 
>> The other shortcoming of the test is that it doesn't look at the
>> content of the replay file. It only warns if they differ. The replay
>> file produced by the VM and the one produced by the SA should be
>> identical (except for comment lines). So I propose we check that.
>> 
>> Finally, I can't run that test on my system because core files are
>> handled by systemd (I'm running some recent version of fedora). I
>> suppose, the system can be configured differently but having the test
>> work out the box is nice. I extended the test case to handle that.
>> 
>> With the improved test, there are a few differences between the VM and
>> SA replay files caused by VM changes that were not mirrored in the
>> SA. I fixed those.
>
> Roland Westrelin 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:
> 
>  - convert all tests
>  - Merge branch 'master' into JDK-8260296
>  - use CoreUtils
>  - whitespaces
>  - SA fixes
>  - VM fix
>  - test

test/lib/jdk/test/lib/util/CoreUtils.java line 166:

> 164:                                 for (int i = 0; i < 10; i++) {
> 165:                                     Thread.sleep(5000);
> 166:                                     OutputAnalyzer out = ProcessTools.executeProcess("coredumpctl", "dump",  "-1",  "-o", core, Long.valueOf(pid).toString());

you can use `String::valueOf` to a string represenatation of `long`:
Suggestion:

                                    OutputAnalyzer out = ProcessTools.executeProcess("coredumpctl", "dump",  "-1",  "-o", core, String.valueOf(pid));

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

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

From iignatyev at openjdk.java.net  Wed Feb  3 05:57:48 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Wed, 3 Feb 2021 05:57:48 GMT
Subject: RFR: 8260296: SA's dumpreplaydata fails [v3]
In-Reply-To: <N4znCSiBMzQSv2T9Nn42nKEmmfVw59SZoc6fZVq7lgw=.1c87d509-70f1-4ddb-a1aa-eda427d8e259@github.com>
References: <dbCVL_PF2kTQaXwi_ss4MX87d4wO2jPo-j7mn8Hrtao=.94bd9abc-2143-4306-ada0-0d7d09684ed2@github.com>
 <N4znCSiBMzQSv2T9Nn42nKEmmfVw59SZoc6fZVq7lgw=.1c87d509-70f1-4ddb-a1aa-eda427d8e259@github.com>
Message-ID: <GQ4Rh3M9G3dwYmXwULK0Vc6ui6omGakm8vswFEQqOl8=.a5b31e8a-5af0-4914-8e65-ad6d44b73d21@github.com>

On Wed, 27 Jan 2021 08:07:04 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> I noticed that the SA's dumpreplaydata command fails with:
>> 
>> java.lang.AssertionError: CLHSDB wasn't run successfully: Opening core file, please wait...
>> hsdb> Exception in thread "main" java.lang.InternalError: ciMetadata does not appear to be polymorphic
>> 
>> with a simple test program. This happens because the SA can't find the
>> vtable symbol for ciMetadata (build produced by gcc 9.2.1). AFAIU,
>> there's nothing in our build system that hides that symbol. I had to
>> move one method's definition from the header file to the cpp file for
>> the symbol to be visible again.
>> 
>> We have a test that checks dumpreplaydata but it doesn't catch that
>> problem. The test produces a replay file from a core file with the SA
>> by running a simple test with -Xcomp and CICrash=1. So the replay data
>> has very little or no profile data (which is what causes the problem
>> above). I propose running a slightly more complicated test method and
>> crashing after the method has had time to run for long enough to
>> collect profile data.
>> 
>> The other shortcoming of the test is that it doesn't look at the
>> content of the replay file. It only warns if they differ. The replay
>> file produced by the VM and the one produced by the SA should be
>> identical (except for comment lines). So I propose we check that.
>> 
>> Finally, I can't run that test on my system because core files are
>> handled by systemd (I'm running some recent version of fedora). I
>> suppose, the system can be configured differently but having the test
>> work out the box is nice. I extended the test case to handle that.
>> 
>> With the improved test, there are a few differences between the VM and
>> SA replay files caused by VM changes that were not mirrored in the
>> SA. I fixed those.
>
> Roland Westrelin 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:
> 
>  - convert all tests
>  - Merge branch 'master' into JDK-8260296
>  - use CoreUtils
>  - whitespaces
>  - SA fixes
>  - VM fix
>  - test

a few more nits

test/lib/jdk/test/lib/process/ProcessTools.java line 461:

> 459:     }
> 460: 
> 461:     static public class OutputAnalyzerAndPID {

Suggestion:

    public static class OutputAnalyzerAndPID {

test/lib/jdk/test/lib/process/ProcessTools.java line 461:

> 459:     }
> 460: 
> 461:     static public class OutputAnalyzerAndPID {

can we either change `OutputAnalyzer` to store pid (and use -1 for cases when there is no one) or make `OutputAnalyzer` non-final and have `OutputAnalyzerAndPID` extending `OutputAnalyzer`?

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

Changes requested by iignatyev (Reviewer).

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

From stuefe at openjdk.java.net  Wed Feb  3 06:39:01 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Wed, 3 Feb 2021 06:39:01 GMT
Subject: RFR: JDK-8260926: Trace resource exhausted events unconditionally
 [v2]
In-Reply-To: <-LuicM5vRHrcchY00NJhTTgngnNKX3ZkbKZVM_pmHpE=.372c1b6a-120c-460d-a168-76f200408efd@github.com>
References: <-LuicM5vRHrcchY00NJhTTgngnNKX3ZkbKZVM_pmHpE=.372c1b6a-120c-460d-a168-76f200408efd@github.com>
Message-ID: <GMjFgCwRTZYyOEjLHhAmkpPS3bBPCCYQEqDEUk0HzQA=.fba195f4-c2b0-4773-9784-e0bdc12becc9@github.com>

> Analyzing out-of-resource situations in cloud scenarios is no fun. With CloudFoundry, a JVMTI agent (jvmkill) is hooked up intercepting the jvmti "resource exhausted" event, then attempts to write up a heap report. That may fail, e.g. due to bugs in the agent [1], but also because that report runs java code and may suffer from the same resource exhaustion. Successful or not, it unceremoniously kills the VM when done, often leaving us with no information about the actual resource.
> 
> It would be very helpful if we had unconditional tracing here. We do have tracing, but it requires a non-product build and is triggered with TraceJVMTI. Also, it traces at trace level which is way to fine granular.
> 
> I'd like to introduce another, unconditional trace line here. Arguably, resource exhausted is fatal enough that it justifies unconditional tracing.
> 
> This is a bit of a coin toss. Tracing unconditionally would help in most scenarios, where it would be either difficult or even impossible to specify a trace command line switch. OTOH it may trip up scripts parsing the VM output, or some of our tests (which can be fixed).
> 
> Thoughts?
> 
> ..Thomas
> 
> [1] https://github.com/cloudfoundry/jvmkill/issues/18

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

  Feedback David

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2350/files
  - new: https://git.openjdk.java.net/jdk/pull/2350/files/abe2bf60..40e3af87

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

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

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

From stuefe at openjdk.java.net  Wed Feb  3 06:39:03 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Wed, 3 Feb 2021 06:39:03 GMT
Subject: RFR: JDK-8260926: Trace resource exhausted events unconditionally
 [v2]
In-Reply-To: <-ZUFjDD0KRceDLzTEHDuyfhPq47VOKzZAtPXECxwNMI=.a4b9069a-30a8-4aed-9625-94ee854531ba@github.com>
References: <-LuicM5vRHrcchY00NJhTTgngnNKX3ZkbKZVM_pmHpE=.372c1b6a-120c-460d-a168-76f200408efd@github.com>
 <-ZUFjDD0KRceDLzTEHDuyfhPq47VOKzZAtPXECxwNMI=.a4b9069a-30a8-4aed-9625-94ee854531ba@github.com>
Message-ID: <sLFIlR3dtxxdQe5SetmG9MNxIUAGH6cUOBQ67FqYGRk=.0e93fad3-3d24-442d-a0d2-391a4a24b763@github.com>

On Wed, 3 Feb 2021 01:43:25 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Hi Thomas,
> 
> Approval in principle, but changes suggested.
> 
> Thanks,
> David

Hi David, thanks for looking at this. I changed text and tag as requested.

..Thomas

> src/hotspot/share/prims/jvmtiExport.cpp line 1509:
> 
>> 1507:   JavaThread *thread  = JavaThread::current();
>> 1508: 
>> 1509:   log_error(os)("Resource Exhausted (%s)", description != nullptr ? description : "no info");
> 
> Shouldn't that be `log_error(jvmti)`?
> I'd also suggest the text "Posting Resource Exhausted event: %s" with "unknown" for a null description.

Sure, no problem.

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

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

From aph at openjdk.java.net  Wed Feb  3 09:25:52 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Wed, 3 Feb 2021 09:25:52 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
In-Reply-To: <MlC0k95KyLxJCu7ZSluQlSdVrGTPolMjYG_rX3lpebU=.9ccf1fac-6fec-4479-80d7-9ee89d3bbb54@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>
Message-ID: <zb9Bc_BB0rmhHtPuXwahy9m9Xbr518NDrcAFHO729oc=.5010faf9-3705-4e3e-bec9-8b3a2f0c72e9@github.com>

On Tue, 2 Feb 2021 18:03:50 GMT, Gerard Ziemski <gziemski 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/cpu/aarch64/macroAssembler_aarch64.cpp line 5271:
> 
>> 5269: //
>> 5270: void MacroAssembler::get_thread(Register dst) {
>> 5271:   RegSet saved_regs = RegSet::range(r0, r1) + BSD_ONLY(RegSet::range(r2, r17)) + lr - dst;
> 
> The comment needs to be updated, since on BSD we also seem to clobber r2,r17 ?

Surely this should be 

 saved_regs = RegSet::range(r0, r1) BSD_ONLY(+ RegSet::range(r2, r17)) + lr - dst;```

Shouldn't it?

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

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

From aph at openjdk.java.net  Wed Feb  3 09:25:51 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Wed, 3 Feb 2021 09:25: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: <N_-2fM_jiKpNy74POTcXmRWWkYevnfQ-pLQA9C49B6I=.e3a78aa0-dde9-429e-9de7-5d64037378a9@github.com>

On Tue, 2 Feb 2021 21:49:36 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/cpu/aarch64/macroAssembler_aarch64.cpp line 323:
> 
>> 321:   str(zr, Address(rthread, JavaThread::last_Java_pc_offset()));
>> 322: 
>> 323:   str(zr, Address(rthread, JavaFrameAnchor::saved_fp_address_offset()));
> 
> I don't think this switch from `JavaThread::saved_fp_address_offset()`
> to `JavaFrameAnchor::saved_fp_address_offset()` is correct since
> `rthread` is still used and is a JavaThread*. The new code will give you:
> 
>     `rthread` + offset of the `saved_fp_address` field in a JavaFrameAnchor
> 
> The old code gave you:
> 
>     `rthread` + offset of the `saved_fp_address` field in the JavaFrameAnchor field in the JavaThread
> 
> Those are not the same things.

I agree, I don't understand why this change was made.

> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.hpp line 45:
> 
>> 43:   // Atomically copy 64 bits of data
>> 44:   static void atomic_copy64(const volatile void *src, volatile void *dst) {
>> 45:     *(jlong *) dst = *(const jlong *) src;
> 
> Is this construct actually atomic on aarch64?

Yes.

> src/hotspot/os_cpu/windows_aarch64/os_windows_aarch64.hpp line 37:
> 
>> 35: 
>> 36: private:
>> 37: 
> 
> 'private' usually has one space in front of it.
> Also, why the blank line after it?

It reads better with the blank line, and it's not in violation of HotSpot conventions.

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

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

From magnus.ihse.bursie at oracle.com  Wed Feb  3 09:37:57 2021
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 3 Feb 2021 10:37:57 +0100
Subject: RFR: 8257988: Remove JNF dependency from
 libsaproc/MacosxDebuggerLocal.m
In-Reply-To: <F9DwpPI9FudOqRU7VmGGnD_YajHiw_QN1n4Sy5WDOgQ=.ea3e8531-d345-45c0-9372-2f8cec9a2763@github.com>
References: <cUes5jnPfmVPzfl9a6CeLDL3m34aLsa1oIoetgnANzI=.d9440b4c-9c8e-48f8-b573-6cb5c35242d7@github.com>
 <F9DwpPI9FudOqRU7VmGGnD_YajHiw_QN1n4Sy5WDOgQ=.ea3e8531-d345-45c0-9372-2f8cec9a2763@github.com>
Message-ID: <ad9fe641-2668-dc46-b462-d3c9e9cba6e7@oracle.com>

On 2021-02-02 21:47, Chris Plummer wrote:
> Is there a reason why `java.desktop` continues to use `JNFJavaToNSString`? I was looking to see how this was handled in other places, but I couldn't find an example where `JNFJavaToNSString` was converted to call a newly implemented `JavaStringToNSString`.
That conversion is handled in https://github.com/openjdk/jdk/pull/2305.

/Magnus

From lzang at openjdk.java.net  Wed Feb  3 11:22:07 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Wed, 3 Feb 2021 11:22:07 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v5]
In-Reply-To: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
Message-ID: <czhT52U08F3xbttRV-_SbTG-huTGrQNCHdsYyTViyl0=.d4d4026e-0599-40e9-ab6a-c58299952e50@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 logic in thread number calculation and code refine

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2261/files
  - new: https://git.openjdk.java.net/jdk/pull/2261/files/06719159..016218ba

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

  Stats: 9 lines in 1 file changed: 5 ins; 0 del; 4 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 roland at openjdk.java.net  Wed Feb  3 12:06:45 2021
From: roland at openjdk.java.net (Roland Westrelin)
Date: Wed, 3 Feb 2021 12:06:45 GMT
Subject: RFR: 8260296: SA's dumpreplaydata fails [v3]
In-Reply-To: <GQ4Rh3M9G3dwYmXwULK0Vc6ui6omGakm8vswFEQqOl8=.a5b31e8a-5af0-4914-8e65-ad6d44b73d21@github.com>
References: <dbCVL_PF2kTQaXwi_ss4MX87d4wO2jPo-j7mn8Hrtao=.94bd9abc-2143-4306-ada0-0d7d09684ed2@github.com>
 <N4znCSiBMzQSv2T9Nn42nKEmmfVw59SZoc6fZVq7lgw=.1c87d509-70f1-4ddb-a1aa-eda427d8e259@github.com>
 <GQ4Rh3M9G3dwYmXwULK0Vc6ui6omGakm8vswFEQqOl8=.a5b31e8a-5af0-4914-8e65-ad6d44b73d21@github.com>
Message-ID: <aj2K1Z1z6rE-rB46D83uV6Fbs4kHF2P_LOumtjWrC6s=.3ea6a5bf-1356-4287-a746-aa2da2f60677@github.com>

On Wed, 3 Feb 2021 05:45:02 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Roland Westrelin 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:
>> 
>>  - convert all tests
>>  - Merge branch 'master' into JDK-8260296
>>  - use CoreUtils
>>  - whitespaces
>>  - SA fixes
>>  - VM fix
>>  - test
>
> test/lib/jdk/test/lib/process/ProcessTools.java line 461:
> 
>> 459:     }
>> 460: 
>> 461:     static public class OutputAnalyzerAndPID {
> 
> can we either change `OutputAnalyzer` to store pid (and use -1 for cases when there is no one) or make `OutputAnalyzer` non-final and have `OutputAnalyzerAndPID` extending `OutputAnalyzer`?

Thanks for reviewing this. I did not store the pid in the OutputAnalyzer because it doesn't seem to belong there as it has nothing to do with the text output of a test. But if you think that's ok. that's fine with me too. Do you prefer an extra field in OutputAnalyzer or a new subclass?

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

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

From iignatyev at openjdk.java.net  Wed Feb  3 18:54:43 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Wed, 3 Feb 2021 18:54:43 GMT
Subject: RFR: 8260296: SA's dumpreplaydata fails [v3]
In-Reply-To: <aj2K1Z1z6rE-rB46D83uV6Fbs4kHF2P_LOumtjWrC6s=.3ea6a5bf-1356-4287-a746-aa2da2f60677@github.com>
References: <dbCVL_PF2kTQaXwi_ss4MX87d4wO2jPo-j7mn8Hrtao=.94bd9abc-2143-4306-ada0-0d7d09684ed2@github.com>
 <N4znCSiBMzQSv2T9Nn42nKEmmfVw59SZoc6fZVq7lgw=.1c87d509-70f1-4ddb-a1aa-eda427d8e259@github.com>
 <GQ4Rh3M9G3dwYmXwULK0Vc6ui6omGakm8vswFEQqOl8=.a5b31e8a-5af0-4914-8e65-ad6d44b73d21@github.com>
 <aj2K1Z1z6rE-rB46D83uV6Fbs4kHF2P_LOumtjWrC6s=.3ea6a5bf-1356-4287-a746-aa2da2f60677@github.com>
Message-ID: <szyKVJwJZABJzqj8BOKjMfGo7rn8KLUfzrTdE1l0SNQ=.2ea62edd-dc83-4da2-8a16-6cb86076a46b@github.com>

On Wed, 3 Feb 2021 12:04:00 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> test/lib/jdk/test/lib/process/ProcessTools.java line 461:
>> 
>>> 459:     }
>>> 460: 
>>> 461:     static public class OutputAnalyzerAndPID {
>> 
>> can we either change `OutputAnalyzer` to store pid (and use -1 for cases when there is no one) or make `OutputAnalyzer` non-final and have `OutputAnalyzerAndPID` extending `OutputAnalyzer`?
>
> Thanks for reviewing this. I did not store the pid in the OutputAnalyzer because it doesn't seem to belong there as it has nothing to do with the text output of a test. But if you think that's ok. that's fine with me too. Do you prefer an extra field in OutputAnalyzer or a new subclass?

`OutputAnalyzer`/ `OutputBuffer` already have an exit value, which arguable has nothing to do w/ the text output either, so I think it's ok to add a pid into `OutputBuffer` i-face and both of its implementations.

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

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

From akozlov at openjdk.java.net  Wed Feb  3 20:01:15 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Wed, 3 Feb 2021 20:01:15 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v10]
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: <QZ7stXQpgmcHxvq5cmr2FB_R8lyy2xGDNK8m1cawvWk=.f436fe10-400b-4a6c-a41c-ebdb170a3248@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 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

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2200/files
  - new: https://git.openjdk.java.net/jdk/pull/2200/files/3c705ae5..80827176

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

  Stats: 444 lines in 64 files changed: 112 ins; 278 del; 54 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  Wed Feb  3 20:01:16 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Wed, 3 Feb 2021 20:01:16 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: <6oqFTX-wDWyEUpJ6FLHvgP8gi0zmnkF6Mzz87hC6A1w=.e0b31425-4750-472f-9335-0b187a59c834@github.com>

On Tue, 2 Feb 2021 23:10:17 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
>
> 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.

Thank you all for your comments regarding W^X implementation. I've made a change that reduces the footprint of the implementation, also addressing most of the comments. I'll revisit them individually to make sure nothing is forgotten.

The basic principle has not changed: when we execute JVM code (owned by libjvm.so, starting from JVM entry function), we switch to Write state. When we leave JVM to execute generated or JNI code, we switch to Executable state. I would like to highlight that JVM code does not mean the VM state of the java thread. After @stefank's suggestion, I could also drop a few W^X state switches, so now it should be more clear that switches are tied to JVM entry functions.

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

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

From akozlov at openjdk.java.net  Wed Feb  3 20:11:50 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Wed, 3 Feb 2021 20:11:50 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
In-Reply-To: <6oqFTX-wDWyEUpJ6FLHvgP8gi0zmnkF6Mzz87hC6A1w=.e0b31425-4750-472f-9335-0b187a59c834@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>
 <6oqFTX-wDWyEUpJ6FLHvgP8gi0zmnkF6Mzz87hC6A1w=.e0b31425-4750-472f-9335-0b187a59c834@github.com>
Message-ID: <Qb8Gta50pNQAKiE8nUCa9dl9O19tEkeUg4E25At5Bwk=.0c5c6b99-eaf2-4617-b6ec-fef2b7dbfc03@github.com>

On Wed, 3 Feb 2021 19:57:24 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.
>
> Thank you all for your comments regarding W^X implementation. I've made a change that reduces the footprint of the implementation, also addressing most of the comments. I'll revisit them individually to make sure nothing is forgotten.
> 
> The basic principle has not changed: when we execute JVM code (owned by libjvm.so, starting from JVM entry function), we switch to Write state. When we leave JVM to execute generated or JNI code, we switch to Executable state. I would like to highlight that JVM code does not mean the VM state of the java thread. After @stefank's suggestion, I could also drop a few W^X state switches, so now it should be more clear that switches are tied to JVM entry functions.

> I wonder if this is the right choice
> ...
> ```
> OopStorageParIterPerf::~OopStorageParIterPerf() {
> ...
> ```
> 

The transition in OopStorageParIterPerf was made for gtest setup to execute in WXWrite context. For tests themselves, defining macro set WXWrite.

I've simplified the scheme and now we switch to WXWrite once at the gtest launcher. So this transition was dropped.

I've also refreshed my memory and tried to switch to WXWrite as close as possible to each place where we'll be writing executable memory. There are a lot of such places! As you correctly noted, code cache contains objects, not plain data. For example, CodeCache memory management structures, CompiledMethod, ...  are there, so we need more WXWrite switches than we have in the current approach. I had a comparable amount of them just to run -version, but certainly not enough to run tier1 tests.

Following your advice, I don't require a known "from" state anymore. So a few W^X transitions were dropped, e.g. when the JVM code calls a JNI entry function, which expects to be called from the native code. I had to switch to WXExec just only to satisfy the expectations. After the update, we don't need this anymore.

W^X switches are mostly hidden by VM_ENTRY and similar macros. Some JVM functions are not marked as entries for some reason, although they are called directly from e.g. interpreter. I added W^X management to such functions.

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

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

From mikael at openjdk.java.net  Wed Feb  3 20:11:50 2021
From: mikael at openjdk.java.net (Mikael Vidstedt)
Date: Wed, 3 Feb 2021 20:11:50 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
In-Reply-To: <Qb8Gta50pNQAKiE8nUCa9dl9O19tEkeUg4E25At5Bwk=.0c5c6b99-eaf2-4617-b6ec-fef2b7dbfc03@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>
 <6oqFTX-wDWyEUpJ6FLHvgP8gi0zmnkF6Mzz87hC6A1w=.e0b31425-4750-472f-9335-0b187a59c834@github.com>
 <Qb8Gta50pNQAKiE8nUCa9dl9O19tEkeUg4E25At5Bwk=.0c5c6b99-eaf2-4617-b6ec-fef2b7dbfc03@github.com>
Message-ID: <sMzpTev5Co7zYwj_MDJAQwt1h4TclV5VupIfIVXXS5Q=.de8bfe1b-8e72-4fc5-a6ec-cc46f5b1649f@github.com>

On Wed, 3 Feb 2021 20:05:29 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Thank you all for your comments regarding W^X implementation. I've made a change that reduces the footprint of the implementation, also addressing most of the comments. I'll revisit them individually to make sure nothing is forgotten.
>> 
>> The basic principle has not changed: when we execute JVM code (owned by libjvm.so, starting from JVM entry function), we switch to Write state. When we leave JVM to execute generated or JNI code, we switch to Executable state. I would like to highlight that JVM code does not mean the VM state of the java thread. After @stefank's suggestion, I could also drop a few W^X state switches, so now it should be more clear that switches are tied to JVM entry functions.
>
>> I wonder if this is the right choice
>> ...
>> ```
>> OopStorageParIterPerf::~OopStorageParIterPerf() {
>> ...
>> ```
>> 
> 
> The transition in OopStorageParIterPerf was made for gtest setup to execute in WXWrite context. For tests themselves, defining macro set WXWrite.
> 
> I've simplified the scheme and now we switch to WXWrite once at the gtest launcher. So this transition was dropped.
> 
> I've also refreshed my memory and tried to switch to WXWrite as close as possible to each place where we'll be writing executable memory. There are a lot of such places! As you correctly noted, code cache contains objects, not plain data. For example, CodeCache memory management structures, CompiledMethod, ...  are there, so we need more WXWrite switches than we have in the current approach. I had a comparable amount of them just to run -version, but certainly not enough to run tier1 tests.
> 
> Following your advice, I don't require a known "from" state anymore. So a few W^X transitions were dropped, e.g. when the JVM code calls a JNI entry function, which expects to be called from the native code. I had to switch to WXExec just only to satisfy the expectations. After the update, we don't need this anymore.
> 
> W^X switches are mostly hidden by VM_ENTRY and similar macros. Some JVM functions are not marked as entries for some reason, although they are called directly from e.g. interpreter. I added W^X management to such functions.

Out of curiosity, have you looked at the performance of the W^X state transition? In particular I'm wondering if the cost is effectively negligible so doing it unconditionally on JVM entry is a no-brainer and just easier/cleaner than the alternatives, or if there are reasons to look at only doing the transition if/when needed (perhaps do it lazily and revert back to X when leaving the JVM?).

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

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

From akozlov at openjdk.java.net  Wed Feb  3 20:11:50 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Wed, 3 Feb 2021 20:11:50 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2]
In-Reply-To: <LAHF4QAE1MzvoQElpyRW5K_MnNdA3asNRceSXclodHw=.b2b705e3-a073-4597-8293-b2f25fdca37f@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com>
 <X9wlF4x4NEgbqm4jgkh3npkup8hOt70EBr9HOk_boU0=.2850f987-a8bf-436d-9a8f-f3588f18f0f7@github.com>
 <gh9aHbfKHXKAG3LTBZWitlw6L7p5kxwQC-Xxiyii1Ww=.d56e467d-4135-4785-968c-766c4505eb3c@github.com>
 <jXnEmEqfBhFsYuuaQSFX09N2_0SdvH05rEhstHxEtIU=.87837f33-2ddc-4667-84db-b2134a916069@github.com>
 <LAHF4QAE1MzvoQElpyRW5K_MnNdA3asNRceSXclodHw=.b2b705e3-a073-4597-8293-b2f25fdca37f@github.com>
Message-ID: <na8sPjKYkxO9JxbPmiLdCXjA5ZGzjkxjE2G57kuIkzs=.0eae428f-c768-41b6-8571-22ae676c9664@github.com>

On Tue, 26 Jan 2021 12:50:22 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Yes, that's why I thought it should be added to the classes ThreadInVMfromNative, etc like:
>> class ThreadInVMfromNative : public ThreadStateTransition {
>>   ResetNoHandleMark __rnhm;
>> 
>> We can look at it with cleaning up the thread transitions RFE or as a follow-on.  If every line of ThreadInVMfromNative has to have one of these   Thread::WXWriteVerifier __wx_write;     people are going to miss them when adding the former.
>
> Not every ThreadInVMfromNative needs this, for example JIT goes to Native state without changing of W^X state. But from some experience of maintaining this patch, I actually had a duty to add missing W^X transitions after assert failures. A possible solution is actually to make W^X transition a part of ThreadInVMfromNative (and similar), but controlled by an optional constructor parameter with possible values "do exec->write", "verify write"...;. So in a common case ThreadInVMfromNative would implicitly do the transition and still would allow something uncommon like verification of the state for the JIT. I have to think about this.

I've dropped this transition here and in similar places after state tracking always available. As a benefit, there are few places really using the setter and all of them are tied to VM_ENTRY macro or similar one. I expect we don't need to do W^X management near every java thread state change.

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

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

From akozlov at openjdk.java.net  Wed Feb  3 20:11:51 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Wed, 3 Feb 2021 20:11:51 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v2]
In-Reply-To: <OTfNjQUNPASnskM8tBLuTLhT5OrJ36rjx4RDRbyBhQo=.05a1a086-9494-4483-963a-cb41955623a5@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com>
 <51L0YGiOtGUEJUjhJkGnTRsoNofBsnSbopxjamQSesE=.0c2f3387-9f62-4d37-b2e8-73b5a5002641@github.com>
 <-_A-bf8i3jWY1awmyxwzi3yv4UoJQelRbJrMQVWQGLU=.5103b95d-3ad7-4a70-8d46-60c0eb0a301f@github.com>
 <YPcSqODkAflJPr_fnUNlHxpGB9IQSNqMhuf_2gFq8GY=.c8ed7d36-a354-43a8-9161-9c7160e7096b@github.com>
 <OTfNjQUNPASnskM8tBLuTLhT5OrJ36rjx4RDRbyBhQo=.05a1a086-9494-4483-963a-cb41955623a5@github.com>
Message-ID: <hCpT3WbhqPixLrzti7TJi0EwW57z9Y4pBaddeXBLcNE=.e610b1a5-2794-4244-92ce-1f51d70b448c@github.com>

On Tue, 26 Jan 2021 12:01:30 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I assume a WXVerifier class that tracks W^X mode in debug mode and does nothing in release mode. I've considered to do this, it's relates to small inefficiencies, while this patch brings zero overhead (in release) for a platform that does not need W^X. 
>> * We don't need thread instance in release to call `os::current_thread_enable_wx`. Having WXVerifier a part of the Thread will require calling `Thread::current()` first and we could only hope for compiler to optimize this out, not sure if it will happen at all. In some contexts the Thread instance is available, in some it's not. 
>> * An instance of the empty class (as WXVerifier will be in the release) will occupy non-zero space in the Thread instance.
>> 
>> If such costs are negligible, I can do as suggested.
>
> I really just want the minimal number of lines of code and hooks in thread.hpp.  You can still access it through the thread, just like these lines currently.  Look at HandshakeState as an example.

Please take a look at the recent changes.

Changes in thread.hpp were reduced:
https://github.com/openjdk/jdk/pull/2200/files#diff-abdc409967d04172ecc20e3747aa55a79e755584d570b57c4d58902a9813d188

thread.inline.hpp provides definitions of accessors (non-trivial):
https://github.com/openjdk/jdk/pull/2200/files#diff-3a29f7f952bf2bd936f49e97cb3b86a7324851133e879c142dec724455310b50

And new threadWXSetters.hpp defines RAII context setter:
https://github.com/openjdk/jdk/pull/2200/files#diff-6424782ec43941031282f079e89adaa76d341ce340a3b78b0e9657358ec16278

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

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

From gziemski at openjdk.java.net  Wed Feb  3 20:11:52 2021
From: gziemski at openjdk.java.net (Gerard Ziemski)
Date: Wed, 3 Feb 2021 20:11:52 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
In-Reply-To: <gdmSyDFlKNJfjwP2R9NL99cuUnJvVlNAVSuTGXX1aGI=.5ae84a36-aaf7-44d5-968f-594d09c71683@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>
 <gdmSyDFlKNJfjwP2R9NL99cuUnJvVlNAVSuTGXX1aGI=.5ae84a36-aaf7-44d5-968f-594d09c71683@github.com>
Message-ID: <fHJqmfpRVckaOW7MOyMjXwKjehndN__p9QjsTf9B9Js=.5875bc1b-07e3-4c07-b9c4-c727f8103eef@github.com>

On Tue, 2 Feb 2021 19:23:16 GMT, Bernhard Urban-Forster <burban at openjdk.org> wrote:

>> src/hotspot/os/posix/signals_posix.cpp line 1297:
>> 
>>> 1295:   kern_return_t kr;
>>> 1296:   kr = task_set_exception_ports(mach_task_self(),
>>> 1297:                                 EXC_MASK_BAD_ACCESS | EXC_MASK_BAD_INSTRUCTION | EXC_MASK_ARITHMETIC,
>> 
>> Could someone elaborate on why we need to add `EXC_MASK_BAD_INSTRUCTION` to the mask here?
>
> See comment above about `gdb`, the same applies to `lldb` today. The AArch64 backend uses `SIGILL` (~= `EXC_MASK_BAD_INSTRUCTION`) to initiate a deoptimization. Without this change you cannot continue debugging once you the debuggee receives `SIGILL`. This wasn't needed before as x86 doesn't use `SIGILL`.

Part of the comment said `This work-around is not necessary for 10.5+, as CrashReporter no longer intercedes on caught fatal signals.` so I thought it was no longer needed, but it sounds like the part about `gdb` still applies then.

We should update the comment to just say the `gdb` relevant part perhaps (and evaluate which of the EXC_MASK_BAD_ACCESS | EXC_MASK_BAD_INSTRUCTION | EXC_MASK_ARITHMETIC) we actually need for gdb:

 `// gdb installs both standard BSD signal handlers, and mach exception`
 `// handlers. By replacing the existing task exception handler, we disable gdb's mach`
 `// exception handling, while leaving the standard BSD signal handlers functional.`

Do you know if this also apply to `lldb` or is it `gdb` only specific? How do you run `gdb` on macOS nowadays anyhow?

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

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

From akozlov at openjdk.java.net  Wed Feb  3 20:11:53 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Wed, 3 Feb 2021 20:11:53 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: <pPMe2-Do3rfV7V4b7ZmbTRp9dTOlGSWpiQxtGn9O7eo=.093857c6-1481-4317-87e7-ea7c9bf948e9@github.com>

On Tue, 2 Feb 2021 23:03:45 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/runtime/thread.cpp line 3991:
> 
>> 3989:       JavaThread* thread = JavaThread::current();
>> 3990:       ThreadToNativeFromVM ttn(thread);
>> 3991:       Thread::WXExecFromWriteSetter wx_exec;
> 
> I saw somewhere in this review a comment about why this new
> WXExecFromWriteSetter helper isn't folded into ThreadToNativeFromVM
> and I understand that not every current ThreadToNativeFromVM needs
> the new helper. If the vast majority of the ThreadToNativeFromVM
> locations need WXExecFromWriteSetter, then perhaps those locations
> that currently have a ThreadToNativeFromVM followed by the new
> WXExecFromWriteSetter should use a new helper:
> 
>     ThreadToNativeWithWXExecFromVM
> 
> so we'll see changes from:
> 
>     ThreadToNativeFromVM -> ThreadToNativeWithWXExecFromVM
> 
> where we need them and hopefully a short comment can be added
> at the same time to explain the need for WXExec. This will allow us
> to easily distinguish ThreadToNativeFromVM locations that DO NOT
> need WXExec from those that DO need it.

With a small overhead for tracking the current W^X state, I avoided WXExecFromWriteSetter near ThreadToNativeFromVM at all. New ThreadWXEnable(WXExec) is used only to call a generated function. More common ThreadWXEnable(WXWrite) is tied to JVM entry functions. I added comments for functions that are not clear to be entries, although they are. Thank you for the suggestion!

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

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

From akozlov at openjdk.java.net  Wed Feb  3 20:11:54 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Wed, 3 Feb 2021 20:11:54 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
In-Reply-To: <MlC0k95KyLxJCu7ZSluQlSdVrGTPolMjYG_rX3lpebU=.9ccf1fac-6fec-4479-80d7-9ee89d3bbb54@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>
Message-ID: <VRubHtUOaz3-yAHaC71ZiRvh_V1kkkbuviPPRBtuToo=.5ee2c5d2-7895-4967-9088-eb8d78fddf2e@github.com>

On Tue, 2 Feb 2021 18:00:06 GMT, Gerard Ziemski <gziemski 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/cpu/aarch64/interpreterRT_aarch64.cpp line 390:
> 
>> 388:       store_and_inc(_to, from_obj, NativeStack::intSpace);
>> 389: 
>> 390:       _num_int_args++;
> 
> `pass_byte()` and  `pass_short()` use only one `_num_int_args++;` after the `if else` but other methods use 2 of them inside `if else` branches.
> 
> We should be consistent.

Agree. I'm going to do as much refactoring as needed before this patch under JDK-8261071

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

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

From prr at openjdk.java.net  Wed Feb  3 20:17:03 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 3 Feb 2021 20:17:03 GMT
Subject: RFR: 8257988: Remove JNF dependency from
 libsaproc/MacosxDebuggerLocal.m [v2]
In-Reply-To: <cUes5jnPfmVPzfl9a6CeLDL3m34aLsa1oIoetgnANzI=.d9440b4c-9c8e-48f8-b573-6cb5c35242d7@github.com>
References: <cUes5jnPfmVPzfl9a6CeLDL3m34aLsa1oIoetgnANzI=.d9440b4c-9c8e-48f8-b573-6cb5c35242d7@github.com>
Message-ID: <3hZqDjqCTVPr34viaIoK9mbEvs5rAOOhX7GPgWBNrP8=.dae1f4d1-4384-454a-9e71-05f86ba0ca0a@github.com>

> This removes the JNF dependency from the jdk.hotspot.agent module.
> The macro expansions are the same as already used in the Java desktop module - which actually uses a macro
> still but there there are hundreds of uses.
> The function of this macro code is to prevent NSExceptions escaping to Java and also to drain the auto-release pool.
> What test group would be good for verifying this change ?

Phil Race has updated the pull request incrementally with one additional commit since the last revision:

  8257988: Remove JNF dependency from libsaproc/MacosxDebuggerLocal.m

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2304/files
  - new: https://git.openjdk.java.net/jdk/pull/2304/files/9919a02c..d7ed0158

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

  Stats: 39 lines in 1 file changed: 18 ins; 15 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2304.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2304/head:pull/2304

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

From akozlov at openjdk.java.net  Wed Feb  3 20:16:52 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Wed, 3 Feb 2021 20:16:52 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
In-Reply-To: <zb9Bc_BB0rmhHtPuXwahy9m9Xbr518NDrcAFHO729oc=.5010faf9-3705-4e3e-bec9-8b3a2f0c72e9@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>
 <zb9Bc_BB0rmhHtPuXwahy9m9Xbr518NDrcAFHO729oc=.5010faf9-3705-4e3e-bec9-8b3a2f0c72e9@github.com>
Message-ID: <Qs3u_mRY2A8q77HeSqVfifo4oVlQDqtshteMvYaf3SE=.3347daad-bc88-4175-9e60-a0bb3a22e25c@github.com>

On Wed, 3 Feb 2021 09:14:24 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5271:
>> 
>>> 5269: //
>>> 5270: void MacroAssembler::get_thread(Register dst) {
>>> 5271:   RegSet saved_regs = RegSet::range(r0, r1) + BSD_ONLY(RegSet::range(r2, r17)) + lr - dst;
>> 
>> The comment needs to be updated, since on BSD we also seem to clobber r2,r17 ?
>
> Surely this should be 
> 
>  saved_regs = RegSet::range(r0, r1) BSD_ONLY(+ RegSet::range(r2, r17)) + lr - dst;```
> 
> Shouldn't it?

Interesting, I wonder why it has built successfully on Linux. I'm going to fix this under as JDK-8261072

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

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

From prr at openjdk.java.net  Wed Feb  3 20:17:05 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 3 Feb 2021 20:17:05 GMT
Subject: RFR: 8257988: Remove JNF dependency from
 libsaproc/MacosxDebuggerLocal.m [v2]
In-Reply-To: <F9DwpPI9FudOqRU7VmGGnD_YajHiw_QN1n4Sy5WDOgQ=.ea3e8531-d345-45c0-9372-2f8cec9a2763@github.com>
References: <cUes5jnPfmVPzfl9a6CeLDL3m34aLsa1oIoetgnANzI=.d9440b4c-9c8e-48f8-b573-6cb5c35242d7@github.com>
 <F9DwpPI9FudOqRU7VmGGnD_YajHiw_QN1n4Sy5WDOgQ=.ea3e8531-d345-45c0-9372-2f8cec9a2763@github.com>
Message-ID: <riFhq06m74Kr0mnpyk8JSI_ah9-MdQCZORXLDkMjYwI=.d7af2bb7-aebf-450b-83cb-42c24bea6512@github.com>

On Tue, 2 Feb 2021 20:27:17 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8257988: Remove JNF dependency from libsaproc/MacosxDebuggerLocal.m
>
> src/jdk.hotspot.agent/macosx/native/libsaproc/MacosxDebuggerLocal.m line 294:
> 
>> 292: 
>> 293:   NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
>> 294:   @try {
> 
> Although there are only 3 places where the `JNF_COCOA_ENTER/EXIT` macros are used, it seems it would still be worth taking the same approach you did for `java.desktop` and add the replacement macros instead of inlining them. So just copy what you added to `src/java.desktop/macosx/native/libosxapp/JNIUtilities.h`, and replace `JNF_COCOA_ENTER` with `JNI_COCOA_ENTER/EXIT`. Otherwise the `JNF_COCOA_ENTER/EXIT` changes look fine to me, but I'm just basing this on a comparison with what you've done with `java.desktop`. I'm no expert in this area.

OK .. I don't really mind either way and if this helps gets it pushed .. so I've updated.

> src/jdk.hotspot.agent/macosx/native/libsaproc/MacosxDebuggerLocal.m line 296:
> 
>> 294:   @try {
>> 295: 
>> 296:   NSString *symbolNameString = JavaStringToNSString(env, symbolName);
> 
> Is there a reason why `java.desktop` continues to use `JNFJavaToNSString`? I was looking to see how this was handled in other places, but I couldn't find an example where `JNFJavaToNSString` was converted to call a newly implemented `JavaStringToNSString`.

As Magnus said that is in progress. Hoping it will be pushed very soon.

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

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

From gziemski at openjdk.java.net  Wed Feb  3 20:32:47 2021
From: gziemski at openjdk.java.net (Gerard Ziemski)
Date: Wed, 3 Feb 2021 20:32:47 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
In-Reply-To: <fHJqmfpRVckaOW7MOyMjXwKjehndN__p9QjsTf9B9Js=.5875bc1b-07e3-4c07-b9c4-c727f8103eef@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>
 <gdmSyDFlKNJfjwP2R9NL99cuUnJvVlNAVSuTGXX1aGI=.5ae84a36-aaf7-44d5-968f-594d09c71683@github.com>
 <fHJqmfpRVckaOW7MOyMjXwKjehndN__p9QjsTf9B9Js=.5875bc1b-07e3-4c07-b9c4-c727f8103eef@github.com>
Message-ID: <wQBsTj0KvZ7rck0NUDidYgao4zGeX78K-rxKB-e5tpA=.1922d92c-7594-4937-a2d5-2399a8d7e559@github.com>

On Wed, 3 Feb 2021 20:04:18 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> See comment above about `gdb`, the same applies to `lldb` today. The AArch64 backend uses `SIGILL` (~= `EXC_MASK_BAD_INSTRUCTION`) to initiate a deoptimization. Without this change you cannot continue debugging once you the debuggee receives `SIGILL`. This wasn't needed before as x86 doesn't use `SIGILL`.
>
> Part of the comment said `This work-around is not necessary for 10.5+, as CrashReporter no longer intercedes on caught fatal signals.` so I thought it was no longer needed, but it sounds like the part about `gdb` still applies then.
> 
> We should update the comment to just say the `gdb` relevant part perhaps (and evaluate which of the EXC_MASK_BAD_ACCESS | EXC_MASK_BAD_INSTRUCTION | EXC_MASK_ARITHMETIC) we actually need for gdb:
> 
>  `// gdb installs both standard BSD signal handlers, and mach exception`
>  `// handlers. By replacing the existing task exception handler, we disable gdb's mach`
>  `// exception handling, while leaving the standard BSD signal handlers functional.`
> 
> Do you know if this also apply to `lldb` or is it `gdb` only specific? How do you run `gdb` on macOS nowadays anyhow?

To answer my own question, it seems that code is still needed on `x86_64` for `lldb` with `EXC_MASK_BAD_ACCESS` or we keep tripping over `EXC_BAD_ACCESS`

Remaining questions:

a) why we need `EXC_MASK_ARITHMETIC` ?
b) we hit `signal SIGSEGV` in debugger even with the code in place, any way to avoid that?
c) does `BSD aarch64` need only `EXC_MASK_BAD_INSTRUCTION` or does it need `EXC_MASK_BAD_ACCESS` as well?
d) can we `#ifdef` the `EXC_MASK_BAD_INSTRUCTION` part of the mask only to apply to `aarch64`?

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

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

From cjplummer at openjdk.java.net  Wed Feb  3 20:52:42 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 3 Feb 2021 20:52:42 GMT
Subject: RFR: 8257988: Remove JNF dependency from
 libsaproc/MacosxDebuggerLocal.m [v2]
In-Reply-To: <3hZqDjqCTVPr34viaIoK9mbEvs5rAOOhX7GPgWBNrP8=.dae1f4d1-4384-454a-9e71-05f86ba0ca0a@github.com>
References: <cUes5jnPfmVPzfl9a6CeLDL3m34aLsa1oIoetgnANzI=.d9440b4c-9c8e-48f8-b573-6cb5c35242d7@github.com>
 <3hZqDjqCTVPr34viaIoK9mbEvs5rAOOhX7GPgWBNrP8=.dae1f4d1-4384-454a-9e71-05f86ba0ca0a@github.com>
Message-ID: <r53Yjsk1B-gJiht1X76nu0a4Ro4VDGwERxFcp1cW7nw=.5a474c10-1b88-44d9-91fe-ffd7d0316d21@github.com>

On Wed, 3 Feb 2021 20:17:03 GMT, Phil Race <prr at openjdk.org> wrote:

>> This removes the JNF dependency from the jdk.hotspot.agent module.
>> The macro expansions are the same as already used in the Java desktop module - which actually uses a macro
>> still but there there are hundreds of uses.
>> The function of this macro code is to prevent NSExceptions escaping to Java and also to drain the auto-release pool.
>> What test group would be good for verifying this change ?
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8257988: Remove JNF dependency from libsaproc/MacosxDebuggerLocal.m

Marked as reviewed by cjplummer (Reviewer).

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

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

From cjplummer at openjdk.java.net  Wed Feb  3 21:36:41 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 3 Feb 2021 21:36:41 GMT
Subject: RFR: JDK-8261034: improve jcmd GC.class_histogram to support
 parallel
In-Reply-To: <VKzVY-01CEXUbQdlKMhDWjtjxUgpxs_6487x232VsAI=.3b9c5d8a-972b-4997-9f75-1951f98e1751@github.com>
References: <VKzVY-01CEXUbQdlKMhDWjtjxUgpxs_6487x232VsAI=.3b9c5d8a-972b-4997-9f75-1951f98e1751@github.com>
Message-ID: <BWaUKtnK-yrdctz5EX_ACTm27QiJHSvnsfPe42sI1vw=.a8c96623-0f6c-484e-9cce-1d9b1a3634e8@github.com>

On Wed, 3 Feb 2021 12:44:53 GMT, Hamlin Li <mli at openjdk.org> wrote:

> parallel -histo of jmap was added by JDK-8214535, it's better to support parallel for jcmd GC.class_histogram too.

I think you'll need a CSR just as [JDK-8215624](https://bugs.openjdk.java.net/browse/JDK-8215624). Also, a test is needed. There are a couple of tests under `test/hotspot/jtreg/serviceability/dcmd/gc` that already test `GC.class_histogram`. You could probably clone or modify one of them to test the new `-parallel` option.

src/hotspot/share/services/diagnosticCommand.cpp line 559:

> 557:        "BOOLEAN", false, "false"),
> 558:   _parallel_thread_num("-parallel", "parallel threads number for heap iteration",
> 559:        "INT", false, "0")     {

Does "0" mean use a default number of parallel threads as it does for the jmap? It's unclear, but it seems that it doesn't, which I think leads to eventually hitting this assert in `update_active_workers(uint v)`:
    assert(v != 0, "Trying to set active workers to 0");
If that's not the case, please explain how 0 is handled. In any case, I think it should be made consistent with jmap and should also be documented in the above  help output:
  parallel=<count> generate histogram using this many parallel threads, default 0
                     0 use system determined number of threads
                     1 use one thread, i.e., disable parallelism
                     n use n threads, n must be positive

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

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

From cjplummer at openjdk.java.net  Wed Feb  3 21:54:40 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 3 Feb 2021 21:54:40 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump
In-Reply-To: <vN4ZxgYOLsOQLqwyX4fXMJsQ-LM-S5JqeZoWdMXzmqc=.dfdc97a5-4838-4f09-9082-e5562c4691e0@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
 <crJcuaqSgYZQCEw2lqGaLpRmCVOXr99P1i5bcnSFpQc=.cb824923-e649-4ecd-ba5b-8d26cb93b265@github.com>
 <esex_demB2ZT0CsAp2WrzNGC_gieM9USGg_fYgmFCAE=.1911dd08-7dcc-4d88-9532-5d670399dd62@github.com>
 <ztN32xTk5joNRB7MhfYMl9zHCfGA1j8bQNu-ke975qc=.4c7ff2a9-2af8-495d-8f22-83e98c2e3221@github.com>
 <oQe3_j7vewkS8wlIuYXRCa_86pI215cFIceztTf5jX0=.d6d6201b-ec15-418e-a73b-e907d9d02607@github.com>
 <oPJ9OfKdD8CTbihLREww1QM2hc3Ckiai0-1OSpkq830=.87c4f119-07c9-471f-8c25-99dcfaad8d11@github.com>
 <ngMsS8jp0GTuqLVGD5k2ZL5AckbFwh8CBj5ec_GaBes=.0c51dacf-b158-4e62-874d-5e9c5a7b5f8e@github.com>
 <JDsbDqJRQ0V_s1SvGBhr3FLu98T2-X51kpkCs8s8vxQ=.fdb2242c-8706-4057-b4aa-084cfcb24166@github.com>
 <cHsGHKQrSqSUKJJ2OIRVUYuKUVOJGH-Pch-aDmoPj64=.88025b63-b0bb-401a-a749-57089ebea3aa@github.com>
 <gnDO9moDHlyHgJCEdcILr-MauRQgQP7I6QE38XZHus0=.4e488aca-8206-4db5-acec-5c029a6328ca@github.com>
 <vN4ZxgYOLsOQLqwyX4fXMJsQ-LM-S5JqeZo
 WdMXzmqc=.dfdc97a5-4838-4f09-9082-e5562c4691e0@github.com>
Message-ID: <hLyibl3_enSszfZLKP74PE3i_ranX51N3nNiX0F9KoA=.8f2fea52-c394-4612-9c74-d9d975a3c42a@github.com>

On Wed, 3 Feb 2021 02:19:43 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> Hi All,
>> As discussed in this PR, it is reasonable to enable parallel heap dump by default rather than introducing a new "parallel" option. I would like to close the CSR at https://bugs.openjdk.java.net/browse/JDK-8260424.
>
> Dear All,
> I have updated the patch and remove the introduction of new "parallel" option. So there can be no backward-compatibility issue for jmap -dump command.  May I ask your help to remove the CSR label if agreed? 
> 
> BRs,
> Lin

Hi Lin, When I suggested that it would ok just to just always use the default number of parallel threads, I wasn't considering that we also have `jmap -histo`, which also supports parallel threads, but includes an argument to specify it. For example, `jmap -histo:parallel=<n>`. Now this PR adds parallel support to `jmap -dump`, but you are suggesting not to have a parallel option to specify it, and use a default number of threads, which would be the same as what you would get with `jmap -histo:parallel=0`.  So this is inconsistent. If `-histo` is going to allow you to control the number of parallel threads, then `-dump` should also. I guess an option would be to not allow `-histo` to control the number of threads, and have it work just like you are proposing for `-dump`.

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

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

From prr at openjdk.java.net  Wed Feb  3 22:00:42 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 3 Feb 2021 22:00:42 GMT
Subject: Integrated: 8257988: Remove JNF dependency from
 libsaproc/MacosxDebuggerLocal.m
In-Reply-To: <cUes5jnPfmVPzfl9a6CeLDL3m34aLsa1oIoetgnANzI=.d9440b4c-9c8e-48f8-b573-6cb5c35242d7@github.com>
References: <cUes5jnPfmVPzfl9a6CeLDL3m34aLsa1oIoetgnANzI=.d9440b4c-9c8e-48f8-b573-6cb5c35242d7@github.com>
Message-ID: <WOlObHgg2e5bR96kqLn_6SI0gpJmj7fzmS4OjMpP7RY=.b8ceb994-49dc-49de-91f1-a7e723c366d2@github.com>

On Thu, 28 Jan 2021 22:40:57 GMT, Phil Race <prr at openjdk.org> wrote:

> This removes the JNF dependency from the jdk.hotspot.agent module.
> The macro expansions are the same as already used in the Java desktop module - which actually uses a macro
> still but there there are hundreds of uses.
> The function of this macro code is to prevent NSExceptions escaping to Java and also to drain the auto-release pool.
> What test group would be good for verifying this change ?

This pull request has now been integrated.

Changeset: 2be60e37
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2be60e37
Stats:     45 lines in 2 files changed: 35 ins; 2 del; 8 mod

8257988: Remove JNF dependency from libsaproc/MacosxDebuggerLocal.m

Reviewed-by: ihse, cjplummer

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

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

From cjplummer at openjdk.java.net  Wed Feb  3 22:04:50 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 3 Feb 2021 22:04:50 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump
In-Reply-To: <hLyibl3_enSszfZLKP74PE3i_ranX51N3nNiX0F9KoA=.8f2fea52-c394-4612-9c74-d9d975a3c42a@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
 <crJcuaqSgYZQCEw2lqGaLpRmCVOXr99P1i5bcnSFpQc=.cb824923-e649-4ecd-ba5b-8d26cb93b265@github.com>
 <esex_demB2ZT0CsAp2WrzNGC_gieM9USGg_fYgmFCAE=.1911dd08-7dcc-4d88-9532-5d670399dd62@github.com>
 <ztN32xTk5joNRB7MhfYMl9zHCfGA1j8bQNu-ke975qc=.4c7ff2a9-2af8-495d-8f22-83e98c2e3221@github.com>
 <oQe3_j7vewkS8wlIuYXRCa_86pI215cFIceztTf5jX0=.d6d6201b-ec15-418e-a73b-e907d9d02607@github.com>
 <oPJ9OfKdD8CTbihLREww1QM2hc3Ckiai0-1OSpkq830=.87c4f119-07c9-471f-8c25-99dcfaad8d11@github.com>
 <ngMsS8jp0GTuqLVGD5k2ZL5AckbFwh8CBj5ec_GaBes=.0c51dacf-b158-4e62-874d-5e9c5a7b5f8e@github.com>
 <JDsbDqJRQ0V_s1SvGBhr3FLu98T2-X51kpkCs8s8vxQ=.fdb2242c-8706-4057-b4aa-084cfcb24166@github.com>
 <cHsGHKQrSqSUKJJ2OIRVUYuKUVOJGH-Pch-aDmoPj64=.88025b63-b0bb-401a-a749-57089ebea3aa@github.com>
 <gnDO9moDHlyHgJCEdcILr-MauRQgQP7I6QE38XZHus0=.4e488aca-8206-4db5-acec-5c029a6328ca@github.com>
 <vN4ZxgYOLsOQLqwyX4fXMJsQ-LM-S5JqeZo
 WdMXzmqc=.dfdc97a5-4838-4f09-9082-e5562c4691e0@github.com>
 <hLyibl3_enSszfZLKP74PE3i_ranX51N3nNiX0F9KoA=.8f2fea52-c394-4612-9c74-d9d975a3c42a@github.com>
Message-ID: <Gs7-OplIQn5Vtq9vmQ6QXnB3l_XGSwfsagD044OQ2RM=.564b8980-fd3b-4555-864c-33c1b55a9fbd@github.com>

On Wed, 3 Feb 2021 21:52:00 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Dear All,
>> I have updated the patch and remove the introduction of new "parallel" option. So there can be no backward-compatibility issue for jmap -dump command.  May I ask your help to remove the CSR label if agreed? 
>> 
>> BRs,
>> Lin
>
> Hi Lin, When I suggested that it would ok just to just always use the default number of parallel threads, I wasn't considering that we also have `jmap -histo`, which also supports parallel threads, but includes an argument to specify it. For example, `jmap -histo:parallel=<n>`. Now this PR adds parallel support to `jmap -dump`, but you are suggesting not to have a parallel option to specify it, and use a default number of threads, which would be the same as what you would get with `jmap -histo:parallel=0`.  So this is inconsistent. If `-histo` is going to allow you to control the number of parallel threads, then `-dump` should also. I guess an option would be to not allow `-histo` to control the number of threads, and have it work just like you are proposing for `-dump`.

Here's another thought. What if we added a new Attach API command called something like `setparallel`. Then when you specify `parallel=<n>` for  `jmap -histo` or `jmap -dump`, first JMap would send the `setparallel` command, and then it would send the `dumpheap` or `inspectheap` commands, and they would use the parallel setting from the previous `setparallel` command. I assume of `setparallel` is sent to an older JDK, I think you just get an error message back that can be ignored.

Anyway, just throwing this idea out there. I'm not so sure I like it myself, but given we don't have a good solution yet, it may be as good as any of the others.

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

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

From amenkov at openjdk.java.net  Wed Feb  3 22:17:03 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Wed, 3 Feb 2021 22:17:03 GMT
Subject: RFR: 8260431: com/sun/jdi/JdbOptions.java failed with
 "RuntimeException: 'prop[boo] = >foo<' missing from stdout/stderr" [v2]
In-Reply-To: <yJAqWSrjL-E2p_2vZUEcmwznaodNn-KsbGOntHWwkZs=.5ac1e125-8932-4c09-b3a6-d7838b28e5dd@github.com>
References: <yJAqWSrjL-E2p_2vZUEcmwznaodNn-KsbGOntHWwkZs=.5ac1e125-8932-4c09-b3a6-d7838b28e5dd@github.com>
Message-ID: <KM9yOr-DSCAn9507z_YhmQD7vVcrWVD9rUm7cxM6_J0=.fe92e1f3-0456-4af8-84ad-85e6575f4cd0@github.com>

> The test expects debuggee output in jdb output stream.
> But jdb redirects debuggee output asynchronously so sometimes it's incomplete or mixed with jdb output.
> The fix updates debuggee to print output to file and read/analyze it after jdb (and debuggee) exits.

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  separated debuggee class name and args

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2322/files
  - new: https://git.openjdk.java.net/jdk/pull/2322/files/ac0b08b0..fbd3f8ec

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

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

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

From cjplummer at openjdk.java.net  Wed Feb  3 22:19:52 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 3 Feb 2021 22:19:52 GMT
Subject: RFR: 8248876: LoadObject with bad base address created for exec
 file on linux
In-Reply-To: <R53sQGWiJHl8JzP_wmXoupayROl3DVu0l0rBCzYurWY=.4d6762e8-1de6-4b7d-805f-0a9b977950fb@github.com>
References: <R53sQGWiJHl8JzP_wmXoupayROl3DVu0l0rBCzYurWY=.4d6762e8-1de6-4b7d-805f-0a9b977950fb@github.com>
Message-ID: <f1274sofRndSfbHeMMqKwwOrJercIi9B4gI7WoP17Bw=.2c539e92-06fa-4efe-86eb-d416f4caf83e@github.com>

On Tue, 2 Feb 2021 23:37:21 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> We could see NPE on `LinuxCDebugger::loadObjectContainingPC` which is used mainly by the clhsdb `findpc` command. (See [JDK-8248876](https://bugs.openjdk.java.net/browse/JDK-8248876) for more details)
> 
> It is caused by PIE executable handling.
> 
> Currently we use virtual address of top of PT_LOAD in executable as base address - it is valid for ET_EXEC binary.
> However, in case of ET_DYN binary (PIE binary), we should handle it like a shared library.
> In GDB, base address of executable would be calculated by dynamic section. SA should also do so.

Marked as reviewed by cjplummer (Reviewer).

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

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

From burban at openjdk.java.net  Wed Feb  3 22:19:58 2021
From: burban at openjdk.java.net (Bernhard Urban-Forster)
Date: Wed, 3 Feb 2021 22:19:58 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
In-Reply-To: <wQBsTj0KvZ7rck0NUDidYgao4zGeX78K-rxKB-e5tpA=.1922d92c-7594-4937-a2d5-2399a8d7e559@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>
 <gdmSyDFlKNJfjwP2R9NL99cuUnJvVlNAVSuTGXX1aGI=.5ae84a36-aaf7-44d5-968f-594d09c71683@github.com>
 <fHJqmfpRVckaOW7MOyMjXwKjehndN__p9QjsTf9B9Js=.5875bc1b-07e3-4c07-b9c4-c727f8103eef@github.com>
 <wQBsTj0KvZ7rck0NUDidYgao4zGeX78K-rxKB-e5tpA=.1922d92c-7594-4937-a2d5-2399a8d7e559@github.com>
Message-ID: <qojI0u-VDQwQaoiqXAunT3_yqDzr3BBK25K27nBtb3g=.eeb61acb-ca8b-4b7b-9fe7-482c3ce92b14@github.com>

On Wed, 3 Feb 2021 20:29:48 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Part of the comment said `This work-around is not necessary for 10.5+, as CrashReporter no longer intercedes on caught fatal signals.` so I thought it was no longer needed, but it sounds like the part about `gdb` still applies then.
>> 
>> We should update the comment to just say the `gdb` relevant part perhaps (and evaluate which of the EXC_MASK_BAD_ACCESS | EXC_MASK_BAD_INSTRUCTION | EXC_MASK_ARITHMETIC) we actually need for gdb:
>> 
>>  `// gdb installs both standard BSD signal handlers, and mach exception`
>>  `// handlers. By replacing the existing task exception handler, we disable gdb's mach`
>>  `// exception handling, while leaving the standard BSD signal handlers functional.`
>> 
>> Do you know if this also apply to `lldb` or is it `gdb` only specific? How do you run `gdb` on macOS nowadays anyhow?
>
> To answer my own question, it seems that code is still needed on `x86_64` for `lldb` with `EXC_MASK_BAD_ACCESS` or we keep tripping over `EXC_BAD_ACCESS`
> 
> Remaining questions:
> 
> a) why we need `EXC_MASK_ARITHMETIC` ?
> b) we hit `signal SIGSEGV` in debugger even with the code in place, any way to avoid that?
> c) does `BSD aarch64` need only `EXC_MASK_BAD_INSTRUCTION` or does it need `EXC_MASK_BAD_ACCESS` as well?
> d) can we `#ifdef` the `EXC_MASK_BAD_INSTRUCTION` part of the mask only to apply to `aarch64`?

Thanks for your questions Gerard.

> Part of the comment said This work-around is not necessary for 10.5+, as CrashReporter no longer intercedes on caught fatal signals.

That comment can probably be deleted since minversion is anyway 10.9 (and soon 10.12 https://github.com/openjdk/jdk/pull/2268 ).

> Do you know if this also apply to lldb or is it gdb only specific? How do you run gdb on macOS nowadays anyhow?

`lldb` is shipped with Xcode, `gdb` isn't. You would need to build and sign it yourself, I haven't tried that in a while. So, we should update that comment to talk about `lldb` ?? 

> a) why we need `EXC_MASK_ARITHMETIC` ?

I _believe_ this dates back to i386. As far as I can tell this isn't needed for x86_64 or aarch64. I guess we can remove it, the worst case is that it makes the debugging experience of the runtime a little bit worse. OTOH it doesn't hurt either to have it here.

> b) we hit signal SIGSEGV in debugger even with the code in place, any way to avoid that?

The equivalent for `handle SIGSEGV nostop noprint` (gdb) in lldb is `process handle -n false -p true -s false SIGSEGV`.

> c) does `BSD aarch6` need only `EXC_MASK_BAD_INSTRUCTION` or does it need `EXC_MASK_BAD_ACCESS` as well?

aarch64 needs `EXC_MASK_BAD_ACCESS` at least for implicit null checking, there might be other cases.

> d) can we `#ifdef` the `EXC_MASK_BAD_INSTRUCTION` part of the mask only to apply to `aarch64`?

Maybe. I don't see any value in it though, except making the code more complicated to read ??

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

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

From sspitsyn at openjdk.java.net  Wed Feb  3 23:54:52 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Wed, 3 Feb 2021 23:54:52 GMT
Subject: RFR: 8260431: com/sun/jdi/JdbOptions.java failed with
 "RuntimeException: 'prop[boo] = >foo<' missing from stdout/stderr" [v2]
In-Reply-To: <KM9yOr-DSCAn9507z_YhmQD7vVcrWVD9rUm7cxM6_J0=.fe92e1f3-0456-4af8-84ad-85e6575f4cd0@github.com>
References: <yJAqWSrjL-E2p_2vZUEcmwznaodNn-KsbGOntHWwkZs=.5ac1e125-8932-4c09-b3a6-d7838b28e5dd@github.com>
 <KM9yOr-DSCAn9507z_YhmQD7vVcrWVD9rUm7cxM6_J0=.fe92e1f3-0456-4af8-84ad-85e6575f4cd0@github.com>
Message-ID: <sB4ZiTMGu8x59vJuB7HWmODt_eWchUZKY7DecxzGIAg=.97bada92-ee58-435b-8cce-3d81e6c9b1cd@github.com>

On Wed, 3 Feb 2021 22:17:03 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The test expects debuggee output in jdb output stream.
>> But jdb redirects debuggee output asynchronously so sometimes it's incomplete or mixed with jdb output.
>> The fix updates debuggee to print output to file and read/analyze it after jdb (and debuggee) exits.
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   separated debuggee class name and args

Hi Alex,
It looks good to me.
I liked previous variant as well.
It looks a little bit strange to duplicate the same  pattern on many lines:
  "targ + outFileArg"
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

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

From cjplummer at openjdk.java.net  Wed Feb  3 23:54:56 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 3 Feb 2021 23:54:56 GMT
Subject: RFR: 8260431: com/sun/jdi/JdbOptions.java failed with
 "RuntimeException: 'prop[boo] = >foo<' missing from stdout/stderr" [v2]
In-Reply-To: <KM9yOr-DSCAn9507z_YhmQD7vVcrWVD9rUm7cxM6_J0=.fe92e1f3-0456-4af8-84ad-85e6575f4cd0@github.com>
References: <yJAqWSrjL-E2p_2vZUEcmwznaodNn-KsbGOntHWwkZs=.5ac1e125-8932-4c09-b3a6-d7838b28e5dd@github.com>
 <KM9yOr-DSCAn9507z_YhmQD7vVcrWVD9rUm7cxM6_J0=.fe92e1f3-0456-4af8-84ad-85e6575f4cd0@github.com>
Message-ID: <e5aNkqtAFEMi4w1WUvTzFuuXX_i6uOum0co4_2nyPsU=.a184c206-be43-4839-bbb1-1cedea21ac3a@github.com>

On Wed, 3 Feb 2021 22:17:03 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The test expects debuggee output in jdb output stream.
>> But jdb redirects debuggee output asynchronously so sometimes it's incomplete or mixed with jdb output.
>> The fix updates debuggee to print output to file and read/analyze it after jdb (and debuggee) exits.
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   separated debuggee class name and args

test/jdk/com/sun/jdi/JdbOptions.java line 91:

> 89:         // the simplest case
> 90:         test("-connect",
> 91:                 "com.sun.jdi.CommandLineLaunch:vmexec=java,options=-client -XX:+PrintVMOptions,main=" + targ + outFileArg)

Not to be too nit picky, but I was assuming that the " " would be here and not in outFileName. That would make it much more obvious how the args are separated (eg we are not using commas here).

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

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

From gziemski at openjdk.java.net  Wed Feb  3 23:55:06 2021
From: gziemski at openjdk.java.net (Gerard Ziemski)
Date: Wed, 3 Feb 2021 23:55:06 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
In-Reply-To: <qojI0u-VDQwQaoiqXAunT3_yqDzr3BBK25K27nBtb3g=.eeb61acb-ca8b-4b7b-9fe7-482c3ce92b14@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>
 <gdmSyDFlKNJfjwP2R9NL99cuUnJvVlNAVSuTGXX1aGI=.5ae84a36-aaf7-44d5-968f-594d09c71683@github.com>
 <fHJqmfpRVckaOW7MOyMjXwKjehndN__p9QjsTf9B9Js=.5875bc1b-07e3-4c07-b9c4-c727f8103eef@github.com>
 <wQBsTj0KvZ7rck0NUDidYgao4zGeX78K-rxKB-e5tpA=.1922d92c-7594-4937-a2d5-2399a8d7e559@github.com>
 <qojI0u-VDQwQaoiqXAunT3_yqDzr3BBK25K27nBtb3g=.eeb61acb-ca8b-4b7b-9fe7-482c3ce92b14@github.com>
Message-ID: <ywsbiBtPywrS-Ouy15DesxAwaKcefenfqEy0F8kaZfM=.f9c21d8d-79e9-4ff6-ab8c-885e0662efb7@github.com>

On Wed, 3 Feb 2021 22:17:02 GMT, Bernhard Urban-Forster <burban at openjdk.org> wrote:

>> To answer my own question, it seems that code is still needed on `x86_64` for `lldb` with `EXC_MASK_BAD_ACCESS` or we keep tripping over `EXC_BAD_ACCESS`
>> 
>> Remaining questions:
>> 
>> a) why we need `EXC_MASK_ARITHMETIC` ?
>> b) we hit `signal SIGSEGV` in debugger even with the code in place, any way to avoid that?
>> c) does `BSD aarch64` need only `EXC_MASK_BAD_INSTRUCTION` or does it need `EXC_MASK_BAD_ACCESS` as well?
>> d) can we `#ifdef` the `EXC_MASK_BAD_INSTRUCTION` part of the mask only to apply to `aarch64`?
>
> Thanks for your questions Gerard.
> 
>> Part of the comment said This work-around is not necessary for 10.5+, as CrashReporter no longer intercedes on caught fatal signals.
> 
> That comment can probably be deleted since minversion is anyway 10.9 (and soon 10.12 https://github.com/openjdk/jdk/pull/2268 ).
> 
>> Do you know if this also apply to lldb or is it gdb only specific? How do you run gdb on macOS nowadays anyhow?
> 
> `lldb` is shipped with Xcode, `gdb` isn't. You would need to build and sign it yourself, I haven't tried that in a while. So, we should update that comment to talk about `lldb` ?? 
> 
>> a) why we need `EXC_MASK_ARITHMETIC` ?
> 
> I _believe_ this dates back to i386. As far as I can tell this isn't needed for x86_64 or aarch64. I guess we can remove it, the worst case is that it makes the debugging experience of the runtime a little bit worse. OTOH it doesn't hurt either to have it here.
> 
>> b) we hit signal SIGSEGV in debugger even with the code in place, any way to avoid that?
> 
> The equivalent for `handle SIGSEGV nostop noprint` (gdb) in lldb is `process handle -n false -p true -s false SIGSEGV`.
> 
>> c) does `BSD aarch6` need only `EXC_MASK_BAD_INSTRUCTION` or does it need `EXC_MASK_BAD_ACCESS` as well?
> 
> aarch64 needs `EXC_MASK_BAD_ACCESS` at least for implicit null checking, there might be other cases.
> 
>> d) can we `#ifdef` the `EXC_MASK_BAD_INSTRUCTION` part of the mask only to apply to `aarch64`?
> 
> Maybe. I don't see any value in it though, except making the code more complicated to read ??

I don't like the idea of using masks on architectures that do not require them. How about something like this?

`#if defined(__APPLE__)`
`  // lldb (gdb) installs both standard BSD signal handlers, and mach exception`
`  // handlers. By replacing the existing task exception handler, we disable lldb's mach`
`  // exception handling, while leaving the standard BSD signal handlers functional.`
`  //`
`  // EXC_MASK_BAD_ACCESS needed by all architectures for NULL ptr checking`
`  // EXC_MASK_ARITHMETIC needed by i386`
`  // EXC_MASK_BAD_INSTRUCTION needed by aarch64 to initiate deoptimization`
`  kern_return_t kr;`
`  kr = task_set_exception_ports(mach_task_self(),`
`                                EXC_MASK_BAD_ACCESS`
`                                NOT_LP64(| EXC_MASK_ARITHMETIC)`
`                                AARCH64_ONLY(| EXC_MASK_BAD_INSTRUCTION),`
`                                MACH_PORT_NULL,`
`                                EXCEPTION_STATE_IDENTITY,`
`                                MACHINE_THREAD_STATE);`
` `
`  assert(kr == KERN_SUCCESS, "could not set mach task signal handler");`
`#endif`

If I just knew why i386 needs `EXC_MASK_ARITHMETIC` and add that to the comment I would be personally happy with that chunk of code.

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

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

From gziemski at openjdk.java.net  Wed Feb  3 23:55:07 2021
From: gziemski at openjdk.java.net (Gerard Ziemski)
Date: Wed, 3 Feb 2021 23:55:07 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
In-Reply-To: <ywsbiBtPywrS-Ouy15DesxAwaKcefenfqEy0F8kaZfM=.f9c21d8d-79e9-4ff6-ab8c-885e0662efb7@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>
 <gdmSyDFlKNJfjwP2R9NL99cuUnJvVlNAVSuTGXX1aGI=.5ae84a36-aaf7-44d5-968f-594d09c71683@github.com>
 <fHJqmfpRVckaOW7MOyMjXwKjehndN__p9QjsTf9B9Js=.5875bc1b-07e3-4c07-b9c4-c727f8103eef@github.com>
 <wQBsTj0KvZ7rck0NUDidYgao4zGeX78K-rxKB-e5tpA=.1922d92c-7594-4937-a2d5-2399a8d7e559@github.com>
 <qojI0u-VDQwQaoiqXAunT3_yqDzr3BBK25K27nBtb3g=.eeb61acb-ca8b-4b7b-9fe7-482c3ce92b14@github.com>
 <ywsbiBtPywrS-Ouy15DesxAwaKcefenfqEy0F8kaZfM=.f9c21d8d-79e9-4ff6-ab8c-885e0662efb7@github.com>
Message-ID: <lNhDXQS_2VEZmm1RPX0lkcbJ4kKQvYEyufORZ8TEHMk=.168a7f7f-27b5-4c9c-abfc-35170587c856@github.com>

On Wed, 3 Feb 2021 22:44:18 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Thanks for your questions Gerard.
>> 
>>> Part of the comment said This work-around is not necessary for 10.5+, as CrashReporter no longer intercedes on caught fatal signals.
>> 
>> That comment can probably be deleted since minversion is anyway 10.9 (and soon 10.12 https://github.com/openjdk/jdk/pull/2268 ).
>> 
>>> Do you know if this also apply to lldb or is it gdb only specific? How do you run gdb on macOS nowadays anyhow?
>> 
>> `lldb` is shipped with Xcode, `gdb` isn't. You would need to build and sign it yourself, I haven't tried that in a while. So, we should update that comment to talk about `lldb` ?? 
>> 
>>> a) why we need `EXC_MASK_ARITHMETIC` ?
>> 
>> I _believe_ this dates back to i386. As far as I can tell this isn't needed for x86_64 or aarch64. I guess we can remove it, the worst case is that it makes the debugging experience of the runtime a little bit worse. OTOH it doesn't hurt either to have it here.
>> 
>>> b) we hit signal SIGSEGV in debugger even with the code in place, any way to avoid that?
>> 
>> The equivalent for `handle SIGSEGV nostop noprint` (gdb) in lldb is `process handle -n false -p true -s false SIGSEGV`.
>> 
>>> c) does `BSD aarch6` need only `EXC_MASK_BAD_INSTRUCTION` or does it need `EXC_MASK_BAD_ACCESS` as well?
>> 
>> aarch64 needs `EXC_MASK_BAD_ACCESS` at least for implicit null checking, there might be other cases.
>> 
>>> d) can we `#ifdef` the `EXC_MASK_BAD_INSTRUCTION` part of the mask only to apply to `aarch64`?
>> 
>> Maybe. I don't see any value in it though, except making the code more complicated to read ??
>
> I don't like the idea of using masks on architectures that do not require them. How about something like this?
> 
> `#if defined(__APPLE__)`
> `  // lldb (gdb) installs both standard BSD signal handlers, and mach exception`
> `  // handlers. By replacing the existing task exception handler, we disable lldb's mach`
> `  // exception handling, while leaving the standard BSD signal handlers functional.`
> `  //`
> `  // EXC_MASK_BAD_ACCESS needed by all architectures for NULL ptr checking`
> `  // EXC_MASK_ARITHMETIC needed by i386`
> `  // EXC_MASK_BAD_INSTRUCTION needed by aarch64 to initiate deoptimization`
> `  kern_return_t kr;`
> `  kr = task_set_exception_ports(mach_task_self(),`
> `                                EXC_MASK_BAD_ACCESS`
> `                                NOT_LP64(| EXC_MASK_ARITHMETIC)`
> `                                AARCH64_ONLY(| EXC_MASK_BAD_INSTRUCTION),`
> `                                MACH_PORT_NULL,`
> `                                EXCEPTION_STATE_IDENTITY,`
> `                                MACHINE_THREAD_STATE);`
> ` `
> `  assert(kr == KERN_SUCCESS, "could not set mach task signal handler");`
> `#endif`
> 
> If I just knew why i386 needs `EXC_MASK_ARITHMETIC` and add that to the comment I would be personally happy with that chunk of code.

No idea how to insert spaces and make text align :-(

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

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

From gziemski at openjdk.java.net  Wed Feb  3 23:55:07 2021
From: gziemski at openjdk.java.net (Gerard Ziemski)
Date: Wed, 3 Feb 2021 23:55:07 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
In-Reply-To: <hKXPfOkcCykuWVivbdtVTwN18T_iOWP5jgBzEGJxSSQ=.b37718c5-f5f1-44e8-82d6-518d76398e91@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>
 <gdmSyDFlKNJfjwP2R9NL99cuUnJvVlNAVSuTGXX1aGI=.5ae84a36-aaf7-44d5-968f-594d09c71683@github.com>
 <fHJqmfpRVckaOW7MOyMjXwKjehndN__p9QjsTf9B9Js=.5875bc1b-07e3-4c07-b9c4-c727f8103eef@github.com>
 <wQBsTj0KvZ7rck0NUDidYgao4zGeX78K-rxKB-e5tpA=.1922d92c-7594-4937-a2d5-2399a8d7e559@github.com>
 <qojI0u-VDQwQaoiqXAunT3_yqDzr3BBK25K27nBtb3g=.eeb61acb-ca8b-4b7b-9fe7-482c3ce92b14@github.com>
 <ywsbiBtPywrS-Ouy15DesxAwaKcefenfqEy0F8kaZfM=.f9c21d8d-79e9-4ff6-ab8c-885e0662efb7@github.com>
 <lNhDXQS_2VEZmm1RPX0lkcbJ4kKQvYEyufORZ8TEHMk=.168a7f7f-27b5-4c9c-abfc-35170587c856@github.com>
 <hKXPfOkcCykuWVivbdtVTwN18T_iOWP5jgBzEGJxSSQ=.b37718c5-f5f1-44e8-82d6-518d76398e91@github.com>
Message-ID: <ufvmALKCsU5RoY8Sqxdp7JKcBY2N4F6nwwg72Lc1ESQ=.075d302c-c039-4819-b061-a0d3559b766c@github.com>

On Wed, 3 Feb 2021 23:13:12 GMT, Bernhard Urban-Forster <burban at openjdk.org> wrote:

>> No idea how to insert spaces and make text align :-(
>
> using ` ```c ` https://docs.github.com/en/github/writing-on-github/creating-and-highlighting-code-blocks
> 
> I was wrong about `SIGFPE` / `EXC_MASK_ARITHMETIC`, it's used on i386, x86_64:
> https://github.com/openjdk/jdk/blob/2be60e37e0e433141b2e3d3e32f8e638a4888e3a/src/hotspot/os_cpu/bsd_x86/os_bsd_x86.cpp#L467-L524
> and aarch64:
> https://github.com/AntonKozlov/jdk/blob/80827176cbc5f0dd26003cf234a8076f3f557928/src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp#L309-L323
> (What happened with the formatting here, ugh?)
> 
> Your suggestion sounds good otherwise. @AntonKozlov, do you mind to integrate that?

So it should be:

#if defined(__APPLE__)
  // lldb (gdb) installs both standard BSD signal handlers, and mach exception
  // handlers. By replacing the existing task exception handler, we disable lldb's mach
  // exception handling, while leaving the standard BSD signal handlers functional.
  //
  // EXC_MASK_BAD_ACCESS needed by all architectures for NULL ptr checking
  // EXC_MASK_ARITHMETIC needed by all architectures for div by 0 checking
  // EXC_MASK_BAD_INSTRUCTION needed by aarch64 to initiate deoptimization
  kern_return_t kr;
  kr = task_set_exception_ports(mach_task_self(),
                                EXC_MASK_BAD_ACCESS | EXC_MASK_ARITHMETIC
                                AARCH64_ONLY(| EXC_MASK_BAD_INSTRUCTION),
                                MACH_PORT_NULL,
                                EXCEPTION_STATE_IDENTITY,
                                MACHINE_THREAD_STATE);

  assert(kr == KERN_SUCCESS, "could not set mach task signal handler");
#endif

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

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

From burban at openjdk.java.net  Wed Feb  3 23:55:07 2021
From: burban at openjdk.java.net (Bernhard Urban-Forster)
Date: Wed, 3 Feb 2021 23:55:07 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
In-Reply-To: <lNhDXQS_2VEZmm1RPX0lkcbJ4kKQvYEyufORZ8TEHMk=.168a7f7f-27b5-4c9c-abfc-35170587c856@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>
 <gdmSyDFlKNJfjwP2R9NL99cuUnJvVlNAVSuTGXX1aGI=.5ae84a36-aaf7-44d5-968f-594d09c71683@github.com>
 <fHJqmfpRVckaOW7MOyMjXwKjehndN__p9QjsTf9B9Js=.5875bc1b-07e3-4c07-b9c4-c727f8103eef@github.com>
 <wQBsTj0KvZ7rck0NUDidYgao4zGeX78K-rxKB-e5tpA=.1922d92c-7594-4937-a2d5-2399a8d7e559@github.com>
 <qojI0u-VDQwQaoiqXAunT3_yqDzr3BBK25K27nBtb3g=.eeb61acb-ca8b-4b7b-9fe7-482c3ce92b14@github.com>
 <ywsbiBtPywrS-Ouy15DesxAwaKcefenfqEy0F8kaZfM=.f9c21d8d-79e9-4ff6-ab8c-885e0662efb7@github.com>
 <lNhDXQS_2VEZmm1RPX0lkcbJ4kKQvYEyufORZ8TEHMk=.168a7f7f-27b5-4c9c-abfc-35170587c856@github.com>
Message-ID: <hKXPfOkcCykuWVivbdtVTwN18T_iOWP5jgBzEGJxSSQ=.b37718c5-f5f1-44e8-82d6-518d76398e91@github.com>

On Wed, 3 Feb 2021 22:48:33 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> I don't like the idea of using masks on architectures that do not require them. How about something like this?
>> 
>> `#if defined(__APPLE__)`
>> `  // lldb (gdb) installs both standard BSD signal handlers, and mach exception`
>> `  // handlers. By replacing the existing task exception handler, we disable lldb's mach`
>> `  // exception handling, while leaving the standard BSD signal handlers functional.`
>> `  //`
>> `  // EXC_MASK_BAD_ACCESS needed by all architectures for NULL ptr checking`
>> `  // EXC_MASK_ARITHMETIC needed by i386`
>> `  // EXC_MASK_BAD_INSTRUCTION needed by aarch64 to initiate deoptimization`
>> `  kern_return_t kr;`
>> `  kr = task_set_exception_ports(mach_task_self(),`
>> `                                EXC_MASK_BAD_ACCESS`
>> `                                NOT_LP64(| EXC_MASK_ARITHMETIC)`
>> `                                AARCH64_ONLY(| EXC_MASK_BAD_INSTRUCTION),`
>> `                                MACH_PORT_NULL,`
>> `                                EXCEPTION_STATE_IDENTITY,`
>> `                                MACHINE_THREAD_STATE);`
>> ` `
>> `  assert(kr == KERN_SUCCESS, "could not set mach task signal handler");`
>> `#endif`
>> 
>> If I just knew why i386 needs `EXC_MASK_ARITHMETIC` and add that to the comment I would be personally happy with that chunk of code.
>
> No idea how to insert spaces and make text align :-(

using ` ```c ` https://docs.github.com/en/github/writing-on-github/creating-and-highlighting-code-blocks

I was wrong about `SIGFPE` / `EXC_MASK_ARITHMETIC`, it's used on i386, x86_64:
https://github.com/openjdk/jdk/blob/2be60e37e0e433141b2e3d3e32f8e638a4888e3a/src/hotspot/os_cpu/bsd_x86/os_bsd_x86.cpp#L467-L524
and aarch64:
https://github.com/AntonKozlov/jdk/blob/80827176cbc5f0dd26003cf234a8076f3f557928/src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp#L309-L323
(What happened with the formatting here, ugh?)

Your suggestion sounds good otherwise. @AntonKozlov, do you mind to integrate that?

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

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

From amenkov at openjdk.java.net  Thu Feb  4 00:36:57 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Thu, 4 Feb 2021 00:36:57 GMT
Subject: RFR: 8260431: com/sun/jdi/JdbOptions.java failed with
 "RuntimeException: 'prop[boo] = >foo<' missing from stdout/stderr" [v3]
In-Reply-To: <yJAqWSrjL-E2p_2vZUEcmwznaodNn-KsbGOntHWwkZs=.5ac1e125-8932-4c09-b3a6-d7838b28e5dd@github.com>
References: <yJAqWSrjL-E2p_2vZUEcmwznaodNn-KsbGOntHWwkZs=.5ac1e125-8932-4c09-b3a6-d7838b28e5dd@github.com>
Message-ID: <GGP9KSTi-pAH23UbJ3Wmo0oZqJDpVtRMg4zzWcVkCek=.5db672d2-9416-4eaa-a435-29101a09d046@github.com>

> The test expects debuggee output in jdb output stream.
> But jdb redirects debuggee output asynchronously so sometimes it's incomplete or mixed with jdb output.
> The fix updates debuggee to print output to file and read/analyze it after jdb (and debuggee) exits.

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  made command line generation more explicit

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2322/files
  - new: https://git.openjdk.java.net/jdk/pull/2322/files/fbd3f8ec..b7bf749a

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

  Stats: 13 lines in 1 file changed: 4 ins; 1 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2322.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2322/head:pull/2322

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

From jwilhelm at openjdk.java.net  Thu Feb  4 01:24:02 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 4 Feb 2021 01:24:02 GMT
Subject: RFR: Merge jdk16
Message-ID: <L2_q8bEWe8cQRclrCLPoHGIKlEGdSGlG4MwTiMo9Oe4=.b41c5dbc-ca26-4e13-afdd-acaf1e8a4089@github.com>

Forwardport JDK 16 -> JDK 17

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

Commit messages:
 - Merge
 - 8259794: Remove EA from JDK 16 version string starting with Initial RC promotion on Feb 04, 2021(B35)
 - 8260704: ParallelGC: oldgen expansion needs release-store for _end
 - 8260927: StringBuilder::insert is incorrect without Compact Strings
 - 8258378: Final nroff manpage update for JDK 16
 - 8257215: JFR: Events dropped when streaming over a chunk rotation
 - 8260473: [vector] ZGC: VectorReshape test produces incorrect results with ZGC enabled
 - 8260632: Build failures after JDK-8253353
 - 8260339: JVM crashes when executing PhaseIdealLoop::match_fill_loop
 - 8260608: add a regression test for 8260370
 - ... and 2 more: https://git.openjdk.java.net/jdk/compare/f025bc1d...dad835ee

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=2392&range=00.0
 - jdk16: https://webrevs.openjdk.java.net/?repo=jdk&pr=2392&range=00.1

Changes: https://git.openjdk.java.net/jdk/pull/2392/files
  Stats: 2645 lines in 56 files changed: 2497 ins; 69 del; 79 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2392.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2392/head:pull/2392

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

From jwilhelm at openjdk.java.net  Thu Feb  4 02:09:40 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 4 Feb 2021 02:09:40 GMT
Subject: Integrated: Merge jdk16
In-Reply-To: <L2_q8bEWe8cQRclrCLPoHGIKlEGdSGlG4MwTiMo9Oe4=.b41c5dbc-ca26-4e13-afdd-acaf1e8a4089@github.com>
References: <L2_q8bEWe8cQRclrCLPoHGIKlEGdSGlG4MwTiMo9Oe4=.b41c5dbc-ca26-4e13-afdd-acaf1e8a4089@github.com>
Message-ID: <9bIQlW7tZAt5i8quzTGD6Z6vHAG4-Q8-_saIecOJ4dM=.b1dacc8a-2678-417c-958b-650ff659723f@github.com>

On Thu, 4 Feb 2021 01:17:48 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 16 -> JDK 17

This pull request has now been integrated.

Changeset: 9b7a8f19
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9b7a8f19
Stats:     2645 lines in 56 files changed: 2497 ins; 69 del; 79 mod

Merge

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

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

From lzang at openjdk.java.net  Thu Feb  4 03:01:41 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Thu, 4 Feb 2021 03:01:41 GMT
Subject: RFR: JDK-8261034: improve jcmd GC.class_histogram to support
 parallel
In-Reply-To: <VKzVY-01CEXUbQdlKMhDWjtjxUgpxs_6487x232VsAI=.3b9c5d8a-972b-4997-9f75-1951f98e1751@github.com>
References: <VKzVY-01CEXUbQdlKMhDWjtjxUgpxs_6487x232VsAI=.3b9c5d8a-972b-4997-9f75-1951f98e1751@github.com>
Message-ID: <oUkJ0uQKU0kV8Xvvq19Ce5MZda7nQjUp8V9uvIBBBa0=.9a95b0d7-5000-4ebe-9feb-058d4330912f@github.com>

On Wed, 3 Feb 2021 12:44:53 GMT, Hamlin Li <mli at openjdk.org> wrote:

> parallel -histo of jmap was added by JDK-8214535, it's better to support parallel for jcmd GC.class_histogram too.

Hi @Hamlin-Li 
I am not reviewer, but maybe you could add test for "parallel" in BasicJMapTest.java.

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

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

From lzang at openjdk.java.net  Thu Feb  4 03:20:44 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Thu, 4 Feb 2021 03:20:44 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump
In-Reply-To: <Gs7-OplIQn5Vtq9vmQ6QXnB3l_XGSwfsagD044OQ2RM=.564b8980-fd3b-4555-864c-33c1b55a9fbd@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
 <crJcuaqSgYZQCEw2lqGaLpRmCVOXr99P1i5bcnSFpQc=.cb824923-e649-4ecd-ba5b-8d26cb93b265@github.com>
 <esex_demB2ZT0CsAp2WrzNGC_gieM9USGg_fYgmFCAE=.1911dd08-7dcc-4d88-9532-5d670399dd62@github.com>
 <ztN32xTk5joNRB7MhfYMl9zHCfGA1j8bQNu-ke975qc=.4c7ff2a9-2af8-495d-8f22-83e98c2e3221@github.com>
 <oQe3_j7vewkS8wlIuYXRCa_86pI215cFIceztTf5jX0=.d6d6201b-ec15-418e-a73b-e907d9d02607@github.com>
 <oPJ9OfKdD8CTbihLREww1QM2hc3Ckiai0-1OSpkq830=.87c4f119-07c9-471f-8c25-99dcfaad8d11@github.com>
 <ngMsS8jp0GTuqLVGD5k2ZL5AckbFwh8CBj5ec_GaBes=.0c51dacf-b158-4e62-874d-5e9c5a7b5f8e@github.com>
 <JDsbDqJRQ0V_s1SvGBhr3FLu98T2-X51kpkCs8s8vxQ=.fdb2242c-8706-4057-b4aa-084cfcb24166@github.com>
 <cHsGHKQrSqSUKJJ2OIRVUYuKUVOJGH-Pch-aDmoPj64=.88025b63-b0bb-401a-a749-57089ebea3aa@github.com>
 <gnDO9moDHlyHgJCEdcILr-MauRQgQP7I6QE38XZHus0=.4e488aca-8206-4db5-acec-5c029a6328ca@github.com>
 <vN4ZxgYOLsOQLqwyX4fXMJsQ-LM-S5JqeZo
 WdMXzmqc=.dfdc97a5-4838-4f09-9082-e5562c4691e0@github.com>
 <hLyibl3_enSszfZLKP74PE3i_ranX51N3nNiX0F9KoA=.8f2fea52-c394-4612-9c74-d9d975a3c42a@github.com>
 <Gs7-OplIQn5Vtq9vmQ6QXnB3l_XGSwfsagD044OQ2RM=.564b8980-fd3b-4555-864c-33c1b55a9fbd@github.com>
Message-ID: <ONgCbmqprWaFkq_OtsFB5KBW1KjPIQu7QRaHXFEHOB8=.e1af696f-9e30-4b94-9524-682a14226c74@github.com>

On Wed, 3 Feb 2021 22:02:04 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Hi Lin, When I suggested that it would ok just to just always use the default number of parallel threads, I wasn't considering that we also have `jmap -histo`, which also supports parallel threads, but includes an argument to specify it. For example, `jmap -histo:parallel=<n>`. Now this PR adds parallel support to `jmap -dump`, but you are suggesting not to have a parallel option to specify it, and use a default number of threads, which would be the same as what you would get with `jmap -histo:parallel=0`.  So this is inconsistent. If `-histo` is going to allow you to control the number of parallel threads, then `-dump` should also. I guess an option would be to not allow `-histo` to control the number of threads, and have it work just like you are proposing for `-dump`.
>
> Here's another thought. What if we added a new Attach API command called something like `setparallel`. Then when you specify `parallel=<n>` for  `jmap -histo` or `jmap -dump`, first JMap would send the `setparallel` command, and then it would send the `dumpheap` or `inspectheap` commands, and they would use the parallel setting from the previous `setparallel` command. I assume of `setparallel` is sent to an older JDK, I think you just get an error message back that can be ignored.
> 
> Anyway, just throwing this idea out there. I'm not so sure I like it myself, but given we don't have a good solution yet, it may be as good as any of the others.

Hi Chris,

> Hi Lin, When I suggested that it would ok just to just always use the default number of parallel threads, I wasn't considering that we also have `jmap -histo`, which also supports parallel threads, but includes an argument to specify it. For example, `jmap -histo:parallel=<n>`. Now this PR adds parallel support to `jmap -dump`, but you are suggesting not to have a parallel option to specify it, and use a default number of threads, which would be the same as what you would get with `jmap -histo:parallel=0`. So this is inconsistent. If `-histo` is going to allow you to control the number of parallel threads, then `-dump` should also. I guess an option would be to not allow `-histo` to control the number of threads, and have it work just like you are proposing for `-dump`.

I agree that -dump and -histo should keep consistent with "parallel" options. IMHO, removing "parallel" option for "-histo" from (maybe) JDK17 which was just introduced in JDK16 may confuse users. so maybe we could think of introducing "parallel" to "-dump". 


> Here's another thought. What if we added a new Attach API command called something like `setparallel`. Then when you specify `parallel=<n>` for `jmap -histo` or `jmap -dump`, first JMap would send the `setparallel` command, and then it would send the `dumpheap` or `inspectheap` commands, and they would use the parallel setting from the previous `setparallel` command. I assume of `setparallel` is sent to an older JDK, I think you just get an error message back that can be ignored.
> 
> Anyway, just throwing this idea out there. I'm not so sure I like it myself, but given we don't have a good solution yet, it may be as good as any of the others.

I think this is a good idea,  I will try it to see whether there is any problem.
IMO, there can be two ways which may help solve the compatibility issue of introducing "parallel" option:
- unblock socket with timeout. In this way, old Jmap could work with new JDK, but it maybe complicated because of different implementation for different OS. 
- Two times communication as you mentioned,  it sounds a reasonable solution, I will work out a prototype and then discuss with you . 

P.S.  I will re-open the CSR when we make the final decision on introducing "parallel" options. 
Thanks!

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

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

From lzang at openjdk.java.net  Thu Feb  4 03:41:43 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Thu, 4 Feb 2021 03:41:43 GMT
Subject: RFR: 8257234 : Add gz option to SA jmap to write a gzipped heap
 dump [v13]
In-Reply-To: <k-WhLggIqzlJq3A1jILFkmImIWzvvWjo6DmZFD4E6ig=.20383022-47d7-4a96-b13c-1382790675e4@github.com>
References: <oTMRc7LWvx9_Uov01HPX9UgyEqFmXt_nMG920HUQBIM=.3651754b-e1f1-46f8-9f44-c118a5c56dbe@github.com>
 <_XHsdihfp48gENT26xI6Br_8d1kdCBwXzHZBtRJ5ZWY=.874f77c5-c945-458c-a260-1f5e02b635a5@github.com>
 <k-WhLggIqzlJq3A1jILFkmImIWzvvWjo6DmZFD4E6ig=.20383022-47d7-4a96-b13c-1382790675e4@github.com>
Message-ID: <b9EGIseTyYzLsau4pHcm_kS40zs0-eXT4omVAW3IAiU=.7788e314-7131-4f58-9341-139b8da1fe9b@github.com>

On Thu, 28 Jan 2021 22:33:53 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Lin Zang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix the logic of using gz= as file name
>
> You added clhsdb testing to ClhsdbDumpheap.java, but I had also suggested adding testing to BasicJMapTest.java to test pmap. Can you please add some testing there also?

Hi @plummercj, 
> I have found that there is a bug in jcmd jmap, it could accept the argument "gz=" with no value specified.
> so jmap -dump:file=a.hprof,gz= could generate dump file successfully.

After re-think of it, the jcmd jmap issue mentioned here seems not quite related with this PR, so maybe a standalone one is better?  What do you think?

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

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

From cjplummer at openjdk.java.net  Thu Feb  4 03:42:45 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 4 Feb 2021 03:42:45 GMT
Subject: RFR: JDK-8261034: improve jcmd GC.class_histogram to support
 parallel
In-Reply-To: <oUkJ0uQKU0kV8Xvvq19Ce5MZda7nQjUp8V9uvIBBBa0=.9a95b0d7-5000-4ebe-9feb-058d4330912f@github.com>
References: <VKzVY-01CEXUbQdlKMhDWjtjxUgpxs_6487x232VsAI=.3b9c5d8a-972b-4997-9f75-1951f98e1751@github.com>
 <oUkJ0uQKU0kV8Xvvq19Ce5MZda7nQjUp8V9uvIBBBa0=.9a95b0d7-5000-4ebe-9feb-058d4330912f@github.com>
Message-ID: <ij1ln8Iq9zn7GQ5xVrloWONKUpCiUsv6PvseQzgYTOY=.78772221-61d3-4691-8a25-ec3bdcfd0283@github.com>

On Thu, 4 Feb 2021 02:58:52 GMT, Lin Zang <lzang at openjdk.org> wrote:

>  I am not reviewer, but maybe you could add test for "parallel" in BasicJMapTest.java.

That test is for the `jmap` command, not the `GC.class_histogram` jcmd. As I pointed out, there are tests in `test/hotpot/jtreg/serviceability/dcmd/gc` that already test `GC.class_histogram`. That would be a better starting point.

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

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

From lzang at openjdk.java.net  Thu Feb  4 03:47:40 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Thu, 4 Feb 2021 03:47:40 GMT
Subject: RFR: JDK-8261034: improve jcmd GC.class_histogram to support
 parallel
In-Reply-To: <ij1ln8Iq9zn7GQ5xVrloWONKUpCiUsv6PvseQzgYTOY=.78772221-61d3-4691-8a25-ec3bdcfd0283@github.com>
References: <VKzVY-01CEXUbQdlKMhDWjtjxUgpxs_6487x232VsAI=.3b9c5d8a-972b-4997-9f75-1951f98e1751@github.com>
 <oUkJ0uQKU0kV8Xvvq19Ce5MZda7nQjUp8V9uvIBBBa0=.9a95b0d7-5000-4ebe-9feb-058d4330912f@github.com>
 <ij1ln8Iq9zn7GQ5xVrloWONKUpCiUsv6PvseQzgYTOY=.78772221-61d3-4691-8a25-ec3bdcfd0283@github.com>
Message-ID: <H1bROxMQNiBZcEriw6mRnwzk47du4i0UmZXMd14aidI=.9fef71b1-3ea5-4f71-aaa5-c15051373ba9@github.com>

On Thu, 4 Feb 2021 03:40:26 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> > I am not reviewer, but maybe you could add test for "parallel" in BasicJMapTest.java.
> 
> That test is for the `jmap` command, not the `GC.class_histogram` jcmd. As I pointed out, there are tests in `test/hotpot/jtreg/serviceability/dcmd/gc` that already test `GC.class_histogram`. That would be a better starting point.

Correct!  Thanks for point it out, and sorry for misleading the test case.

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

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

From cjplummer at openjdk.java.net  Thu Feb  4 03:54:41 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 4 Feb 2021 03:54:41 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump
In-Reply-To: <ONgCbmqprWaFkq_OtsFB5KBW1KjPIQu7QRaHXFEHOB8=.e1af696f-9e30-4b94-9524-682a14226c74@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
 <crJcuaqSgYZQCEw2lqGaLpRmCVOXr99P1i5bcnSFpQc=.cb824923-e649-4ecd-ba5b-8d26cb93b265@github.com>
 <esex_demB2ZT0CsAp2WrzNGC_gieM9USGg_fYgmFCAE=.1911dd08-7dcc-4d88-9532-5d670399dd62@github.com>
 <ztN32xTk5joNRB7MhfYMl9zHCfGA1j8bQNu-ke975qc=.4c7ff2a9-2af8-495d-8f22-83e98c2e3221@github.com>
 <oQe3_j7vewkS8wlIuYXRCa_86pI215cFIceztTf5jX0=.d6d6201b-ec15-418e-a73b-e907d9d02607@github.com>
 <oPJ9OfKdD8CTbihLREww1QM2hc3Ckiai0-1OSpkq830=.87c4f119-07c9-471f-8c25-99dcfaad8d11@github.com>
 <ngMsS8jp0GTuqLVGD5k2ZL5AckbFwh8CBj5ec_GaBes=.0c51dacf-b158-4e62-874d-5e9c5a7b5f8e@github.com>
 <JDsbDqJRQ0V_s1SvGBhr3FLu98T2-X51kpkCs8s8vxQ=.fdb2242c-8706-4057-b4aa-084cfcb24166@github.com>
 <cHsGHKQrSqSUKJJ2OIRVUYuKUVOJGH-Pch-aDmoPj64=.88025b63-b0bb-401a-a749-57089ebea3aa@github.com>
 <gnDO9moDHlyHgJCEdcILr-MauRQgQP7I6QE38XZHus0=.4e488aca-8206-4db5-acec-5c029a6328ca@github.com>
 <vN4ZxgYOLsOQLqwyX4fXMJsQ-LM-S5JqeZo
 WdMXzmqc=.dfdc97a5-4838-4f09-9082-e5562c4691e0@github.com>
 <hLyibl3_enSszfZLKP74PE3i_ranX51N3nNiX0F9KoA=.8f2fea52-c394-4612-9c74-d9d975a3c42a@github.com>
 <Gs7-OplIQn5Vtq9vmQ6QXnB3l_XGSwfsagD044OQ2RM=.564b8980-fd3b-4555-864c-33c1b55a9fbd@github.com>
 <ONgCbmqprWaFkq_OtsFB5KBW1KjPIQu7QRaHXFEHOB8=.e1af696f-9e30-4b94-9524-682a14226c74@github.com>
Message-ID: <sQsnkEh6czmuyAbsFV8pm0HRBc4iR21hMXj0o5Za8VA=.c455e261-03b5-4bd7-8b88-0fff84c20e85@github.com>

On Thu, 4 Feb 2021 03:17:28 GMT, Lin Zang <lzang at openjdk.org> wrote:

>  IMO, there can be two ways which may help solve the compatibility issue of introducing "parallel" option:
> 
>     * unblock socket with timeout. In this way, old Jmap could work with new JDK, but it maybe complicated because of different implementation for different OS.
> 
>     * Two times communication as you mentioned,  it sounds a reasonable solution, I will work out a prototype and then discuss with you .
> 
A 3rd would be to create a new `dumpheap` command for the Attach API, maybe `dumpheap_parallel`. If you try using it with an old JVM, it should immediately return an error:

        st.print("Operation %s not recognized!", op->name());
        res = JNI_ERR;
If it does, you can fallback to the regular `dumpheap` command. If an old JVM attaches and uses `dumpheap`, you can choose to make it parallel by default if you wish. A slightly different variant of this idea is have something like `dumpheap_extraargs` or `dumpheap_ext`, leaving room to add even more args in the future (possibly a single argument with a list of args as you suggested before)

BTW, one thing to keep in mind that whatever we do with `dumpheap`, the jcmd version will support fine control over parallelism. So for that reason it wouldn't be so bad to just have `dumpheap` and `inspectheap` always use some default parallelism, and allow tuning it with the jcmd versions. But since the `inspectheap` parallel support already went into 16, that might be hard to undo.

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

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

From cjplummer at openjdk.java.net  Thu Feb  4 03:57:47 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 4 Feb 2021 03:57:47 GMT
Subject: RFR: 8257234 : Add gz option to SA jmap to write a gzipped heap
 dump [v14]
In-Reply-To: <hshEN06sqJcgNmcW4Yb75mtnYFVMiqX3lfmekNjzApU=.183255d4-56da-48ac-8a81-7a81b5900253@github.com>
References: <oTMRc7LWvx9_Uov01HPX9UgyEqFmXt_nMG920HUQBIM=.3651754b-e1f1-46f8-9f44-c118a5c56dbe@github.com>
 <hshEN06sqJcgNmcW4Yb75mtnYFVMiqX3lfmekNjzApU=.183255d4-56da-48ac-8a81-7a81b5900253@github.com>
Message-ID: <d2qneSjNn2StFBGSsQy45NNz8SI7WTogYPq8WR9pIlQ=.7d78b062-3606-4d29-9b18-81dfe9f38df9@github.com>

On Fri, 29 Jan 2021 05:39:59 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> 8257234 : Add gz option to SA jmap to write a gzipped heap dump
>
> Lin Zang has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - fix an issue of double printing error message.
>  - fix jcmd jmap issue and add test in BascJMapTest and code refine

> > I have found that there is a bug in jcmd jmap, it could accept the argument "gz=" with no value specified.
> > so jmap -dump:file=a.hprof,gz= could generate dump file successfully.
> 
> After re-think of it, the jcmd jmap issue mentioned here seems not quite related with this PR, so maybe a standalone one is better? What do you think?

That's probably a good idea since this PR is for SA changes, and it's probably best not to mix it with attach api changes.

test/jdk/sun/tools/jmap/BasicJMapTest.java line 121:

> 119:         testDumpAll();
> 120:         testDumpCompressed();
> 121:         testDumpIllegalCompressedArgs();

Thanks for updating this test to better check the args, but it looks like I pointed you to the wrong test. This is testing the pmap tool, which already had the gz option. I actually meant for you to add testing for the gz option support you added to "jhsdb jmap --binaryheap" , which is what you added to SALauncher.java. The testing for "jhsdb jmap --binaryheap" is done in test/jdk/sun/tools/jhsdb/HeapDumpTest.java.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/SALauncher.java line 130:

> 128:         System.out.println("    --binaryheap            To dump java heap in hprof binary format.");
> 129:         System.out.println("    --dumpfile <name>       The name of the dump file.");
> 130:         System.out.println("    --gz <1-9>              The compression level for gzipped dump file.");

`--dumpfile` and `--gz` can only be used with `--binaryheap`. That should be made clear in the help text. 

I just noticed that `jhsdb pmap` does not support the equivalent of `format=x` that the jcmd version does. However, the support is actually there in the SA JMap.java. It's confusing because both `jhsdb jmap` and the clhsdb `dumpheap` command use the JMap class, but neither support passing `format=x` to it. In order to get SA to dump with `format=x`, you would need to launch `sun/jvm/hotspot/tools/JMap` directly and pass in `-heap:format=x`. I'm not suggesting you fix that, but just something for us to be aware of.

One question though. Have you tried running JMap directly to make sure the help output looks right. You've made fixes to it in this webrev, but since there are so many different "jmap" commands (5), and each with their own help, I've lost sight of whether or not this is even tested. I don't believe it is, but I wouldn't worry about that. However, since made changes to the help output, it would be good to at least check it out.

And if you are wonder what the 5 `jmap` commands are:

- SA's `jhsdb jmap --binaryheap` (which uses JMap.java with `-heap:format=b`)
- SA's clhsdb `dumpheap` command (which also uses JMap.java with `-heap:format=b`)
- executing  SA's `sun/jvm/hotspot/tools/JMap` class directly
- `jmap -dump` command (Uses Attach API's `heapdump` command, which uses hotspot `HeapDump` class)
- `GC.heap_dump` dcmd, which also uses the hotspot `HeapDumper` class

So really there are two implementations of heap dumping, one in the VM and one in SA, but a total of 5 ways to get to them. I'm just starting to get my head wrapped around all this myself. We've created a very confusing situation for us, and unfortunately I think some of the changes that got us here was driven by a goal to simply things.

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

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

From mli at openjdk.java.net  Thu Feb  4 07:12:54 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Thu, 4 Feb 2021 07:12:54 GMT
Subject: RFR: JDK-8261034: improve jcmd GC.class_histogram to support
 parallel [v2]
In-Reply-To: <VKzVY-01CEXUbQdlKMhDWjtjxUgpxs_6487x232VsAI=.3b9c5d8a-972b-4997-9f75-1951f98e1751@github.com>
References: <VKzVY-01CEXUbQdlKMhDWjtjxUgpxs_6487x232VsAI=.3b9c5d8a-972b-4997-9f75-1951f98e1751@github.com>
Message-ID: <i5vD6hbRvxypc-YucJU3EY7n0NbdwS0dJamB8_g00Ac=.5f76fb0b-ce64-4efb-b6d8-4e7a0877467d@github.com>

> parallel -histo of jmap was added by JDK-8214535, it's better to support parallel for jcmd GC.class_histogram too.

Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8261034: improve jcmd GC.class_histogram to support parallel

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2379/files
  - new: https://git.openjdk.java.net/jdk/pull/2379/files/4f17b97b..2b517feb

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

  Stats: 71 lines in 3 files changed: 23 ins; 42 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2379.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2379/head:pull/2379

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

From lzang at openjdk.java.net  Thu Feb  4 07:20:51 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Thu, 4 Feb 2021 07:20:51 GMT
Subject: RFR: 8261131: jcmd jmap dump should not accept gz option with no value
Message-ID: <qUp1tOUkdsvzPGH03MyAhSokYQUUYm9xz-2X6GjsSC4=.21007ed7-65f7-4768-a2f8-e7d2ac2533f6@github.com>

8261131: jcmd jmap dump should not accept gz option with no value

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

Commit messages:
 - 8261131: jcmd jmap dump should not accept gz option with no value

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

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

From mli at openjdk.java.net  Thu Feb  4 07:28:04 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Thu, 4 Feb 2021 07:28:04 GMT
Subject: RFR: JDK-8261034: improve jcmd GC.class_histogram to support
 parallel [v3]
In-Reply-To: <BWaUKtnK-yrdctz5EX_ACTm27QiJHSvnsfPe42sI1vw=.a8c96623-0f6c-484e-9cce-1d9b1a3634e8@github.com>
References: <VKzVY-01CEXUbQdlKMhDWjtjxUgpxs_6487x232VsAI=.3b9c5d8a-972b-4997-9f75-1951f98e1751@github.com>
 <BWaUKtnK-yrdctz5EX_ACTm27QiJHSvnsfPe42sI1vw=.a8c96623-0f6c-484e-9cce-1d9b1a3634e8@github.com>
Message-ID: <9gNTZ95gR1DbtS376PUXTmJE1PuFqjZLZeT1NBBsDek=.7d760574-43dd-4383-9417-fe1a8102419b@github.com>

On Wed, 3 Feb 2021 21:28:40 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   JDK-8261034: improve jcmd GC.class_histogram to support parallel
>
> src/hotspot/share/services/diagnosticCommand.cpp line 559:
> 
>> 557:        "BOOLEAN", false, "false"),
>> 558:   _parallel_thread_num("-parallel", "parallel threads number for heap iteration",
>> 559:        "INT", false, "0")     {
> 
> Does "0" mean use a default number of parallel threads as it does for the jmap? It's unclear, but it seems that it doesn't, which I think leads to eventually hitting this assert in `update_active_workers(uint v)`:
>     assert(v != 0, "Trying to set active workers to 0");
> If that's not the case, please explain how 0 is handled. In any case, I think it should be made consistent with jmap and should also be documented in the above  help output:
>   parallel=<count> generate histogram using this many parallel threads, default 0
>                      0 use system determined number of threads
>                      1 use one thread, i.e., disable parallelism
>                      n use n threads, n must be positive

Thanks Chris for reviewing, I have updated the patch as you suggested, would you mind to have another look at it?
CSR is created at https://bugs.openjdk.java.net/browse/JDK-8261105

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

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

From mli at openjdk.java.net  Thu Feb  4 07:28:03 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Thu, 4 Feb 2021 07:28:03 GMT
Subject: RFR: JDK-8261034: improve jcmd GC.class_histogram to support
 parallel [v3]
In-Reply-To: <VKzVY-01CEXUbQdlKMhDWjtjxUgpxs_6487x232VsAI=.3b9c5d8a-972b-4997-9f75-1951f98e1751@github.com>
References: <VKzVY-01CEXUbQdlKMhDWjtjxUgpxs_6487x232VsAI=.3b9c5d8a-972b-4997-9f75-1951f98e1751@github.com>
Message-ID: <EtePCjI8QD6rSfd7DjihG3MT5XzPRGXVUhtKAl7ioY4=.b9c89460-7998-416e-8bec-60980abee6f6@github.com>

> parallel -histo of jmap was added by JDK-8214535, it's better to support parallel for jcmd GC.class_histogram too.

Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8261034: improve jcmd GC.class_histogram to support parallel

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2379/files
  - new: https://git.openjdk.java.net/jdk/pull/2379/files/2b517feb..c083f6bd

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

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

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

From mli at openjdk.java.net  Thu Feb  4 07:34:40 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Thu, 4 Feb 2021 07:34:40 GMT
Subject: RFR: JDK-8261034: improve jcmd GC.class_histogram to support
 parallel
In-Reply-To: <VKzVY-01CEXUbQdlKMhDWjtjxUgpxs_6487x232VsAI=.3b9c5d8a-972b-4997-9f75-1951f98e1751@github.com>
References: <VKzVY-01CEXUbQdlKMhDWjtjxUgpxs_6487x232VsAI=.3b9c5d8a-972b-4997-9f75-1951f98e1751@github.com>
Message-ID: <ZLg2oDxJ4Db6xvH9pspM-li3kukSyshlsU-2T1nvu_8=.ec1711ed-c45b-4575-ae6d-f7dddbab1381@github.com>

On Wed, 3 Feb 2021 12:44:53 GMT, Hamlin Li <mli at openjdk.org> wrote:

> parallel -histo of jmap was added by JDK-8214535, it's better to support parallel for jcmd GC.class_histogram too.

> Hi @Hamlin-Li
> I am not reviewer, but maybe you could add test for "parallel" in BasicJMapTest.java.

Hi @linzang , it's ok, anyone can review. :-)

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

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

From mli at openjdk.java.net  Thu Feb  4 07:39:41 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Thu, 4 Feb 2021 07:39:41 GMT
Subject: RFR: JDK-8261034: improve jcmd GC.class_histogram to support
 parallel
In-Reply-To: <ij1ln8Iq9zn7GQ5xVrloWONKUpCiUsv6PvseQzgYTOY=.78772221-61d3-4691-8a25-ec3bdcfd0283@github.com>
References: <VKzVY-01CEXUbQdlKMhDWjtjxUgpxs_6487x232VsAI=.3b9c5d8a-972b-4997-9f75-1951f98e1751@github.com>
 <oUkJ0uQKU0kV8Xvvq19Ce5MZda7nQjUp8V9uvIBBBa0=.9a95b0d7-5000-4ebe-9feb-058d4330912f@github.com>
 <ij1ln8Iq9zn7GQ5xVrloWONKUpCiUsv6PvseQzgYTOY=.78772221-61d3-4691-8a25-ec3bdcfd0283@github.com>
Message-ID: <oRyb7iT88wLQZJmsU8epocc8H4ibegW15dlWizrrQpU=.76754cd7-f20e-422a-b339-dac4a9f3c45c@github.com>

On Thu, 4 Feb 2021 03:40:26 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Hi @Hamlin-Li 
>> I am not reviewer, but maybe you could add test for "parallel" in BasicJMapTest.java.
>
>>  I am not reviewer, but maybe you could add test for "parallel" in BasicJMapTest.java.
> 
> That test is for the `jmap` command, not the `GC.class_histogram` jcmd. As I pointed out, there are tests in `test/hotpot/jtreg/serviceability/dcmd/gc` that already test `GC.class_histogram`. That would be a better starting point.

@plummercj Hi Chris, I have a question which might not be related to the patch, my presubmit tests always failed on linux platforms, but I don't think the failure is related to my patch. Would you mind to share some point? I totally have no idea what's going wrong.
The error messages are as following:

E: Could not configure 'libc6:i386'. 
E: Could not perform immediate configuration on 'libgcc-s1:i386'. Please see man 5 apt.conf under APT::Immediate-Configure for details. (2)
Error: Process completed with exit code 100.

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

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

From cjplummer at openjdk.java.net  Thu Feb  4 07:54:54 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 4 Feb 2021 07:54:54 GMT
Subject: RFR: JDK-8261034: improve jcmd GC.class_histogram to support
 parallel
In-Reply-To: <oRyb7iT88wLQZJmsU8epocc8H4ibegW15dlWizrrQpU=.76754cd7-f20e-422a-b339-dac4a9f3c45c@github.com>
References: <VKzVY-01CEXUbQdlKMhDWjtjxUgpxs_6487x232VsAI=.3b9c5d8a-972b-4997-9f75-1951f98e1751@github.com>
 <oUkJ0uQKU0kV8Xvvq19Ce5MZda7nQjUp8V9uvIBBBa0=.9a95b0d7-5000-4ebe-9feb-058d4330912f@github.com>
 <ij1ln8Iq9zn7GQ5xVrloWONKUpCiUsv6PvseQzgYTOY=.78772221-61d3-4691-8a25-ec3bdcfd0283@github.com>
 <oRyb7iT88wLQZJmsU8epocc8H4ibegW15dlWizrrQpU=.76754cd7-f20e-422a-b339-dac4a9f3c45c@github.com>
Message-ID: <nrXMXFS52KW8RLluqr05TEWD2lmM0nOTTEhELtr82pg=.002d2fc7-36bb-4714-8f87-5598e5caa8d9@github.com>

On Thu, 4 Feb 2021 07:37:03 GMT, Hamlin Li <mli at openjdk.org> wrote:

>>>  I am not reviewer, but maybe you could add test for "parallel" in BasicJMapTest.java.
>> 
>> That test is for the `jmap` command, not the `GC.class_histogram` jcmd. As I pointed out, there are tests in `test/hotpot/jtreg/serviceability/dcmd/gc` that already test `GC.class_histogram`. That would be a better starting point.
>
> @plummercj Hi Chris, I have a question which might not be related to the patch, my presubmit tests always failed on linux platforms, but I don't think the failure is related to my patch. Would you mind to share some point? I totally have no idea what's going wrong.
> The error messages are as following:
> 
> E: Could not configure 'libc6:i386'. 
> E: Could not perform immediate configuration on 'libgcc-s1:i386'. Please see man 5 apt.conf under APT::Immediate-Configure for details. (2)
> Error: Process completed with exit code 100.

>From what I've seen it's normal for the 32-bit builds to fail. I'm not sure why they are even being built.

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

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

From lzang at openjdk.java.net  Thu Feb  4 08:03:45 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Thu, 4 Feb 2021 08:03:45 GMT
Subject: RFR: 8257234 : Add gz option to SA jmap to write a gzipped heap
 dump [v14]
In-Reply-To: <d2qneSjNn2StFBGSsQy45NNz8SI7WTogYPq8WR9pIlQ=.7d78b062-3606-4d29-9b18-81dfe9f38df9@github.com>
References: <oTMRc7LWvx9_Uov01HPX9UgyEqFmXt_nMG920HUQBIM=.3651754b-e1f1-46f8-9f44-c118a5c56dbe@github.com>
 <hshEN06sqJcgNmcW4Yb75mtnYFVMiqX3lfmekNjzApU=.183255d4-56da-48ac-8a81-7a81b5900253@github.com>
 <d2qneSjNn2StFBGSsQy45NNz8SI7WTogYPq8WR9pIlQ=.7d78b062-3606-4d29-9b18-81dfe9f38df9@github.com>
Message-ID: <5Ti2FXJpOfhTPD8cnxl02ftzmCzDgs2U0Zi5XCv4ms8=.ca2602d7-0500-4662-b356-00c8282beb0a@github.com>

On Fri, 29 Jan 2021 22:51:23 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Lin Zang has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - fix an issue of double printing error message.
>>  - fix jcmd jmap issue and add test in BascJMapTest and code refine
>
> test/jdk/sun/tools/jmap/BasicJMapTest.java line 121:
> 
>> 119:         testDumpAll();
>> 120:         testDumpCompressed();
>> 121:         testDumpIllegalCompressedArgs();
> 
> Thanks for updating this test to better check the args, but it looks like I pointed you to the wrong test. This is testing the pmap tool, which already had the gz option. I actually meant for you to add testing for the gz option support you added to "jhsdb jmap --binaryheap" , which is what you added to SALauncher.java. The testing for "jhsdb jmap --binaryheap" is done in test/jdk/sun/tools/jhsdb/HeapDumpTest.java.

Thanks Chris!,
I have created another PR and move jcmd jmap fix and this test case enhancement there. (https://github.com/openjdk/jdk/pull/2399)

I will add the test in HeapDumpTest.java in this PR.

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

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

From lzang at openjdk.java.net  Thu Feb  4 08:12:44 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Thu, 4 Feb 2021 08:12:44 GMT
Subject: RFR: 8257234 : Add gz option to SA jmap to write a gzipped heap
 dump [v14]
In-Reply-To: <d2qneSjNn2StFBGSsQy45NNz8SI7WTogYPq8WR9pIlQ=.7d78b062-3606-4d29-9b18-81dfe9f38df9@github.com>
References: <oTMRc7LWvx9_Uov01HPX9UgyEqFmXt_nMG920HUQBIM=.3651754b-e1f1-46f8-9f44-c118a5c56dbe@github.com>
 <hshEN06sqJcgNmcW4Yb75mtnYFVMiqX3lfmekNjzApU=.183255d4-56da-48ac-8a81-7a81b5900253@github.com>
 <d2qneSjNn2StFBGSsQy45NNz8SI7WTogYPq8WR9pIlQ=.7d78b062-3606-4d29-9b18-81dfe9f38df9@github.com>
Message-ID: <3AOVqSv3mzE-QVGg7NWJ8vs4pKBoHTgeHZjf1FHA9XA=.d0ab8c18-6d62-43c6-8232-4b1621ebc609@github.com>

On Fri, 29 Jan 2021 22:54:57 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Lin Zang has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - fix an issue of double printing error message.
>>  - fix jcmd jmap issue and add test in BascJMapTest and code refine
>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/SALauncher.java line 130:
> 
>> 128:         System.out.println("    --binaryheap            To dump java heap in hprof binary format.");
>> 129:         System.out.println("    --dumpfile <name>       The name of the dump file.");
>> 130:         System.out.println("    --gz <1-9>              The compression level for gzipped dump file.");
> 
> `--dumpfile` and `--gz` can only be used with `--binaryheap`. That should be made clear in the help text. 
> 
> I just noticed that `jhsdb pmap` does not support the equivalent of `format=x` that the jcmd version does. However, the support is actually there in the SA JMap.java. It's confusing because both `jhsdb jmap` and the clhsdb `dumpheap` command use the JMap class, but neither support passing `format=x` to it. In order to get SA to dump with `format=x`, you would need to launch `sun/jvm/hotspot/tools/JMap` directly and pass in `-heap:format=x`. I'm not suggesting you fix that, but just something for us to be aware of.
> 
> One question though. Have you tried running JMap directly to make sure the help output looks right. You've made fixes to it in this webrev, but since there are so many different "jmap" commands (5), and each with their own help, I've lost sight of whether or not this is even tested. I don't believe it is, but I wouldn't worry about that. However, since made changes to the help output, it would be good to at least check it out.
> 
> And if you are wonder what the 5 `jmap` commands are:
> 
> - SA's `jhsdb jmap --binaryheap` (which uses JMap.java with `-heap:format=b`)
> - SA's clhsdb `dumpheap` command (which also uses JMap.java with `-heap:format=b`)
> - executing  SA's `sun/jvm/hotspot/tools/JMap` class directly
> - `jmap -dump` command (Uses Attach API's `heapdump` command, which uses hotspot `HeapDump` class)
> - `GC.heap_dump` dcmd, which also uses the hotspot `HeapDumper` class
> 
> So really there are two implementations of heap dumping, one in the VM and one in SA, but a total of 5 ways to get to them. I'm just starting to get my head wrapped around all this myself. We've created a very confusing situation for us, and unfortunately I think some of the changes that got us here was driven by a goal to simply things.

Thanks for the thorough list, I have tested most of them but not all. I will cover them and update here later.

> So really there are two implementations of heap dumping, one in the VM and one in SA, but a total of 5 ways to get to them. I'm just starting to get my head wrapped around all this myself. We've created a very confusing situation for us, and unfortunately I think some of the changes that got us here was driven by a goal to simply things.

Yes, it makes me even curious about why there can be two different implementation of them (one by C++ and one by Java),  it seems we need double the work of adding new options for those tools, like parallal for jmap histo and dump, etc.

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

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

From mli at openjdk.java.net  Thu Feb  4 08:17:47 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Thu, 4 Feb 2021 08:17:47 GMT
Subject: RFR: JDK-8261034: improve jcmd GC.class_histogram to support
 parallel
In-Reply-To: <nrXMXFS52KW8RLluqr05TEWD2lmM0nOTTEhELtr82pg=.002d2fc7-36bb-4714-8f87-5598e5caa8d9@github.com>
References: <VKzVY-01CEXUbQdlKMhDWjtjxUgpxs_6487x232VsAI=.3b9c5d8a-972b-4997-9f75-1951f98e1751@github.com>
 <oUkJ0uQKU0kV8Xvvq19Ce5MZda7nQjUp8V9uvIBBBa0=.9a95b0d7-5000-4ebe-9feb-058d4330912f@github.com>
 <ij1ln8Iq9zn7GQ5xVrloWONKUpCiUsv6PvseQzgYTOY=.78772221-61d3-4691-8a25-ec3bdcfd0283@github.com>
 <oRyb7iT88wLQZJmsU8epocc8H4ibegW15dlWizrrQpU=.76754cd7-f20e-422a-b339-dac4a9f3c45c@github.com>
 <nrXMXFS52KW8RLluqr05TEWD2lmM0nOTTEhELtr82pg=.002d2fc7-36bb-4714-8f87-5598e5caa8d9@github.com>
Message-ID: <uw2j_w8lI-Rv10zedg0mUgs-r3HDqGamrK_NOzTYjXY=.9e68d205-a70a-4510-931a-8c5cc2cd3d90@github.com>

On Thu, 4 Feb 2021 07:51:35 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> From what I've seen it's normal for the 32-bit builds to fail. I'm not sure why they are even being built.

Thanks for the info, then I think it's safe for me to ignore the failures in linux x86.

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

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

From mikael at openjdk.java.net  Thu Feb  4 08:30:48 2021
From: mikael at openjdk.java.net (Mikael Vidstedt)
Date: Thu, 4 Feb 2021 08:30:48 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
In-Reply-To: <sMzpTev5Co7zYwj_MDJAQwt1h4TclV5VupIfIVXXS5Q=.de8bfe1b-8e72-4fc5-a6ec-cc46f5b1649f@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>
 <6oqFTX-wDWyEUpJ6FLHvgP8gi0zmnkF6Mzz87hC6A1w=.e0b31425-4750-472f-9335-0b187a59c834@github.com>
 <Qb8Gta50pNQAKiE8nUCa9dl9O19tEkeUg4E25At5Bwk=.0c5c6b99-eaf2-4617-b6ec-fef2b7dbfc03@github.com>
 <sMzpTev5Co7zYwj_MDJAQwt1h4TclV5VupIfIVXXS5Q=.de8bfe1b-8e72-4fc5-a6ec-cc46f5b1649f@github.com>
Message-ID: <zRhpkKVeWL0jh_hqugUVc6jHF-ywB6SoH-lNSI7R-jw=.6ae275f4-5e41-4828-b49a-40ab52957c07@github.com>

On Wed, 3 Feb 2021 20:08:28 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

>>> I wonder if this is the right choice
>>> ...
>>> ```
>>> OopStorageParIterPerf::~OopStorageParIterPerf() {
>>> ...
>>> ```
>>> 
>> 
>> The transition in OopStorageParIterPerf was made for gtest setup to execute in WXWrite context. For tests themselves, defining macro set WXWrite.
>> 
>> I've simplified the scheme and now we switch to WXWrite once at the gtest launcher. So this transition was dropped.
>> 
>> I've also refreshed my memory and tried to switch to WXWrite as close as possible to each place where we'll be writing executable memory. There are a lot of such places! As you correctly noted, code cache contains objects, not plain data. For example, CodeCache memory management structures, CompiledMethod, ...  are there, so we need more WXWrite switches than we have in the current approach. I had a comparable amount of them just to run -version, but certainly not enough to run tier1 tests.
>> 
>> Following your advice, I don't require a known "from" state anymore. So a few W^X transitions were dropped, e.g. when the JVM code calls a JNI entry function, which expects to be called from the native code. I had to switch to WXExec just only to satisfy the expectations. After the update, we don't need this anymore.
>> 
>> W^X switches are mostly hidden by VM_ENTRY and similar macros. Some JVM functions are not marked as entries for some reason, although they are called directly from e.g. interpreter. I added W^X management to such functions.
>> 
>> Thank you!
>
> Out of curiosity, have you looked at the performance of the W^X state transition? In particular I'm wondering if the cost is effectively negligible so doing it unconditionally on JVM entry is a no-brainer and just easier/cleaner than the alternatives, or if there are reasons to look at only doing the transition if/when needed (perhaps do it lazily and revert back to X when leaving the JVM?).

You read my mind, Andrew. Unless, of course, it's optimized to leverage the fact that it's thread-specific..

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

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

From david.holmes at oracle.com  Thu Feb  4 09:25:37 2021
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 4 Feb 2021 19:25:37 +1000
Subject: RFR: JDK-8261034: improve jcmd GC.class_histogram to support
 parallel
In-Reply-To: <oRyb7iT88wLQZJmsU8epocc8H4ibegW15dlWizrrQpU=.76754cd7-f20e-422a-b339-dac4a9f3c45c@github.com>
References: <VKzVY-01CEXUbQdlKMhDWjtjxUgpxs_6487x232VsAI=.3b9c5d8a-972b-4997-9f75-1951f98e1751@github.com>
 <oUkJ0uQKU0kV8Xvvq19Ce5MZda7nQjUp8V9uvIBBBa0=.9a95b0d7-5000-4ebe-9feb-058d4330912f@github.com>
 <ij1ln8Iq9zn7GQ5xVrloWONKUpCiUsv6PvseQzgYTOY=.78772221-61d3-4691-8a25-ec3bdcfd0283@github.com>
 <oRyb7iT88wLQZJmsU8epocc8H4ibegW15dlWizrrQpU=.76754cd7-f20e-422a-b339-dac4a9f3c45c@github.com>
Message-ID: <1bad3559-1cf1-e73b-2ee3-8fff198e2e46@oracle.com>

On 4/02/2021 5:39 pm, Hamlin Li wrote:
> On Thu, 4 Feb 2021 03:40:26 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:
> 
>>> Hi @Hamlin-Li
>>> I am not reviewer, but maybe you could add test for "parallel" in BasicJMapTest.java.
>>
>>>   I am not reviewer, but maybe you could add test for "parallel" in BasicJMapTest.java.
>>
>> That test is for the `jmap` command, not the `GC.class_histogram` jcmd. As I pointed out, there are tests in `test/hotpot/jtreg/serviceability/dcmd/gc` that already test `GC.class_histogram`. That would be a better starting point.
> 
> @plummercj Hi Chris, I have a question which might not be related to the patch, my presubmit tests always failed on linux platforms, but I don't think the failure is related to my patch. Would you mind to share some point? I totally have no idea what's going wrong.
> The error messages are as following:
> 
> E: Could not configure 'libc6:i386'.
> E: Could not perform immediate configuration on 'libgcc-s1:i386'. Please see man 5 apt.conf under APT::Immediate-Configure for details. (2)
> Error: Process completed with exit code 100.

I believe this has been fixed, so your repo may be missing that 
changeset at the moment.

David

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

From roland at openjdk.java.net  Thu Feb  4 09:44:13 2021
From: roland at openjdk.java.net (Roland Westrelin)
Date: Thu, 4 Feb 2021 09:44:13 GMT
Subject: RFR: 8260296: SA's dumpreplaydata fails [v4]
In-Reply-To: <dbCVL_PF2kTQaXwi_ss4MX87d4wO2jPo-j7mn8Hrtao=.94bd9abc-2143-4306-ada0-0d7d09684ed2@github.com>
References: <dbCVL_PF2kTQaXwi_ss4MX87d4wO2jPo-j7mn8Hrtao=.94bd9abc-2143-4306-ada0-0d7d09684ed2@github.com>
Message-ID: <YodG6Yp77UtKIjzx5TB3jfDu-az1kN3-b_GyKG1deVI=.07ab2194-72ab-4d54-a8fa-b32ed50f2ed9@github.com>

> I noticed that the SA's dumpreplaydata command fails with:
> 
> java.lang.AssertionError: CLHSDB wasn't run successfully: Opening core file, please wait...
> hsdb> Exception in thread "main" java.lang.InternalError: ciMetadata does not appear to be polymorphic
> 
> with a simple test program. This happens because the SA can't find the
> vtable symbol for ciMetadata (build produced by gcc 9.2.1). AFAIU,
> there's nothing in our build system that hides that symbol. I had to
> move one method's definition from the header file to the cpp file for
> the symbol to be visible again.
> 
> We have a test that checks dumpreplaydata but it doesn't catch that
> problem. The test produces a replay file from a core file with the SA
> by running a simple test with -Xcomp and CICrash=1. So the replay data
> has very little or no profile data (which is what causes the problem
> above). I propose running a slightly more complicated test method and
> crashing after the method has had time to run for long enough to
> collect profile data.
> 
> The other shortcoming of the test is that it doesn't look at the
> content of the replay file. It only warns if they differ. The replay
> file produced by the VM and the one produced by the SA should be
> identical (except for comment lines). So I propose we check that.
> 
> Finally, I can't run that test on my system because core files are
> handled by systemd (I'm running some recent version of fedora). I
> suppose, the system can be configured differently but having the test
> work out the box is nice. I extended the test case to handle that.
> 
> With the improved test, there are a few differences between the VM and
> SA replay files caused by VM changes that were not mirrored in the
> SA. I fixed those.

Roland Westrelin 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:

 - pid in OutputAnalyzer
 - pid in OutputAnalyzer
 - Merge branch 'master' into JDK-8260296
 - convert all tests
 - Merge branch 'master' into JDK-8260296
 - use CoreUtils
 - whitespaces
 - SA fixes
 - VM fix
 - test

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2195/files
  - new: https://git.openjdk.java.net/jdk/pull/2195/files/d1e9381c..da2fe2be

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

  Stats: 30246 lines in 796 files changed: 11471 ins; 7752 del; 11023 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2195.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2195/head:pull/2195

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

From roland at openjdk.java.net  Thu Feb  4 09:44:13 2021
From: roland at openjdk.java.net (Roland Westrelin)
Date: Thu, 4 Feb 2021 09:44:13 GMT
Subject: RFR: 8260296: SA's dumpreplaydata fails [v3]
In-Reply-To: <szyKVJwJZABJzqj8BOKjMfGo7rn8KLUfzrTdE1l0SNQ=.2ea62edd-dc83-4da2-8a16-6cb86076a46b@github.com>
References: <dbCVL_PF2kTQaXwi_ss4MX87d4wO2jPo-j7mn8Hrtao=.94bd9abc-2143-4306-ada0-0d7d09684ed2@github.com>
 <N4znCSiBMzQSv2T9Nn42nKEmmfVw59SZoc6fZVq7lgw=.1c87d509-70f1-4ddb-a1aa-eda427d8e259@github.com>
 <GQ4Rh3M9G3dwYmXwULK0Vc6ui6omGakm8vswFEQqOl8=.a5b31e8a-5af0-4914-8e65-ad6d44b73d21@github.com>
 <aj2K1Z1z6rE-rB46D83uV6Fbs4kHF2P_LOumtjWrC6s=.3ea6a5bf-1356-4287-a746-aa2da2f60677@github.com>
 <szyKVJwJZABJzqj8BOKjMfGo7rn8KLUfzrTdE1l0SNQ=.2ea62edd-dc83-4da2-8a16-6cb86076a46b@github.com>
Message-ID: <ba-Xnb7Fj1KwMez4GsvQXbKP8HrC0VGGdDFyn14zclc=.ba00c708-b580-4904-b4a5-de91e6c7e181@github.com>

On Wed, 3 Feb 2021 18:51:57 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Thanks for reviewing this. I did not store the pid in the OutputAnalyzer because it doesn't seem to belong there as it has nothing to do with the text output of a test. But if you think that's ok. that's fine with me too. Do you prefer an extra field in OutputAnalyzer or a new subclass?
>
> `OutputAnalyzer`/ `OutputBuffer` already have an exit value, which arguable has nothing to do w/ the text output either, so I think it's ok to add a pid into `OutputBuffer` i-face and both of its implementations.

I just pushed a change that does this. Does that look ok to you?

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

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

From vkempik at openjdk.java.net  Thu Feb  4 09:51:57 2021
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Thu, 4 Feb 2021 09:51:57 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
In-Reply-To: <zRhpkKVeWL0jh_hqugUVc6jHF-ywB6SoH-lNSI7R-jw=.6ae275f4-5e41-4828-b49a-40ab52957c07@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>
 <6oqFTX-wDWyEUpJ6FLHvgP8gi0zmnkF6Mzz87hC6A1w=.e0b31425-4750-472f-9335-0b187a59c834@github.com>
 <Qb8Gta50pNQAKiE8nUCa9dl9O19tEkeUg4E25At5Bwk=.0c5c6b99-eaf2-4617-b6ec-fef2b7dbfc03@github.com>
 <sMzpTev5Co7zYwj_MDJAQwt1h4TclV5VupIfIVXXS5Q=.de8bfe1b-8e72-4fc5-a6ec-cc46f5b1649f@github.com>
 <zRhpkKVeWL0jh_hqugUVc6jHF-ywB6SoH-lNSI7R-jw=.6ae275f4-5e41-4828-b49a-40ab52957c07@github.com>
Message-ID: <R528o-L-66HqOlUjCWsFXTFMtzxgO2wE1Sm-sI7LHa0=.cdcfb777-8f05-4171-aea7-087db4b98387@github.com>

On Thu, 4 Feb 2021 08:26:35 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> You read my mind, Andrew. Unless, of course, it's optimized to leverage the fact that it's thread-specific..

it's thread-specific

https://developer.apple.com/documentation/apple_silicon/porting_just-in-time_compilers_to_apple_silicon

>Because pthread_jit_write_protect_np changes only the current thread?s permissions, avoid accessing the same memory region from multiple threads. Giving multiple threads access to the same memory region opens up a potential attack vector, in which one thread has write access and another has executable access to the same region.

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

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

From ihse at openjdk.java.net  Thu Feb  4 10:17:59 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 4 Feb 2021 10:17:59 GMT
Subject: RFR: 8261149: Initial nroff manpage update for JDK 17
Message-ID: <HvPsFX2azuvcaU5K-lTwixZ8Q8fYkTkJakELuAFVnVc=.56d0445a-74e3-48c6-824b-043a008610aa@github.com>

We need to regenerate the exported nroff man pages to include the proper version string. This will also bring in some recent textual updates to the man pages.

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

Commit messages:
 - 8261149: Initial nroff manpage update for JDK 17

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

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

From mli at openjdk.java.net  Thu Feb  4 11:58:48 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Thu, 4 Feb 2021 11:58:48 GMT
Subject: RFR: JDK-8261034: improve jcmd GC.class_histogram to support
 parallel
In-Reply-To: <uw2j_w8lI-Rv10zedg0mUgs-r3HDqGamrK_NOzTYjXY=.9e68d205-a70a-4510-931a-8c5cc2cd3d90@github.com>
References: <VKzVY-01CEXUbQdlKMhDWjtjxUgpxs_6487x232VsAI=.3b9c5d8a-972b-4997-9f75-1951f98e1751@github.com>
 <oUkJ0uQKU0kV8Xvvq19Ce5MZda7nQjUp8V9uvIBBBa0=.9a95b0d7-5000-4ebe-9feb-058d4330912f@github.com>
 <ij1ln8Iq9zn7GQ5xVrloWONKUpCiUsv6PvseQzgYTOY=.78772221-61d3-4691-8a25-ec3bdcfd0283@github.com>
 <oRyb7iT88wLQZJmsU8epocc8H4ibegW15dlWizrrQpU=.76754cd7-f20e-422a-b339-dac4a9f3c45c@github.com>
 <nrXMXFS52KW8RLluqr05TEWD2lmM0nOTTEhELtr82pg=.002d2fc7-36bb-4714-8f87-5598e5caa8d9@github.com>
 <uw2j_w8lI-Rv10zedg0mUgs-r3HDqGamrK_NOzTYjXY=.9e68d205-a70a-4510-931a-8c5cc2cd3d90@github.com>
Message-ID: <ZQSu_x9jsdspvfLm-GfUbKjU7pgLuTyOJYJGFWvPqY8=.809db48c-d3bf-4cef-b7d7-aa5fee138e08@github.com>

On Thu, 4 Feb 2021 08:14:47 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> From what I've seen it's normal for the 32-bit builds to fail. I'm not sure why they are even being built.
>
>> From what I've seen it's normal for the 32-bit builds to fail. I'm not sure why they are even being built.
> 
> Thanks for the info, then I think it's safe for me to ignore the failures in linux x86.

> _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [hotspot-runtime-dev](mailto:hotspot-runtime-dev at openjdk.java.net):_
> 
> On 4/02/2021 5:39 pm, Hamlin Li wrote:
> 
> > On Thu, 4 Feb 2021 03:40:26 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:
> > > > Hi @Hamlin-Li
> > > > I am not reviewer, but maybe you could add test for "parallel" in BasicJMapTest.java.
> > > 
> > > 
> > > > I am not reviewer, but maybe you could add test for "parallel" in BasicJMapTest.java.
> > > 
> > > 
> > > That test is for the `jmap` command, not the `GC.class_histogram` jcmd. As I pointed out, there are tests in `test/hotpot/jtreg/serviceability/dcmd/gc` that already test `GC.class_histogram`. That would be a better starting point.
> > 
> > 
> > @plummercj Hi Chris, I have a question which might not be related to the patch, my presubmit tests always failed on linux platforms, but I don't think the failure is related to my patch. Would you mind to share some point? I totally have no idea what's going wrong.
> > The error messages are as following:
> > E: Could not configure 'libc6:i386'.
> > E: Could not perform immediate configuration on 'libgcc-s1:i386'. Please see man 5 apt.conf under APT::Immediate-Configure for details. (2)
> > Error: Process completed with exit code 100.
> 
> I believe this has been fixed, so your repo may be missing that
> changeset at the moment.
> 
> David

Hi David, Thank you for the information.

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

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

From akozlov at openjdk.java.net  Thu Feb  4 12:00:51 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Thu, 4 Feb 2021 12:00: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: <9N0zJ8ZgY9e3yIF3IKnkdbkRu80waLyh8GHBti22DK8=.949c0612-f514-44a0-9d2b-ff9e2eb539d1@github.com>

On Tue, 2 Feb 2021 22:56:55 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/runtime/stubRoutines.inline.hpp line 1:
> 
>> 1: /*
> 
> NOW I understand the reason for switching from include to inline-include.
> Is there a reason that this change is part of this project and not extracted
> into a separate RFE. That would reduce the number of files touched by
> this project.

Makes sense, thanks. I'll do this as JDK-8261075.

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

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

From coleenp at openjdk.java.net  Thu Feb  4 13:20:41 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Thu, 4 Feb 2021 13:20:41 GMT
Subject: RFR: JDK-8260926: Trace resource exhausted events unconditionally
 [v2]
In-Reply-To: <GMjFgCwRTZYyOEjLHhAmkpPS3bBPCCYQEqDEUk0HzQA=.fba195f4-c2b0-4773-9784-e0bdc12becc9@github.com>
References: <-LuicM5vRHrcchY00NJhTTgngnNKX3ZkbKZVM_pmHpE=.372c1b6a-120c-460d-a168-76f200408efd@github.com>
 <GMjFgCwRTZYyOEjLHhAmkpPS3bBPCCYQEqDEUk0HzQA=.fba195f4-c2b0-4773-9784-e0bdc12becc9@github.com>
Message-ID: <K6qwIdolbOWT82hV7dbGumpw0eUCIrnm1vlmgpEbbnQ=.55e2c1f3-bee9-4caf-9b0c-17970d142957@github.com>

On Wed, 3 Feb 2021 06:39:01 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Analyzing out-of-resource situations in cloud scenarios is no fun. With CloudFoundry, a JVMTI agent (jvmkill) is hooked up intercepting the jvmti "resource exhausted" event, then attempts to write up a heap report. That may fail, e.g. due to bugs in the agent [1], but also because that report runs java code and may suffer from the same resource exhaustion. Successful or not, it unceremoniously kills the VM when done, often leaving us with no information about the actual resource.
>> 
>> It would be very helpful if we had unconditional tracing here. We do have tracing, but it requires a non-product build and is triggered with TraceJVMTI. Also, it traces at trace level which is way to fine granular.
>> 
>> I'd like to introduce another, unconditional trace line here. Arguably, resource exhausted is fatal enough that it justifies unconditional tracing.
>> 
>> This is a bit of a coin toss. Tracing unconditionally would help in most scenarios, where it would be either difficult or even impossible to specify a trace command line switch. OTOH it may trip up scripts parsing the VM output, or some of our tests (which can be fixed).
>> 
>> Thoughts?
>> 
>> ..Thomas
>> 
>> [1] https://github.com/cloudfoundry/jvmkill/issues/18
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Feedback David

This looks good!

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

Marked as reviewed by coleenp (Reviewer).

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

From stuefe at openjdk.java.net  Thu Feb  4 13:28:45 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Thu, 4 Feb 2021 13:28:45 GMT
Subject: RFR: JDK-8260926: Trace resource exhausted events unconditionally
 [v2]
In-Reply-To: <K6qwIdolbOWT82hV7dbGumpw0eUCIrnm1vlmgpEbbnQ=.55e2c1f3-bee9-4caf-9b0c-17970d142957@github.com>
References: <-LuicM5vRHrcchY00NJhTTgngnNKX3ZkbKZVM_pmHpE=.372c1b6a-120c-460d-a168-76f200408efd@github.com>
 <GMjFgCwRTZYyOEjLHhAmkpPS3bBPCCYQEqDEUk0HzQA=.fba195f4-c2b0-4773-9784-e0bdc12becc9@github.com>
 <K6qwIdolbOWT82hV7dbGumpw0eUCIrnm1vlmgpEbbnQ=.55e2c1f3-bee9-4caf-9b0c-17970d142957@github.com>
Message-ID: <dLU-zzLq_LfGPiMiwW9IKjkSt5hfofziXekVqqdMojs=.996569f2-abca-495d-b998-3fdebf4aa9cc@github.com>

On Thu, 4 Feb 2021 13:18:22 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Feedback David
>
> This looks good!

Thanks, Coleen!

@dholmes-ora : are you fine with the latest version?

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

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

From aph at openjdk.java.net  Thu Feb  4 14:30:49 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Thu, 4 Feb 2021 14:30:49 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
In-Reply-To: <R528o-L-66HqOlUjCWsFXTFMtzxgO2wE1Sm-sI7LHa0=.cdcfb777-8f05-4171-aea7-087db4b98387@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>
 <6oqFTX-wDWyEUpJ6FLHvgP8gi0zmnkF6Mzz87hC6A1w=.e0b31425-4750-472f-9335-0b187a59c834@github.com>
 <Qb8Gta50pNQAKiE8nUCa9dl9O19tEkeUg4E25At5Bwk=.0c5c6b99-eaf2-4617-b6ec-fef2b7dbfc03@github.com>
 <sMzpTev5Co7zYwj_MDJAQwt1h4TclV5VupIfIVXXS5Q=.de8bfe1b-8e72-4fc5-a6ec-cc46f5b1649f@github.com>
 <zRhpkKVeWL0jh_hqugUVc6jHF-ywB6SoH-lNSI7R-jw=.6ae275f4-5e41-4828-b49a-40ab52957c07@github.com>
 <R528o-L-66HqOlUjCWsFXTFMtzxgO2wE1Sm-sI7LHa0=.cdcfb777-8f05-4171-aea7-087db4b98387@github.com>
Message-ID: <tBm6Uwcyjx2nW2QjSzu4UsYVdG1p0qBueMqHXEGpU4A=.a197d217-efd5-47d3-9d2c-292248f17b72@github.com>

On Thu, 4 Feb 2021 09:49:17 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

> > You read my mind, Andrew. Unless, of course, it's optimized to leverage the fact that it's thread-specific..
> 
> it's thread-specific
> 
> https://developer.apple.com/documentation/apple_silicon/porting_just-in-time_compilers_to_apple_silicon
> 
> > Because pthread_jit_write_protect_np changes only the current thread?s permissions, avoid accessing the same memory region from multiple threads. Giving multiple threads access to the same memory region opens up a potential attack vector, in which one thread has write access and another has executable access to the same region.

Umm, so how does patching work? We don't even know if other threads are executing the code we need to patch.

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

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

From vkempik at openjdk.java.net  Thu Feb  4 14:43:51 2021
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Thu, 4 Feb 2021 14:43:51 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
In-Reply-To: <tBm6Uwcyjx2nW2QjSzu4UsYVdG1p0qBueMqHXEGpU4A=.a197d217-efd5-47d3-9d2c-292248f17b72@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>
 <6oqFTX-wDWyEUpJ6FLHvgP8gi0zmnkF6Mzz87hC6A1w=.e0b31425-4750-472f-9335-0b187a59c834@github.com>
 <Qb8Gta50pNQAKiE8nUCa9dl9O19tEkeUg4E25At5Bwk=.0c5c6b99-eaf2-4617-b6ec-fef2b7dbfc03@github.com>
 <sMzpTev5Co7zYwj_MDJAQwt1h4TclV5VupIfIVXXS5Q=.de8bfe1b-8e72-4fc5-a6ec-cc46f5b1649f@github.com>
 <zRhpkKVeWL0jh_hqugUVc6jHF-ywB6SoH-lNSI7R-jw=.6ae275f4-5e41-4828-b49a-40ab52957c07@github.com>
 <R528o-L-66HqOlUjCWsFXTFMtzxgO2wE1Sm-sI7LHa0=.cdcfb777-8f05-4171-aea7-087db4b98387@github.com>
 <tBm6Uwcyjx2nW2QjSzu4UsYVdG1p0qBueMqHXEGpU4A=.a197d217-efd5-47d3-9d2c-292248f17b72@github.com>
Message-ID: <LkqQp1RD7b0r8ONv6djUl6y5kzi3zk2F62TZGtOM3dE=.8ac5b2eb-75db-4be8-a2d9-ddc6587ee43d@github.com>

On Thu, 4 Feb 2021 14:27:53 GMT, Andrew Haley <aph at openjdk.org> wrote:

> > > You read my mind, Andrew. Unless, of course, it's optimized to leverage the fact that it's thread-specific..
> > 
> > 
> > it's thread-specific
> > https://developer.apple.com/documentation/apple_silicon/porting_just-in-time_compilers_to_apple_silicon
> > > Because pthread_jit_write_protect_np changes only the current thread?s permissions, avoid accessing the same memory region from multiple threads. Giving multiple threads access to the same memory region opens up a potential attack vector, in which one thread has write access and another has executable access to the same region.
> 
> Umm, so how does patching work? We don't even know if other threads are executing the code we need to patch.

I thought java can handle that scenario in usual (non W^X systems) just fine, so we just believe jvm did everything right and it's safe to rewrite some code at specific moment.

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

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

From akozlov at openjdk.java.net  Thu Feb  4 15:16:49 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Thu, 4 Feb 2021 15:16:49 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
In-Reply-To: <sMzpTev5Co7zYwj_MDJAQwt1h4TclV5VupIfIVXXS5Q=.de8bfe1b-8e72-4fc5-a6ec-cc46f5b1649f@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>
 <6oqFTX-wDWyEUpJ6FLHvgP8gi0zmnkF6Mzz87hC6A1w=.e0b31425-4750-472f-9335-0b187a59c834@github.com>
 <Qb8Gta50pNQAKiE8nUCa9dl9O19tEkeUg4E25At5Bwk=.0c5c6b99-eaf2-4617-b6ec-fef2b7dbfc03@github.com>
 <sMzpTev5Co7zYwj_MDJAQwt1h4TclV5VupIfIVXXS5Q=.de8bfe1b-8e72-4fc5-a6ec-cc46f5b1649f@github.com>
Message-ID: <73MpfeAfsTCSMLBU7q_Ho-oOWdCevCHXTIuxCHHWZBA=.26d22cdc-cb67-490f-9c7b-03623aa049c6@github.com>

On Wed, 3 Feb 2021 20:08:28 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> Out of curiosity, have you looked at the performance of the W^X state transition?

Earlier it was possible to disable W^X protection (unfortunately, I don't know a way to do this now). We compared Renaissance results with W^X transitions like the proposed one vs. no transitions with the protection disabled once. Results were identical for a small and large number of iterations.

>From the other hand, I've used https://github.com/AntonKozlov/macos-aarch64-transition-bench to estimate the cost of the transition.
I re-did measurements with the current implementation and on consumer hardware:

testJNI            thrpt   25   277997000.151 ?   4095685.956  ops/s
testJniNanoTime    thrpt   25    17851098.010 ?    119489.599  ops/s
testNanoTime       thrpt   25    78007491.762 ?    628455.971  ops/s
testNothing        thrpt   25  1724298829.088 ? 100537565.068  ops/s
testTwoStateAndWX  thrpt   25    21958839.057 ?    210490.755  ops/s
testWX             thrpt   25    23299813.266 ?    149837.302  ops/s

There is an overhead, but it does not look like blocking the first implementation. I'm not refusing future optimizations like enabling W only when necessary. But for now, I don't have a robust and maintainable solution for this, sorry.

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

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

From iignatyev at openjdk.java.net  Thu Feb  4 18:28:48 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 4 Feb 2021 18:28:48 GMT
Subject: RFR: 8260296: SA's dumpreplaydata fails [v4]
In-Reply-To: <YodG6Yp77UtKIjzx5TB3jfDu-az1kN3-b_GyKG1deVI=.07ab2194-72ab-4d54-a8fa-b32ed50f2ed9@github.com>
References: <dbCVL_PF2kTQaXwi_ss4MX87d4wO2jPo-j7mn8Hrtao=.94bd9abc-2143-4306-ada0-0d7d09684ed2@github.com>
 <YodG6Yp77UtKIjzx5TB3jfDu-az1kN3-b_GyKG1deVI=.07ab2194-72ab-4d54-a8fa-b32ed50f2ed9@github.com>
Message-ID: <nAB2xwZQWJau49XlzYYOIVIGjInjsHD1beNGGfIghiA=.8eac5f66-1944-42a7-b15b-80cd7b279282@github.com>

On Thu, 4 Feb 2021 09:44:13 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> I noticed that the SA's dumpreplaydata command fails with:
>> 
>> java.lang.AssertionError: CLHSDB wasn't run successfully: Opening core file, please wait...
>> hsdb> Exception in thread "main" java.lang.InternalError: ciMetadata does not appear to be polymorphic
>> 
>> with a simple test program. This happens because the SA can't find the
>> vtable symbol for ciMetadata (build produced by gcc 9.2.1). AFAIU,
>> there's nothing in our build system that hides that symbol. I had to
>> move one method's definition from the header file to the cpp file for
>> the symbol to be visible again.
>> 
>> We have a test that checks dumpreplaydata but it doesn't catch that
>> problem. The test produces a replay file from a core file with the SA
>> by running a simple test with -Xcomp and CICrash=1. So the replay data
>> has very little or no profile data (which is what causes the problem
>> above). I propose running a slightly more complicated test method and
>> crashing after the method has had time to run for long enough to
>> collect profile data.
>> 
>> The other shortcoming of the test is that it doesn't look at the
>> content of the replay file. It only warns if they differ. The replay
>> file produced by the VM and the one produced by the SA should be
>> identical (except for comment lines). So I propose we check that.
>> 
>> Finally, I can't run that test on my system because core files are
>> handled by systemd (I'm running some recent version of fedora). I
>> suppose, the system can be configured differently but having the test
>> work out the box is nice. I extended the test case to handle that.
>> 
>> With the improved test, there are a few differences between the VM and
>> SA replay files caused by VM changes that were not mirrored in the
>> SA. I fixed those.
>
> Roland Westrelin 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:
> 
>  - pid in OutputAnalyzer
>  - pid in OutputAnalyzer
>  - Merge branch 'master' into JDK-8260296
>  - convert all tests
>  - Merge branch 'master' into JDK-8260296
>  - use CoreUtils
>  - whitespaces
>  - SA fixes
>  - VM fix
>  - test

LGTM, you still need to update the copyright years as @plummercj [mentioned](https://github.com/openjdk/jdk/pull/2195#issuecomment-768115732).

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

Marked as reviewed by iignatyev (Reviewer).

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

From iignatyev at openjdk.java.net  Thu Feb  4 18:28:48 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 4 Feb 2021 18:28:48 GMT
Subject: RFR: 8260296: SA's dumpreplaydata fails [v3]
In-Reply-To: <ba-Xnb7Fj1KwMez4GsvQXbKP8HrC0VGGdDFyn14zclc=.ba00c708-b580-4904-b4a5-de91e6c7e181@github.com>
References: <dbCVL_PF2kTQaXwi_ss4MX87d4wO2jPo-j7mn8Hrtao=.94bd9abc-2143-4306-ada0-0d7d09684ed2@github.com>
 <N4znCSiBMzQSv2T9Nn42nKEmmfVw59SZoc6fZVq7lgw=.1c87d509-70f1-4ddb-a1aa-eda427d8e259@github.com>
 <GQ4Rh3M9G3dwYmXwULK0Vc6ui6omGakm8vswFEQqOl8=.a5b31e8a-5af0-4914-8e65-ad6d44b73d21@github.com>
 <aj2K1Z1z6rE-rB46D83uV6Fbs4kHF2P_LOumtjWrC6s=.3ea6a5bf-1356-4287-a746-aa2da2f60677@github.com>
 <szyKVJwJZABJzqj8BOKjMfGo7rn8KLUfzrTdE1l0SNQ=.2ea62edd-dc83-4da2-8a16-6cb86076a46b@github.com>
 <ba-Xnb7Fj1KwMez4GsvQXbKP8HrC0VGGdDFyn14zclc=.ba00c708-b580-4904-b4a5-de91e6c7e181@github.com>
Message-ID: <ppXJxks_xkkYNh50ehTLGHyHjgsTxCBSaJGN7yvWTS0=.866e3059-0074-4dcd-9e6d-31e8e32f8381@github.com>

On Thu, 4 Feb 2021 09:40:33 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> `OutputAnalyzer`/ `OutputBuffer` already have an exit value, which arguable has nothing to do w/ the text output either, so I think it's ok to add a pid into `OutputBuffer` i-face and both of its implementations.
>
> I just pushed a change that does this. Does that look ok to you?

yes, thank you.

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

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

From cjplummer at openjdk.java.net  Thu Feb  4 19:18:46 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 4 Feb 2021 19:18:46 GMT
Subject: RFR: 8260296: SA's dumpreplaydata fails [v4]
In-Reply-To: <nAB2xwZQWJau49XlzYYOIVIGjInjsHD1beNGGfIghiA=.8eac5f66-1944-42a7-b15b-80cd7b279282@github.com>
References: <dbCVL_PF2kTQaXwi_ss4MX87d4wO2jPo-j7mn8Hrtao=.94bd9abc-2143-4306-ada0-0d7d09684ed2@github.com>
 <YodG6Yp77UtKIjzx5TB3jfDu-az1kN3-b_GyKG1deVI=.07ab2194-72ab-4d54-a8fa-b32ed50f2ed9@github.com>
 <nAB2xwZQWJau49XlzYYOIVIGjInjsHD1beNGGfIghiA=.8eac5f66-1944-42a7-b15b-80cd7b279282@github.com>
Message-ID: <brSRUCTWuBzI7zRElceeBNFI8_LXQEy4fAnl6yIg9pc=.b5087e9d-005f-401a-a563-61950ffec345@github.com>

On Thu, 4 Feb 2021 18:25:45 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Roland Westrelin 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:
>> 
>>  - pid in OutputAnalyzer
>>  - pid in OutputAnalyzer
>>  - Merge branch 'master' into JDK-8260296
>>  - convert all tests
>>  - Merge branch 'master' into JDK-8260296
>>  - use CoreUtils
>>  - whitespaces
>>  - SA fixes
>>  - VM fix
>>  - test
>
> LGTM, you still need to update the copyright years as @plummercj [mentioned](https://github.com/openjdk/jdk/pull/2195#issuecomment-768115732).

Yes, this is a much better solution for getting the pid.

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

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

From vkempik at openjdk.java.net  Thu Feb  4 21:53:49 2021
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Thu, 4 Feb 2021 21:53:49 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
In-Reply-To: <73MpfeAfsTCSMLBU7q_Ho-oOWdCevCHXTIuxCHHWZBA=.26d22cdc-cb67-490f-9c7b-03623aa049c6@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>
 <6oqFTX-wDWyEUpJ6FLHvgP8gi0zmnkF6Mzz87hC6A1w=.e0b31425-4750-472f-9335-0b187a59c834@github.com>
 <Qb8Gta50pNQAKiE8nUCa9dl9O19tEkeUg4E25At5Bwk=.0c5c6b99-eaf2-4617-b6ec-fef2b7dbfc03@github.com>
 <sMzpTev5Co7zYwj_MDJAQwt1h4TclV5VupIfIVXXS5Q=.de8bfe1b-8e72-4fc5-a6ec-cc46f5b1649f@github.com>
 <73MpfeAfsTCSMLBU7q_Ho-oOWdCevCHXTIuxCHHWZBA=.26d22cdc-cb67-490f-9c7b-03623aa049c6@github.com>
Message-ID: <Veugm55g1oZCofTLY3Pfdv3SpMWU1z3VtHQlP4AgNQE=.cf5161c7-fff6-43d5-bab8-66ca928bd736@github.com>

On Thu, 4 Feb 2021 15:13:49 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Out of curiosity, have you looked at the performance of the W^X state transition? In particular I'm wondering if the cost is effectively negligible so doing it unconditionally on JVM entry is a no-brainer and just easier/cleaner than the alternatives, or if there are reasons to look at only doing the transition if/when needed (perhaps do it lazily and revert back to X when leaving the JVM?).
>
>> Out of curiosity, have you looked at the performance of the W^X state transition?
> 
> Earlier it was possible to disable W^X protection (unfortunately, I don't know a way to do this now). We compared Renaissance results with W^X transitions like the proposed one vs. no transitions with the protection disabled once. Results were identical for a small and large number of iterations.
> 
> From the other hand, I've used https://github.com/AntonKozlov/macos-aarch64-transition-bench to estimate the cost of the transition.
> I re-did measurements with the current implementation and on consumer hardware:
> 
> testJNI            thrpt   25   277997000.151 ?   4095685.956  ops/s
> testJniNanoTime    thrpt   25    17851098.010 ?    119489.599  ops/s
> testNanoTime       thrpt   25    78007491.762 ?    628455.971  ops/s
> testNothing        thrpt   25  1724298829.088 ? 100537565.068  ops/s
> testTwoStateAndWX  thrpt   25    21958839.057 ?    210490.755  ops/s
> testWX             thrpt   25    23299813.266 ?    149837.302  ops/s
> 
> There is an overhead, but it does not look like blocking the first implementation. I'm not refusing future optimizations like enabling W only when necessary. But for now, I don't have a robust and maintainable solution for this, sorry.

> _Mailing list message from [erik.joelsson at oracle.com](mailto:erik.joelsson at oracle.com) on [2d-dev](mailto:2d-dev at openjdk.java.net):_
> 
> On 2021-01-26 04:44, Magnus Ihse Bursie wrote:
> 
> > On 2021-01-26 13:09, Vladimir Kempik wrote:
> > > On Tue, 26 Jan 2021 12:02:02 GMT, Alan Hayward
> > > <github.com+4146708+a74nh at openjdk.org> wrote:
> > > > AIUI, the configure line needs passing a prebuilt
> > > > JavaNativeFoundation framework
> > > > ie:
> > > > `--with-extra-ldflags='-F
> > > > /Applications/Xcode.app/Contents/SharedFrameworks/ContentDeliveryServices.framework/Versions/A/itms/java/Frameworks/'`
> > > > Otherwise there will be missing _JNFNative* functions.
> > > > Is this the long term plan? Or will eventually the required code be
> > > > moved into JDK and/or the xcode one automatically get picked up by
> > > > the configure scripts?
> > > > There is ongoing work by P. Race to eliminate dependence on JNF at all
> > > > How far has that work come? Otherwise the logic should be added to
> > > > configure to look for this framework automatically, and provide a way
> > > > to override it/set it if not found.
> > 
> > 
> > I don't think it's OK to publish a new port that cannot build
> > out-of-the-box without hacks like this.
> 
> My understanding is that Apple chose to not provide JNF for aarch64, so
> if you want to build OpenJDK, you first need to build JNF yourself (it's
> available in github). Phil is working on removing this dependency
> completely, which will solve this issue [1].
> 
> In the meantime, I don't think we should rely on finding JNF in
> unsupported locations inside Xcode. Could we wait with integrating this
> port until it can be built without such hacks? If not, then adding
> something in the documentation on how to get a working JNF would at
> least be needed.
> 
> /Erik
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8257852

This doesn't seem to be an issue anymore, After P.Race have finished with JDK-8257852, Macarm port can be build without extra ld flags. J2Demo works fine as example.
This can be checked if one merges pull/2200 branch into his local copy of master branch.

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

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

From gziemski at openjdk.java.net  Thu Feb  4 22:01:51 2021
From: gziemski at openjdk.java.net (Gerard Ziemski)
Date: Thu, 4 Feb 2021 22:01:51 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v10]
In-Reply-To: <QZ7stXQpgmcHxvq5cmr2FB_R8lyy2xGDNK8m1cawvWk=.f436fe10-400b-4a6c-a41c-ebdb170a3248@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <QZ7stXQpgmcHxvq5cmr2FB_R8lyy2xGDNK8m1cawvWk=.f436fe10-400b-4a6c-a41c-ebdb170a3248@github.com>
Message-ID: <9Nasu4m7orJoGYjX4EYCuz5-aevYNno3Ru3jPHgwkvc=.168cfdf0-648b-46e4-9cb4-b24956eeba7d@github.com>

On Wed, 3 Feb 2021 20:01:15 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 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 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?

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

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

From gziemski at openjdk.java.net  Thu Feb  4 22:18:49 2021
From: gziemski at openjdk.java.net (Gerard Ziemski)
Date: Thu, 4 Feb 2021 22:18:49 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v10]
In-Reply-To: <QZ7stXQpgmcHxvq5cmr2FB_R8lyy2xGDNK8m1cawvWk=.f436fe10-400b-4a6c-a41c-ebdb170a3248@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <QZ7stXQpgmcHxvq5cmr2FB_R8lyy2xGDNK8m1cawvWk=.f436fe10-400b-4a6c-a41c-ebdb170a3248@github.com>
Message-ID: <hEaFWHE_iOfvoT79PO1tsOkG0IVniyDakQlyH3_t70s=.a0083425-ef18-413b-be61-bfaa1eea8452@github.com>

On Wed, 3 Feb 2021 20:01:15 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 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 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.

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?

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

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

From gziemski at openjdk.java.net  Thu Feb  4 22:22:48 2021
From: gziemski at openjdk.java.net (Gerard Ziemski)
Date: Thu, 4 Feb 2021 22:22:48 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v10]
In-Reply-To: <QZ7stXQpgmcHxvq5cmr2FB_R8lyy2xGDNK8m1cawvWk=.f436fe10-400b-4a6c-a41c-ebdb170a3248@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <QZ7stXQpgmcHxvq5cmr2FB_R8lyy2xGDNK8m1cawvWk=.f436fe10-400b-4a6c-a41c-ebdb170a3248@github.com>
Message-ID: <BBmY-RwJnKmZsM2hkLj7698FHz3GCM-ZOgLyRuuI10k=.3afc8557-9ac3-4c48-bbc2-3b5f9cebda5a@github.com>

On Wed, 3 Feb 2021 20:01:15 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 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 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?

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

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

From gziemski at openjdk.java.net  Thu Feb  4 22:36:49 2021
From: gziemski at openjdk.java.net (Gerard Ziemski)
Date: Thu, 4 Feb 2021 22:36:49 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v10]
In-Reply-To: <QZ7stXQpgmcHxvq5cmr2FB_R8lyy2xGDNK8m1cawvWk=.f436fe10-400b-4a6c-a41c-ebdb170a3248@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <QZ7stXQpgmcHxvq5cmr2FB_R8lyy2xGDNK8m1cawvWk=.f436fe10-400b-4a6c-a41c-ebdb170a3248@github.com>
Message-ID: <9bn80xM9g41OytCtH71-krOZtAgy27TbvTFJHmfmKrE=.e9d223d5-2922-4891-8f45-ee039d88ced6@github.com>

On Wed, 3 Feb 2021 20:01:15 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 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?

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

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

From gziemski at openjdk.java.net  Thu Feb  4 22:44:47 2021
From: gziemski at openjdk.java.net (Gerard Ziemski)
Date: Thu, 4 Feb 2021 22:44:47 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v10]
In-Reply-To: <QZ7stXQpgmcHxvq5cmr2FB_R8lyy2xGDNK8m1cawvWk=.f436fe10-400b-4a6c-a41c-ebdb170a3248@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <QZ7stXQpgmcHxvq5cmr2FB_R8lyy2xGDNK8m1cawvWk=.f436fe10-400b-4a6c-a41c-ebdb170a3248@github.com>
Message-ID: <5xcTYtv5IrRdAkhPa6uG0C__8L6IsXKQOCsAaeha0vk=.217371e5-85a4-4b62-a885-5236a94cd242@github.com>

On Wed, 3 Feb 2021 20:01:15 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 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 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?

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

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

From gziemski at openjdk.java.net  Thu Feb  4 22:51:50 2021
From: gziemski at openjdk.java.net (Gerard Ziemski)
Date: Thu, 4 Feb 2021 22:51:50 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v10]
In-Reply-To: <QZ7stXQpgmcHxvq5cmr2FB_R8lyy2xGDNK8m1cawvWk=.f436fe10-400b-4a6c-a41c-ebdb170a3248@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <QZ7stXQpgmcHxvq5cmr2FB_R8lyy2xGDNK8m1cawvWk=.f436fe10-400b-4a6c-a41c-ebdb170a3248@github.com>
Message-ID: <i9UArB35vpHowW6HbtTkKLQX-wwfSx1dg1NKLHIRdGs=.5e08a151-8ad3-46cc-b006-34d750410c47@github.com>

On Wed, 3 Feb 2021 20:01:15 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 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 297:

> 295:           stub = SharedRuntime::handle_unsafe_access(thread, next_pc);
> 296:         }
> 297:       } else if (sig == SIGILL && nativeInstruction_at(pc)->is_stop()) {

Can we add a comment here describing what this case means?

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

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

From gziemski at openjdk.java.net  Thu Feb  4 23:08:50 2021
From: gziemski at openjdk.java.net (Gerard Ziemski)
Date: Thu, 4 Feb 2021 23:08:50 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v10]
In-Reply-To: <QZ7stXQpgmcHxvq5cmr2FB_R8lyy2xGDNK8m1cawvWk=.f436fe10-400b-4a6c-a41c-ebdb170a3248@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <QZ7stXQpgmcHxvq5cmr2FB_R8lyy2xGDNK8m1cawvWk=.f436fe10-400b-4a6c-a41c-ebdb170a3248@github.com>
Message-ID: <RsX4BRh-N8Gch2KVeObHHtsMgc9TTLdeiZJSY5QuTYY=.3af04858-7c03-4eec-be0f-b6f2a31c15cf@github.com>

On Wed, 3 Feb 2021 20:01:15 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 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

I reviewed bsd_aarch64.cpp digging bit deeper and left some comments.

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

Changes requested by gziemski (Committer).

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

From cjplummer at openjdk.java.net  Thu Feb  4 23:19:43 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 4 Feb 2021 23:19:43 GMT
Subject: RFR: JDK-8261034: improve jcmd GC.class_histogram to support
 parallel [v3]
In-Reply-To: <EtePCjI8QD6rSfd7DjihG3MT5XzPRGXVUhtKAl7ioY4=.b9c89460-7998-416e-8bec-60980abee6f6@github.com>
References: <VKzVY-01CEXUbQdlKMhDWjtjxUgpxs_6487x232VsAI=.3b9c5d8a-972b-4997-9f75-1951f98e1751@github.com>
 <EtePCjI8QD6rSfd7DjihG3MT5XzPRGXVUhtKAl7ioY4=.b9c89460-7998-416e-8bec-60980abee6f6@github.com>
Message-ID: <hTE1AreVDhxMyojIXd_VFAdY8-9BiUenSbW7E9VxyG0=.d116728f-7a36-43c3-be9a-53f613da5565@github.com>

On Thu, 4 Feb 2021 07:28:03 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> parallel -histo of jmap was added by JDK-8214535, it's better to support parallel for jcmd GC.class_histogram too.
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8261034: improve jcmd GC.class_histogram to support parallel

test/hotspot/jtreg/serviceability/dcmd/gc/ClassHistogramTest.java line 96:

> 94:                 {"-parallel=0"},
> 95:                 {"-parallel=1"},
> 96:                 {"-parallel=2"},

Is there a way to test invalid arguments within this test framework? It seems the assumption for the `run()` method is that the arguments are valid and a histogram should be in the output.

src/hotspot/share/services/diagnosticCommand.cpp line 562:

> 560:        "0 use system determined number of threads, "
> 561:        "1 use one thread, i.e., disable parallelism, "
> 562:        "n use n threads, n must be positive.",

"Number of parallel threads for heap iteration. "
       "0 means let the VM determined the number of threads. "
       "1 means use one thread, i.e. disable parallelism. "
       "n means use n threads. n must be positive.",

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

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

From cjplummer at openjdk.java.net  Thu Feb  4 23:26:46 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 4 Feb 2021 23:26:46 GMT
Subject: RFR: 8257234 : Add gz option to SA jmap to write a gzipped heap
 dump [v14]
In-Reply-To: <3AOVqSv3mzE-QVGg7NWJ8vs4pKBoHTgeHZjf1FHA9XA=.d0ab8c18-6d62-43c6-8232-4b1621ebc609@github.com>
References: <oTMRc7LWvx9_Uov01HPX9UgyEqFmXt_nMG920HUQBIM=.3651754b-e1f1-46f8-9f44-c118a5c56dbe@github.com>
 <hshEN06sqJcgNmcW4Yb75mtnYFVMiqX3lfmekNjzApU=.183255d4-56da-48ac-8a81-7a81b5900253@github.com>
 <d2qneSjNn2StFBGSsQy45NNz8SI7WTogYPq8WR9pIlQ=.7d78b062-3606-4d29-9b18-81dfe9f38df9@github.com>
 <3AOVqSv3mzE-QVGg7NWJ8vs4pKBoHTgeHZjf1FHA9XA=.d0ab8c18-6d62-43c6-8232-4b1621ebc609@github.com>
Message-ID: <eXFuaiLypqbGOiQMANkJ39sR1aTMSxtAlwG9XD4KuFk=.0efbc8de-50d4-4ed4-9566-074213c23b5f@github.com>

On Thu, 4 Feb 2021 08:10:00 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/SALauncher.java line 130:
>> 
>>> 128:         System.out.println("    --binaryheap            To dump java heap in hprof binary format.");
>>> 129:         System.out.println("    --dumpfile <name>       The name of the dump file.");
>>> 130:         System.out.println("    --gz <1-9>              The compression level for gzipped dump file.");
>> 
>> `--dumpfile` and `--gz` can only be used with `--binaryheap`. That should be made clear in the help text. 
>> 
>> I just noticed that `jhsdb pmap` does not support the equivalent of `format=x` that the jcmd version does. However, the support is actually there in the SA JMap.java. It's confusing because both `jhsdb jmap` and the clhsdb `dumpheap` command use the JMap class, but neither support passing `format=x` to it. In order to get SA to dump with `format=x`, you would need to launch `sun/jvm/hotspot/tools/JMap` directly and pass in `-heap:format=x`. I'm not suggesting you fix that, but just something for us to be aware of.
>> 
>> One question though. Have you tried running JMap directly to make sure the help output looks right. You've made fixes to it in this webrev, but since there are so many different "jmap" commands (5), and each with their own help, I've lost sight of whether or not this is even tested. I don't believe it is, but I wouldn't worry about that. However, since made changes to the help output, it would be good to at least check it out.
>> 
>> And if you are wonder what the 5 `jmap` commands are:
>> 
>> - SA's `jhsdb jmap --binaryheap` (which uses JMap.java with `-heap:format=b`)
>> - SA's clhsdb `dumpheap` command (which also uses JMap.java with `-heap:format=b`)
>> - executing  SA's `sun/jvm/hotspot/tools/JMap` class directly
>> - `jmap -dump` command (Uses Attach API's `heapdump` command, which uses hotspot `HeapDump` class)
>> - `GC.heap_dump` dcmd, which also uses the hotspot `HeapDumper` class
>> 
>> So really there are two implementations of heap dumping, one in the VM and one in SA, but a total of 5 ways to get to them. I'm just starting to get my head wrapped around all this myself. We've created a very confusing situation for us, and unfortunately I think some of the changes that got us here was driven by a goal to simply things.
>
> Thanks for the thorough list, I have tested most of them but not all. I will cover them and update here later.
> 
>> So really there are two implementations of heap dumping, one in the VM and one in SA, but a total of 5 ways to get to them. I'm just starting to get my head wrapped around all this myself. We've created a very confusing situation for us, and unfortunately I think some of the changes that got us here was driven by a goal to simply things.
> 
> Yes, it makes me even curious about why there can be two different implementation of them (one by C++ and one by Java),  it seems we need double the work of adding new options for those tools, like parallal for jmap histo and dump, etc.

One implementation is in the JVM itself, to be used when the JVM is still running well, and not just from command line tools. Heap dumping can also be triggered by the JVM itslef by setting flags like -XX:+HeapDumpBeforeFullGC. The other implementation is in SA, to be used on a core file or a hung JVM process, although it can also be used on a JVM that is still running well. BTW, there used to be a 3rd implementation. The old hprof profiler (a JVMTI agent) also was used to generate hprof files.

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

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

From dholmes at openjdk.java.net  Thu Feb  4 23:26:43 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 4 Feb 2021 23:26:43 GMT
Subject: RFR: JDK-8260926: Trace resource exhausted events unconditionally
 [v2]
In-Reply-To: <GMjFgCwRTZYyOEjLHhAmkpPS3bBPCCYQEqDEUk0HzQA=.fba195f4-c2b0-4773-9784-e0bdc12becc9@github.com>
References: <-LuicM5vRHrcchY00NJhTTgngnNKX3ZkbKZVM_pmHpE=.372c1b6a-120c-460d-a168-76f200408efd@github.com>
 <GMjFgCwRTZYyOEjLHhAmkpPS3bBPCCYQEqDEUk0HzQA=.fba195f4-c2b0-4773-9784-e0bdc12becc9@github.com>
Message-ID: <MhJsMStqxHs9IQE574u0h3HYlvke8BBLNs6bCYsiwN8=.ed57434b-3818-44cd-b9de-473088a90625@github.com>

On Wed, 3 Feb 2021 06:39:01 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Analyzing out-of-resource situations in cloud scenarios is no fun. With CloudFoundry, a JVMTI agent (jvmkill) is hooked up intercepting the jvmti "resource exhausted" event, then attempts to write up a heap report. That may fail, e.g. due to bugs in the agent [1], but also because that report runs java code and may suffer from the same resource exhaustion. Successful or not, it unceremoniously kills the VM when done, often leaving us with no information about the actual resource.
>> 
>> It would be very helpful if we had unconditional tracing here. We do have tracing, but it requires a non-product build and is triggered with TraceJVMTI. Also, it traces at trace level which is way to fine granular.
>> 
>> I'd like to introduce another, unconditional trace line here. Arguably, resource exhausted is fatal enough that it justifies unconditional tracing.
>> 
>> This is a bit of a coin toss. Tracing unconditionally would help in most scenarios, where it would be either difficult or even impossible to specify a trace command line switch. OTOH it may trip up scripts parsing the VM output, or some of our tests (which can be fixed).
>> 
>> Thoughts?
>> 
>> ..Thomas
>> 
>> [1] https://github.com/cloudfoundry/jvmkill/issues/18
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Feedback David

I would have formatted the message differently as per my first comment. But ok.

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

Marked as reviewed by dholmes (Reviewer).

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

From cjplummer at openjdk.java.net  Thu Feb  4 23:33:48 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 4 Feb 2021 23:33:48 GMT
Subject: RFR: 8261131: jcmd jmap dump should not accept gz option with no
 value
In-Reply-To: <qUp1tOUkdsvzPGH03MyAhSokYQUUYm9xz-2X6GjsSC4=.21007ed7-65f7-4768-a2f8-e7d2ac2533f6@github.com>
References: <qUp1tOUkdsvzPGH03MyAhSokYQUUYm9xz-2X6GjsSC4=.21007ed7-65f7-4768-a2f8-e7d2ac2533f6@github.com>
Message-ID: <Q27V-7NuhGt5rMtp02i4fKrOPXSKXDUvfHzKKbQsNaY=.401e9ab4-a592-4381-8b61-ab82ab698d6d@github.com>

On Thu, 4 Feb 2021 07:11:19 GMT, Lin Zang <lzang at openjdk.org> wrote:

> 8261131: jcmd jmap dump should not accept gz option with no value

Copyrights needs updating in both files.

src/jdk.jcmd/share/classes/sun/tools/jmap/JMap.java line 230:

> 228:             } else if (subopt.startsWith("gz=")) {
> 229:                compress_level = subopt.substring("gz=".length());
> 230:                if (compress_level == null || compress_level.length() == 0) {

I don't think `substring` can return `null`, so the proper fix was to remove the null check and replace with your check for `== 0`.

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

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

From mli at openjdk.java.net  Fri Feb  5 02:43:03 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Fri, 5 Feb 2021 02:43:03 GMT
Subject: RFR: JDK-8261034: improve jcmd GC.class_histogram to support
 parallel [v3]
In-Reply-To: <hTE1AreVDhxMyojIXd_VFAdY8-9BiUenSbW7E9VxyG0=.d116728f-7a36-43c3-be9a-53f613da5565@github.com>
References: <VKzVY-01CEXUbQdlKMhDWjtjxUgpxs_6487x232VsAI=.3b9c5d8a-972b-4997-9f75-1951f98e1751@github.com>
 <EtePCjI8QD6rSfd7DjihG3MT5XzPRGXVUhtKAl7ioY4=.b9c89460-7998-416e-8bec-60980abee6f6@github.com>
 <hTE1AreVDhxMyojIXd_VFAdY8-9BiUenSbW7E9VxyG0=.d116728f-7a36-43c3-be9a-53f613da5565@github.com>
Message-ID: <S6IuLJ19Du-PSnI7KSeR7obqbNoS8GJ_wm0Z2U7Y_2w=.ac2466e0-8333-45e2-b030-ab240b31bd53@github.com>

On Thu, 4 Feb 2021 23:08:21 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   JDK-8261034: improve jcmd GC.class_histogram to support parallel
>
> test/hotspot/jtreg/serviceability/dcmd/gc/ClassHistogramTest.java line 96:
> 
>> 94:                 {"-parallel=0"},
>> 95:                 {"-parallel=1"},
>> 96:                 {"-parallel=2"},
> 
> Is there a way to test invalid arguments within this test framework? It seems the assumption for the `run()` method is that the arguments are valid and a histogram should be in the output.

sure, just added some test cases for invalid args, and also added test condition in production to return if parallel < 0.

> src/hotspot/share/services/diagnosticCommand.cpp line 562:
> 
>> 560:        "0 use system determined number of threads, "
>> 561:        "1 use one thread, i.e., disable parallelism, "
>> 562:        "n use n threads, n must be positive.",
> 
> "Number of parallel threads for heap iteration. "
>        "0 means let the VM determined the number of threads. "
>        "1 means use one thread, i.e. disable parallelism. "
>        "n means use n threads. n must be positive.",

Thanks for detailed review, Chris, just modified as you suggested.

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

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

From mli at openjdk.java.net  Fri Feb  5 02:43:01 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Fri, 5 Feb 2021 02:43:01 GMT
Subject: RFR: JDK-8261034: improve jcmd GC.class_histogram to support
 parallel [v4]
In-Reply-To: <VKzVY-01CEXUbQdlKMhDWjtjxUgpxs_6487x232VsAI=.3b9c5d8a-972b-4997-9f75-1951f98e1751@github.com>
References: <VKzVY-01CEXUbQdlKMhDWjtjxUgpxs_6487x232VsAI=.3b9c5d8a-972b-4997-9f75-1951f98e1751@github.com>
Message-ID: <tLypVGBk-BlHtdCQL4MoCpd9k-r1lC1uBxgWUVBydQ8=.dc1a9826-ef45-4f45-af16-7e9213b80dd7@github.com>

> parallel -histo of jmap was added by JDK-8214535, it's better to support parallel for jcmd GC.class_histogram too.

Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8261034: improve jcmd GC.class_histogram to support parallel

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2379/files
  - new: https://git.openjdk.java.net/jdk/pull/2379/files/c083f6bd..f01fdbc7

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

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

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

From mli at openjdk.java.net  Fri Feb  5 02:47:01 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Fri, 5 Feb 2021 02:47:01 GMT
Subject: RFR: JDK-8261034: improve jcmd GC.class_histogram to support
 parallel [v5]
In-Reply-To: <VKzVY-01CEXUbQdlKMhDWjtjxUgpxs_6487x232VsAI=.3b9c5d8a-972b-4997-9f75-1951f98e1751@github.com>
References: <VKzVY-01CEXUbQdlKMhDWjtjxUgpxs_6487x232VsAI=.3b9c5d8a-972b-4997-9f75-1951f98e1751@github.com>
Message-ID: <VSTJIsFLpVyvAf9R2WTIaIhXtn6RPqQvQ7TlKbfJBgY=.2d4e5748-214e-44fe-a3f9-a93672743720@github.com>

> parallel -histo of jmap was added by JDK-8214535, it's better to support parallel for jcmd GC.class_histogram too.

Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8261034: improve jcmd GC.class_histogram to support parallel

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2379/files
  - new: https://git.openjdk.java.net/jdk/pull/2379/files/f01fdbc7..380d2acc

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

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

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

From david.holmes at oracle.com  Fri Feb  5 05:01:10 2021
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 5 Feb 2021 15:01:10 +1000
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v10]
In-Reply-To: <QZ7stXQpgmcHxvq5cmr2FB_R8lyy2xGDNK8m1cawvWk=.f436fe10-400b-4a6c-a41c-ebdb170a3248@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <QZ7stXQpgmcHxvq5cmr2FB_R8lyy2xGDNK8m1cawvWk=.f436fe10-400b-4a6c-a41c-ebdb170a3248@github.com>
Message-ID: <8ac7e6ab-2e12-67fc-3440-5fd8f7a585ea@oracle.com>

Hi Anton,

On 4/02/2021 6:01 am, Anton Kozlov wrote:
>> Please review the implementation of JEP 391: macOS/AArch64 Port.
> 
> 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

These updates to the w^x code look good to me, this is much improved in 
terms of the pervasiveness/intrusiveness. Hopefully there can still be 
further refinement in the future (after the initial integration).

Thanks,
David

> -------------
> 
> Changes:
>    - all: https://git.openjdk.java.net/jdk/pull/2200/files
>    - new: https://git.openjdk.java.net/jdk/pull/2200/files/3c705ae5..80827176
> 
> Webrevs:
>   - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=09
>   - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=08-09
> 
>    Stats: 444 lines in 64 files changed: 112 ins; 278 del; 54 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 gziemski at openjdk.java.net  Fri Feb  5 05:03:54 2021
From: gziemski at openjdk.java.net (Gerard Ziemski)
Date: Fri, 5 Feb 2021 05:03:54 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v10]
In-Reply-To: <QZ7stXQpgmcHxvq5cmr2FB_R8lyy2xGDNK8m1cawvWk=.f436fe10-400b-4a6c-a41c-ebdb170a3248@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <QZ7stXQpgmcHxvq5cmr2FB_R8lyy2xGDNK8m1cawvWk=.f436fe10-400b-4a6c-a41c-ebdb170a3248@github.com>
Message-ID: <snefTFoz9nOu7pghwG_v5GiOsmMvFSiICF3Hr1UskCs=.e9df3841-8204-41f5-a2b7-d8b07569a646@github.com>

On Wed, 3 Feb 2021 20:01:15 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 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 403:

> 401:   }
> 402: 
> 403:   return false; // Mute compiler

Is this comment needed?

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?

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/.

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

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

From gziemski at openjdk.java.net  Fri Feb  5 05:03:53 2021
From: gziemski at openjdk.java.net (Gerard Ziemski)
Date: Fri, 5 Feb 2021 05:03:53 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: <UnSWIprKrFiPt4vWX36CgseOH4-iJVexy8UBjsGUJ4k=.67e5231b-a1f0-4ded-9852-6ea7fcbff05a@github.com>

On Tue, 2 Feb 2021 22:09:58 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/os_bsd_aarch64.cpp line 363:
> 
>> 361:     address pc = os::Posix::ucontext_get_pc(uc);
>> 362: 
>> 363:     if (pc != addr && uc->context_esr == 0x9200004F) { //TODO: figure out what this value means
> 
> Is this TODO going to be resolved by this port?

Where did this come from - some snippet/example/tech note code? Maybe other people can help figure it out if we provide more info.

> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 374:
> 
>> 372: 
>> 373:       last_addr = (address) -1;
>> 374:     } else if (pc == addr && uc->context_esr == 0x8200000f) { //TODO: figure out what this value means
> 
> Is this TODO going to be resolved by this port?

Where did this come from - some snippet/example/tech note code? Maybe other people can help figure it out if we provide more info.

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

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

From lzang at openjdk.java.net  Fri Feb  5 06:38:53 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Fri, 5 Feb 2021 06:38:53 GMT
Subject: RFR: 8261131: jcmd jmap dump should not accept gz option with no
 value [v2]
In-Reply-To: <qUp1tOUkdsvzPGH03MyAhSokYQUUYm9xz-2X6GjsSC4=.21007ed7-65f7-4768-a2f8-e7d2ac2533f6@github.com>
References: <qUp1tOUkdsvzPGH03MyAhSokYQUUYm9xz-2X6GjsSC4=.21007ed7-65f7-4768-a2f8-e7d2ac2533f6@github.com>
Message-ID: <7B5igYqyeO29bJbDvlD-Kd5t8Y4Bfb6PMaBFW35JJU8=.57c38feb-a3ff-4f02-a8b2-0f295b8ef53e@github.com>

> 8261131: jcmd jmap dump should not accept gz option with no value

Lin Zang has updated the pull request incrementally with one additional commit since the last revision:

  remove useless code and update copyright

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2399/files
  - new: https://git.openjdk.java.net/jdk/pull/2399/files/cebc008c..620423ef

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

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

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

From stuefe at openjdk.java.net  Fri Feb  5 07:33:59 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 5 Feb 2021 07:33:59 GMT
Subject: RFR: JDK-8260926: Trace resource exhausted events unconditionally
 [v3]
In-Reply-To: <-LuicM5vRHrcchY00NJhTTgngnNKX3ZkbKZVM_pmHpE=.372c1b6a-120c-460d-a168-76f200408efd@github.com>
References: <-LuicM5vRHrcchY00NJhTTgngnNKX3ZkbKZVM_pmHpE=.372c1b6a-120c-460d-a168-76f200408efd@github.com>
Message-ID: <5Xj68CmxmlFgu8fPxmL9wfPFgLfGsuLxKSr1l8VhmW0=.9ad80a17-d485-443b-8e89-85e1ef7597e9@github.com>

> Analyzing out-of-resource situations in cloud scenarios is no fun. With CloudFoundry, a JVMTI agent (jvmkill) is hooked up intercepting the jvmti "resource exhausted" event, then attempts to write up a heap report. That may fail, e.g. due to bugs in the agent [1], but also because that report runs java code and may suffer from the same resource exhaustion. Successful or not, it unceremoniously kills the VM when done, often leaving us with no information about the actual resource.
> 
> It would be very helpful if we had unconditional tracing here. We do have tracing, but it requires a non-product build and is triggered with TraceJVMTI. Also, it traces at trace level which is way to fine granular.
> 
> I'd like to introduce another, unconditional trace line here. Arguably, resource exhausted is fatal enough that it justifies unconditional tracing.
> 
> This is a bit of a coin toss. Tracing unconditionally would help in most scenarios, where it would be either difficult or even impossible to specify a trace command line switch. OTOH it may trip up scripts parsing the VM output, or some of our tests (which can be fixed).
> 
> Thoughts?
> 
> ..Thomas
> 
> [1] https://github.com/cloudfoundry/jvmkill/issues/18

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

  Reformulate message

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2350/files
  - new: https://git.openjdk.java.net/jdk/pull/2350/files/40e3af87..b3d331ff

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

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

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

From stuefe at openjdk.java.net  Fri Feb  5 07:33:59 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 5 Feb 2021 07:33:59 GMT
Subject: RFR: JDK-8260926: Trace resource exhausted events unconditionally
 [v2]
In-Reply-To: <MhJsMStqxHs9IQE574u0h3HYlvke8BBLNs6bCYsiwN8=.ed57434b-3818-44cd-b9de-473088a90625@github.com>
References: <-LuicM5vRHrcchY00NJhTTgngnNKX3ZkbKZVM_pmHpE=.372c1b6a-120c-460d-a168-76f200408efd@github.com>
 <GMjFgCwRTZYyOEjLHhAmkpPS3bBPCCYQEqDEUk0HzQA=.fba195f4-c2b0-4773-9784-e0bdc12becc9@github.com>
 <MhJsMStqxHs9IQE574u0h3HYlvke8BBLNs6bCYsiwN8=.ed57434b-3818-44cd-b9de-473088a90625@github.com>
Message-ID: <DRSQE3Rt57pDXQlFUJ8j53WI2ePHc49ZWr46ezzRe7I=.a306bcc2-55c5-4c80-86a6-4ecdb3e92eb2@github.com>

On Thu, 4 Feb 2021 23:23:56 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I would have formatted the message differently as per my first comment. But ok.

Sorry, I misread part your original comment. I changed the message according to your suggestion.

Cheers, Thomas

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

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

From stuefe at openjdk.java.net  Fri Feb  5 07:34:00 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 5 Feb 2021 07:34:00 GMT
Subject: Integrated: JDK-8260926: Trace resource exhausted events
 unconditionally
In-Reply-To: <-LuicM5vRHrcchY00NJhTTgngnNKX3ZkbKZVM_pmHpE=.372c1b6a-120c-460d-a168-76f200408efd@github.com>
References: <-LuicM5vRHrcchY00NJhTTgngnNKX3ZkbKZVM_pmHpE=.372c1b6a-120c-460d-a168-76f200408efd@github.com>
Message-ID: <5S3aJ8TNsarqVNUIIoUhR2yoDXAK-Hiiu5x6-zmXNy8=.bcb50b06-4c91-4618-9fd7-7bc0807696ee@github.com>

On Tue, 2 Feb 2021 11:02:18 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Analyzing out-of-resource situations in cloud scenarios is no fun. With CloudFoundry, a JVMTI agent (jvmkill) is hooked up intercepting the jvmti "resource exhausted" event, then attempts to write up a heap report. That may fail, e.g. due to bugs in the agent [1], but also because that report runs java code and may suffer from the same resource exhaustion. Successful or not, it unceremoniously kills the VM when done, often leaving us with no information about the actual resource.
> 
> It would be very helpful if we had unconditional tracing here. We do have tracing, but it requires a non-product build and is triggered with TraceJVMTI. Also, it traces at trace level which is way to fine granular.
> 
> I'd like to introduce another, unconditional trace line here. Arguably, resource exhausted is fatal enough that it justifies unconditional tracing.
> 
> This is a bit of a coin toss. Tracing unconditionally would help in most scenarios, where it would be either difficult or even impossible to specify a trace command line switch. OTOH it may trip up scripts parsing the VM output, or some of our tests (which can be fixed).
> 
> Thoughts?
> 
> ..Thomas
> 
> [1] https://github.com/cloudfoundry/jvmkill/issues/18

This pull request has now been integrated.

Changeset: ee2f2055
Author:    Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ee2f2055
Stats:     3 lines in 1 file changed: 3 ins; 0 del; 0 mod

8260926: Trace resource exhausted events unconditionally

Reviewed-by: dholmes, coleenp

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

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

From roland at openjdk.java.net  Fri Feb  5 09:36:58 2021
From: roland at openjdk.java.net (Roland Westrelin)
Date: Fri, 5 Feb 2021 09:36:58 GMT
Subject: RFR: 8260296: SA's dumpreplaydata fails [v5]
In-Reply-To: <dbCVL_PF2kTQaXwi_ss4MX87d4wO2jPo-j7mn8Hrtao=.94bd9abc-2143-4306-ada0-0d7d09684ed2@github.com>
References: <dbCVL_PF2kTQaXwi_ss4MX87d4wO2jPo-j7mn8Hrtao=.94bd9abc-2143-4306-ada0-0d7d09684ed2@github.com>
Message-ID: <BiiS5KckTFlkD2zzj_j0PWQSWYFBABbvt4WrsnG77OQ=.09fa12dc-2349-4634-a3cf-591d924febb7@github.com>

> I noticed that the SA's dumpreplaydata command fails with:
> 
> java.lang.AssertionError: CLHSDB wasn't run successfully: Opening core file, please wait...
> hsdb> Exception in thread "main" java.lang.InternalError: ciMetadata does not appear to be polymorphic
> 
> with a simple test program. This happens because the SA can't find the
> vtable symbol for ciMetadata (build produced by gcc 9.2.1). AFAIU,
> there's nothing in our build system that hides that symbol. I had to
> move one method's definition from the header file to the cpp file for
> the symbol to be visible again.
> 
> We have a test that checks dumpreplaydata but it doesn't catch that
> problem. The test produces a replay file from a core file with the SA
> by running a simple test with -Xcomp and CICrash=1. So the replay data
> has very little or no profile data (which is what causes the problem
> above). I propose running a slightly more complicated test method and
> crashing after the method has had time to run for long enough to
> collect profile data.
> 
> The other shortcoming of the test is that it doesn't look at the
> content of the replay file. It only warns if they differ. The replay
> file produced by the VM and the one produced by the SA should be
> identical (except for comment lines). So I propose we check that.
> 
> Finally, I can't run that test on my system because core files are
> handled by systemd (I'm running some recent version of fedora). I
> suppose, the system can be configured differently but having the test
> work out the box is nice. I extended the test case to handle that.
> 
> With the improved test, there are a few differences between the VM and
> SA replay files caused by VM changes that were not mirrored in the
> SA. I fixed those.

Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision:

  copyrights

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2195/files
  - new: https://git.openjdk.java.net/jdk/pull/2195/files/da2fe2be..150ea54c

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

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

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

From roland at openjdk.java.net  Fri Feb  5 09:37:02 2021
From: roland at openjdk.java.net (Roland Westrelin)
Date: Fri, 5 Feb 2021 09:37:02 GMT
Subject: RFR: 8260296: SA's dumpreplaydata fails [v4]
In-Reply-To: <nAB2xwZQWJau49XlzYYOIVIGjInjsHD1beNGGfIghiA=.8eac5f66-1944-42a7-b15b-80cd7b279282@github.com>
References: <dbCVL_PF2kTQaXwi_ss4MX87d4wO2jPo-j7mn8Hrtao=.94bd9abc-2143-4306-ada0-0d7d09684ed2@github.com>
 <YodG6Yp77UtKIjzx5TB3jfDu-az1kN3-b_GyKG1deVI=.07ab2194-72ab-4d54-a8fa-b32ed50f2ed9@github.com>
 <nAB2xwZQWJau49XlzYYOIVIGjInjsHD1beNGGfIghiA=.8eac5f66-1944-42a7-b15b-80cd7b279282@github.com>
Message-ID: <pYD7U1pPmAebbSIa7IdCekEV8xNMzIsf-VBD39wQN_Q=.3158ff68-0244-476c-8bbf-31a3d9192d95@github.com>

On Thu, 4 Feb 2021 18:25:45 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Roland Westrelin 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:
>> 
>>  - pid in OutputAnalyzer
>>  - pid in OutputAnalyzer
>>  - Merge branch 'master' into JDK-8260296
>>  - convert all tests
>>  - Merge branch 'master' into JDK-8260296
>>  - use CoreUtils
>>  - whitespaces
>>  - SA fixes
>>  - VM fix
>>  - test
>
> LGTM, you still need to update the copyright years as @plummercj [mentioned](https://github.com/openjdk/jdk/pull/2195#issuecomment-768115732).

@iignatev thanks for the review. I updated the copyrights.

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

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

From roland at openjdk.java.net  Fri Feb  5 09:37:03 2021
From: roland at openjdk.java.net (Roland Westrelin)
Date: Fri, 5 Feb 2021 09:37:03 GMT
Subject: Integrated: 8260296: SA's dumpreplaydata fails
In-Reply-To: <dbCVL_PF2kTQaXwi_ss4MX87d4wO2jPo-j7mn8Hrtao=.94bd9abc-2143-4306-ada0-0d7d09684ed2@github.com>
References: <dbCVL_PF2kTQaXwi_ss4MX87d4wO2jPo-j7mn8Hrtao=.94bd9abc-2143-4306-ada0-0d7d09684ed2@github.com>
Message-ID: <cz2TXinyn_GsLSonWLj_FAaSMjBPMppj3va6h8kCdxU=.5f3061a5-52d3-45f3-93d3-ab0cc126307d@github.com>

On Fri, 22 Jan 2021 14:21:52 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> I noticed that the SA's dumpreplaydata command fails with:
> 
> java.lang.AssertionError: CLHSDB wasn't run successfully: Opening core file, please wait...
> hsdb> Exception in thread "main" java.lang.InternalError: ciMetadata does not appear to be polymorphic
> 
> with a simple test program. This happens because the SA can't find the
> vtable symbol for ciMetadata (build produced by gcc 9.2.1). AFAIU,
> there's nothing in our build system that hides that symbol. I had to
> move one method's definition from the header file to the cpp file for
> the symbol to be visible again.
> 
> We have a test that checks dumpreplaydata but it doesn't catch that
> problem. The test produces a replay file from a core file with the SA
> by running a simple test with -Xcomp and CICrash=1. So the replay data
> has very little or no profile data (which is what causes the problem
> above). I propose running a slightly more complicated test method and
> crashing after the method has had time to run for long enough to
> collect profile data.
> 
> The other shortcoming of the test is that it doesn't look at the
> content of the replay file. It only warns if they differ. The replay
> file produced by the VM and the one produced by the SA should be
> identical (except for comment lines). So I propose we check that.
> 
> Finally, I can't run that test on my system because core files are
> handled by systemd (I'm running some recent version of fedora). I
> suppose, the system can be configured differently but having the test
> work out the box is nice. I extended the test case to handle that.
> 
> With the improved test, there are a few differences between the VM and
> SA replay files caused by VM changes that were not mirrored in the
> SA. I fixed those.

This pull request has now been integrated.

Changeset: 3495febf
Author:    Roland Westrelin <roland at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/3495febf
Stats:     228 lines in 20 files changed: 109 ins; 55 del; 64 mod

8260296: SA's dumpreplaydata fails

Reviewed-by: kvn, cjplummer, iignatyev

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

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

From ihse at openjdk.java.net  Fri Feb  5 09:51:54 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 5 Feb 2021 09:51:54 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: <Xm2zaLzFtkwU47kbxleP3EGyAS5q4imHh5TrbLuVskU=.a409a2b2-0841-4f48-8bed-e0ede1830a94@github.com>

On Tue, 2 Feb 2021 21:20:52 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
>
> make/autoconf/flags.m4 line 140:
> 
>> 138:     else
>> 139:       MACOSX_VERSION_MIN=10.12.0
>> 140:     fi
> 
> Not something that needs to be addressed here, but these changes
> illustrate that our collective use of macOSX/MACOSX/MacOSX names
> are tied to the fact that the macOS major version number was at 10
> for a very long time.
> 
> @magicus - Do we have an RFE to rename MACOSX or are we sticking
> with it and evolving our interpretation of the 'X' from '10' to */splat/asterik?

@dcubed-ojdk There is no RFE to renaming "macosx" to "macos". I'm not sure it should be done. We can't follow all marketing trends (Apple recently renamed iOS to iPadOS for the iPad; we can't keep adapting to such schemes). Personally, I like the new name without the "x", but we had already spent some time trying to find and fix all (or at least, most) instances of "osx" in the code, that I don't really think it's worth the effort. 

If you can drill up enough enthusiasm for such a project, and get any objections down to minimum, I can help implementing it. But I won't be spearheading it.

> make/common/NativeCompilation.gmk line 1178:
> 
>> 1176:                 endif
>> 1177:                 # This only works if the openjdk_codesign identity is present on the system. Let
>> 1178:                 # silently fail otherwise.
> 
> Might want to add a comment here:
>     #  The '-f' option will replace an existing signature if one exists.

We're not really in the habit of adding comments for various command line options. Normally, you can check these with "man" if you are uncertain. If they do something surprising, sure, but here it's more of a "it's needed on aarch64 to work at all", so I don't think a comment will be anything but added clutter.

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

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

From aph at openjdk.java.net  Fri Feb  5 09:51:52 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Fri, 5 Feb 2021 09:51:52 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v10]
In-Reply-To: <RsX4BRh-N8Gch2KVeObHHtsMgc9TTLdeiZJSY5QuTYY=.3af04858-7c03-4eec-be0f-b6f2a31c15cf@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <QZ7stXQpgmcHxvq5cmr2FB_R8lyy2xGDNK8m1cawvWk=.f436fe10-400b-4a6c-a41c-ebdb170a3248@github.com>
 <RsX4BRh-N8Gch2KVeObHHtsMgc9TTLdeiZJSY5QuTYY=.3af04858-7c03-4eec-be0f-b6f2a31c15cf@github.com>
Message-ID: <F3BaIgr1GNRSJNyRI1wShm8LiI7CeMcSr5phlwknB-Q=.8a5143cb-f33b-451f-a717-6de17246d98a@github.com>

On Thu, 4 Feb 2021 23:05:56 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
>
> I reviewed bsd_aarch64.cpp digging bit deeper and left some comments.

> > Umm, so how does patching work? We don't even know if other threads are executing the code we need to patch.
> 
> I thought java can handle that scenario in usual (non W^X systems) just fine, so we just believe jvm did everything right and it's safe to rewrite some code at specific moment.

Got it, OK.

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

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

From ihse at openjdk.java.net  Fri Feb  5 10:00:50 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 5 Feb 2021 10:00:50 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v10]
In-Reply-To: <QZ7stXQpgmcHxvq5cmr2FB_R8lyy2xGDNK8m1cawvWk=.f436fe10-400b-4a6c-a41c-ebdb170a3248@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <QZ7stXQpgmcHxvq5cmr2FB_R8lyy2xGDNK8m1cawvWk=.f436fe10-400b-4a6c-a41c-ebdb170a3248@github.com>
Message-ID: <hBhQnU1mrrMvbfQ0qbCucgTCNJV8X6ss1WF3WCbFx4U=.46407a1b-6bd6-416f-b18a-0bff83b99f99@github.com>

On Wed, 3 Feb 2021 20:01:15 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 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

Marked as reviewed by ihse (Reviewer).

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

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

From ihse at openjdk.java.net  Fri Feb  5 10:00:50 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 5 Feb 2021 10:00:50 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v10]
In-Reply-To: <F3BaIgr1GNRSJNyRI1wShm8LiI7CeMcSr5phlwknB-Q=.8a5143cb-f33b-451f-a717-6de17246d98a@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <QZ7stXQpgmcHxvq5cmr2FB_R8lyy2xGDNK8m1cawvWk=.f436fe10-400b-4a6c-a41c-ebdb170a3248@github.com>
 <RsX4BRh-N8Gch2KVeObHHtsMgc9TTLdeiZJSY5QuTYY=.3af04858-7c03-4eec-be0f-b6f2a31c15cf@github.com>
 <F3BaIgr1GNRSJNyRI1wShm8LiI7CeMcSr5phlwknB-Q=.8a5143cb-f33b-451f-a717-6de17246d98a@github.com>
Message-ID: <CW65x4qh-3xrIDqTzLqtf4xXDuDwNB2uzZhPfApuL5Q=.1aad1483-a7a8-4c34-ba4c-48740d3fb4b1@github.com>

On Fri, 5 Feb 2021 09:49:11 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> I reviewed bsd_aarch64.cpp digging bit deeper and left some comments.
>
>> > Umm, so how does patching work? We don't even know if other threads are executing the code we need to patch.
>> 
>> I thought java can handle that scenario in usual (non W^X systems) just fine, so we just believe jvm did everything right and it's safe to rewrite some code at specific moment.
> 
> Got it, OK.

> This doesn't seem to be an issue anymore, After P.Race have finished with JDK-8257852, Macarm port can be build without extra ld flags.

@VladimirKempik I agree. That concludes the build issues with this PR. So from a build perspective, this is now good to go.

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

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

From sspitsyn at openjdk.java.net  Fri Feb  5 10:05:46 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Fri, 5 Feb 2021 10:05:46 GMT
Subject: RFR: 8257234 : Add gz option to SA jmap to write a gzipped heap
 dump [v14]
In-Reply-To: <eXFuaiLypqbGOiQMANkJ39sR1aTMSxtAlwG9XD4KuFk=.0efbc8de-50d4-4ed4-9566-074213c23b5f@github.com>
References: <oTMRc7LWvx9_Uov01HPX9UgyEqFmXt_nMG920HUQBIM=.3651754b-e1f1-46f8-9f44-c118a5c56dbe@github.com>
 <hshEN06sqJcgNmcW4Yb75mtnYFVMiqX3lfmekNjzApU=.183255d4-56da-48ac-8a81-7a81b5900253@github.com>
 <d2qneSjNn2StFBGSsQy45NNz8SI7WTogYPq8WR9pIlQ=.7d78b062-3606-4d29-9b18-81dfe9f38df9@github.com>
 <3AOVqSv3mzE-QVGg7NWJ8vs4pKBoHTgeHZjf1FHA9XA=.d0ab8c18-6d62-43c6-8232-4b1621ebc609@github.com>
 <eXFuaiLypqbGOiQMANkJ39sR1aTMSxtAlwG9XD4KuFk=.0efbc8de-50d4-4ed4-9566-074213c23b5f@github.com>
Message-ID: <2VseKBjYyTAB2qKbTaqBDizxxyeOFrktBzShuPclgK4=.f98b7a55-71cb-480d-a703-2f2afc2ffc79@github.com>

On Thu, 4 Feb 2021 23:23:41 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Thanks for the thorough list, I have tested most of them but not all. I will cover them and update here later.
>> 
>>> So really there are two implementations of heap dumping, one in the VM and one in SA, but a total of 5 ways to get to them. I'm just starting to get my head wrapped around all this myself. We've created a very confusing situation for us, and unfortunately I think some of the changes that got us here was driven by a goal to simply things.
>> 
>> Yes, it makes me even curious about why there can be two different implementation of them (one by C++ and one by Java),  it seems we need double the work of adding new options for those tools, like parallal for jmap histo and dump, etc.
>
> One implementation is in the JVM itself, to be used when the JVM is still running well, and not just from command line tools. Heap dumping can also be triggered by the JVM itslef by setting flags like -XX:+HeapDumpBeforeFullGC. The other implementation is in SA, to be used on a core file or a hung JVM process, although it can also be used on a JVM that is still running well. BTW, there used to be a 3rd implementation. The old hprof profiler (a JVMTI agent) also was used to generate hprof files.

Hi Lin,

A week ago you replied that you are accepting the following suggested refactoring:

                   /*
                    * Possible commands:
                    *     dumpheap gz=1 file
                    *     dumpheap gz=1
                    *     dumpheap file
                    *     dumpheap
                    *
                    * Use default filename if cntTokens == 0.
                    * Handle cases with cntTokens == 1 or 2.
                    */

                    if (cntTokens > 2) {
                        err.println("Too big number of options: " + cntTokens);
                        usage();
                        return;
                    }
                    if (cntTokens >= 1) { // parse first argument which is "gz=" option
                        String option  = t.nextToken();
                        gzlevel = parseHeapDumpCompressionLevel(option);
                        if (gzlevel == 0) {
                            usage();
                            return;
                        }
                        filename = "heap.bin.gz";
                    }
                    if (cntTokens == 2) { // parse second argument which is filename
                        filename = t.nextToken();
                        if (filename.startsWith("gz=")) {
                            err.println("Filename should not start with "gz=": " + filename);
                            usage();
                            return;
                        }
                    }

But I still do not see it in the latest updates from you. It feels like there is some misunderstanding and confusion.
Could you, please, clear this up?

Thanks,
Serguei

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

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

From sspitsyn at openjdk.java.net  Fri Feb  5 10:39:45 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Fri, 5 Feb 2021 10:39:45 GMT
Subject: RFR: 8257234 : Add gz option to SA jmap to write a gzipped heap
 dump [v14]
In-Reply-To: <2VseKBjYyTAB2qKbTaqBDizxxyeOFrktBzShuPclgK4=.f98b7a55-71cb-480d-a703-2f2afc2ffc79@github.com>
References: <oTMRc7LWvx9_Uov01HPX9UgyEqFmXt_nMG920HUQBIM=.3651754b-e1f1-46f8-9f44-c118a5c56dbe@github.com>
 <hshEN06sqJcgNmcW4Yb75mtnYFVMiqX3lfmekNjzApU=.183255d4-56da-48ac-8a81-7a81b5900253@github.com>
 <d2qneSjNn2StFBGSsQy45NNz8SI7WTogYPq8WR9pIlQ=.7d78b062-3606-4d29-9b18-81dfe9f38df9@github.com>
 <3AOVqSv3mzE-QVGg7NWJ8vs4pKBoHTgeHZjf1FHA9XA=.d0ab8c18-6d62-43c6-8232-4b1621ebc609@github.com>
 <eXFuaiLypqbGOiQMANkJ39sR1aTMSxtAlwG9XD4KuFk=.0efbc8de-50d4-4ed4-9566-074213c23b5f@github.com>
 <2VseKBjYyTAB2qKbTaqBDizxxyeOFrktBzShuPclgK4=.f98b7a55-71cb-480d-a703-2f2afc2ffc79@github.com>
Message-ID: <nhA2NqfFwf1dJpUYZBH3X6O2C0NZ5Nqm-gSj7yR8wps=.2a8edb83-939b-4c06-9508-7b1241caa4c8@github.com>

On Fri, 5 Feb 2021 10:03:09 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> One implementation is in the JVM itself, to be used when the JVM is still running well, and not just from command line tools. Heap dumping can also be triggered by the JVM itslef by setting flags like -XX:+HeapDumpBeforeFullGC. The other implementation is in SA, to be used on a core file or a hung JVM process, although it can also be used on a JVM that is still running well. BTW, there used to be a 3rd implementation. The old hprof profiler (a JVMTI agent) also was used to generate hprof files.
>
> Hi Lin,
> 
> A week ago you replied that you are accepting the following suggested refactoring:
> 
>                    /*
>                     * Possible commands:
>                     *     dumpheap gz=1 file
>                     *     dumpheap gz=1
>                     *     dumpheap file
>                     *     dumpheap
>                     *
>                     * Use default filename if cntTokens == 0.
>                     * Handle cases with cntTokens == 1 or 2.
>                     */
> 
>                     if (cntTokens > 2) {
>                         err.println("Too big number of options: " + cntTokens);
>                         usage();
>                         return;
>                     }
>                     if (cntTokens >= 1) { // parse first argument which is "gz=" option
>                         String option  = t.nextToken();
>                         gzlevel = parseHeapDumpCompressionLevel(option);
>                         if (gzlevel == 0) {
>                             usage();
>                             return;
>                         }
>                         filename = "heap.bin.gz";
>                     }
>                     if (cntTokens == 2) { // parse second argument which is filename
>                         filename = t.nextToken();
>                         if (filename.startsWith("gz=")) {
>                             err.println("Filename should not start with "gz=": " + filename);
>                             usage();
>                             return;
>                         }
>                     }
> 
> But I still do not see it in the latest updates from you. It feels like there is some misunderstanding and confusion.
> Could you, please, clear this up?
> 
> Thanks,
> Serguei

Also, this method can be refactored to something like this (the check for exactly one option argument is needed):
   private int parseHeapDumpCompressionLevel(String option) {
       int gzl = 0;
       String[] keyValue = option.split("=");
       assert keyValue[0].equals("gz") : "expected option to start from gz=";
       if (keyValue.length != 2) {
           err.println("Exactly one argument is expected for option "gz"");
           return 0;
       }
       String level = keyValue[1];
       try {
           gzl = Integer.parseInt(level);
       } catch (NumberFormatException e) {
           err.println("gz option value not an integer ("+level+")");
           return 0;
       }
       if (gzl < 1 || gzl > 9) {
           err.println("Compression level out of range (1-9): " + level);
           return 0;
       }
       return gzl;
   }

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

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

From akozlov at openjdk.java.net  Fri Feb  5 12:29:50 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Fri, 5 Feb 2021 12:29:50 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v10]
In-Reply-To: <hBhQnU1mrrMvbfQ0qbCucgTCNJV8X6ss1WF3WCbFx4U=.46407a1b-6bd6-416f-b18a-0bff83b99f99@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <QZ7stXQpgmcHxvq5cmr2FB_R8lyy2xGDNK8m1cawvWk=.f436fe10-400b-4a6c-a41c-ebdb170a3248@github.com>
 <hBhQnU1mrrMvbfQ0qbCucgTCNJV8X6ss1WF3WCbFx4U=.46407a1b-6bd6-416f-b18a-0bff83b99f99@github.com>
Message-ID: <gTyCOrnDSvk7XA-D7_1FqekY2Q3jURGoH0-Tld9wpRo=.86e5b809-06be-411e-9de3-fabb65933aad@github.com>

On Fri, 5 Feb 2021 09:57:54 GMT, Magnus Ihse Bursie <ihse 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
>
> Marked as reviewed by ihse (Reviewer).

> I haven't got a MacOS AArch64 system right now. Is it possible to
> enable W^X in Linux in order to kick the tyres?

I've just got rid of asserts that fired on Linux sometime :) As for W^X like on macOS, I vaguely remember working with a Linux system with one-way transition W->X, probably provided by SELinux. But I don't think it allowed per-thread W^X state.

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

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

From akozlov at openjdk.java.net  Fri Feb  5 13:01:05 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Fri, 5 Feb 2021 13:01:05 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v11]
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: <U5N77U540HaEtllquzyTnN-oseH71eEHzJMxtz4Sjt0=.87c1091a-627d-409c-9b7e-7bcd16fdf2fc@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:

  Cleanup SA changes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2200/files
  - new: https://git.openjdk.java.net/jdk/pull/2200/files/80827176..8652d21d

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

  Stats: 11 lines in 1 file changed: 3 ins; 8 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  Fri Feb  5 13:01:06 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Fri, 5 Feb 2021 13:01:06 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3]
In-Reply-To: <rdKaZHN6LY1Q-gyUsnoyyVo1v_aNHC2FA9o2fnHV7p4=.22083b03-2e46-4ebf-80d0-08ca351a26d7@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <jfepsNqfNE9TSizS98ltKa_H47jkQiDJlgfLZdF01mk=.064ad260-417b-495b-bc28-4017d570a4dc@github.com>
 <rdKaZHN6LY1Q-gyUsnoyyVo1v_aNHC2FA9o2fnHV7p4=.22083b03-2e46-4ebf-80d0-08ca351a26d7@github.com>
Message-ID: <fjYF-3GanxJMPbovsYdf7O7JVEpDUoN4HaDYl5Eb3o0=.e9613648-2fb8-446d-a217-0b4b7cc101d8@github.com>

On Mon, 25 Jan 2021 22:48:50 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Refactor CDS disabling
>>  - Redo builsys support for aarch64-darwin
>
> src/jdk.hotspot.agent/macosx/native/libsaproc/MacosxDebuggerLocal.m line 702:
> 
>> 700:   primitiveArray = (*env)->GetLongArrayElements(env, registerArray, NULL);
>> 701: 
>> 702: #undef REG_INDEX
> 
> I'm not so sure why the #undef and subsequent #define of REG_INDEX is needed since it seems to just get #define'd back to the same value.

We've merged two implementations of SA, this change slipped in. I've cleaned this up. Thanks for noticing!

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

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

From hseigel at openjdk.java.net  Fri Feb  5 14:53:53 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Fri, 5 Feb 2021 14:53:53 GMT
Subject: RFR: 8261161: Clean up warnings in hotspot/jtreg/vmTestbase tests
Message-ID: <G2NyGRcvSDtF9Il0jYkZSNrkigmfFeschsStnaD42L4=.e5dc8ca5-d49b-4799-a6c9-5aa35e0ca7fd@github.com>

Please review this change to clean up warnings, such as the following, in the vmTestbase tests.  

warning: [synchronization] attempt to synchronize on an instance of a value-based class 
warning: [removal] Integer(int) in Integer has been deprecated and marked for removal

This change cleans up the warnings by using a non-value based class to synchronize on, and replacing calls such as Integer(int) with Integer.valueOf(int).

The change was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-8 on Linux x64.

Thanks, Harold

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

Commit messages:
 - 8261161: Clean up warnings in hotspot/jtreg/vmTestbase tests

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

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

From lzang at openjdk.java.net  Fri Feb  5 15:04:46 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Fri, 5 Feb 2021 15:04:46 GMT
Subject: RFR: 8257234 : Add gz option to SA jmap to write a gzipped heap
 dump [v14]
In-Reply-To: <nhA2NqfFwf1dJpUYZBH3X6O2C0NZ5Nqm-gSj7yR8wps=.2a8edb83-939b-4c06-9508-7b1241caa4c8@github.com>
References: <oTMRc7LWvx9_Uov01HPX9UgyEqFmXt_nMG920HUQBIM=.3651754b-e1f1-46f8-9f44-c118a5c56dbe@github.com>
 <hshEN06sqJcgNmcW4Yb75mtnYFVMiqX3lfmekNjzApU=.183255d4-56da-48ac-8a81-7a81b5900253@github.com>
 <d2qneSjNn2StFBGSsQy45NNz8SI7WTogYPq8WR9pIlQ=.7d78b062-3606-4d29-9b18-81dfe9f38df9@github.com>
 <3AOVqSv3mzE-QVGg7NWJ8vs4pKBoHTgeHZjf1FHA9XA=.d0ab8c18-6d62-43c6-8232-4b1621ebc609@github.com>
 <eXFuaiLypqbGOiQMANkJ39sR1aTMSxtAlwG9XD4KuFk=.0efbc8de-50d4-4ed4-9566-074213c23b5f@github.com>
 <2VseKBjYyTAB2qKbTaqBDizxxyeOFrktBzShuPclgK4=.f98b7a55-71cb-480d-a703-2f2afc2ffc79@github.com>
 <nhA2NqfFwf1dJpUYZBH3X6O2C0NZ5Nqm-gSj7yR8wps=.2a8edb83-939b-4c06-9508-7b1241caa4c8@github.com>
Message-ID: <JiIQKupFg9-Jz0IYUuK122mgG7k2Mz2d7LTtvMZRG7g=.bcb8be25-0a09-42b0-a700-40ffb4d7b6be@github.com>

On Fri, 5 Feb 2021 10:36:25 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Hi Lin,
>> 
>> A week ago you replied that you are accepting the following suggested refactoring:
>> 
>>                    /*
>>                     * Possible commands:
>>                     *     dumpheap gz=1 file
>>                     *     dumpheap gz=1
>>                     *     dumpheap file
>>                     *     dumpheap
>>                     *
>>                     * Use default filename if cntTokens == 0.
>>                     * Handle cases with cntTokens == 1 or 2.
>>                     */
>> 
>>                     if (cntTokens > 2) {
>>                         err.println("Too big number of options: " + cntTokens);
>>                         usage();
>>                         return;
>>                     }
>>                     if (cntTokens >= 1) { // parse first argument which is "gz=" option
>>                         String option  = t.nextToken();
>>                         gzlevel = parseHeapDumpCompressionLevel(option);
>>                         if (gzlevel == 0) {
>>                             usage();
>>                             return;
>>                         }
>>                         filename = "heap.bin.gz";
>>                     }
>>                     if (cntTokens == 2) { // parse second argument which is filename
>>                         filename = t.nextToken();
>>                         if (filename.startsWith("gz=")) {
>>                             err.println("Filename should not start with "gz=": " + filename);
>>                             usage();
>>                             return;
>>                         }
>>                     }
>> 
>> But I still do not see it in the latest updates from you. It feels like there is some misunderstanding and confusion.
>> Could you, please, clear this up?
>> 
>> Thanks,
>> Serguei
>
> Also, this method can be refactored to something like this (the check for exactly one option argument is needed):
>    private int parseHeapDumpCompressionLevel(String option) {
>        String[] keyValue = option.split("=");
>        if (!keyValue[0].equals("gz")) {
>            err.println("Expected option is "gz="");
>            return 0;
>       }
>        if (keyValue.length != 2) {
>            err.println("Exactly one argument is expected for option "gz"");
>            return 0;
>        }
>        int gzl = 0;
>        String level = keyValue[1];
>        try {
>            gzl = Integer.parseInt(level);
>        } catch (NumberFormatException e) {
>            err.println("gz option value not an integer ("+level+")");
>            return 0;
>        }
>        if (gzl < 1 || gzl > 9) {
>            err.println("Compression level out of range (1-9): " + level);
>            return 0;
>        }
>        return gzl;
>    }

Hi Serguei,

> But I still do not see it in the latest updates from you. It feels like there is some misunderstanding and confusion.

Thanks a lot for remainder! Sorry that I forgot to submit the change.

> Also, this method can be refactored to something like this (the check for exactly one option argument is needed):

The change looks nice, I will made the change and submit it in a minute.

BRs,
Lin

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

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

From daniel.daugherty at oracle.com  Fri Feb  5 15:05:25 2021
From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com)
Date: Fri, 5 Feb 2021 10:05:25 -0500
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
In-Reply-To: <Xm2zaLzFtkwU47kbxleP3EGyAS5q4imHh5TrbLuVskU=.a409a2b2-0841-4f48-8bed-e0ede1830a94@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>
 <Xm2zaLzFtkwU47kbxleP3EGyAS5q4imHh5TrbLuVskU=.a409a2b2-0841-4f48-8bed-e0ede1830a94@github.com>
Message-ID: <18c74331-6056-405f-1207-e62787f34830@oracle.com>

On 2/5/21 4:51 AM, Magnus Ihse Bursie wrote:
> On Tue, 2 Feb 2021 21:20:52 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
>> make/autoconf/flags.m4 line 140:
>>
>>> 138:     else
>>> 139:       MACOSX_VERSION_MIN=10.12.0
>>> 140:     fi
>> Not something that needs to be addressed here, but these changes
>> illustrate that our collective use of macOSX/MACOSX/MacOSX names
>> are tied to the fact that the macOS major version number was at 10
>> for a very long time.
>>
>> @magicus - Do we have an RFE to rename MACOSX or are we sticking
>> with it and evolving our interpretation of the 'X' from '10' to */splat/asterik?
> @dcubed-ojdk There is no RFE to renaming "macosx" to "macos". I'm not sure it should be done. We can't follow all marketing trends (Apple recently renamed iOS to iPadOS for the iPad; we can't keep adapting to such schemes). Personally, I like the new name without the "x", but we had already spent some time trying to find and fix all (or at least, most) instances of "osx" in the code, that I don't really think it's worth the effort.
>
> If you can drill up enough enthusiasm for such a project, and get any objections down to minimum, I can help implementing it. But I won't be spearheading it.
>
>> make/common/NativeCompilation.gmk line 1178:
>>
>>> 1176:                 endif
>>> 1177:                 # This only works if the openjdk_codesign identity is present on the system. Let
>>> 1178:                 # silently fail otherwise.
>> Might want to add a comment here:
>>      #  The '-f' option will replace an existing signature if one exists.
> We're not really in the habit of adding comments for various command line options. Normally, you can check these with "man" if you are uncertain. If they do something surprising, sure, but here it's more of a "it's needed on aarch64 to work at all", so I don't think a comment will be anything but added clutter.
>
> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/2200

@magicus - I'm good with both of these answers. I personally like 'macosx'.

Dan

From lzang at openjdk.java.net  Fri Feb  5 15:28:44 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Fri, 5 Feb 2021 15:28:44 GMT
Subject: RFR: 8257234 : Add gz option to SA jmap to write a gzipped heap
 dump [v14]
In-Reply-To: <JiIQKupFg9-Jz0IYUuK122mgG7k2Mz2d7LTtvMZRG7g=.bcb8be25-0a09-42b0-a700-40ffb4d7b6be@github.com>
References: <oTMRc7LWvx9_Uov01HPX9UgyEqFmXt_nMG920HUQBIM=.3651754b-e1f1-46f8-9f44-c118a5c56dbe@github.com>
 <hshEN06sqJcgNmcW4Yb75mtnYFVMiqX3lfmekNjzApU=.183255d4-56da-48ac-8a81-7a81b5900253@github.com>
 <d2qneSjNn2StFBGSsQy45NNz8SI7WTogYPq8WR9pIlQ=.7d78b062-3606-4d29-9b18-81dfe9f38df9@github.com>
 <3AOVqSv3mzE-QVGg7NWJ8vs4pKBoHTgeHZjf1FHA9XA=.d0ab8c18-6d62-43c6-8232-4b1621ebc609@github.com>
 <eXFuaiLypqbGOiQMANkJ39sR1aTMSxtAlwG9XD4KuFk=.0efbc8de-50d4-4ed4-9566-074213c23b5f@github.com>
 <2VseKBjYyTAB2qKbTaqBDizxxyeOFrktBzShuPclgK4=.f98b7a55-71cb-480d-a703-2f2afc2ffc79@github.com>
 <nhA2NqfFwf1dJpUYZBH3X6O2C0NZ5Nqm-gSj7yR8wps=.2a8edb83-939b-4c06-9508-7b1241caa4c8@github.com>
 <JiIQKupFg9-Jz0IYUuK122mgG7k2Mz2d7LTtvMZRG7g=.bcb8be25-0a09-42b0-a700-40ffb4d7b6be@github.com>
Message-ID: <FzIQSB0Rq8BtjJdi1DvY2xC_xqqfeDxH9So3BSNPFT8=.d74a52c9-524e-4d04-a86c-df97c5b0be84@github.com>

On Fri, 5 Feb 2021 15:01:26 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> Also, this method can be refactored to something like this (the check for exactly one option argument is needed):
>>    private int parseHeapDumpCompressionLevel(String option) {
>>        String[] keyValue = option.split("=");
>>        if (!keyValue[0].equals("gz")) {
>>            err.println("Expected option is "gz="");
>>            return 0;
>>       }
>>        if (keyValue.length != 2) {
>>            err.println("Exactly one argument is expected for option "gz"");
>>            return 0;
>>        }
>>        int gzl = 0;
>>        String level = keyValue[1];
>>        try {
>>            gzl = Integer.parseInt(level);
>>        } catch (NumberFormatException e) {
>>            err.println("gz option value not an integer ("+level+")");
>>            return 0;
>>        }
>>        if (gzl < 1 || gzl > 9) {
>>            err.println("Compression level out of range (1-9): " + level);
>>            return 0;
>>        }
>>        return gzl;
>>    }
>
> Hi Serguei,
> 
>> But I still do not see it in the latest updates from you. It feels like there is some misunderstanding and confusion.
> 
> Thanks a lot for remainder! Sorry that I forgot to submit the change.
> 
>> Also, this method can be refactored to something like this (the check for exactly one option argument is needed):
> 
> The change looks nice, I will made the change and submit it in a minute.
> 
> BRs,
> Lin

Hi Chris, 

> It's confusing because both `jhsdb jmap` and the clhsdb `dumpheap` command use the JMap class, but neither support passing `format=x` to it. In order to get SA to dump with `format=x`, you would need to launch `sun/jvm/hotspot/tools/JMap` directly and pass in `-heap:format=x`. I'm not suggesting you fix that, but just something for us to be aware of.

I think new PR can be created for adding `format=x` to `clhsdb dumpheap` and  `jhsdb jmap`. And maybe new CSR is required?

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

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

From lzang at openjdk.java.net  Fri Feb  5 15:36:00 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Fri, 5 Feb 2021 15:36:00 GMT
Subject: RFR: 8257234 : Add gz option to SA jmap to write a gzipped heap
 dump [v15]
In-Reply-To: <oTMRc7LWvx9_Uov01HPX9UgyEqFmXt_nMG920HUQBIM=.3651754b-e1f1-46f8-9f44-c118a5c56dbe@github.com>
References: <oTMRc7LWvx9_Uov01HPX9UgyEqFmXt_nMG920HUQBIM=.3651754b-e1f1-46f8-9f44-c118a5c56dbe@github.com>
Message-ID: <hM3DCh9yCmFFN9_mr3ChsAleoQ-bK25vEoCTH6G0d9U=.77d54919-42bd-4744-a281-b3e4a9b5e474@github.com>

> 8257234 : Add gz option to SA jmap to write a gzipped heap dump

Lin Zang has updated the pull request incrementally with one additional commit since the last revision:

  refine help message and also refactor the logic in CommandProcessor

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1712/files
  - new: https://git.openjdk.java.net/jdk/pull/1712/files/0d30aaf3..0aa703d3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1712&range=14
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1712&range=13-14

  Stats: 55 lines in 3 files changed: 10 ins; 16 del; 29 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1712.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1712/head:pull/1712

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

From gziemski at openjdk.java.net  Fri Feb  5 15:47:52 2021
From: gziemski at openjdk.java.net (Gerard Ziemski)
Date: Fri, 5 Feb 2021 15:47:52 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v10]
In-Reply-To: <gTyCOrnDSvk7XA-D7_1FqekY2Q3jURGoH0-Tld9wpRo=.86e5b809-06be-411e-9de3-fabb65933aad@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <QZ7stXQpgmcHxvq5cmr2FB_R8lyy2xGDNK8m1cawvWk=.f436fe10-400b-4a6c-a41c-ebdb170a3248@github.com>
 <hBhQnU1mrrMvbfQ0qbCucgTCNJV8X6ss1WF3WCbFx4U=.46407a1b-6bd6-416f-b18a-0bff83b99f99@github.com>
 <gTyCOrnDSvk7XA-D7_1FqekY2Q3jURGoH0-Tld9wpRo=.86e5b809-06be-411e-9de3-fabb65933aad@github.com>
Message-ID: <1WBui88c5lauE5a6N6u6iqV93EDULATd6jx-VTi7ctY=.4fc4b9e2-1e6d-4ff4-9693-27cdbb06e7ef@github.com>

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

>> Marked as reviewed by ihse (Reviewer).
>
>> I haven't got a MacOS AArch64 system right now. Is it possible to
>> enable W^X in Linux in order to kick the tyres?
> 
> I've just got rid of asserts that fired on Linux sometime :) As for W^X like on macOS, I vaguely remember working with a Linux system with one-way transition W->X, probably provided by SELinux. But I don't think it allowed per-thread W^X state.

> _Mailing list message from [daniel.daugherty at oracle.com](mailto:daniel.daugherty at oracle.com) on [security-dev](mailto:security-dev at openjdk.java.net):_
> 
> On 2/5/21 4:51 AM, Magnus Ihse Bursie wrote:
> 
> @magicus - I'm good with both of these answers. I personally like 'macosx'.
> 
> Dan

It's no longer `macosx`, it's just `macos` now - see https://en.wikipedia.org/wiki/MacOS

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

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

From lfoltan at openjdk.java.net  Fri Feb  5 15:49:41 2021
From: lfoltan at openjdk.java.net (Lois Foltan)
Date: Fri, 5 Feb 2021 15:49:41 GMT
Subject: RFR: 8261161: Clean up warnings in hotspot/jtreg/vmTestbase tests
In-Reply-To: <G2NyGRcvSDtF9Il0jYkZSNrkigmfFeschsStnaD42L4=.e5dc8ca5-d49b-4799-a6c9-5aa35e0ca7fd@github.com>
References: <G2NyGRcvSDtF9Il0jYkZSNrkigmfFeschsStnaD42L4=.e5dc8ca5-d49b-4799-a6c9-5aa35e0ca7fd@github.com>
Message-ID: <FBRIqJQSqQsB1VTWlQBjJ3HbqWeMsJd77lWgOKaQXyc=.5851bb79-32ed-49ac-b551-53f1ed8eb0d6@github.com>

On Fri, 5 Feb 2021 14:48:25 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this change to clean up warnings, such as the following, in the vmTestbase tests.  
> 
> warning: [synchronization] attempt to synchronize on an instance of a value-based class 
> warning: [removal] Integer(int) in Integer has been deprecated and marked for removal
> 
> This change cleans up the warnings by using a non-value based class to synchronize on, and replacing calls such as Integer(int) with Integer.valueOf(int).
> 
> The change was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-8 on Linux x64.
> 
> Thanks, Harold

Looks good.
Lois

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

Marked as reviewed by lfoltan (Reviewer).

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

From akozlov at openjdk.java.net  Fri Feb  5 16:07:09 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Fri, 5 Feb 2021 16:07:09 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v12]
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: <Vg27jHtpjAQ36mYoE5MyolUJUi8K9lSb_c3grH_DLvM=.df18633b-2124-44b0-ac51-e5405a3f745d@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 signal handler part for debugger

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2200/files
  - new: https://git.openjdk.java.net/jdk/pull/2200/files/8652d21d..0d0e9baf

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

  Stats: 16 lines in 1 file changed: 5 ins; 8 del; 3 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  Fri Feb  5 16:17:50 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Fri, 5 Feb 2021 16:17:50 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
In-Reply-To: <ufvmALKCsU5RoY8Sqxdp7JKcBY2N4F6nwwg72Lc1ESQ=.075d302c-c039-4819-b061-a0d3559b766c@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>
 <gdmSyDFlKNJfjwP2R9NL99cuUnJvVlNAVSuTGXX1aGI=.5ae84a36-aaf7-44d5-968f-594d09c71683@github.com>
 <fHJqmfpRVckaOW7MOyMjXwKjehndN__p9QjsTf9B9Js=.5875bc1b-07e3-4c07-b9c4-c727f8103eef@github.com>
 <wQBsTj0KvZ7rck0NUDidYgao4zGeX78K-rxKB-e5tpA=.1922d92c-7594-4937-a2d5-2399a8d7e559@github.com>
 <qojI0u-VDQwQaoiqXAunT3_yqDzr3BBK25K27nBtb3g=.eeb61acb-ca8b-4b7b-9fe7-482c3ce92b14@github.com>
 <ywsbiBtPywrS-Ouy15DesxAwaKcefenfqEy0F8kaZfM=.f9c21d8d-79e9-4ff6-ab8c-885e0662efb7@github.com>
 <lNhDXQS_2VEZmm1RPX0lkcbJ4kKQvYEyufORZ8TEHMk=.168a7f7f-27b5-4c9c-abfc-35170587c856@github.com>
 <hKXPfOkcCykuWVivbdtVTwN18T_iOWP5jgBzEGJxSSQ=.b37718c5-f5f1-44e8-82d6-518d76398e91@github.com>
 <ufvmALKCsU5RoY8Sqxdp7JKcBY2N4F6nwwg
 72Lc1ESQ=.075d302c-c039-4819-b061-a0d3559b766c@github.com>
Message-ID: <d6Wk3NNawGLLhluMZaSSYSbZjaypt9SJSFIoN0EUT1w=.87226322-3842-4573-9669-e59e1db9fdfc@github.com>

On Wed, 3 Feb 2021 23:29:30 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> using ` ```c ` https://docs.github.com/en/github/writing-on-github/creating-and-highlighting-code-blocks
>> 
>> I was wrong about `SIGFPE` / `EXC_MASK_ARITHMETIC`, it's used on i386, x86_64:
>> https://github.com/openjdk/jdk/blob/2be60e37e0e433141b2e3d3e32f8e638a4888e3a/src/hotspot/os_cpu/bsd_x86/os_bsd_x86.cpp#L467-L524
>> and aarch64:
>> https://github.com/AntonKozlov/jdk/blob/80827176cbc5f0dd26003cf234a8076f3f557928/src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp#L309-L323
>> (What happened with the formatting here, ugh?)
>> 
>> Your suggestion sounds good otherwise. @AntonKozlov, do you mind to integrate that?
>
> So it should be:
> 
> #if defined(__APPLE__)
>   // lldb (gdb) installs both standard BSD signal handlers, and mach exception
>   // handlers. By replacing the existing task exception handler, we disable lldb's mach
>   // exception handling, while leaving the standard BSD signal handlers functional.
>   //
>   // EXC_MASK_BAD_ACCESS needed by all architectures for NULL ptr checking
>   // EXC_MASK_ARITHMETIC needed by all architectures for div by 0 checking
>   // EXC_MASK_BAD_INSTRUCTION needed by aarch64 to initiate deoptimization
>   kern_return_t kr;
>   kr = task_set_exception_ports(mach_task_self(),
>                                 EXC_MASK_BAD_ACCESS | EXC_MASK_ARITHMETIC
>                                 AARCH64_ONLY(| EXC_MASK_BAD_INSTRUCTION),
>                                 MACH_PORT_NULL,
>                                 EXCEPTION_STATE_IDENTITY,
>                                 MACHINE_THREAD_STATE);
> 
>   assert(kr == KERN_SUCCESS, "could not set mach task signal handler");
> #endif

Thanks! I've updated the PR with this code, with extra indentation of `AARCH64_ONLY(...)` line, since this is continuation of the first parameter.

I'll fix the formatting in os_bsd_arch64.cpp along other changes to `bsd_aarch64` directory

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

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

From coleenp at openjdk.java.net  Fri Feb  5 16:55:40 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Fri, 5 Feb 2021 16:55:40 GMT
Subject: RFR: 8261161: Clean up warnings in hotspot/jtreg/vmTestbase tests
In-Reply-To: <G2NyGRcvSDtF9Il0jYkZSNrkigmfFeschsStnaD42L4=.e5dc8ca5-d49b-4799-a6c9-5aa35e0ca7fd@github.com>
References: <G2NyGRcvSDtF9Il0jYkZSNrkigmfFeschsStnaD42L4=.e5dc8ca5-d49b-4799-a6c9-5aa35e0ca7fd@github.com>
Message-ID: <1KH2oh0e-Qi8fsB4oxmJPN4AIdvEU2gYlhdGVZoPyjg=.1c2e2036-1fff-4ec5-97e4-616987dd7864@github.com>

On Fri, 5 Feb 2021 14:48:25 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this change to clean up warnings, such as the following, in the vmTestbase tests.  
> 
> warning: [synchronization] attempt to synchronize on an instance of a value-based class 
> warning: [removal] Integer(int) in Integer has been deprecated and marked for removal
> 
> This change cleans up the warnings by using a non-value based class to synchronize on, and replacing calls such as Integer(int) with Integer.valueOf(int).
> 
> The change was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-8 on Linux x64.
> 
> Thanks, Harold

Wow. thank you!

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

Marked as reviewed by coleenp (Reviewer).

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

From akozlov at openjdk.java.net  Fri Feb  5 17:23:50 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Fri, 5 Feb 2021 17:23:50 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
In-Reply-To: <MlC0k95KyLxJCu7ZSluQlSdVrGTPolMjYG_rX3lpebU=.9ccf1fac-6fec-4479-80d7-9ee89d3bbb54@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>
Message-ID: <x0F1vjGptkr-cbJzQ-3bS5zX7mFSgxIEDAjn6DxTfW4=.732c6cb4-7044-4561-821c-6ca63f9768a7@github.com>

On Tue, 2 Feb 2021 18:35:51 GMT, Gerard Ziemski <gziemski 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/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

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

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

From lzang at openjdk.java.net  Fri Feb  5 20:01:47 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Fri, 5 Feb 2021 20:01:47 GMT
Subject: RFR: 8257234 : Add gz option to SA jmap to write a gzipped heap
 dump [v14]
In-Reply-To: <eXFuaiLypqbGOiQMANkJ39sR1aTMSxtAlwG9XD4KuFk=.0efbc8de-50d4-4ed4-9566-074213c23b5f@github.com>
References: <oTMRc7LWvx9_Uov01HPX9UgyEqFmXt_nMG920HUQBIM=.3651754b-e1f1-46f8-9f44-c118a5c56dbe@github.com>
 <hshEN06sqJcgNmcW4Yb75mtnYFVMiqX3lfmekNjzApU=.183255d4-56da-48ac-8a81-7a81b5900253@github.com>
 <d2qneSjNn2StFBGSsQy45NNz8SI7WTogYPq8WR9pIlQ=.7d78b062-3606-4d29-9b18-81dfe9f38df9@github.com>
 <3AOVqSv3mzE-QVGg7NWJ8vs4pKBoHTgeHZjf1FHA9XA=.d0ab8c18-6d62-43c6-8232-4b1621ebc609@github.com>
 <eXFuaiLypqbGOiQMANkJ39sR1aTMSxtAlwG9XD4KuFk=.0efbc8de-50d4-4ed4-9566-074213c23b5f@github.com>
Message-ID: <D38V6wrLStQOicy6Q_WRIiMaZS0uxvkdSNYi9PhNW9U=.b6a8f8ee-19dd-416c-9824-44d192afe8e9@github.com>

On Thu, 4 Feb 2021 23:23:41 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Thanks for the thorough list, I have tested most of them but not all. I will cover them and update here later.
>> 
>>> So really there are two implementations of heap dumping, one in the VM and one in SA, but a total of 5 ways to get to them. I'm just starting to get my head wrapped around all this myself. We've created a very confusing situation for us, and unfortunately I think some of the changes that got us here was driven by a goal to simply things.
>> 
>> Yes, it makes me even curious about why there can be two different implementation of them (one by C++ and one by Java),  it seems we need double the work of adding new options for those tools, like parallal for jmap histo and dump, etc.
>
> One implementation is in the JVM itself, to be used when the JVM is still running well, and not just from command line tools. Heap dumping can also be triggered by the JVM itslef by setting flags like -XX:+HeapDumpBeforeFullGC. The other implementation is in SA, to be used on a core file or a hung JVM process, although it can also be used on a JVM that is still running well. BTW, there used to be a 3rd implementation. The old hprof profiler (a JVMTI agent) also was used to generate hprof files.

Dear @plummercj,

> `--dumpfile` and `--gz` can only be used with `--binaryheap`. That should be made clear in the help text.

I added indentation for these two sub-options.

> * SA's `jhsdb jmap --binaryheap` (which uses JMap.java with `-heap:format=b`)
> * SA's clhsdb `dumpheap` command (which also uses JMap.java with `-heap:format=b`)
> * executing  SA's `sun/jvm/hotspot/tools/JMap` class directly
> * `jmap -dump` command (Uses Attach API's `heapdump` command, which uses hotspot `HeapDump` class)
> * `GC.heap_dump` dcmd, which also uses the hotspot `HeapDumper` class
All 5 commands help message have been tested.

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

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

From sspitsyn at openjdk.java.net  Fri Feb  5 20:01:48 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Fri, 5 Feb 2021 20:01:48 GMT
Subject: RFR: 8257234 : Add gz option to SA jmap to write a gzipped heap
 dump [v14]
In-Reply-To: <D38V6wrLStQOicy6Q_WRIiMaZS0uxvkdSNYi9PhNW9U=.b6a8f8ee-19dd-416c-9824-44d192afe8e9@github.com>
References: <oTMRc7LWvx9_Uov01HPX9UgyEqFmXt_nMG920HUQBIM=.3651754b-e1f1-46f8-9f44-c118a5c56dbe@github.com>
 <hshEN06sqJcgNmcW4Yb75mtnYFVMiqX3lfmekNjzApU=.183255d4-56da-48ac-8a81-7a81b5900253@github.com>
 <d2qneSjNn2StFBGSsQy45NNz8SI7WTogYPq8WR9pIlQ=.7d78b062-3606-4d29-9b18-81dfe9f38df9@github.com>
 <3AOVqSv3mzE-QVGg7NWJ8vs4pKBoHTgeHZjf1FHA9XA=.d0ab8c18-6d62-43c6-8232-4b1621ebc609@github.com>
 <eXFuaiLypqbGOiQMANkJ39sR1aTMSxtAlwG9XD4KuFk=.0efbc8de-50d4-4ed4-9566-074213c23b5f@github.com>
 <D38V6wrLStQOicy6Q_WRIiMaZS0uxvkdSNYi9PhNW9U=.b6a8f8ee-19dd-416c-9824-44d192afe8e9@github.com>
Message-ID: <hUVB2Cre6Fb8ICAL89Hg-DPtbAIOQ-5A7QceGXwWVHY=.9c373f24-99f4-45b3-88e8-c6a5e37bbca8@github.com>

On Fri, 5 Feb 2021 15:32:26 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> One implementation is in the JVM itself, to be used when the JVM is still running well, and not just from command line tools. Heap dumping can also be triggered by the JVM itslef by setting flags like -XX:+HeapDumpBeforeFullGC. The other implementation is in SA, to be used on a core file or a hung JVM process, although it can also be used on a JVM that is still running well. BTW, there used to be a 3rd implementation. The old hprof profiler (a JVMTI agent) also was used to generate hprof files.
>
> Dear @plummercj,
> 
>> `--dumpfile` and `--gz` can only be used with `--binaryheap`. That should be made clear in the help text.
> 
> I added indentation for these two sub-options.
> 
>> * SA's `jhsdb jmap --binaryheap` (which uses JMap.java with `-heap:format=b`)
>> * SA's clhsdb `dumpheap` command (which also uses JMap.java with `-heap:format=b`)
>> * executing  SA's `sun/jvm/hotspot/tools/JMap` class directly
>> * `jmap -dump` command (Uses Attach API's `heapdump` command, which uses hotspot `HeapDump` class)
>> * `GC.heap_dump` dcmd, which also uses the hotspot `HeapDumper` class
> All 5 commands help message have been tested.

Hi Lin,
Thank you for the update with requested changes.
Please, note, my suggestion was rough and still needs to be tested/checked for potential bugs. :)
I'll look at changes in other files as well.
Thanks,
Serguei

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

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

From amenkov at openjdk.java.net  Fri Feb  5 21:14:53 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Fri, 5 Feb 2021 21:14:53 GMT
Subject: RFR: 8248162: serviceability/attach/RemovingUnixDomainSocketTest.java
 failed
Message-ID: <mw3-hXbMOC5XQQyQX5ySpBaWT3kEck9diGpIi_q1fJ0=.a82d3ce3-0cc5-40fa-9b43-99c7f5d090e2@github.com>

JDK-8258917 fixed non-java launchers ("wrong launcher" VM warning for tools).
The fix un-problemlists RemovingUnixDomainSocketTest and changes serviceability tests to use OutputAnalyzer.stderrShouldBeEmptyIgnoreDeprecatedWarnings instead of stderrShouldBeEmptyIgnoreVMWarnings

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

Commit messages:
 - JDK-8248162

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

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

From dcubed at openjdk.java.net  Fri Feb  5 21:24:44 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 5 Feb 2021 21:24:44 GMT
Subject: RFR: 8248162:
 serviceability/attach/RemovingUnixDomainSocketTest.java failed
In-Reply-To: <mw3-hXbMOC5XQQyQX5ySpBaWT3kEck9diGpIi_q1fJ0=.a82d3ce3-0cc5-40fa-9b43-99c7f5d090e2@github.com>
References: <mw3-hXbMOC5XQQyQX5ySpBaWT3kEck9diGpIi_q1fJ0=.a82d3ce3-0cc5-40fa-9b43-99c7f5d090e2@github.com>
Message-ID: <WjyzwkuL1fDObrhq_m9TVBJLArRrS2n0AQjT0t04nZU=.8b6921b1-dbee-4290-a3a0-5ba929ae74a0@github.com>

On Fri, 5 Feb 2021 21:09:37 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> JDK-8258917 fixed non-java launchers ("wrong launcher" VM warning for tools).
> The fix un-problemlists RemovingUnixDomainSocketTest and changes serviceability tests to use OutputAnalyzer.stderrShouldBeEmptyIgnoreDeprecatedWarnings instead of stderrShouldBeEmptyIgnoreVMWarnings

What kind of testing was done in Mach5?

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

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

From cjplummer at openjdk.java.net  Fri Feb  5 22:14:42 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Fri, 5 Feb 2021 22:14:42 GMT
Subject: RFR: 8248162:
 serviceability/attach/RemovingUnixDomainSocketTest.java failed
In-Reply-To: <mw3-hXbMOC5XQQyQX5ySpBaWT3kEck9diGpIi_q1fJ0=.a82d3ce3-0cc5-40fa-9b43-99c7f5d090e2@github.com>
References: <mw3-hXbMOC5XQQyQX5ySpBaWT3kEck9diGpIi_q1fJ0=.a82d3ce3-0cc5-40fa-9b43-99c7f5d090e2@github.com>
Message-ID: <wVbGFHvc2GIjGlDjGfnOtqFxuZ_Mnnkth2RCY0WuwuU=.fb9f4239-b92b-4feb-b476-71227a88be9b@github.com>

On Fri, 5 Feb 2021 21:09:37 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> JDK-8258917 fixed non-java launchers ("wrong launcher" VM warning for tools).
> The fix un-problemlists RemovingUnixDomainSocketTest and changes serviceability tests to use OutputAnalyzer.stderrShouldBeEmptyIgnoreDeprecatedWarnings instead of stderrShouldBeEmptyIgnoreVMWarnings

Overall it looks good, but as @dcubed-ojdk hinted, sufficient mach5 testing is necessary. VM warning issues turn up during testing when extra VM options are used during various tiers and "specialized" test tasks. Simply running the tests in question through mach5 or locally isn't enough.

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

Marked as reviewed by cjplummer (Reviewer).

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

From amenkov at openjdk.java.net  Sat Feb  6 00:54:41 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Sat, 6 Feb 2021 00:54:41 GMT
Subject: RFR: 8248162:
 serviceability/attach/RemovingUnixDomainSocketTest.java failed
In-Reply-To: <wVbGFHvc2GIjGlDjGfnOtqFxuZ_Mnnkth2RCY0WuwuU=.fb9f4239-b92b-4feb-b476-71227a88be9b@github.com>
References: <mw3-hXbMOC5XQQyQX5ySpBaWT3kEck9diGpIi_q1fJ0=.a82d3ce3-0cc5-40fa-9b43-99c7f5d090e2@github.com>
 <wVbGFHvc2GIjGlDjGfnOtqFxuZ_Mnnkth2RCY0WuwuU=.fb9f4239-b92b-4feb-b476-71227a88be9b@github.com>
Message-ID: <TKLLeoksbe-Ype5LLEVKmDCEmmJXMOvKLYQu4oHSXDM=.339cac75-daa9-494c-9030-a56a3923329f@github.com>

On Fri, 5 Feb 2021 22:11:39 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> JDK-8258917 fixed non-java launchers ("wrong launcher" VM warning for tools).
>> The fix un-problemlists RemovingUnixDomainSocketTest and changes serviceability tests to use OutputAnalyzer.stderrShouldBeEmptyIgnoreDeprecatedWarnings instead of stderrShouldBeEmptyIgnoreVMWarnings
>
> Overall it looks good, but as @dcubed-ojdk hinted, sufficient mach5 testing is necessary. VM warning issues turn up during testing when extra VM options are used during various tiers and "specialized" test tasks. Simply running the tests in question through mach5 or locally isn't enough.

> 
> 
> What kind of testing was done in Mach5?

I run all affected tests with default arguments and with "-XX:NativeMemoryTracking=detail"

> 
> Overall it looks good, but as @dcubed-ojdk hinted, sufficient mach5 testing is necessary. VM warning issues turn up during testing when extra VM options are used during various tiers and "specialized" test tasks. Simply running the tests in question through mach5 or locally isn't enough.

Do you have some ideas what to run?

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

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

From cjplummer at openjdk.java.net  Sat Feb  6 04:25:43 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Sat, 6 Feb 2021 04:25:43 GMT
Subject: RFR: 8257234 : Add gz option to SA jmap to write a gzipped heap
 dump [v14]
In-Reply-To: <hUVB2Cre6Fb8ICAL89Hg-DPtbAIOQ-5A7QceGXwWVHY=.9c373f24-99f4-45b3-88e8-c6a5e37bbca8@github.com>
References: <oTMRc7LWvx9_Uov01HPX9UgyEqFmXt_nMG920HUQBIM=.3651754b-e1f1-46f8-9f44-c118a5c56dbe@github.com>
 <hshEN06sqJcgNmcW4Yb75mtnYFVMiqX3lfmekNjzApU=.183255d4-56da-48ac-8a81-7a81b5900253@github.com>
 <d2qneSjNn2StFBGSsQy45NNz8SI7WTogYPq8WR9pIlQ=.7d78b062-3606-4d29-9b18-81dfe9f38df9@github.com>
 <3AOVqSv3mzE-QVGg7NWJ8vs4pKBoHTgeHZjf1FHA9XA=.d0ab8c18-6d62-43c6-8232-4b1621ebc609@github.com>
 <eXFuaiLypqbGOiQMANkJ39sR1aTMSxtAlwG9XD4KuFk=.0efbc8de-50d4-4ed4-9566-074213c23b5f@github.com>
 <D38V6wrLStQOicy6Q_WRIiMaZS0uxvkdSNYi9PhNW9U=.b6a8f8ee-19dd-416c-9824-44d192afe8e9@github.com>
 <hUVB2Cre6Fb8ICAL89Hg-DPtbAIOQ-5A7QceGXwWVHY=.9c373f24-99f4-45b3-88e8-c6a5e37bbca8@github.com>
Message-ID: <cOu3ZYH3UkqbQXubenq1hm360tu9ifw1gBY4mXGFXdg=.e58b622b-732e-49a8-8223-76679b9d9ffa@github.com>

On Fri, 5 Feb 2021 19:58:42 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Dear @plummercj,
>> 
>>> `--dumpfile` and `--gz` can only be used with `--binaryheap`. That should be made clear in the help text.
>> 
>> I added indentation for these two sub-options.
>> 
>>> * SA's `jhsdb jmap --binaryheap` (which uses JMap.java with `-heap:format=b`)
>>> * SA's clhsdb `dumpheap` command (which also uses JMap.java with `-heap:format=b`)
>>> * executing  SA's `sun/jvm/hotspot/tools/JMap` class directly
>>> * `jmap -dump` command (Uses Attach API's `heapdump` command, which uses hotspot `HeapDump` class)
>>> * `GC.heap_dump` dcmd, which also uses the hotspot `HeapDumper` class
>> All 5 commands help message have been tested.
>
> Hi Lin,
> Thank you for the update with requested changes.
> Please, note, my suggestion was rough and still needs to be tested/checked for potential bugs. :)
> I'll look at changes in other files as well.
> Thanks,
> Serguei

> I think new PR can be created for adding `format=x` to `clhsdb dumpheap` and `jhsdb jmap`. And maybe new CSR is required?

You can do that if you'd like. I'm not sure how important format=x is.

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

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

From cjplummer at openjdk.java.net  Sat Feb  6 04:45:45 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Sat, 6 Feb 2021 04:45:45 GMT
Subject: RFR: 8257234 : Add gz option to SA jmap to write a gzipped heap
 dump [v15]
In-Reply-To: <hM3DCh9yCmFFN9_mr3ChsAleoQ-bK25vEoCTH6G0d9U=.77d54919-42bd-4744-a281-b3e4a9b5e474@github.com>
References: <oTMRc7LWvx9_Uov01HPX9UgyEqFmXt_nMG920HUQBIM=.3651754b-e1f1-46f8-9f44-c118a5c56dbe@github.com>
 <hM3DCh9yCmFFN9_mr3ChsAleoQ-bK25vEoCTH6G0d9U=.77d54919-42bd-4744-a281-b3e4a9b5e474@github.com>
Message-ID: <SgskwsTM9vXT-X8FytvS7TsBOcuUHD-dVpwDgLCkUE0=.f8ff6ef1-3eec-4278-9d47-350b641fc391@github.com>

On Fri, 5 Feb 2021 15:36:00 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> 8257234 : Add gz option to SA jmap to write a gzipped heap dump
>
> Lin Zang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   refine help message and also refactor the logic in CommandProcessor

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/SALauncher.java line 131:

> 129:         System.out.println("        dump options:");
> 130:         System.out.println("          --dumpfile <name> The name of the dump file.");
> 131:         System.out.println("          --gz <1-9>        The compression level for gzipped dump file.");

This is a little awkward, and will get worse if later you add an option to dump in GXL format (format=x). Maybe for `--dumpfile` and `--gz` just add a comment "Only valid with --binaryheap".

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java line 1807:

> 1805:                         }
> 1806:                         filename = "heap.bin.gz";
> 1807:                     }

I don't think this section works properly if there is just one argument, and it is the filename, not gz=. Also, there appears to be no test case to catch this bug.

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

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

From cjplummer at openjdk.java.net  Sat Feb  6 04:49:42 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Sat, 6 Feb 2021 04:49:42 GMT
Subject: RFR: 8261131: jcmd jmap dump should not accept gz option with no
 value [v2]
In-Reply-To: <7B5igYqyeO29bJbDvlD-Kd5t8Y4Bfb6PMaBFW35JJU8=.57c38feb-a3ff-4f02-a8b2-0f295b8ef53e@github.com>
References: <qUp1tOUkdsvzPGH03MyAhSokYQUUYm9xz-2X6GjsSC4=.21007ed7-65f7-4768-a2f8-e7d2ac2533f6@github.com>
 <7B5igYqyeO29bJbDvlD-Kd5t8Y4Bfb6PMaBFW35JJU8=.57c38feb-a3ff-4f02-a8b2-0f295b8ef53e@github.com>
Message-ID: <hWLcUZzPO0GOp1E86Lokk5PVsMzb4IAXAhOT-RuQST8=.39ef6192-b8c9-4d81-ac21-0cacbfa78679@github.com>

On Fri, 5 Feb 2021 06:38:53 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> 8261131: jcmd jmap dump should not accept gz option with no value
>
> Lin Zang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove useless code and update copyright

Marked as reviewed by cjplummer (Reviewer).

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

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

From cjplummer at openjdk.java.net  Sat Feb  6 04:52:43 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Sat, 6 Feb 2021 04:52:43 GMT
Subject: RFR: JDK-8261034: improve jcmd GC.class_histogram to support
 parallel [v5]
In-Reply-To: <VSTJIsFLpVyvAf9R2WTIaIhXtn6RPqQvQ7TlKbfJBgY=.2d4e5748-214e-44fe-a3f9-a93672743720@github.com>
References: <VKzVY-01CEXUbQdlKMhDWjtjxUgpxs_6487x232VsAI=.3b9c5d8a-972b-4997-9f75-1951f98e1751@github.com>
 <VSTJIsFLpVyvAf9R2WTIaIhXtn6RPqQvQ7TlKbfJBgY=.2d4e5748-214e-44fe-a3f9-a93672743720@github.com>
Message-ID: <53hSBwd86aOSwEqjfQrQAsG5TdqUgqYWHlPml2Tzfk8=.3745396f-f7a5-4679-a58d-3185d33e11d8@github.com>

On Fri, 5 Feb 2021 02:47:01 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> parallel -histo of jmap was added by JDK-8214535, it's better to support parallel for jcmd GC.class_histogram too.
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8261034: improve jcmd GC.class_histogram to support parallel

src/hotspot/share/services/diagnosticCommand.cpp line 560:

> 558:   _parallel_thread_num("-parallel",
> 559:        "Number of parallel threads for heap iteration. "
> 560:        "0 means let the VM determined the number of threads. "

Should be "determine". Sorry that was a typo in the text I suggested.

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

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

From cjplummer at openjdk.java.net  Sat Feb  6 04:56:43 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Sat, 6 Feb 2021 04:56:43 GMT
Subject: RFR: JDK-8261034: improve jcmd GC.class_histogram to support
 parallel [v5]
In-Reply-To: <VSTJIsFLpVyvAf9R2WTIaIhXtn6RPqQvQ7TlKbfJBgY=.2d4e5748-214e-44fe-a3f9-a93672743720@github.com>
References: <VKzVY-01CEXUbQdlKMhDWjtjxUgpxs_6487x232VsAI=.3b9c5d8a-972b-4997-9f75-1951f98e1751@github.com>
 <VSTJIsFLpVyvAf9R2WTIaIhXtn6RPqQvQ7TlKbfJBgY=.2d4e5748-214e-44fe-a3f9-a93672743720@github.com>
Message-ID: <agWwxCFmOBOtcruEYkzCoQnFbcTr87pXy-IlImJ2vDI=.d3e5dae1-2f71-4984-8cec-d5cd0013e822@github.com>

On Fri, 5 Feb 2021 02:47:01 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> parallel -histo of jmap was added by JDK-8214535, it's better to support parallel for jcmd GC.class_histogram too.
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8261034: improve jcmd GC.class_histogram to support parallel

Copyrights need updating in two of the files.

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

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

From lzang at openjdk.java.net  Sat Feb  6 04:56:46 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Sat, 6 Feb 2021 04:56:46 GMT
Subject: RFR: 8257234 : Add gz option to SA jmap to write a gzipped heap
 dump [v15]
In-Reply-To: <SgskwsTM9vXT-X8FytvS7TsBOcuUHD-dVpwDgLCkUE0=.f8ff6ef1-3eec-4278-9d47-350b641fc391@github.com>
References: <oTMRc7LWvx9_Uov01HPX9UgyEqFmXt_nMG920HUQBIM=.3651754b-e1f1-46f8-9f44-c118a5c56dbe@github.com>
 <hM3DCh9yCmFFN9_mr3ChsAleoQ-bK25vEoCTH6G0d9U=.77d54919-42bd-4744-a281-b3e4a9b5e474@github.com>
 <SgskwsTM9vXT-X8FytvS7TsBOcuUHD-dVpwDgLCkUE0=.f8ff6ef1-3eec-4278-9d47-350b641fc391@github.com>
Message-ID: <ZO0sbIMdy839dWUX4OgvwBjtqwLP5EpskwLpi53JlEQ=.465fa87f-e483-4388-a908-2bfd67d653c5@github.com>

On Sat, 6 Feb 2021 04:42:32 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Lin Zang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   refine help message and also refactor the logic in CommandProcessor
>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java line 1807:
> 
>> 1805:                         }
>> 1806:                         filename = "heap.bin.gz";
>> 1807:                     }
> 
> I don't think this section works properly if there is just one argument, and it is the filename, not gz=. Also, there appears to be no test case to catch this bug.

Oh yes, I think there should be a check whether the option is "gz=" first. And I will the test case for that together when with the fix of HeapDumpTest.java.

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

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

From lzang at openjdk.java.net  Sat Feb  6 05:00:43 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Sat, 6 Feb 2021 05:00:43 GMT
Subject: RFR: 8261131: jcmd jmap dump should not accept gz option with no
 value [v2]
In-Reply-To: <hWLcUZzPO0GOp1E86Lokk5PVsMzb4IAXAhOT-RuQST8=.39ef6192-b8c9-4d81-ac21-0cacbfa78679@github.com>
References: <qUp1tOUkdsvzPGH03MyAhSokYQUUYm9xz-2X6GjsSC4=.21007ed7-65f7-4768-a2f8-e7d2ac2533f6@github.com>
 <7B5igYqyeO29bJbDvlD-Kd5t8Y4Bfb6PMaBFW35JJU8=.57c38feb-a3ff-4f02-a8b2-0f295b8ef53e@github.com>
 <hWLcUZzPO0GOp1E86Lokk5PVsMzb4IAXAhOT-RuQST8=.39ef6192-b8c9-4d81-ac21-0cacbfa78679@github.com>
Message-ID: <kZE-knpCk9m3Q-RpRPjo2ygv0bvBaaoFXRxFbGTLO3A=.ab541f06-0d78-4571-a096-eb6c244f78b3@github.com>

On Sat, 6 Feb 2021 04:47:10 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Lin Zang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove useless code and update copyright
>
> Marked as reviewed by cjplummer (Reviewer).

Thanks @plummercj for help reviewing this PR! mark it as ready for push.

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

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

From kevinw at openjdk.java.net  Sat Feb  6 16:47:40 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Sat, 6 Feb 2021 16:47:40 GMT
Subject: RFR: 8248876: LoadObject with bad base address created for exec
 file on linux
In-Reply-To: <f1274sofRndSfbHeMMqKwwOrJercIi9B4gI7WoP17Bw=.2c539e92-06fa-4efe-86eb-d416f4caf83e@github.com>
References: <R53sQGWiJHl8JzP_wmXoupayROl3DVu0l0rBCzYurWY=.4d6762e8-1de6-4b7d-805f-0a9b977950fb@github.com>
 <f1274sofRndSfbHeMMqKwwOrJercIi9B4gI7WoP17Bw=.2c539e92-06fa-4efe-86eb-d416f4caf83e@github.com>
Message-ID: <k5vpSA8E916WusEzkLYfQ4tHvVYdRNmGA1-nyQpf2qk=.7fba986b-3e79-47e2-bfb4-a9231b6989d6@github.com>

On Wed, 3 Feb 2021 22:17:16 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> We could see NPE on `LinuxCDebugger::loadObjectContainingPC` which is used mainly by the clhsdb `findpc` command. (See [JDK-8248876](https://bugs.openjdk.java.net/browse/JDK-8248876) for more details)
>> 
>> It is caused by PIE executable handling.
>> 
>> Currently we use virtual address of top of PT_LOAD in executable as base address - it is valid for ET_EXEC binary.
>> However, in case of ET_DYN binary (PIE binary), we should handle it like a shared library.
>> In GDB, base address of executable would be calculated by dynamic section. SA should also do so.
>
> Marked as reviewed by cjplummer (Reviewer).

Hi!
I found the "svr4_exec_displacement() in GDB" more confusing than informative, maybe this is the same technique GDB uses...  But I followed our dynamic_addr setting and agree with the new changes.

An alternative comment could be this, which would also removes the "substract" typo (which was not yours!):

ps_core.c 509

    } else { // ET_DYN
      // dynamic_addr was initially set to entry point (AT_ENTRY).
      // Now subtract the entry point offset to get load address:
      result = ph->core->dynamic_addr - exec_ehdr->e_entry;
      // Find actual dynamic_addr:
      ph->core->dynamic_addr += exec_php->p_vaddr - exec_ehdr->e_entry;
    }

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

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

From kevinw at openjdk.java.net  Sat Feb  6 17:05:43 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Sat, 6 Feb 2021 17:05:43 GMT
Subject: RFR: 8248876: LoadObject with bad base address created for exec
 file on linux
In-Reply-To: <R53sQGWiJHl8JzP_wmXoupayROl3DVu0l0rBCzYurWY=.4d6762e8-1de6-4b7d-805f-0a9b977950fb@github.com>
References: <R53sQGWiJHl8JzP_wmXoupayROl3DVu0l0rBCzYurWY=.4d6762e8-1de6-4b7d-805f-0a9b977950fb@github.com>
Message-ID: <Jahs5DE3ENM9yMQuvEJylgpcDHlQUMYwljz8nIDmJ8s=.f6f33839-5aea-4964-a472-0c9bbee6bc68@github.com>

On Tue, 2 Feb 2021 23:37:21 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> We could see NPE on `LinuxCDebugger::loadObjectContainingPC` which is used mainly by the clhsdb `findpc` command. (See [JDK-8248876](https://bugs.openjdk.java.net/browse/JDK-8248876) for more details)
> 
> It is caused by PIE executable handling.
> 
> Currently we use virtual address of top of PT_LOAD in executable as base address - it is valid for ET_EXEC binary.
> However, in case of ET_DYN binary (PIE binary), we should handle it like a shared library.
> In GDB, base address of executable would be calculated by dynamic section. SA should also do so.

Looks good, I made a suggestions elsewhere in the PR about the comments at line 510...

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

Marked as reviewed by kevinw (Committer).

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

From mli at openjdk.java.net  Sun Feb  7 00:59:00 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Sun, 7 Feb 2021 00:59:00 GMT
Subject: RFR: JDK-8261034: improve jcmd GC.class_histogram to support
 parallel [v6]
In-Reply-To: <VKzVY-01CEXUbQdlKMhDWjtjxUgpxs_6487x232VsAI=.3b9c5d8a-972b-4997-9f75-1951f98e1751@github.com>
References: <VKzVY-01CEXUbQdlKMhDWjtjxUgpxs_6487x232VsAI=.3b9c5d8a-972b-4997-9f75-1951f98e1751@github.com>
Message-ID: <HeQyRB-LTh7PQJIxC0rU47yB9sAxeg85fgS9ZwXhe7Y=.7b588c98-ebd2-455b-898a-6f5cb84e8a92@github.com>

> parallel -histo of jmap was added by JDK-8214535, it's better to support parallel for jcmd GC.class_histogram too.

Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:

  improve jcmd GC.class_histogram to support parallel

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2379/files
  - new: https://git.openjdk.java.net/jdk/pull/2379/files/380d2acc..fe46037d

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

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

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

From mli at openjdk.java.net  Sun Feb  7 01:05:41 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Sun, 7 Feb 2021 01:05:41 GMT
Subject: RFR: JDK-8261034: improve jcmd GC.class_histogram to support
 parallel [v5]
In-Reply-To: <agWwxCFmOBOtcruEYkzCoQnFbcTr87pXy-IlImJ2vDI=.d3e5dae1-2f71-4984-8cec-d5cd0013e822@github.com>
References: <VKzVY-01CEXUbQdlKMhDWjtjxUgpxs_6487x232VsAI=.3b9c5d8a-972b-4997-9f75-1951f98e1751@github.com>
 <VSTJIsFLpVyvAf9R2WTIaIhXtn6RPqQvQ7TlKbfJBgY=.2d4e5748-214e-44fe-a3f9-a93672743720@github.com>
 <agWwxCFmOBOtcruEYkzCoQnFbcTr87pXy-IlImJ2vDI=.d3e5dae1-2f71-4984-8cec-d5cd0013e822@github.com>
Message-ID: <erNwTtL7f26n-ESBoueQgX3SgDhl6YsY8sB3oqB46Mo=.e2eb7cf1-87b1-45ae-a100-77f1e3849141@github.com>

On Sat, 6 Feb 2021 04:54:01 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Copyrights need updating in two of the files.

Updated. 
BTW, I also updated the copyright for src/hotspot/share/gc/g1/heapRegionSet.cpp which I modified several weeks ago in https://bugs.openjdk.java.net/browse/JDK-8260200, but did not update the copyright at that time.

> src/hotspot/share/services/diagnosticCommand.cpp line 560:
> 
>> 558:   _parallel_thread_num("-parallel",
>> 559:        "Number of parallel threads for heap iteration. "
>> 560:        "0 means let the VM determined the number of threads. "
> 
> Should be "determine". Sorry that was a typo in the text I suggested.

My bad, thanks for pointing out. :-)

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

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

From ysuenaga at openjdk.java.net  Sun Feb  7 02:25:05 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Sun, 7 Feb 2021 02:25:05 GMT
Subject: RFR: 8248876: LoadObject with bad base address created for exec
 file on linux [v2]
In-Reply-To: <R53sQGWiJHl8JzP_wmXoupayROl3DVu0l0rBCzYurWY=.4d6762e8-1de6-4b7d-805f-0a9b977950fb@github.com>
References: <R53sQGWiJHl8JzP_wmXoupayROl3DVu0l0rBCzYurWY=.4d6762e8-1de6-4b7d-805f-0a9b977950fb@github.com>
Message-ID: <LZZrqBRMKMMWFANkF2MG5kRoJdDmQ3qqCeSJekeadTo=.b5401a4f-ec63-45f9-a3dd-2248f3b7a835@github.com>

> We could see NPE on `LinuxCDebugger::loadObjectContainingPC` which is used mainly by the clhsdb `findpc` command. (See [JDK-8248876](https://bugs.openjdk.java.net/browse/JDK-8248876) for more details)
> 
> It is caused by PIE executable handling.
> 
> Currently we use virtual address of top of PT_LOAD in executable as base address - it is valid for ET_EXEC binary.
> However, in case of ET_DYN binary (PIE binary), we should handle it like a shared library.
> In GDB, base address of executable would be calculated by dynamic section. SA should also do so.

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

  Remove unnecessary comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2366/files
  - new: https://git.openjdk.java.net/jdk/pull/2366/files/ed352edd..6a83d12d

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

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

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

From ysuenaga at openjdk.java.net  Sun Feb  7 02:25:06 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Sun, 7 Feb 2021 02:25:06 GMT
Subject: RFR: 8248876: LoadObject with bad base address created for exec
 file on linux [v2]
In-Reply-To: <Jahs5DE3ENM9yMQuvEJylgpcDHlQUMYwljz8nIDmJ8s=.f6f33839-5aea-4964-a472-0c9bbee6bc68@github.com>
References: <R53sQGWiJHl8JzP_wmXoupayROl3DVu0l0rBCzYurWY=.4d6762e8-1de6-4b7d-805f-0a9b977950fb@github.com>
 <Jahs5DE3ENM9yMQuvEJylgpcDHlQUMYwljz8nIDmJ8s=.f6f33839-5aea-4964-a472-0c9bbee6bc68@github.com>
Message-ID: <49zneDLw_YfcFnLRNd9O_m-pRQ5EXbfIfyrpZy-VKTk=.2ec794e3-b1df-40ef-9097-55030bee39bc@github.com>

On Sat, 6 Feb 2021 17:03:26 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unnecessary comments
>
> Looks good, I made a suggestions elsewhere in the PR about the comments at line 510...

@kevinjwalls Thank you for the comment!

> I found the "svr4_exec_displacement() in GDB" more confusing than informative, maybe this is the same technique GDB uses... But I followed our dynamic_addr setting and agree with the new changes.

I removed it in new commit.

> An alternative comment could be this, which would also removes the "substract" typo (which was not yours!):

It's my change in [JDK-8173941](https://bugs.openjdk.java.net/browse/JDK-8173941).
I removed it too.

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

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

From cjplummer at openjdk.java.net  Sun Feb  7 03:32:43 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Sun, 7 Feb 2021 03:32:43 GMT
Subject: RFR: JDK-8261034: improve jcmd GC.class_histogram to support
 parallel [v6]
In-Reply-To: <HeQyRB-LTh7PQJIxC0rU47yB9sAxeg85fgS9ZwXhe7Y=.7b588c98-ebd2-455b-898a-6f5cb84e8a92@github.com>
References: <VKzVY-01CEXUbQdlKMhDWjtjxUgpxs_6487x232VsAI=.3b9c5d8a-972b-4997-9f75-1951f98e1751@github.com>
 <HeQyRB-LTh7PQJIxC0rU47yB9sAxeg85fgS9ZwXhe7Y=.7b588c98-ebd2-455b-898a-6f5cb84e8a92@github.com>
Message-ID: <t39nYCyILS_QpOJ06QoMZKKUGqAWYNXbBv7-qjrRjGQ=.50d2d086-ac24-46b9-b30b-82d38b3a0906@github.com>

On Sun, 7 Feb 2021 00:59:00 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> parallel -histo of jmap was added by JDK-8214535, it's better to support parallel for jcmd GC.class_histogram too.
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   improve jcmd GC.class_histogram to support parallel

diagnosticCommand.hpp still needs a copyright update.

For heapRegionSet.cpp, sorry but you'll need to file a new CR to update its copyright. Among other things, fixing it here makes backports harder to get right.

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

Changes requested by cjplummer (Reviewer).

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

From lzang at openjdk.java.net  Sun Feb  7 08:20:10 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Sun, 7 Feb 2021 08:20:10 GMT
Subject: RFR: 8257234 : Add gz option to SA jmap to write a gzipped heap
 dump [v16]
In-Reply-To: <oTMRc7LWvx9_Uov01HPX9UgyEqFmXt_nMG920HUQBIM=.3651754b-e1f1-46f8-9f44-c118a5c56dbe@github.com>
References: <oTMRc7LWvx9_Uov01HPX9UgyEqFmXt_nMG920HUQBIM=.3651754b-e1f1-46f8-9f44-c118a5c56dbe@github.com>
Message-ID: <OQD34blU9cPwSjWOMtUDQYdfOjPiuaul8dREIAuVWg4=.4dd63517-9383-4008-813f-a37ed58f018f@github.com>

> 8257234 : Add gz option to SA jmap to write a gzipped heap dump

Lin Zang has updated the pull request incrementally with two additional commits since the last revision:

 - add test in HeapDumpTest and fix in argument parsing
 - revert changes in jcmd jmap
   
   Another PR has been created for jcmd jmap.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1712/files
  - new: https://git.openjdk.java.net/jdk/pull/1712/files/0aa703d3..8f38b974

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1712&range=15
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1712&range=14-15

  Stats: 114 lines in 6 files changed: 58 ins; 26 del; 30 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1712.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1712/head:pull/1712

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

From lzang at openjdk.java.net  Sun Feb  7 08:26:51 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Sun, 7 Feb 2021 08:26:51 GMT
Subject: RFR: 8257234 : Add gz option to SA jmap to write a gzipped heap
 dump [v14]
In-Reply-To: <d2qneSjNn2StFBGSsQy45NNz8SI7WTogYPq8WR9pIlQ=.7d78b062-3606-4d29-9b18-81dfe9f38df9@github.com>
References: <oTMRc7LWvx9_Uov01HPX9UgyEqFmXt_nMG920HUQBIM=.3651754b-e1f1-46f8-9f44-c118a5c56dbe@github.com>
 <hshEN06sqJcgNmcW4Yb75mtnYFVMiqX3lfmekNjzApU=.183255d4-56da-48ac-8a81-7a81b5900253@github.com>
 <d2qneSjNn2StFBGSsQy45NNz8SI7WTogYPq8WR9pIlQ=.7d78b062-3606-4d29-9b18-81dfe9f38df9@github.com>
Message-ID: <Yv1XSMWL-UvI5YVskEbiU2xImhNHsE2VR__bYtwBtgk=.b768eccd-dbc1-43d6-ab0a-9c3b13267833@github.com>

On Thu, 4 Feb 2021 03:54:26 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Lin Zang has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - fix an issue of double printing error message.
>>  - fix jcmd jmap issue and add test in BascJMapTest and code refine
>
>> > I have found that there is a bug in jcmd jmap, it could accept the argument "gz=" with no value specified.
>> > so jmap -dump:file=a.hprof,gz= could generate dump file successfully.
>> 
>> After re-think of it, the jcmd jmap issue mentioned here seems not quite related with this PR, so maybe a standalone one is better? What do you think?
> 
> That's probably a good idea since this PR is for SA changes, and it's probably best not to mix it with attach api changes.

Dear @plummercj and @sspitsyn, 
I have uploaded a new change that fix some issues in argument parsing and segment dump. Also added the sub-test in HeapDumpTest.java. 
Would you like to help review again?
Thanks a lot for your patience and suggestion!

-Lin

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

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

From lzang at openjdk.java.net  Sun Feb  7 08:31:10 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Sun, 7 Feb 2021 08:31:10 GMT
Subject: RFR: 8261131: jcmd jmap dump should not accept gz option with no
 value [v3]
In-Reply-To: <qUp1tOUkdsvzPGH03MyAhSokYQUUYm9xz-2X6GjsSC4=.21007ed7-65f7-4768-a2f8-e7d2ac2533f6@github.com>
References: <qUp1tOUkdsvzPGH03MyAhSokYQUUYm9xz-2X6GjsSC4=.21007ed7-65f7-4768-a2f8-e7d2ac2533f6@github.com>
Message-ID: <_wOxIScREVJ2249eVGInbc9G8hiihHCU110IgLDUFBo=.7b656721-b847-420d-b8f8-e7298cc4f5ba@github.com>

> 8261131: jcmd jmap dump should not accept gz option with no value

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 three additional commits since the last revision:

 - Merge branch 'master' into gz-fix
 - remove useless code and update copyright
 - 8261131: jcmd jmap dump should not accept gz option with no value

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2399/files
  - new: https://git.openjdk.java.net/jdk/pull/2399/files/620423ef..ecf05fea

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

  Stats: 12401 lines in 445 files changed: 8062 ins; 3151 del; 1188 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2399.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2399/head:pull/2399

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

From mli at openjdk.java.net  Sun Feb  7 12:38:55 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Sun, 7 Feb 2021 12:38:55 GMT
Subject: RFR: JDK-8261034: improve jcmd GC.class_histogram to support
 parallel [v6]
In-Reply-To: <t39nYCyILS_QpOJ06QoMZKKUGqAWYNXbBv7-qjrRjGQ=.50d2d086-ac24-46b9-b30b-82d38b3a0906@github.com>
References: <VKzVY-01CEXUbQdlKMhDWjtjxUgpxs_6487x232VsAI=.3b9c5d8a-972b-4997-9f75-1951f98e1751@github.com>
 <HeQyRB-LTh7PQJIxC0rU47yB9sAxeg85fgS9ZwXhe7Y=.7b588c98-ebd2-455b-898a-6f5cb84e8a92@github.com>
 <t39nYCyILS_QpOJ06QoMZKKUGqAWYNXbBv7-qjrRjGQ=.50d2d086-ac24-46b9-b30b-82d38b3a0906@github.com>
Message-ID: <3Z5kxEyXuHLeS0d6fHK394fHcnLh2tr2vx06huh7QW0=.72addd36-2914-4220-843c-efce0065e608@github.com>

On Sun, 7 Feb 2021 03:29:36 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> diagnosticCommand.hpp still needs a copyright update.
> 
Thanks for pointing out.
> For heapRegionSet.cpp, sorry but you'll need to file a new CR to update its copyright. Among other things, fixing it here makes backports harder to get right.

I see, revert the related change.

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

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

From mli at openjdk.java.net  Sun Feb  7 12:38:55 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Sun, 7 Feb 2021 12:38:55 GMT
Subject: RFR: JDK-8261034: improve jcmd GC.class_histogram to support
 parallel [v7]
In-Reply-To: <VKzVY-01CEXUbQdlKMhDWjtjxUgpxs_6487x232VsAI=.3b9c5d8a-972b-4997-9f75-1951f98e1751@github.com>
References: <VKzVY-01CEXUbQdlKMhDWjtjxUgpxs_6487x232VsAI=.3b9c5d8a-972b-4997-9f75-1951f98e1751@github.com>
Message-ID: <Xckd1YLQAyNwBz8rnahiWYPmOfG0-3j5NcbiWk8tY0Y=.5e958bbf-e540-4c60-96ac-545ae61984e7@github.com>

> parallel -histo of jmap was added by JDK-8214535, it's better to support parallel for jcmd GC.class_histogram too.

Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:

  improve jcmd GC.class_histogram to support parallel

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2379/files
  - new: https://git.openjdk.java.net/jdk/pull/2379/files/fe46037d..ec2324ec

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

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

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

From ysuenaga at openjdk.java.net  Mon Feb  8 02:37:42 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Mon, 8 Feb 2021 02:37:42 GMT
Subject: Integrated: 8248876: LoadObject with bad base address created for
 exec file on linux
In-Reply-To: <R53sQGWiJHl8JzP_wmXoupayROl3DVu0l0rBCzYurWY=.4d6762e8-1de6-4b7d-805f-0a9b977950fb@github.com>
References: <R53sQGWiJHl8JzP_wmXoupayROl3DVu0l0rBCzYurWY=.4d6762e8-1de6-4b7d-805f-0a9b977950fb@github.com>
Message-ID: <CkVicqcGzvQ4QQcqaCY_vSumeSvfjPU70tqrCP7swsI=.aba175b5-9eae-4c1e-93df-b2555fdf6d31@github.com>

On Tue, 2 Feb 2021 23:37:21 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> We could see NPE on `LinuxCDebugger::loadObjectContainingPC` which is used mainly by the clhsdb `findpc` command. (See [JDK-8248876](https://bugs.openjdk.java.net/browse/JDK-8248876) for more details)
> 
> It is caused by PIE executable handling.
> 
> Currently we use virtual address of top of PT_LOAD in executable as base address - it is valid for ET_EXEC binary.
> However, in case of ET_DYN binary (PIE binary), we should handle it like a shared library.
> In GDB, base address of executable would be calculated by dynamic section. SA should also do so.

This pull request has now been integrated.

Changeset: 9d59dec2
Author:    Yasumasa Suenaga <ysuenaga at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9d59dec2
Stats:     19 lines in 2 files changed: 4 ins; 5 del; 10 mod

8248876: LoadObject with bad base address created for exec file on linux

Reviewed-by: cjplummer, kevinw

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

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

From cjplummer at openjdk.java.net  Mon Feb  8 02:37:44 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Mon, 8 Feb 2021 02:37:44 GMT
Subject: RFR: JDK-8261034: improve jcmd GC.class_histogram to support
 parallel [v7]
In-Reply-To: <Xckd1YLQAyNwBz8rnahiWYPmOfG0-3j5NcbiWk8tY0Y=.5e958bbf-e540-4c60-96ac-545ae61984e7@github.com>
References: <VKzVY-01CEXUbQdlKMhDWjtjxUgpxs_6487x232VsAI=.3b9c5d8a-972b-4997-9f75-1951f98e1751@github.com>
 <Xckd1YLQAyNwBz8rnahiWYPmOfG0-3j5NcbiWk8tY0Y=.5e958bbf-e540-4c60-96ac-545ae61984e7@github.com>
Message-ID: <0NVQ8qEgDIXUK2jJqk5_VR0mFqgpKtPNU41IR43HKxk=.3d9c9fcb-c76b-4f33-99be-bad65b7baf79@github.com>

On Sun, 7 Feb 2021 12:38:55 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> parallel -histo of jmap was added by JDK-8214535, it's better to support parallel for jcmd GC.class_histogram too.
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   improve jcmd GC.class_histogram to support parallel

Marked as reviewed by cjplummer (Reviewer).

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

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

From cjplummer at openjdk.java.net  Mon Feb  8 03:25:45 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Mon, 8 Feb 2021 03:25:45 GMT
Subject: RFR: 8257234 : Add gz option to SA jmap to write a gzipped heap
 dump [v16]
In-Reply-To: <OQD34blU9cPwSjWOMtUDQYdfOjPiuaul8dREIAuVWg4=.4dd63517-9383-4008-813f-a37ed58f018f@github.com>
References: <oTMRc7LWvx9_Uov01HPX9UgyEqFmXt_nMG920HUQBIM=.3651754b-e1f1-46f8-9f44-c118a5c56dbe@github.com>
 <OQD34blU9cPwSjWOMtUDQYdfOjPiuaul8dREIAuVWg4=.4dd63517-9383-4008-813f-a37ed58f018f@github.com>
Message-ID: <LOdgjgGrJDvT7jMn_Cu4cYXZ7XUXpD3EVYOK571GhE4=.bcdeb55c-fed3-4df3-bc04-077ef135a0f3@github.com>

On Sun, 7 Feb 2021 08:20:10 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> 8257234 : Add gz option to SA jmap to write a gzipped heap dump
>
> Lin Zang has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - add test in HeapDumpTest and fix in argument parsing
>  - revert changes in jcmd jmap
>    
>    Another PR has been created for jcmd jmap.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java line 1795:

> 1793:                      */
> 1794:                     if (cntTokens > 2) {
> 1795:                         err.println("Too big number of options: " + cntTokens);

"More than 2 options specified: "

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java line 1824:

> 1822:                             usage();
> 1823:                             return;
> 1824:                         }

I think having `if (cntTokens >= 1)` and `if (cntTokens == 2)` sections makes it harder to follow. Also, after calling parseHeapDumpCompressionLevel() you only need to check if 0 was returned. Otherwise you know it will be with the range of 1 to 9. I think the following might be easier to follow:
                    if (cntTokens == 1) { // first argument could be filename or "gz="
                        String option = t.nextToken();
                        if (!option.startsWith("gz=")) {
                            filename = option;
                        } else {
                            gzlevel = parseHeapDumpCompressionLevel(option);
                            if (gzlevel == 0) {
                                usage();
                                return;
                            }
                            filename = "heap.bin.gz";
                        }
                    }
                    if (cntTokens == 2) { // first argument is "gz=" followed by filename
                        gzlevel = parseHeapDumpCompressionLevel(option);
                        if (gzlevel == 0) {
                            usage();
                            return;
                        }
                        filename = t.nextToken();
                        if (filename.startsWith("gz=")) {
                            err.println("Filename should not start with "gz=": " + filename);
                            usage();
                            return;
                        }
                    }

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

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

From mli at openjdk.java.net  Mon Feb  8 04:22:41 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Mon, 8 Feb 2021 04:22:41 GMT
Subject: RFR: JDK-8261034: improve jcmd GC.class_histogram to support
 parallel [v7]
In-Reply-To: <0NVQ8qEgDIXUK2jJqk5_VR0mFqgpKtPNU41IR43HKxk=.3d9c9fcb-c76b-4f33-99be-bad65b7baf79@github.com>
References: <VKzVY-01CEXUbQdlKMhDWjtjxUgpxs_6487x232VsAI=.3b9c5d8a-972b-4997-9f75-1951f98e1751@github.com>
 <Xckd1YLQAyNwBz8rnahiWYPmOfG0-3j5NcbiWk8tY0Y=.5e958bbf-e540-4c60-96ac-545ae61984e7@github.com>
 <0NVQ8qEgDIXUK2jJqk5_VR0mFqgpKtPNU41IR43HKxk=.3d9c9fcb-c76b-4f33-99be-bad65b7baf79@github.com>
Message-ID: <x6OPolesx1m30-4eCJwb3UmN5SvifWMiueg2yTtq-DY=.4cd0e144-40c8-4c03-885d-05ff7b9eac28@github.com>

On Mon, 8 Feb 2021 02:35:17 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   improve jcmd GC.class_histogram to support parallel
>
> Marked as reviewed by cjplummer (Reviewer).

Hi Chris, Would you mind also help to review the related CSR https://bugs.openjdk.java.net/browse/JDK-8261105? Thanks

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

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

From lzang at openjdk.java.net  Mon Feb  8 08:05:09 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Mon, 8 Feb 2021 08:05:09 GMT
Subject: RFR: 8257234 : Add gz option to SA jmap to write a gzipped heap
 dump [v17]
In-Reply-To: <oTMRc7LWvx9_Uov01HPX9UgyEqFmXt_nMG920HUQBIM=.3651754b-e1f1-46f8-9f44-c118a5c56dbe@github.com>
References: <oTMRc7LWvx9_Uov01HPX9UgyEqFmXt_nMG920HUQBIM=.3651754b-e1f1-46f8-9f44-c118a5c56dbe@github.com>
Message-ID: <OyU95gqglqG8pz7Pm41XTslrHy-eN_TTx08AeDHHfcQ=.6f1111fc-5f54-42bf-9042-611d6f4f8fef@github.com>

> 8257234 : Add gz option to SA jmap to write a gzipped heap dump

Lin Zang has updated the pull request incrementally with one additional commit since the last revision:

  refine code for argument parsing

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1712/files
  - new: https://git.openjdk.java.net/jdk/pull/1712/files/8f38b974..d87a0270

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1712&range=16
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1712&range=15-16

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

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

From hseigel at openjdk.java.net  Mon Feb  8 13:22:43 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Mon, 8 Feb 2021 13:22:43 GMT
Subject: Integrated: 8261161: Clean up warnings in hotspot/jtreg/vmTestbase
 tests
In-Reply-To: <G2NyGRcvSDtF9Il0jYkZSNrkigmfFeschsStnaD42L4=.e5dc8ca5-d49b-4799-a6c9-5aa35e0ca7fd@github.com>
References: <G2NyGRcvSDtF9Il0jYkZSNrkigmfFeschsStnaD42L4=.e5dc8ca5-d49b-4799-a6c9-5aa35e0ca7fd@github.com>
Message-ID: <lkiFEh0mM5NLqI3ujTurxrq5kRiy5s2kD_CF25gKVT8=.23c76bee-ea61-44f2-b8cd-7af9fff1dba2@github.com>

On Fri, 5 Feb 2021 14:48:25 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this change to clean up warnings, such as the following, in the vmTestbase tests.  
> 
> warning: [synchronization] attempt to synchronize on an instance of a value-based class 
> warning: [removal] Integer(int) in Integer has been deprecated and marked for removal
> 
> This change cleans up the warnings by using a non-value based class to synchronize on, and replacing calls such as Integer(int) with Integer.valueOf(int).
> 
> The change was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-8 on Linux x64.
> 
> Thanks, Harold

This pull request has now been integrated.

Changeset: db0ca2b9
Author:    Harold Seigel <hseigel at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/db0ca2b9
Stats:     747 lines in 129 files changed: 2 ins; 0 del; 745 mod

8261161: Clean up warnings in hotspot/jtreg/vmTestbase tests

Reviewed-by: lfoltan, coleenp

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

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

From hseigel at openjdk.java.net  Mon Feb  8 13:22:42 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Mon, 8 Feb 2021 13:22:42 GMT
Subject: RFR: 8261161: Clean up warnings in hotspot/jtreg/vmTestbase tests
In-Reply-To: <1KH2oh0e-Qi8fsB4oxmJPN4AIdvEU2gYlhdGVZoPyjg=.1c2e2036-1fff-4ec5-97e4-616987dd7864@github.com>
References: <G2NyGRcvSDtF9Il0jYkZSNrkigmfFeschsStnaD42L4=.e5dc8ca5-d49b-4799-a6c9-5aa35e0ca7fd@github.com>
 <1KH2oh0e-Qi8fsB4oxmJPN4AIdvEU2gYlhdGVZoPyjg=.1c2e2036-1fff-4ec5-97e4-616987dd7864@github.com>
Message-ID: <x3G8RStW3H6XAPmX311IU2P6wfF8rwkcHJecpyAQpHc=.b09c9e8a-2017-4a17-baf8-a0129df01991@github.com>

On Fri, 5 Feb 2021 16:53:00 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this change to clean up warnings, such as the following, in the vmTestbase tests.  
>> 
>> warning: [synchronization] attempt to synchronize on an instance of a value-based class 
>> warning: [removal] Integer(int) in Integer has been deprecated and marked for removal
>> 
>> This change cleans up the warnings by using a non-value based class to synchronize on, and replacing calls such as Integer(int) with Integer.valueOf(int).
>> 
>> The change was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-8 on Linux x64.
>> 
>> Thanks, Harold
>
> Wow. thank you!

Thanks Lois and Coleen for the reviews!

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

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

From alanb at openjdk.java.net  Mon Feb  8 14:06:55 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 8 Feb 2021 14:06:55 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo [v8]
In-Reply-To: <KcO_olP0uhrkPxSvala6b0MN3zsFy0_Skl06Oq6Gla0=.398341c8-a9c6-4186-ab43-df19bec9d544@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <KcO_olP0uhrkPxSvala6b0MN3zsFy0_Skl06Oq6Gla0=.398341c8-a9c6-4186-ab43-df19bec9d544@github.com>
Message-ID: <BjeBGs7wE7XNdWCI-kZPfaiQqWgrnV9u8i7VdpZXvRU=.812757b3-3920-48f5-844b-7017e1d94df7@github.com>

On Mon, 21 Dec 2020 09:16:11 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> 8080272  Refactor I/O stream copying to use java.io.InputStream.transferTo
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
>   revert changes in Apache Santuario

src/java.management/share/classes/javax/management/loading/MLet.java line 1147:

> 1145:                                       .toFile();
> 1146:                      file.deleteOnExit();
> 1147:                      Files.copy(is, file.toPath());

One thing to check here is the existing behavior when the file already exists (as Files.copy will fail if the file exists, need to specify REPLACE_EXISTING to get the semantics of the existing code).

The code that follows checks if the file exists, this will always be true when Files.copy succeeds.

src/java.base/share/classes/sun/net/www/MimeLauncher.java line 2:

> 1: /*
> 2:  * Copyright (c) 1994, 2020, Oracle and/or its affiliates. All rights reserved.

Is MimeEntry.launch still used? I'm wondering if the MimeLauncher can be deleted.

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

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

From weijun at openjdk.java.net  Mon Feb  8 14:42:44 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 8 Feb 2021 14:42:44 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo [v8]
In-Reply-To: <KcO_olP0uhrkPxSvala6b0MN3zsFy0_Skl06Oq6Gla0=.398341c8-a9c6-4186-ab43-df19bec9d544@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <KcO_olP0uhrkPxSvala6b0MN3zsFy0_Skl06Oq6Gla0=.398341c8-a9c6-4186-ab43-df19bec9d544@github.com>
Message-ID: <cONOB0wrdWjjltXXAuaH_SYz_ay7AgllB3SN64c8K_I=.d711bc68-c800-45fd-9de5-5bd1c5621430@github.com>

On Mon, 21 Dec 2020 09:16:11 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> 8080272  Refactor I/O stream copying to use java.io.InputStream.transferTo
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
>   revert changes in Apache Santuario

The other security-related code changes look good to me.

src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/Utils.java line 49:

> 47:         throws IOException
> 48:     {
> 49:         return is.readAllBytes();

This is also from Apache Santuario. It's better to keep it unchanged.

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

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

From jboes at openjdk.java.net  Mon Feb  8 16:21:56 2021
From: jboes at openjdk.java.net (Julia Boes)
Date: Mon, 8 Feb 2021 16:21:56 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo [v7]
In-Reply-To: <PncFUlxLFmz5-8oLVuhmy3aRoi6dM3FVbLLHhWWYdvA=.5693ccd6-7e39-4118-9d86-3d05a0597d31@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <PncFUlxLFmz5-8oLVuhmy3aRoi6dM3FVbLLHhWWYdvA=.5693ccd6-7e39-4118-9d86-3d05a0597d31@github.com>
Message-ID: <JJEyunSQDMsmXDFNw9SV1U_-BIBx3cP1LXyPalKKrjU=.a199c063-bd12-4772-a1dc-4f362d80c58c@github.com>

On Mon, 21 Dec 2020 08:19:08 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> 8080272  Refactor I/O stream copying to use java.io.InputStream.transferTo
>
> Andrey Turbanov 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/java.base/share/classes/sun/security/provider/certpath/X509CertPath.java line 29:

> 27: 
> 28: import java.io.ByteArrayInputStream;
> 29: import java.io.IOException;

The copyright year needs to be updated for this file and changed to 2021 in the other files where applicable.

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

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

From jboes at openjdk.java.net  Mon Feb  8 16:42:42 2021
From: jboes at openjdk.java.net (Julia Boes)
Date: Mon, 8 Feb 2021 16:42:42 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo [v8]
In-Reply-To: <cONOB0wrdWjjltXXAuaH_SYz_ay7AgllB3SN64c8K_I=.d711bc68-c800-45fd-9de5-5bd1c5621430@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <KcO_olP0uhrkPxSvala6b0MN3zsFy0_Skl06Oq6Gla0=.398341c8-a9c6-4186-ab43-df19bec9d544@github.com>
 <cONOB0wrdWjjltXXAuaH_SYz_ay7AgllB3SN64c8K_I=.d711bc68-c800-45fd-9de5-5bd1c5621430@github.com>
Message-ID: <SNPiblXpzCPdmntADzdMMqFCO6eSjKOltzwD5MWnipc=.814578a6-ea9b-40b1-bfd8-199324b7281e@github.com>

On Mon, 8 Feb 2021 14:40:16 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
>>   revert changes in Apache Santuario
>
> The other security-related code changes look good to me.

I've updated the issue summary to better reflect the changes, the PR summary should be renamed accordingly. 
As mentioned earlier, have you run the tests for the affected areas? Here's some information on how to do that: http://openjdk.java.net/guide/#testing-the-jdk

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

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

From kevinw at openjdk.java.net  Mon Feb  8 18:52:41 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Mon, 8 Feb 2021 18:52:41 GMT
Subject: RFR: 8248876: LoadObject with bad base address created for exec
 file on linux [v2]
In-Reply-To: <49zneDLw_YfcFnLRNd9O_m-pRQ5EXbfIfyrpZy-VKTk=.2ec794e3-b1df-40ef-9097-55030bee39bc@github.com>
References: <R53sQGWiJHl8JzP_wmXoupayROl3DVu0l0rBCzYurWY=.4d6762e8-1de6-4b7d-805f-0a9b977950fb@github.com>
 <Jahs5DE3ENM9yMQuvEJylgpcDHlQUMYwljz8nIDmJ8s=.f6f33839-5aea-4964-a472-0c9bbee6bc68@github.com>
 <49zneDLw_YfcFnLRNd9O_m-pRQ5EXbfIfyrpZy-VKTk=.2ec794e3-b1df-40ef-9097-55030bee39bc@github.com>
Message-ID: <DrAsRkTNXEbe_W0ag086Ov4a9RG_i1016BnTVmCVOgs=.8c31fbe4-d43f-4a51-b07d-884410045465@github.com>

On Sun, 7 Feb 2021 02:21:47 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> Looks good, I made a suggestions elsewhere in the PR about the comments at line 510...
>
> @kevinjwalls Thank you for the comment!
> 
>> I found the "svr4_exec_displacement() in GDB" more confusing than informative, maybe this is the same technique GDB uses... But I followed our dynamic_addr setting and agree with the new changes.
> 
> I removed it in new commit.
> 
>> An alternative comment could be this, which would also removes the "substract" typo (which was not yours!):
> 
> It's my change in [JDK-8173941](https://bugs.openjdk.java.net/browse/JDK-8173941).
> I removed it too.

Oops, I didn't mean to suggest  the comment should go entirely.  It's actually very useful to say something here, as the way we use the dynamic field, setting it then fixing it up.
Is it possible to re-add the comment in a new change?

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

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

From hseigel at openjdk.java.net  Mon Feb  8 19:58:49 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Mon, 8 Feb 2021 19:58:49 GMT
Subject: RFR: 8261340: Fix 'deprecated' warnings in the vmTestbase/nsk tests
Message-ID: <aqxiaaZnSvYQGNcw7B2ybqLLT5HJ-EKoVE3-8Jxb5h8=.a529ba2d-2ee0-48d6-93cd-633bc26925fd@github.com>

Please review this small fix for JDK-8261340 to clean up deprecation warnings, such as the following, in the vmTestbase/nsk tests.

    warning: [dep-ann] deprecated item is not annotated with @Deprecated

The change was tested by running the tests locally and checking for the warnings.  It was regression tested with tiers 1-2 on Linux, Mac OS, and Windows and tiers 3-5 on Linux x64.

Thanks, Harold

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

Commit messages:
 - 8261340: Fix 'deprecated' warnings in the vmTestbase/nsk tests

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

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

From github.com+741251+turbanoff at openjdk.java.net  Mon Feb  8 20:50:41 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 8 Feb 2021 20:50:41 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo [v8]
In-Reply-To: <BjeBGs7wE7XNdWCI-kZPfaiQqWgrnV9u8i7VdpZXvRU=.812757b3-3920-48f5-844b-7017e1d94df7@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <KcO_olP0uhrkPxSvala6b0MN3zsFy0_Skl06Oq6Gla0=.398341c8-a9c6-4186-ab43-df19bec9d544@github.com>
 <BjeBGs7wE7XNdWCI-kZPfaiQqWgrnV9u8i7VdpZXvRU=.812757b3-3920-48f5-844b-7017e1d94df7@github.com>
Message-ID: <BdQsbXFMxgTxyaKoAeQOdJ-52AnWCrUUUmKQe_ilUaY=.74983229-9463-43a0-ac22-8ae2c48ca0fe@github.com>

On Mon, 8 Feb 2021 14:01:34 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
>>   revert changes in Apache Santuario
>
> src/java.management/share/classes/javax/management/loading/MLet.java line 1147:
> 
>> 1145:                                       .toFile();
>> 1146:                      file.deleteOnExit();
>> 1147:                      Files.copy(is, file.toPath());
> 
> One thing to check here is the existing behavior when the file already exists (as Files.copy will fail if the file exists, need to specify REPLACE_EXISTING to get the semantics of the existing code).
> 
> The code that follows checks if the file exists, this will always be true when Files.copy succeeds.

fixed

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

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

From github.com+741251+turbanoff at openjdk.java.net  Mon Feb  8 20:54:47 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 8 Feb 2021 20:54:47 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v7]
In-Reply-To: <JJEyunSQDMsmXDFNw9SV1U_-BIBx3cP1LXyPalKKrjU=.a199c063-bd12-4772-a1dc-4f362d80c58c@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <PncFUlxLFmz5-8oLVuhmy3aRoi6dM3FVbLLHhWWYdvA=.5693ccd6-7e39-4118-9d86-3d05a0597d31@github.com>
 <JJEyunSQDMsmXDFNw9SV1U_-BIBx3cP1LXyPalKKrjU=.a199c063-bd12-4772-a1dc-4f362d80c58c@github.com>
Message-ID: <NDGqsqvKpgvsi0OCV7briRodMEnNwFVseA72F4zbCG0=.5c9554cb-5116-4467-82dd-d919ed4fe5f3@github.com>

On Mon, 8 Feb 2021 16:19:17 GMT, Julia Boes <jboes at openjdk.org> wrote:

>> Andrey Turbanov 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/java.base/share/classes/sun/security/provider/certpath/X509CertPath.java line 29:
> 
>> 27: 
>> 28: import java.io.ByteArrayInputStream;
>> 29: import java.io.IOException;
> 
> The copyright year needs to be updated for this file and changed to 2021 in the other files where applicable.

done

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

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

From github.com+741251+turbanoff at openjdk.java.net  Mon Feb  8 20:54:48 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 8 Feb 2021 20:54:48 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v8]
In-Reply-To: <cONOB0wrdWjjltXXAuaH_SYz_ay7AgllB3SN64c8K_I=.d711bc68-c800-45fd-9de5-5bd1c5621430@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <KcO_olP0uhrkPxSvala6b0MN3zsFy0_Skl06Oq6Gla0=.398341c8-a9c6-4186-ab43-df19bec9d544@github.com>
 <cONOB0wrdWjjltXXAuaH_SYz_ay7AgllB3SN64c8K_I=.d711bc68-c800-45fd-9de5-5bd1c5621430@github.com>
Message-ID: <xIcOD_gjq-dnpKfNpMGm13Uax_5YLkZtatTYWgtBpGc=.78ab950f-b902-4dee-8545-9d0574d75cef@github.com>

On Mon, 8 Feb 2021 14:38:52 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
>>   revert changes in Apache Santuario
>
> src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/Utils.java line 49:
> 
>> 47:         throws IOException
>> 48:     {
>> 49:         return is.readAllBytes();
> 
> This is also from Apache Santuario. It's better to keep it unchanged.

reverted

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

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

From github.com+741251+turbanoff at openjdk.java.net  Mon Feb  8 20:58:01 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 8 Feb 2021 20:58:01 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v9]
In-Reply-To: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
Message-ID: <oyAwqFESfH7q3wJicuQNF0Hds0Sp69dN5bzxYAIBaOQ=.df45bf24-3f70-457d-9df9-8a5b3022f1e1@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 java.io.InputStream.transferTo
  fix review comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1853/files
  - new: https://git.openjdk.java.net/jdk/pull/1853/files/94e99817..6a8a3ae6

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

  Stats: 29 lines in 10 files changed: 16 ins; 0 del; 13 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 lfoltan at openjdk.java.net  Mon Feb  8 21:01:41 2021
From: lfoltan at openjdk.java.net (Lois Foltan)
Date: Mon, 8 Feb 2021 21:01:41 GMT
Subject: RFR: 8261340: Fix 'deprecated' warnings in the vmTestbase/nsk
 tests
In-Reply-To: <aqxiaaZnSvYQGNcw7B2ybqLLT5HJ-EKoVE3-8Jxb5h8=.a529ba2d-2ee0-48d6-93cd-633bc26925fd@github.com>
References: <aqxiaaZnSvYQGNcw7B2ybqLLT5HJ-EKoVE3-8Jxb5h8=.a529ba2d-2ee0-48d6-93cd-633bc26925fd@github.com>
Message-ID: <gSbL9-2VQhLGjqo7Q0uCp22NCCASCcwNVCV12u-f5ag=.d816d486-2539-468a-8934-92fa044908c5@github.com>

On Mon, 8 Feb 2021 19:54:03 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this small fix for JDK-8261340 to clean up deprecation warnings, such as the following, in the vmTestbase/nsk tests.
> 
>     warning: [dep-ann] deprecated item is not annotated with @Deprecated
> 
> The change was tested by running the tests locally and checking for the warnings.  It was regression tested with tiers 1-2 on Linux, Mac OS, and Windows and tiers 3-5 on Linux x64.
> 
> Thanks, Harold

Looks good!
Lois

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

Marked as reviewed by lfoltan (Reviewer).

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

From github.com+471021+marschall at openjdk.java.net  Mon Feb  8 21:21:44 2021
From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall)
Date: Mon, 8 Feb 2021 21:21:44 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v9]
In-Reply-To: <oyAwqFESfH7q3wJicuQNF0Hds0Sp69dN5bzxYAIBaOQ=.df45bf24-3f70-457d-9df9-8a5b3022f1e1@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <oyAwqFESfH7q3wJicuQNF0Hds0Sp69dN5bzxYAIBaOQ=.df45bf24-3f70-457d-9df9-8a5b3022f1e1@github.com>
Message-ID: <WtXQ3xGo_psAegHONwjHWSSdAGsvsW9yN6eXAGL8Sbc=.c5c0ef89-24c9-428d-a86d-71db7437d6d3@github.com>

On Mon, 8 Feb 2021 20:58:01 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
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
>   fix review comments

src/java.base/share/classes/sun/security/provider/certpath/X509CertPath.java line 230:

> 228:                 // Copy the entire input stream into an InputStream that does
> 229:                 // support mark
> 230:                 is = new ByteArrayInputStream(is.readAllBytes());

I don't understand why the check for #markSupported is done there. The InputStream constructor of PKCS7 creates a DataInputStream on the InputStream only to then call #readFully. I can't find a place where a call to #mark happens. Since the InputStream constructor reads all bytes anyway I wonder whether we could remove this if and unconditionally do:

PKCS7 pkcs7 = new PKCS7(is.readAllBytes());

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

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

From cjplummer at openjdk.java.net  Mon Feb  8 22:05:48 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Mon, 8 Feb 2021 22:05:48 GMT
Subject: RFR: 8257234 : Add gz option to SA jmap to write a gzipped heap
 dump [v17]
In-Reply-To: <OyU95gqglqG8pz7Pm41XTslrHy-eN_TTx08AeDHHfcQ=.6f1111fc-5f54-42bf-9042-611d6f4f8fef@github.com>
References: <oTMRc7LWvx9_Uov01HPX9UgyEqFmXt_nMG920HUQBIM=.3651754b-e1f1-46f8-9f44-c118a5c56dbe@github.com>
 <OyU95gqglqG8pz7Pm41XTslrHy-eN_TTx08AeDHHfcQ=.6f1111fc-5f54-42bf-9042-611d6f4f8fef@github.com>
Message-ID: <euAzwDgKrfHEMNDEx71v-JOmBQXcqp-drHei171Wdpc=.6b831e2a-b86d-4910-b044-0e04fa438c8e@github.com>

On Mon, 8 Feb 2021 08:05:09 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> 8257234 : Add gz option to SA jmap to write a gzipped heap dump
>
> Lin Zang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   refine code for argument parsing

Marked as reviewed by cjplummer (Reviewer).

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

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

From lzang at openjdk.java.net  Tue Feb  9 02:41:44 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Tue, 9 Feb 2021 02:41:44 GMT
Subject: RFR: 8257234 : Add gz option to SA jmap to write a gzipped heap
 dump [v17]
In-Reply-To: <euAzwDgKrfHEMNDEx71v-JOmBQXcqp-drHei171Wdpc=.6b831e2a-b86d-4910-b044-0e04fa438c8e@github.com>
References: <oTMRc7LWvx9_Uov01HPX9UgyEqFmXt_nMG920HUQBIM=.3651754b-e1f1-46f8-9f44-c118a5c56dbe@github.com>
 <OyU95gqglqG8pz7Pm41XTslrHy-eN_TTx08AeDHHfcQ=.6f1111fc-5f54-42bf-9042-611d6f4f8fef@github.com>
 <euAzwDgKrfHEMNDEx71v-JOmBQXcqp-drHei171Wdpc=.6b831e2a-b86d-4910-b044-0e04fa438c8e@github.com>
Message-ID: <5LiT1HyqIxOjUMoeqsJlwNA1oHcNempuh4SU_E5NQCE=.40d52a18-d95b-44e4-b198-d29e939dcf15@github.com>

On Mon, 8 Feb 2021 22:03:18 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Lin Zang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   refine code for argument parsing
>
> Marked as reviewed by cjplummer (Reviewer).

Thanks @plummercj @sspitsyn @YaSuenag  a lot for helping review this PR again and again! 
I have marked it as ready for push.

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

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

From sspitsyn at openjdk.java.net  Tue Feb  9 04:30:44 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Tue, 9 Feb 2021 04:30:44 GMT
Subject: RFR: 8257234 : Add gz option to SA jmap to write a gzipped heap
 dump [v17]
In-Reply-To: <5LiT1HyqIxOjUMoeqsJlwNA1oHcNempuh4SU_E5NQCE=.40d52a18-d95b-44e4-b198-d29e939dcf15@github.com>
References: <oTMRc7LWvx9_Uov01HPX9UgyEqFmXt_nMG920HUQBIM=.3651754b-e1f1-46f8-9f44-c118a5c56dbe@github.com>
 <OyU95gqglqG8pz7Pm41XTslrHy-eN_TTx08AeDHHfcQ=.6f1111fc-5f54-42bf-9042-611d6f4f8fef@github.com>
 <euAzwDgKrfHEMNDEx71v-JOmBQXcqp-drHei171Wdpc=.6b831e2a-b86d-4910-b044-0e04fa438c8e@github.com>
 <5LiT1HyqIxOjUMoeqsJlwNA1oHcNempuh4SU_E5NQCE=.40d52a18-d95b-44e4-b198-d29e939dcf15@github.com>
Message-ID: <4N4qR6vCqhGGGNJTP9UVMxJdwUy1L-n5K4iuhw8ryWE=.8e674408-ed21-4f4f-b809-727cd04e642a@github.com>

On Tue, 9 Feb 2021 02:38:44 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> Marked as reviewed by cjplummer (Reviewer).
>
> Thanks @plummercj @sspitsyn @YaSuenag  a lot for helping review this PR again and again! 
> I have marked it as ready for push.

Hi Lin,

Sorry for confusing you but I've not noticed a duplication in your code:

1778                 if (cntTokens > 2) {
1779                     usage();
1780                 } else {
1781                     JMap jmap = new JMap();
1782                     String filename = "heap.bin";
1783                     int gzlevel = 0;
 . . . . 
1794                     if (cntTokens > 2) {
1795                         err.println("More than 2 options specified: " + cntTokens);
1796                         usage();
1797                         return;
1798                     }
1799                     if (cntTokens == 1) { // first argument could be filename or "gz="
                             . . . .

There are two checks for cntTokens > 2. The second check has to be removed.
Also, a return needs to be added after the line 1779 with "usage();" , so the "else" statement can be removed.
This has to be refactored to something like this:
1778                 if (cntTokens > 2) {
                             err.println("More than 2 options specified: " + cntTokens);
1779                     usage();
                             return;
1780                 }
1781                 JMap jmap = new JMap();
1782                 String filename = "heap.bin";
1783                 int gzlevel = 0;
1799                 if (cntTokens == 1) { // first argument could be filename or "gz="
                         . . . .

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

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

From sspitsyn at openjdk.java.net  Tue Feb  9 04:39:55 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Tue, 9 Feb 2021 04:39:55 GMT
Subject: RFR: 8261340: Fix 'deprecated' warnings in the vmTestbase/nsk
 tests
In-Reply-To: <aqxiaaZnSvYQGNcw7B2ybqLLT5HJ-EKoVE3-8Jxb5h8=.a529ba2d-2ee0-48d6-93cd-633bc26925fd@github.com>
References: <aqxiaaZnSvYQGNcw7B2ybqLLT5HJ-EKoVE3-8Jxb5h8=.a529ba2d-2ee0-48d6-93cd-633bc26925fd@github.com>
Message-ID: <EhdtHVB55NODXnSl6KQhobbrC4Ox-miCf_xOQ1WtKbU=.1becf6e1-8708-4eea-a5d9-ad0c50eab680@github.com>

On Mon, 8 Feb 2021 19:54:03 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this small fix for JDK-8261340 to clean up deprecation warnings, such as the following, in the vmTestbase/nsk tests.
> 
>     warning: [dep-ann] deprecated item is not annotated with @Deprecated
> 
> The change was tested by running the tests locally and checking for the warnings.  It was regression tested with tiers 1-2 on Linux, Mac OS, and Windows and tiers 3-5 on Linux x64.
> 
> Thanks, Harold

LGTM++

Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

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

From sspitsyn at openjdk.java.net  Tue Feb  9 05:39:40 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Tue, 9 Feb 2021 05:39:40 GMT
Subject: RFR: 8248162:
 serviceability/attach/RemovingUnixDomainSocketTest.java failed
In-Reply-To: <mw3-hXbMOC5XQQyQX5ySpBaWT3kEck9diGpIi_q1fJ0=.a82d3ce3-0cc5-40fa-9b43-99c7f5d090e2@github.com>
References: <mw3-hXbMOC5XQQyQX5ySpBaWT3kEck9diGpIi_q1fJ0=.a82d3ce3-0cc5-40fa-9b43-99c7f5d090e2@github.com>
Message-ID: <byqUW2ajg5NqAURgeA2r_eDJEitYpig_EgxrVZFWz-U=.9d635418-3d1b-4f3d-99ec-a58dcd5d03cc@github.com>

On Fri, 5 Feb 2021 21:09:37 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> JDK-8258917 fixed non-java launchers ("wrong launcher" VM warning for tools).
> The fix un-problemlists RemovingUnixDomainSocketTest and changes serviceability tests to use OutputAnalyzer.stderrShouldBeEmptyIgnoreDeprecatedWarnings instead of stderrShouldBeEmptyIgnoreVMWarnings

The fix looks good to me.
I don't have good ideas how to tests it better than Alex did.
I'm not sure, we need to care about hidden warnings other than the NMT-related.

Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

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

From sspitsyn at openjdk.java.net  Tue Feb  9 05:52:44 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Tue, 9 Feb 2021 05:52:44 GMT
Subject: RFR: 8261131: jcmd jmap dump should not accept gz option with no
 value [v3]
In-Reply-To: <_wOxIScREVJ2249eVGInbc9G8hiihHCU110IgLDUFBo=.7b656721-b847-420d-b8f8-e7298cc4f5ba@github.com>
References: <qUp1tOUkdsvzPGH03MyAhSokYQUUYm9xz-2X6GjsSC4=.21007ed7-65f7-4768-a2f8-e7d2ac2533f6@github.com>
 <_wOxIScREVJ2249eVGInbc9G8hiihHCU110IgLDUFBo=.7b656721-b847-420d-b8f8-e7298cc4f5ba@github.com>
Message-ID: <oHPlWMiUzIcTABQ_br7GYLv9jTfz8Z0CjHzZxBYz-O8=.408ce287-7269-44fb-9a67-bb091ac603fe@github.com>

On Sun, 7 Feb 2021 08:31:10 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> 8261131: jcmd jmap dump should not accept gz option with no value
>
> 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 three additional commits since the last revision:
> 
>  - Merge branch 'master' into gz-fix
>  - remove useless code and update copyright
>  - 8261131: jcmd jmap dump should not accept gz option with no value

Hi Lin,
The fix looks good to me.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

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

From sspitsyn at openjdk.java.net  Tue Feb  9 06:23:41 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Tue, 9 Feb 2021 06:23:41 GMT
Subject: RFR: JDK-8261034: improve jcmd GC.class_histogram to support
 parallel [v7]
In-Reply-To: <Xckd1YLQAyNwBz8rnahiWYPmOfG0-3j5NcbiWk8tY0Y=.5e958bbf-e540-4c60-96ac-545ae61984e7@github.com>
References: <VKzVY-01CEXUbQdlKMhDWjtjxUgpxs_6487x232VsAI=.3b9c5d8a-972b-4997-9f75-1951f98e1751@github.com>
 <Xckd1YLQAyNwBz8rnahiWYPmOfG0-3j5NcbiWk8tY0Y=.5e958bbf-e540-4c60-96ac-545ae61984e7@github.com>
Message-ID: <Ws825_y4Z7ohk7X740wi-Nzlgh4tDIclwJe_YYKhyHw=.de4aa09a-983d-43d4-8bb5-149ba4307740@github.com>

On Sun, 7 Feb 2021 12:38:55 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> parallel -histo of jmap was added by JDK-8214535, it's better to support parallel for jcmd GC.class_histogram too.
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   improve jcmd GC.class_histogram to support parallel

Hi @Hamlin-Li,

It looks good in general.
A question: What is going to happen if the number of parallel threads passed to the command is too big? Is there any limit, and what has to be the expected behavior in such a case? I'll look at the CSR.
Thanks,
Serguei

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

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

From lzang at openjdk.java.net  Tue Feb  9 06:36:05 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Tue, 9 Feb 2021 06:36:05 GMT
Subject: RFR: 8257234 : Add gz option to SA jmap to write a gzipped heap
 dump [v18]
In-Reply-To: <oTMRc7LWvx9_Uov01HPX9UgyEqFmXt_nMG920HUQBIM=.3651754b-e1f1-46f8-9f44-c118a5c56dbe@github.com>
References: <oTMRc7LWvx9_Uov01HPX9UgyEqFmXt_nMG920HUQBIM=.3651754b-e1f1-46f8-9f44-c118a5c56dbe@github.com>
Message-ID: <pTCNCLk1LNq2sH8GKW0nl4BKEaZ3dPGqwxZhb7FuK6c=.a57b5141-14c7-499c-94ed-e39ca1a4697b@github.com>

> 8257234 : Add gz option to SA jmap to write a gzipped heap dump

Lin Zang has updated the pull request incrementally with one additional commit since the last revision:

  remove redundant check

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1712/files
  - new: https://git.openjdk.java.net/jdk/pull/1712/files/d87a0270..47d93a9d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1712&range=17
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1712&range=16-17

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

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

From ysuenaga at openjdk.java.net  Tue Feb  9 07:38:40 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Tue, 9 Feb 2021 07:38:40 GMT
Subject: RFR: 8248876: LoadObject with bad base address created for exec
 file on linux [v2]
In-Reply-To: <DrAsRkTNXEbe_W0ag086Ov4a9RG_i1016BnTVmCVOgs=.8c31fbe4-d43f-4a51-b07d-884410045465@github.com>
References: <R53sQGWiJHl8JzP_wmXoupayROl3DVu0l0rBCzYurWY=.4d6762e8-1de6-4b7d-805f-0a9b977950fb@github.com>
 <Jahs5DE3ENM9yMQuvEJylgpcDHlQUMYwljz8nIDmJ8s=.f6f33839-5aea-4964-a472-0c9bbee6bc68@github.com>
 <49zneDLw_YfcFnLRNd9O_m-pRQ5EXbfIfyrpZy-VKTk=.2ec794e3-b1df-40ef-9097-55030bee39bc@github.com>
 <DrAsRkTNXEbe_W0ag086Ov4a9RG_i1016BnTVmCVOgs=.8c31fbe4-d43f-4a51-b07d-884410045465@github.com>
Message-ID: <ro6clOBejJTDLgrObY4FxZw7leGWP4BXOguhRrtjcqU=.8ea6286d-6a74-425b-884d-5d588e7d57a4@github.com>

On Mon, 8 Feb 2021 18:49:51 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Oops, I didn't mean to suggest the comment should go entirely. It's actually very useful to say something here, as the way we use the dynamic field, setting it then fixing it up.
> Is it possible to re-add the comment in a new change?

I thought your thumbs-up emoji means to agree to remove all comments.

As you know, I've integrated this PR, so we need to file as a new ticket.
I will do it and send a PR with following patch if you are ok.

diff --git a/src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c b/src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c
index dff4cb3eeca..9f7c4050ef2 100644
--- a/src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c
+++ b/src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c
@@ -507,7 +507,11 @@ static uintptr_t read_exec_segments(struct ps_prochandle* ph, ELF_EHDR* exec_ehd
         result = exec_php->p_vaddr;
         ph->core->dynamic_addr = exec_php->p_vaddr;
       } else { // ET_DYN
+        // Base address of executable is based on entry point (AT_ENTRY).
         result = ph->core->dynamic_addr - exec_ehdr->e_entry;
+
+        // dynamic_addr has entry point of executable.
+        // Thus we should subtract it.
         ph->core->dynamic_addr += exec_php->p_vaddr - exec_ehdr->e_entry;
       }
       print_debug("address of _DYNAMIC is 0x%lx\n", ph->core->dynamic_addr);

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

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

From mli at openjdk.java.net  Tue Feb  9 07:59:41 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Tue, 9 Feb 2021 07:59:41 GMT
Subject: RFR: JDK-8261034: improve jcmd GC.class_histogram to support
 parallel
In-Reply-To: <VKzVY-01CEXUbQdlKMhDWjtjxUgpxs_6487x232VsAI=.3b9c5d8a-972b-4997-9f75-1951f98e1751@github.com>
References: <VKzVY-01CEXUbQdlKMhDWjtjxUgpxs_6487x232VsAI=.3b9c5d8a-972b-4997-9f75-1951f98e1751@github.com>
Message-ID: <X_7cTwpI8cxsVTCMi6oe6f1Fy6yPcw7b0-Pa-Ayou2Y=.69cba9c8-f6e4-40b4-a180-3eb79428692b@github.com>

On Wed, 3 Feb 2021 12:44:53 GMT, Hamlin Li <mli at openjdk.org> wrote:

> parallel -histo of jmap was added by JDK-8214535, it's better to support parallel for jcmd GC.class_histogram too.

> Hi @Hamlin-Li,
> 
> It looks good in general.
> A question: What is going to happen if the number of parallel threads passed to the command is too big? Is there any limit, and what has to be the expected behavior in such a case? I'll look at the CSR.
> Thanks,
> Serguei

Hi Serguer,
Thanks for reviewing.
First, it got truncated as uint by ClassHistogramDCmd, then it got capped by by total_workers of gang, so finally it will not exceed total_workers.
Hope this answer your questions.

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

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

From sspitsyn at openjdk.java.net  Tue Feb  9 08:31:48 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Tue, 9 Feb 2021 08:31:48 GMT
Subject: RFR: 8257234 : Add gz option to SA jmap to write a gzipped heap
 dump [v17]
In-Reply-To: <OhbiKBiRfed_IG5wvnbCNpx24WLDSHXxu7X_rM99GzM=.c63f67c6-c10e-4ee4-b4a0-062150a708d6@github.com>
References: <oTMRc7LWvx9_Uov01HPX9UgyEqFmXt_nMG920HUQBIM=.3651754b-e1f1-46f8-9f44-c118a5c56dbe@github.com>
 <OyU95gqglqG8pz7Pm41XTslrHy-eN_TTx08AeDHHfcQ=.6f1111fc-5f54-42bf-9042-611d6f4f8fef@github.com>
 <euAzwDgKrfHEMNDEx71v-JOmBQXcqp-drHei171Wdpc=.6b831e2a-b86d-4910-b044-0e04fa438c8e@github.com>
 <5LiT1HyqIxOjUMoeqsJlwNA1oHcNempuh4SU_E5NQCE=.40d52a18-d95b-44e4-b198-d29e939dcf15@github.com>
 <4N4qR6vCqhGGGNJTP9UVMxJdwUy1L-n5K4iuhw8ryWE=.8e674408-ed21-4f4f-b809-727cd04e642a@github.com>
 <OhbiKBiRfed_IG5wvnbCNpx24WLDSHXxu7X_rM99GzM=.c63f67c6-c10e-4ee4-b4a0-062150a708d6@github.com>
Message-ID: <ix-Gp7c5EkNhLnWbMfV9kRF6dpehHCBeDDHGxeNB1YQ=.8ed6d745-20d7-4f58-a8ff-613a02604a5d@github.com>

On Tue, 9 Feb 2021 06:37:21 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> Hi Lin,
>> 
>> Sorry for confusing you but I've not noticed a duplication in your code:
>> 
>> 1778                 if (cntTokens > 2) {
>> 1779                     usage();
>> 1780                 } else {
>> 1781                     JMap jmap = new JMap();
>> 1782                     String filename = "heap.bin";
>> 1783                     int gzlevel = 0;
>>  . . . . 
>> 1794                     if (cntTokens > 2) {
>> 1795                         err.println("More than 2 options specified: " + cntTokens);
>> 1796                         usage();
>> 1797                         return;
>> 1798                     }
>> 1799                     if (cntTokens == 1) { // first argument could be filename or "gz="
>>                              . . . .
>> 
>> There are two checks for cntTokens > 2. The second check has to be removed.
>> Also, a return needs to be added after the line 1779 with "usage();" , so the "else" statement can be removed.
>> This has to be refactored to something like this:
>> 1778                 if (cntTokens > 2) {
>>                              err.println("More than 2 options specified: " + cntTokens);
>> 1779                     usage();
>>                              return;
>> 1780                 }
>> 1781                 JMap jmap = new JMap();
>> 1782                 String filename = "heap.bin";
>> 1783                 int gzlevel = 0;
>> 1799                 if (cntTokens == 1) { // first argument could be filename or "gz="
>>                          . . . .
>> 
>> Thanks,
>> Serguei
>
> Dear Serguei,
> 
>> There are two checks for cntTokens > 2. The second check has to be removed.
>> Also, a return needs to be added after the line 1779 with "usage();" , so the "else" statement can be removed.
>> This has to be refactored to something like this:
> 
> Nice catch and good suggestion. Thanks a lot for point it out!
> I think It is no hurry to push this PR, and welcome for any comment.
> Thanks!

Hi Lin,
Thank you for update.

test/lib/jdk/test/lib/hprof/parser/Reader.java:
+            } else if ((i >>> 8) == 0x1f8b08) {
+                // Possible gziped file.

Could you, please, define a named constant and use it instead of the literal value 0x1f8b08?
Also, would it make sense to extend the comment to explain about it a little bit?

I'm still looking at some files (e.g., HeapHprofBinWriter.java).

Thanks,
Serguei

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

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

From lzang at openjdk.java.net  Tue Feb  9 08:31:47 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Tue, 9 Feb 2021 08:31:47 GMT
Subject: RFR: 8257234 : Add gz option to SA jmap to write a gzipped heap
 dump [v17]
In-Reply-To: <4N4qR6vCqhGGGNJTP9UVMxJdwUy1L-n5K4iuhw8ryWE=.8e674408-ed21-4f4f-b809-727cd04e642a@github.com>
References: <oTMRc7LWvx9_Uov01HPX9UgyEqFmXt_nMG920HUQBIM=.3651754b-e1f1-46f8-9f44-c118a5c56dbe@github.com>
 <OyU95gqglqG8pz7Pm41XTslrHy-eN_TTx08AeDHHfcQ=.6f1111fc-5f54-42bf-9042-611d6f4f8fef@github.com>
 <euAzwDgKrfHEMNDEx71v-JOmBQXcqp-drHei171Wdpc=.6b831e2a-b86d-4910-b044-0e04fa438c8e@github.com>
 <5LiT1HyqIxOjUMoeqsJlwNA1oHcNempuh4SU_E5NQCE=.40d52a18-d95b-44e4-b198-d29e939dcf15@github.com>
 <4N4qR6vCqhGGGNJTP9UVMxJdwUy1L-n5K4iuhw8ryWE=.8e674408-ed21-4f4f-b809-727cd04e642a@github.com>
Message-ID: <OhbiKBiRfed_IG5wvnbCNpx24WLDSHXxu7X_rM99GzM=.c63f67c6-c10e-4ee4-b4a0-062150a708d6@github.com>

On Tue, 9 Feb 2021 04:27:44 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Thanks @plummercj @sspitsyn @YaSuenag  a lot for helping review this PR again and again! 
>> I have marked it as ready for push.
>
> Hi Lin,
> 
> Sorry for confusing you but I've not noticed a duplication in your code:
> 
> 1778                 if (cntTokens > 2) {
> 1779                     usage();
> 1780                 } else {
> 1781                     JMap jmap = new JMap();
> 1782                     String filename = "heap.bin";
> 1783                     int gzlevel = 0;
>  . . . . 
> 1794                     if (cntTokens > 2) {
> 1795                         err.println("More than 2 options specified: " + cntTokens);
> 1796                         usage();
> 1797                         return;
> 1798                     }
> 1799                     if (cntTokens == 1) { // first argument could be filename or "gz="
>                              . . . .
> 
> There are two checks for cntTokens > 2. The second check has to be removed.
> Also, a return needs to be added after the line 1779 with "usage();" , so the "else" statement can be removed.
> This has to be refactored to something like this:
> 1778                 if (cntTokens > 2) {
>                              err.println("More than 2 options specified: " + cntTokens);
> 1779                     usage();
>                              return;
> 1780                 }
> 1781                 JMap jmap = new JMap();
> 1782                 String filename = "heap.bin";
> 1783                 int gzlevel = 0;
> 1799                 if (cntTokens == 1) { // first argument could be filename or "gz="
>                          . . . .
> 
> Thanks,
> Serguei

Dear Serguei,

> There are two checks for cntTokens > 2. The second check has to be removed.
> Also, a return needs to be added after the line 1779 with "usage();" , so the "else" statement can be removed.
> This has to be refactored to something like this:

Nice catch and good suggestion. Thanks a lot for point it out!
I think It is no hurry to push this PR, and welcome for any comment.
Thanks!

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

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

From stefank at openjdk.java.net  Tue Feb  9 09:34:38 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Tue, 9 Feb 2021 09:34:38 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v12]
In-Reply-To: <Vg27jHtpjAQ36mYoE5MyolUJUi8K9lSb_c3grH_DLvM=.df18633b-2124-44b0-ac51-e5405a3f745d@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <Vg27jHtpjAQ36mYoE5MyolUJUi8K9lSb_c3grH_DLvM=.df18633b-2124-44b0-ac51-e5405a3f745d@github.com>
Message-ID: <8MnBLkES1lapB4b01NDzU9nhOk8_9_V--NSCM5H_bg8=.7bdb576b-4acd-4e5b-be14-b363a2ef47bf@github.com>

On Fri, 5 Feb 2021 16:07:09 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:
> 
>   Update signal handler part for debugger

Thanks for cleaning out WXWriteFromExecSetter.

src/hotspot/share/gc/shared/barrierSetNMethod.cpp line 52:

> 50: 
> 51: int BarrierSetNMethod::nmethod_stub_entry_barrier(address* return_address_ptr) {
> 52:   // Enable WXWrite: the function is called direclty from nmethod_entry_barrier

direclty -> directly

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

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.

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.

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

Changes requested by stefank (Reviewer).

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

From kevinw at openjdk.java.net  Tue Feb  9 09:35:28 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Tue, 9 Feb 2021 09:35:28 GMT
Subject: RFR: 8248876: LoadObject with bad base address created for exec
 file on linux [v2]
In-Reply-To: <ro6clOBejJTDLgrObY4FxZw7leGWP4BXOguhRrtjcqU=.8ea6286d-6a74-425b-884d-5d588e7d57a4@github.com>
References: <R53sQGWiJHl8JzP_wmXoupayROl3DVu0l0rBCzYurWY=.4d6762e8-1de6-4b7d-805f-0a9b977950fb@github.com>
 <Jahs5DE3ENM9yMQuvEJylgpcDHlQUMYwljz8nIDmJ8s=.f6f33839-5aea-4964-a472-0c9bbee6bc68@github.com>
 <49zneDLw_YfcFnLRNd9O_m-pRQ5EXbfIfyrpZy-VKTk=.2ec794e3-b1df-40ef-9097-55030bee39bc@github.com>
 <DrAsRkTNXEbe_W0ag086Ov4a9RG_i1016BnTVmCVOgs=.8c31fbe4-d43f-4a51-b07d-884410045465@github.com>
 <ro6clOBejJTDLgrObY4FxZw7leGWP4BXOguhRrtjcqU=.8ea6286d-6a74-425b-884d-5d588e7d57a4@github.com>
Message-ID: <SN4eMiDDZNwyTkDFUXK2h4hcHsb58HkPVkP3nxSdabY=.c636cf52-e3d7-4c84-b9ac-2fc006855a8c@github.com>

On Tue, 9 Feb 2021 07:35:46 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> Oops, I didn't mean to suggest  the comment should go entirely.  It's actually very useful to say something here, as the way we use the dynamic field, setting it then fixing it up.
>> Is it possible to re-add the comment in a new change?
>
>> Oops, I didn't mean to suggest the comment should go entirely. It's actually very useful to say something here, as the way we use the dynamic field, setting it then fixing it up.
>> Is it possible to re-add the comment in a new change?
> 
> I thought your thumbs-up emoji means to agree to remove all comments.
> 
> As you know, I've integrated this PR, so we need to file as a new ticket.
> I will do it and send a PR with following patch if you are ok.
> 
> diff --git a/src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c b/src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c
> index dff4cb3eeca..9f7c4050ef2 100644
> --- a/src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c
> +++ b/src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c
> @@ -507,7 +507,11 @@ static uintptr_t read_exec_segments(struct ps_prochandle* ph, ELF_EHDR* exec_ehd
>          result = exec_php->p_vaddr;
>          ph->core->dynamic_addr = exec_php->p_vaddr;
>        } else { // ET_DYN
> +        // Base address of executable is based on entry point (AT_ENTRY).
>          result = ph->core->dynamic_addr - exec_ehdr->e_entry;
> +
> +        // dynamic_addr has entry point of executable.
> +        // Thus we should subtract it.
>          ph->core->dynamic_addr += exec_php->p_vaddr - exec_ehdr->e_entry;
>        }
>        print_debug("address of _DYNAMIC is 0x%lx\n", ph->core->dynamic_addr);

Thanks!

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

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

From lzang at openjdk.java.net  Tue Feb  9 10:04:56 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Tue, 9 Feb 2021 10:04:56 GMT
Subject: RFR: 8257234 : Add gz option to SA jmap to write a gzipped heap
 dump [v17]
In-Reply-To: <ix-Gp7c5EkNhLnWbMfV9kRF6dpehHCBeDDHGxeNB1YQ=.8ed6d745-20d7-4f58-a8ff-613a02604a5d@github.com>
References: <oTMRc7LWvx9_Uov01HPX9UgyEqFmXt_nMG920HUQBIM=.3651754b-e1f1-46f8-9f44-c118a5c56dbe@github.com>
 <OyU95gqglqG8pz7Pm41XTslrHy-eN_TTx08AeDHHfcQ=.6f1111fc-5f54-42bf-9042-611d6f4f8fef@github.com>
 <euAzwDgKrfHEMNDEx71v-JOmBQXcqp-drHei171Wdpc=.6b831e2a-b86d-4910-b044-0e04fa438c8e@github.com>
 <5LiT1HyqIxOjUMoeqsJlwNA1oHcNempuh4SU_E5NQCE=.40d52a18-d95b-44e4-b198-d29e939dcf15@github.com>
 <4N4qR6vCqhGGGNJTP9UVMxJdwUy1L-n5K4iuhw8ryWE=.8e674408-ed21-4f4f-b809-727cd04e642a@github.com>
 <OhbiKBiRfed_IG5wvnbCNpx24WLDSHXxu7X_rM99GzM=.c63f67c6-c10e-4ee4-b4a0-062150a708d6@github.com>
 <ix-Gp7c5EkNhLnWbMfV9kRF6dpehHCBeDDHGxeNB1YQ=.8ed6d745-20d7-4f58-a8ff-613a02604a5d@github.com>
Message-ID: <lfLqW1fNEbKAB5oA3DinO1Mh1wzcYKiOqUl2wQNSqWk=.22990b90-cda5-43c7-9cef-ada0c8756d1e@github.com>

On Tue, 9 Feb 2021 08:28:57 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Dear Serguei,
>> 
>>> There are two checks for cntTokens > 2. The second check has to be removed.
>>> Also, a return needs to be added after the line 1779 with "usage();" , so the "else" statement can be removed.
>>> This has to be refactored to something like this:
>> 
>> Nice catch and good suggestion. Thanks a lot for point it out!
>> I think It is no hurry to push this PR, and welcome for any comment.
>> Thanks!
>
> Hi Lin,
> Thank you for update.
> 
> test/lib/jdk/test/lib/hprof/parser/Reader.java:
> +            } else if ((i >>> 8) == 0x1f8b08) {
> +                // Possible gziped file.
> 
> Could you, please, define a named constant and use it instead of the literal value 0x1f8b08?
> Also, would it make sense to extend the comment to explain about it a little bit?
> 
> I'm still looking at some files (e.g., HeapHprofBinWriter.java).
> 
> Thanks,
> Serguei

Dear @sspitsyn, 
Thanks for your suggestion. 

> I'm still looking at some files (e.g., HeapHprofBinWriter.java).

No problem, please take your time. Appreciated for your effort helping review! 

BRs,
Lin

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

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

From lzang at openjdk.java.net  Tue Feb  9 10:04:55 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Tue, 9 Feb 2021 10:04:55 GMT
Subject: RFR: 8257234 : Add gz option to SA jmap to write a gzipped heap
 dump [v19]
In-Reply-To: <oTMRc7LWvx9_Uov01HPX9UgyEqFmXt_nMG920HUQBIM=.3651754b-e1f1-46f8-9f44-c118a5c56dbe@github.com>
References: <oTMRc7LWvx9_Uov01HPX9UgyEqFmXt_nMG920HUQBIM=.3651754b-e1f1-46f8-9f44-c118a5c56dbe@github.com>
Message-ID: <PwRMr_66t_JDfAzP3aaqAB-R5HI3_YqRQMxBJTqrM08=.ceb346ca-b46b-46af-b25d-98fb7ebc0d1a@github.com>

> 8257234 : Add gz option to SA jmap to write a gzipped heap dump

Lin Zang has updated the pull request incrementally with one additional commit since the last revision:

  refine code in test.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1712/files
  - new: https://git.openjdk.java.net/jdk/pull/1712/files/47d93a9d..6fe0f79b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1712&range=18
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1712&range=17-18

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

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

From github.com+471021+marschall at openjdk.java.net  Tue Feb  9 11:42:34 2021
From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall)
Date: Tue, 9 Feb 2021 11:42:34 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v9]
In-Reply-To: <oyAwqFESfH7q3wJicuQNF0Hds0Sp69dN5bzxYAIBaOQ=.df45bf24-3f70-457d-9df9-8a5b3022f1e1@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <oyAwqFESfH7q3wJicuQNF0Hds0Sp69dN5bzxYAIBaOQ=.df45bf24-3f70-457d-9df9-8a5b3022f1e1@github.com>
Message-ID: <4-2EVrWdbxsKykSlYd3bAuxS7iuzZbxKPEhrE-y_fMk=.986e5094-e940-4a89-a70e-5aad77dde26d@github.com>

On Mon, 8 Feb 2021 20:58:01 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
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
>   fix review comments

src/java.base/share/classes/java/util/jar/JarInputStream.java line 93:

> 91:         if (e != null && JarFile.MANIFEST_NAME.equalsIgnoreCase(e.getName())) {
> 92:             man = new Manifest();
> 93:             byte[] bytes = new BufferedInputStream(this).readAllBytes();

I wonder if it makes sense to avoid reading the entire manifest into a byte[] when we don't need to verify the JAR. This may help avoiding some intermediate allocation and copying. This make be noticeable for some of the larger manifests (Java EE, OSGi, ...). A possible implementation may look like this https://github.com/marschall/jdk/commit/c50880ffb18607077c4da3456b27957d1df8edb7.

In either case since we're calling #readAllBytes I don't see why we are wrapping in a BufferedInputStream rather than calling #readAllBytes directly.

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

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

From ysuenaga at openjdk.java.net  Tue Feb  9 12:26:29 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Tue, 9 Feb 2021 12:26:29 GMT
Subject: RFR: 8248876: LoadObject with bad base address created for exec
 file on linux [v2]
In-Reply-To: <SN4eMiDDZNwyTkDFUXK2h4hcHsb58HkPVkP3nxSdabY=.c636cf52-e3d7-4c84-b9ac-2fc006855a8c@github.com>
References: <R53sQGWiJHl8JzP_wmXoupayROl3DVu0l0rBCzYurWY=.4d6762e8-1de6-4b7d-805f-0a9b977950fb@github.com>
 <Jahs5DE3ENM9yMQuvEJylgpcDHlQUMYwljz8nIDmJ8s=.f6f33839-5aea-4964-a472-0c9bbee6bc68@github.com>
 <49zneDLw_YfcFnLRNd9O_m-pRQ5EXbfIfyrpZy-VKTk=.2ec794e3-b1df-40ef-9097-55030bee39bc@github.com>
 <DrAsRkTNXEbe_W0ag086Ov4a9RG_i1016BnTVmCVOgs=.8c31fbe4-d43f-4a51-b07d-884410045465@github.com>
 <ro6clOBejJTDLgrObY4FxZw7leGWP4BXOguhRrtjcqU=.8ea6286d-6a74-425b-884d-5d588e7d57a4@github.com>
 <SN4eMiDDZNwyTkDFUXK2h4hcHsb58HkPVkP3nxSdabY=.c636cf52-e3d7-4c84-b9ac-2fc006855a8c@github.com>
Message-ID: <lC8KjWOpnualIp3f7gwuDEOHPkE73bErD8IJeoOuQUw=.985805c9-c772-4fca-b96c-ac1cfe2fc945@github.com>

On Tue, 9 Feb 2021 09:32:34 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>>> Oops, I didn't mean to suggest the comment should go entirely. It's actually very useful to say something here, as the way we use the dynamic field, setting it then fixing it up.
>>> Is it possible to re-add the comment in a new change?
>> 
>> I thought your thumbs-up emoji means to agree to remove all comments.
>> 
>> As you know, I've integrated this PR, so we need to file as a new ticket.
>> I will do it and send a PR with following patch if you are ok.
>> 
>> diff --git a/src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c b/src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c
>> index dff4cb3eeca..9f7c4050ef2 100644
>> --- a/src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c
>> +++ b/src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c
>> @@ -507,7 +507,11 @@ static uintptr_t read_exec_segments(struct ps_prochandle* ph, ELF_EHDR* exec_ehd
>>          result = exec_php->p_vaddr;
>>          ph->core->dynamic_addr = exec_php->p_vaddr;
>>        } else { // ET_DYN
>> +        // Base address of executable is based on entry point (AT_ENTRY).
>>          result = ph->core->dynamic_addr - exec_ehdr->e_entry;
>> +
>> +        // dynamic_addr has entry point of executable.
>> +        // Thus we should subtract it.
>>          ph->core->dynamic_addr += exec_php->p_vaddr - exec_ehdr->e_entry;
>>        }
>>        print_debug("address of _DYNAMIC is 0x%lx\n", ph->core->dynamic_addr);
>
> Thanks!

@kevinjwalls I've sent PR about adding comments in #2478. I hope you review it!

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

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

From ysuenaga at openjdk.java.net  Tue Feb  9 12:27:38 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Tue, 9 Feb 2021 12:27:38 GMT
Subject: RFR: 8261431: SA: Add comments about load address of executable
Message-ID: <tTSRlEL6jGzU4fHk36ARVR3NTssnQQIvDwTXH8xHZAs=.95bf2519-5f16-41aa-b24e-8b9cf600fa7a@github.com>

I removed the comment about load address of executable in [JDK-8248876](https://bugs.openjdk.java.net/browse/JDK-8248876) (#2366), but it contained useful information for maintenance.

So I re-add them, and add comment for the change in JDK-8248876. Please see https://github.com/openjdk/jdk/pull/2366#issuecomment-775362982

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

Commit messages:
 - 8261431: SA: Add comments about load address of executable

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

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

From hseigel at openjdk.java.net  Tue Feb  9 13:19:29 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Tue, 9 Feb 2021 13:19:29 GMT
Subject: Integrated: 8261340: Fix 'deprecated' warnings in the vmTestbase/nsk
 tests
In-Reply-To: <aqxiaaZnSvYQGNcw7B2ybqLLT5HJ-EKoVE3-8Jxb5h8=.a529ba2d-2ee0-48d6-93cd-633bc26925fd@github.com>
References: <aqxiaaZnSvYQGNcw7B2ybqLLT5HJ-EKoVE3-8Jxb5h8=.a529ba2d-2ee0-48d6-93cd-633bc26925fd@github.com>
Message-ID: <P2DR24_FrIl2vIp6vvRpSzwnOIpNRoHp5J4XIvCk7sA=.5715e849-8075-44a5-8f2d-9b562cac193b@github.com>

On Mon, 8 Feb 2021 19:54:03 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this small fix for JDK-8261340 to clean up deprecation warnings, such as the following, in the vmTestbase/nsk tests.
> 
>     warning: [dep-ann] deprecated item is not annotated with @Deprecated
> 
> The change was tested by running the tests locally and checking for the warnings.  It was regression tested with tiers 1-2 on Linux, Mac OS, and Windows and tiers 3-5 on Linux x64.
> 
> Thanks, Harold

This pull request has now been integrated.

Changeset: b38d5be8
Author:    Harold Seigel <hseigel at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b38d5be8
Stats:     17 lines in 5 files changed: 12 ins; 0 del; 5 mod

8261340: Fix 'deprecated' warnings in the vmTestbase/nsk tests

Reviewed-by: lfoltan, sspitsyn

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

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

From hseigel at openjdk.java.net  Tue Feb  9 13:19:28 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Tue, 9 Feb 2021 13:19:28 GMT
Subject: RFR: 8261340: Fix 'deprecated' warnings in the vmTestbase/nsk
 tests
In-Reply-To: <EhdtHVB55NODXnSl6KQhobbrC4Ox-miCf_xOQ1WtKbU=.1becf6e1-8708-4eea-a5d9-ad0c50eab680@github.com>
References: <aqxiaaZnSvYQGNcw7B2ybqLLT5HJ-EKoVE3-8Jxb5h8=.a529ba2d-2ee0-48d6-93cd-633bc26925fd@github.com>
 <EhdtHVB55NODXnSl6KQhobbrC4Ox-miCf_xOQ1WtKbU=.1becf6e1-8708-4eea-a5d9-ad0c50eab680@github.com>
Message-ID: <WsiedHMCOFTF8Dolw4nSN6aq2ch8WXnr2gAu3CAqDaM=.c45cbf86-b742-4744-8610-bb550b889252@github.com>

On Tue, 9 Feb 2021 04:36:29 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Please review this small fix for JDK-8261340 to clean up deprecation warnings, such as the following, in the vmTestbase/nsk tests.
>> 
>>     warning: [dep-ann] deprecated item is not annotated with @Deprecated
>> 
>> The change was tested by running the tests locally and checking for the warnings.  It was regression tested with tiers 1-2 on Linux, Mac OS, and Windows and tiers 3-5 on Linux x64.
>> 
>> Thanks, Harold
>
> LGTM++
> 
> Thanks,
> Serguei

Thanks Lois and Sergei for reviewing this change!

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

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

From sgehwolf at openjdk.java.net  Tue Feb  9 13:31:25 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Tue, 9 Feb 2021 13:31:25 GMT
Subject: RFR: 8254001: [Metrics] Enhance parsing of cgroup interface files
 for version detection [v4]
In-Reply-To: <52vN8j9B_6s6amMHb8b_1QKyhwjCvThIz5T17aNix28=.31113ef4-61d0-4525-a3df-9aa20d408935@github.com>
References: <52vN8j9B_6s6amMHb8b_1QKyhwjCvThIz5T17aNix28=.31113ef4-61d0-4525-a3df-9aa20d408935@github.com>
Message-ID: <3x47AFywS6_XcwXLLRw-js174URG35nifn1_G19vsKc=.b5ad4fdc-e040-44bc-a7fd-6fe7268dc341@github.com>

> This is an enhancement which solves two issues:
> 
> 1. Multiple reads of relevant cgroup interface files. Now interface files are only read once per file (just like Hotspot).
> 2. Proxies creation of the impl specific subsystem via `determineType()` as before, but now reads all relevant interface files: `/proc/cgroups`, `/proc/self/mountinfo` and `/proc/self/cgroup`. Once read it passes the parsed information to the impl specific subsystem classes for instantiation. This allows for more flexibility of testing as interface files can be mocked and, thus, more cases can be tested that way without having access to these specific systems. For example, proper regression tests for JDK-8217766 and JDK-8253435 have been added now with this in place.
> 
> * [x] Tested on Linux x86_64 on cgroups v1 and cgroups v2. Container tests pass.

Severin Gehwolf 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:

 - Fix jcheck
 - Add documentation and reduce code running in the critical section
 - Add some documentation
 - Merge branch 'master' into jdk-8254001-enhance-file-parsing-java-metrics
 - Merge branch 'master' into jdk-8254001-enhance-file-parsing-java-metrics
 - Merge branch 'master' into jdk-8254001-enhance-file-parsing-java-metrics
 - 8254001: [Metrics] Enhance parsing of cgroup interface files for version detection

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1393/files
  - new: https://git.openjdk.java.net/jdk/pull/1393/files/0ece5f22..9a2d6a20

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

  Stats: 100580 lines in 2281 files changed: 44215 ins; 36687 del; 19678 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1393.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1393/head:pull/1393

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

From sgehwolf at openjdk.java.net  Tue Feb  9 13:45:39 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Tue, 9 Feb 2021 13:45:39 GMT
Subject: RFR: 8254001: [Metrics] Enhance parsing of cgroup interface files
 for version detection
In-Reply-To: <oGVjtCZ-VkXvuxH0oR8BWwE09Q2r3z6vM1j6YPwwRvE=.30e018b1-2b96-484e-b2e7-fcafb36c13f2@github.com>
References: <52vN8j9B_6s6amMHb8b_1QKyhwjCvThIz5T17aNix28=.31113ef4-61d0-4525-a3df-9aa20d408935@github.com>
 <Ynmw17EfEzNeUK5w2ABmHkXqqXo98GTcYTnZFGoAYIk=.1079ee11-c9e7-443f-b74b-d94838206a2a@github.com>
 <eFFokFwfdmu0YTyAhvPJ7xBFo0ypjHw3MyC_9-aTS6g=.80ad5876-3ae3-4ca3-96b5-08db53ed6627@github.com>
 <COWzygAauFzmvgYYP6DVjIg0MH6EDyIMx0ZzeTRHol0=.8a01079b-6e40-4b1b-bb75-e693f89d8871@github.com>
 <iT7Ltrm52E9skv98tAKIYPB1ZCaXw8ep-YSegjEnhxc=.68635047-f51c-4c60-9731-0da103e56a39@github.com>
 <m1iurC4l1M904NY7lj5eVIB8jgCfBLR2sh8XrQzhJUM=.c2c5c01f-c29a-4b22-922b-e56472e951ec@github.com>
 <Mat51HIuUYISDvMtuz4R7LJ2R1aBeGASWCyBWAXFlAI=.f3329041-9c29-4b4b-ba66-163233764fb9@github.com>
 <oGVjtCZ-VkXvuxH0oR8BWwE09Q2r3z6vM1j6YPwwRvE=.30e018b1-2b96-484e-b2e7-fcafb36c13f2@github.com>
Message-ID: <qDP_U7qiySEJY88sA-hY1dq3o8OCcAbX_GhyZ9-ykfw=.d98bc0ed-25e3-496b-9d31-b169a374c793@github.com>

On Mon, 1 Feb 2021 20:26:54 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> > Anybody willing to review this?
> 
> I can have a go.
> 
> I have two main concerns:
> 
>     1. There seems to be little documentation on the new additions. I'm particularly concerned about things like CgroupV1Subsystem.java where a big chunk of documentation on the formats being read is removed and I don't see it being moved elsewhere. Documentation on the new getInstance methods would be helpful too.

The updated patch now includes some more documentation. The reason why I've removed some of it was because the logic changed and it was outdated.

>     2. With the new volatile fields, I think it would be better if the lock being held to initialise them was only held when necessary to perform the assignment. Holding it while performing an extensive process of parsing multiple files that could potentially fail seems a little dangerous. i.e. something like:
>        if (INSTANCE == null) { CGroupV1Subsystem tmp = initSubSystem(infos); synchronized (CgroupV1Subsystem.class) { if (INSTANCE == null) { INSTANCE = tmp; } } }

I've changed this as suggested, but keep in mind no parsing of multiple files happens after this patch. It happens in CgroupSubsystemFactory.

Thanks,
Severin

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

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

From sspitsyn at openjdk.java.net  Tue Feb  9 18:00:38 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Tue, 9 Feb 2021 18:00:38 GMT
Subject: RFR: 8261431: SA: Add comments about load address of executable
In-Reply-To: <tTSRlEL6jGzU4fHk36ARVR3NTssnQQIvDwTXH8xHZAs=.95bf2519-5f16-41aa-b24e-8b9cf600fa7a@github.com>
References: <tTSRlEL6jGzU4fHk36ARVR3NTssnQQIvDwTXH8xHZAs=.95bf2519-5f16-41aa-b24e-8b9cf600fa7a@github.com>
Message-ID: <UggOpq_fdaVVRzz_owig-HUhXlZ570JkCMu2AwT9UL8=.fab6ccf5-cef6-4ef4-aecf-ba1173e66f8b@github.com>

On Tue, 9 Feb 2021 12:22:00 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> I removed the comment about load address of executable in [JDK-8248876](https://bugs.openjdk.java.net/browse/JDK-8248876) (#2366), but it contained useful information for maintenance.
> 
> So I re-add them, and add comment for the change in JDK-8248876. Please see https://github.com/openjdk/jdk/pull/2366#issuecomment-775362982

Hi Yasumasa,
LGTM
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

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

From cjplummer at openjdk.java.net  Tue Feb  9 19:16:39 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 9 Feb 2021 19:16:39 GMT
Subject: RFR: JDK-8261034: improve jcmd GC.class_histogram to support
 parallel
In-Reply-To: <X_7cTwpI8cxsVTCMi6oe6f1Fy6yPcw7b0-Pa-Ayou2Y=.69cba9c8-f6e4-40b4-a180-3eb79428692b@github.com>
References: <VKzVY-01CEXUbQdlKMhDWjtjxUgpxs_6487x232VsAI=.3b9c5d8a-972b-4997-9f75-1951f98e1751@github.com>
 <X_7cTwpI8cxsVTCMi6oe6f1Fy6yPcw7b0-Pa-Ayou2Y=.69cba9c8-f6e4-40b4-a180-3eb79428692b@github.com>
Message-ID: <EQm4vRIvMgIFwt3dwYO3YTdbCLyQEKjISTt-QudCNbE=.f2366e5b-b9fa-456d-bafa-6531293b2cc2@github.com>

On Tue, 9 Feb 2021 07:57:24 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> parallel -histo of jmap was added by JDK-8214535, it's better to support parallel for jcmd GC.class_histogram too.
>
>> Hi @Hamlin-Li,
>> 
>> It looks good in general.
>> A question: What is going to happen if the number of parallel threads passed to the command is too big? Is there any limit, and what has to be the expected behavior in such a case? I'll look at the CSR.
>> Thanks,
>> Serguei
> 
> Hi Serguer,
> Thanks for reviewing.
> First, it got truncated as uint by ClassHistogramDCmd, then it got capped in HeapInspection by by total_workers of gang, so finally it will not exceed total_workers.
> Hope this answer your questions.

I think part of the concern here is that this is all hidden from the user. "total_workers of gang" is not something that is spec'd somewhere. So when the user chooses to set "parallel" to something other than 0 (the default), then there really is no guidance as to what a good alternative number is. Presumably you are setting it because you feel the default is too low or too high, but without knowing the actual number of threads used by default, it's hard to come up with a reasonable adjustment to specify. We also have the relationship to `-XX:ParallelGCThreads`, which impacts this.

Maybe the option should just be to enable or disable parallel. Before your changes it looks like you got parallel=1, so no parallel threads, and no ability to change that. With your changes the default is now parallel=0, so you get the default number of threads, and you can change it to any number. So maybe we should choose one of the following two simpler approaches:

- Default to not parallel. Allow the user to specify `-parallel`, but not specify the thread count. They will get the default number of threads just like `parallel=0`
- Default to parallel using the default number of threads. Allow the user to turn parallel off with a `-noparallel` option.

However, this probably needs to be consistent with the jmap command and the attach API protocol, which is being discussed in  #2261. They should both either choose one of the above simplified approaches, or do a better job of specifying defaults and limits for the number of threads. So some input from @linzang woudl be useful here.

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

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

From kevinw at openjdk.java.net  Tue Feb  9 20:51:39 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Tue, 9 Feb 2021 20:51:39 GMT
Subject: RFR: 8261431: SA: Add comments about load address of executable
In-Reply-To: <UggOpq_fdaVVRzz_owig-HUhXlZ570JkCMu2AwT9UL8=.fab6ccf5-cef6-4ef4-aecf-ba1173e66f8b@github.com>
References: <tTSRlEL6jGzU4fHk36ARVR3NTssnQQIvDwTXH8xHZAs=.95bf2519-5f16-41aa-b24e-8b9cf600fa7a@github.com>
 <UggOpq_fdaVVRzz_owig-HUhXlZ570JkCMu2AwT9UL8=.fab6ccf5-cef6-4ef4-aecf-ba1173e66f8b@github.com>
Message-ID: <ZO8YHrI7GaPbUUuQJ53eVLJCHWOohP-oRPrvh1H6XLc=.884484fb-a58d-4513-988a-a7a57a70f77a@github.com>

On Tue, 9 Feb 2021 17:57:42 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> I removed the comment about load address of executable in [JDK-8248876](https://bugs.openjdk.java.net/browse/JDK-8248876) (#2366), but it contained useful information for maintenance.
>> 
>> So I re-add them, and add comment for the change in JDK-8248876. Please see https://github.com/openjdk/jdk/pull/2366#issuecomment-775362982
>
> Hi Yasumasa,
> LGTM
> Thanks,
> Serguei

Thanks!

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

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

From ysuenaga at openjdk.java.net  Wed Feb 10 00:36:38 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Wed, 10 Feb 2021 00:36:38 GMT
Subject: RFR: 8261431: SA: Add comments about load address of executable
In-Reply-To: <UggOpq_fdaVVRzz_owig-HUhXlZ570JkCMu2AwT9UL8=.fab6ccf5-cef6-4ef4-aecf-ba1173e66f8b@github.com>
References: <tTSRlEL6jGzU4fHk36ARVR3NTssnQQIvDwTXH8xHZAs=.95bf2519-5f16-41aa-b24e-8b9cf600fa7a@github.com>
 <UggOpq_fdaVVRzz_owig-HUhXlZ570JkCMu2AwT9UL8=.fab6ccf5-cef6-4ef4-aecf-ba1173e66f8b@github.com>
Message-ID: <ybgWXJ3mwkI5Z2_pq2GAmNlG_SWwnJwiEVjs7J8_YeE=.b2214537-8333-4665-9cb7-72ba9ab90ccf@github.com>

On Tue, 9 Feb 2021 17:57:42 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> I removed the comment about load address of executable in [JDK-8248876](https://bugs.openjdk.java.net/browse/JDK-8248876) (#2366), but it contained useful information for maintenance.
>> 
>> So I re-add them, and add comment for the change in JDK-8248876. Please see https://github.com/openjdk/jdk/pull/2366#issuecomment-775362982
>
> Hi Yasumasa,
> LGTM
> Thanks,
> Serguei

Thanks @sspitsyn !
@kevinjwalls Can you approve this change?

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

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

From lzang at openjdk.java.net  Wed Feb 10 00:36:41 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Wed, 10 Feb 2021 00:36:41 GMT
Subject: RFR: JDK-8261034: improve jcmd GC.class_histogram to support
 parallel
In-Reply-To: <EQm4vRIvMgIFwt3dwYO3YTdbCLyQEKjISTt-QudCNbE=.f2366e5b-b9fa-456d-bafa-6531293b2cc2@github.com>
References: <VKzVY-01CEXUbQdlKMhDWjtjxUgpxs_6487x232VsAI=.3b9c5d8a-972b-4997-9f75-1951f98e1751@github.com>
 <X_7cTwpI8cxsVTCMi6oe6f1Fy6yPcw7b0-Pa-Ayou2Y=.69cba9c8-f6e4-40b4-a180-3eb79428692b@github.com>
 <EQm4vRIvMgIFwt3dwYO3YTdbCLyQEKjISTt-QudCNbE=.f2366e5b-b9fa-456d-bafa-6531293b2cc2@github.com>
Message-ID: <gBKEb-EMtCvqvSZiS1ImsYpQg63tg6R8KaizkL-BrlE=.f51a4335-251c-4041-bd71-75ec13f0591d@github.com>

On Tue, 9 Feb 2021 19:13:55 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>>> Hi @Hamlin-Li,
>>> 
>>> It looks good in general.
>>> A question: What is going to happen if the number of parallel threads passed to the command is too big? Is there any limit, and what has to be the expected behavior in such a case? I'll look at the CSR.
>>> Thanks,
>>> Serguei
>> 
>> Hi Serguer,
>> Thanks for reviewing.
>> First, it got truncated as uint by ClassHistogramDCmd, then it got capped in HeapInspection by by total_workers of gang, so finally it will not exceed total_workers.
>> Hope this answer your questions.
>
> I think part of the concern here is that this is all hidden from the user. "total_workers of gang" is not something that is spec'd somewhere. So when the user chooses to set "parallel" to something other than 0 (the default), then there really is no guidance as to what a good alternative number is. Presumably you are setting it because you feel the default is too low or too high, but without knowing the actual number of threads used by default, it's hard to come up with a reasonable adjustment to specify. We also have the relationship to `-XX:ParallelGCThreads`, which impacts this.
> 
> Maybe the option should just be to enable or disable parallel. Before your changes it looks like you got parallel=1, so no parallel threads, and no ability to change that. With your changes the default is now parallel=0, so you get the default number of threads, and you can change it to any number. So maybe we should choose one of the following two simpler approaches:
> 
> - Default to not parallel. Allow the user to specify `-parallel`, but not specify the thread count. They will get the default number of threads just like `parallel=0`
> - Default to parallel using the default number of threads. Allow the user to turn parallel off with a `-noparallel` option.
> 
> However, this probably needs to be consistent with the jmap command and the attach API protocol, which is being discussed in  #2261. They should both either choose one of the above simplified approaches, or do a better job of specifying defaults and limits for the number of threads. So some input from @linzang woudl be useful here.

Hi Chris, 

> * Default to not parallel. Allow the user to specify `-parallel`, but not specify the thread count. They will get the default number of threads just like `parallel=0`
> * Default to parallel using the default number of threads. Allow the user to turn parallel off with a `-noparallel` option.

I would prefer the -noparallel option that enable parallel by default. IMHO, the parallel heap inspection is a little bit like parallelGCThreads -  which allowing the hotspot to decide the parallel thread number based on the platfrom by default. 

And I remember Serguei (@sspitsyn) and I discussed the "-parallel" option at https://mail.openjdk.java.net/pipermail/serviceability-dev/2020-September/032836.html,  we finally decide to not introduce it. just FYI. 

> However, this probably needs to be consistent with the jmap command and the attach API protocol, which is being discussed in #2261.

if just introducing new option like "parallel" or "noparallel", I think we don't need to bother about attach API protocol. we can preprocess it in JMap.java and then pass the value of "0" or "1" as parallel_thread_number, just like what it is implemented at present, no compatibility issue introduced :-)
 

Moreover, I am thinking maybe we could print a meesage like "inspected heap parallelly with `parallel_numer` threads" in the result,  just like -dump's output "Heap dump file created [18904360 bytes in 0.039 secs]"

Thanks, 
Lin

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

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

From mli at openjdk.java.net  Wed Feb 10 01:51:38 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Wed, 10 Feb 2021 01:51:38 GMT
Subject: RFR: JDK-8261034: improve jcmd GC.class_histogram to support
 parallel
In-Reply-To: <gBKEb-EMtCvqvSZiS1ImsYpQg63tg6R8KaizkL-BrlE=.f51a4335-251c-4041-bd71-75ec13f0591d@github.com>
References: <VKzVY-01CEXUbQdlKMhDWjtjxUgpxs_6487x232VsAI=.3b9c5d8a-972b-4997-9f75-1951f98e1751@github.com>
 <X_7cTwpI8cxsVTCMi6oe6f1Fy6yPcw7b0-Pa-Ayou2Y=.69cba9c8-f6e4-40b4-a180-3eb79428692b@github.com>
 <EQm4vRIvMgIFwt3dwYO3YTdbCLyQEKjISTt-QudCNbE=.f2366e5b-b9fa-456d-bafa-6531293b2cc2@github.com>
 <gBKEb-EMtCvqvSZiS1ImsYpQg63tg6R8KaizkL-BrlE=.f51a4335-251c-4041-bd71-75ec13f0591d@github.com>
Message-ID: <v4SsYZMv2DVW2v8KDDDrCMa-JlyDX6Nsa20ue9JZKqs=.2617d216-b696-48c9-b34e-b0a97bb3bf12@github.com>

On Wed, 10 Feb 2021 00:34:02 GMT, Lin Zang <lzang at openjdk.org> wrote:

> > * Default to not parallel. Allow the user to specify `-parallel`, but not specify the thread count. They will get the default number of threads just like `parallel=0`
> > * Default to parallel using the default number of threads. Allow the user to turn parallel off with a `-noparallel` option.
> 
> I would prefer the -noparallel option that enable parallel by default. IMHO, the parallel heap inspection is a little bit like parallelGCThreads - which allowing the hotspot to decide the parallel thread number based on the platfrom by default.
> 

Hi Chris, Lin,
Thanks for discussion.
I'm OK with either options, both ways simplify the spec and hide details from users.

> And I remember Serguei (@sspitsyn) and I discussed the "-parallel" option at https://mail.openjdk.java.net/pipermail/serviceability-dev/2020-September/032836.html, we finally decide to not introduce it. just FYI.
> 
> > However, this probably needs to be consistent with the jmap command and the attach API protocol, which is being discussed in #2261.
> 
> if just introducing new option like "parallel" or "noparallel", I think we don't need to bother about attach API protocol. we can preprocess it in JMap.java and then pass the value of "0" or "1" as parallel_thread_number, just like what it is implemented at present, no compatibility issue introduced :-)

If we decide to take either of above ways, then we should modify the uint to bool, it's more clear.

> 
> Moreover, I am thinking maybe we could print a meesage like "inspected heap parallelly with `parallel_numer` threads" in the result, just like -dump's output "Heap dump file created [18904360 bytes in 0.039 secs]"

Agree, it helps.

BTW, I think we have mixed several threads(jcmd, jmap histo/dump) together. How about we address jmap -histo first (I filed a new bug at https://bugs.openjdk.java.net/browse/JDK-8261482), then I adjust the behavior of jcmd accordingly?

Thanks.

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

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

From ysuenaga at openjdk.java.net  Wed Feb 10 01:56:43 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Wed, 10 Feb 2021 01:56:43 GMT
Subject: RFR: 8257234 : Add gz option to SA jmap to write a gzipped heap
 dump [v19]
In-Reply-To: <PwRMr_66t_JDfAzP3aaqAB-R5HI3_YqRQMxBJTqrM08=.ceb346ca-b46b-46af-b25d-98fb7ebc0d1a@github.com>
References: <oTMRc7LWvx9_Uov01HPX9UgyEqFmXt_nMG920HUQBIM=.3651754b-e1f1-46f8-9f44-c118a5c56dbe@github.com>
 <PwRMr_66t_JDfAzP3aaqAB-R5HI3_YqRQMxBJTqrM08=.ceb346ca-b46b-46af-b25d-98fb7ebc0d1a@github.com>
Message-ID: <eARm7FTSUIV7R-gZ4J99XdTsdohBdixSwg-Q3AdNT0A=.b00a1c9c-e53d-4263-827b-ee4481f10b67@github.com>

On Tue, 9 Feb 2021 10:04:55 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> 8257234 : Add gz option to SA jmap to write a gzipped heap dump
>
> Lin Zang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   refine code in test.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java line 1504:

> 1502:             segmentBuffer[segmentWritten++] = (byte)(v >>>  8);
> 1503:             segmentBuffer[segmentWritten++] = (byte)(v >>>  0);
> 1504:         }

I'm not familiar to hprof format, but I guess we need to write them with big endian.
Can we use `ByteBuffer::putInt` and `ByteBuffer::order` at here? I guess it makes ease to maintenance.

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

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

From mli at openjdk.java.net  Wed Feb 10 02:02:38 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Wed, 10 Feb 2021 02:02:38 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump
In-Reply-To: <sQsnkEh6czmuyAbsFV8pm0HRBc4iR21hMXj0o5Za8VA=.c455e261-03b5-4bd7-8b88-0fff84c20e85@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
 <crJcuaqSgYZQCEw2lqGaLpRmCVOXr99P1i5bcnSFpQc=.cb824923-e649-4ecd-ba5b-8d26cb93b265@github.com>
 <esex_demB2ZT0CsAp2WrzNGC_gieM9USGg_fYgmFCAE=.1911dd08-7dcc-4d88-9532-5d670399dd62@github.com>
 <ztN32xTk5joNRB7MhfYMl9zHCfGA1j8bQNu-ke975qc=.4c7ff2a9-2af8-495d-8f22-83e98c2e3221@github.com>
 <oQe3_j7vewkS8wlIuYXRCa_86pI215cFIceztTf5jX0=.d6d6201b-ec15-418e-a73b-e907d9d02607@github.com>
 <oPJ9OfKdD8CTbihLREww1QM2hc3Ckiai0-1OSpkq830=.87c4f119-07c9-471f-8c25-99dcfaad8d11@github.com>
 <ngMsS8jp0GTuqLVGD5k2ZL5AckbFwh8CBj5ec_GaBes=.0c51dacf-b158-4e62-874d-5e9c5a7b5f8e@github.com>
 <JDsbDqJRQ0V_s1SvGBhr3FLu98T2-X51kpkCs8s8vxQ=.fdb2242c-8706-4057-b4aa-084cfcb24166@github.com>
 <cHsGHKQrSqSUKJJ2OIRVUYuKUVOJGH-Pch-aDmoPj64=.88025b63-b0bb-401a-a749-57089ebea3aa@github.com>
 <gnDO9moDHlyHgJCEdcILr-MauRQgQP7I6QE38XZHus0=.4e488aca-8206-4db5-acec-5c029a6328ca@github.com>
 <vN4ZxgYOLsOQLqwyX4fXMJsQ-LM-S5JqeZo
 WdMXzmqc=.dfdc97a5-4838-4f09-9082-e5562c4691e0@github.com>
 <hLyibl3_enSszfZLKP74PE3i_ranX51N3nNiX0F9KoA=.8f2fea52-c394-4612-9c74-d9d975a3c42a@github.com>
 <Gs7-OplIQn5Vtq9vmQ6QXnB3l_XGSwfsagD044OQ2RM=.564b8980-fd3b-4555-864c-33c1b55a9fbd@github.com>
 <ONgCbmqprWaFkq_OtsFB5KBW1KjPIQu7QRaHXFEHOB8=.e1af696f-9e30-4b94-9524-682a14226c74@github.com>
 <sQsnkEh6czmuyAbsFV8pm0HRBc4iR21hMXj0o5Za8VA=.c455e261-03b5-4bd7-8b88-0fff84c20e85@github.com>
Message-ID: <yWtKl2uvn5MZTKXzjBrZBhXf-slKdGI1DjBZxBJaTws=.01b30893-7395-4e00-aa50-e2c25fd33ba1@github.com>

On Thu, 4 Feb 2021 03:52:23 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> BTW, one thing to keep in mind that whatever we do with `dumpheap`, the jcmd version will support fine control over parallelism. So for that reason it wouldn't be so bad to just have `dumpheap` and `inspectheap` always use some default parallelism, and allow tuning it with the jcmd versions. But since the `inspectheap` parallel support already went into 16, that might be hard to undo.

Hi Chris, Lin,
IMHO, 16 is not an LTS, maybe it's better for us to adjust the behavior of jmap -histo in 17 which is LTS? I just filed https://bugs.openjdk.java.net/browse/JDK-8261482.
Thanks.

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

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

From lzang at openjdk.java.net  Wed Feb 10 02:23:38 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Wed, 10 Feb 2021 02:23:38 GMT
Subject: RFR: JDK-8261034: improve jcmd GC.class_histogram to support
 parallel
In-Reply-To: <v4SsYZMv2DVW2v8KDDDrCMa-JlyDX6Nsa20ue9JZKqs=.2617d216-b696-48c9-b34e-b0a97bb3bf12@github.com>
References: <VKzVY-01CEXUbQdlKMhDWjtjxUgpxs_6487x232VsAI=.3b9c5d8a-972b-4997-9f75-1951f98e1751@github.com>
 <X_7cTwpI8cxsVTCMi6oe6f1Fy6yPcw7b0-Pa-Ayou2Y=.69cba9c8-f6e4-40b4-a180-3eb79428692b@github.com>
 <EQm4vRIvMgIFwt3dwYO3YTdbCLyQEKjISTt-QudCNbE=.f2366e5b-b9fa-456d-bafa-6531293b2cc2@github.com>
 <gBKEb-EMtCvqvSZiS1ImsYpQg63tg6R8KaizkL-BrlE=.f51a4335-251c-4041-bd71-75ec13f0591d@github.com>
 <v4SsYZMv2DVW2v8KDDDrCMa-JlyDX6Nsa20ue9JZKqs=.2617d216-b696-48c9-b34e-b0a97bb3bf12@github.com>
Message-ID: <C47zxVTOUeIMyATz4LgWhTZsmZ6Nk5ncQRbgNKSvTxg=.7570353c-862e-428d-b6bf-aed24b461ea9@github.com>

On Wed, 10 Feb 2021 01:49:02 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi Chris, 
>> 
>>> * Default to not parallel. Allow the user to specify `-parallel`, but not specify the thread count. They will get the default number of threads just like `parallel=0`
>>> * Default to parallel using the default number of threads. Allow the user to turn parallel off with a `-noparallel` option.
>> 
>> I would prefer the -noparallel option that enable parallel by default. IMHO, the parallel heap inspection is a little bit like parallelGCThreads -  which allowing the hotspot to decide the parallel thread number based on the platfrom by default. 
>> 
>> And I remember Serguei (@sspitsyn) and I discussed the "-parallel" option at https://mail.openjdk.java.net/pipermail/serviceability-dev/2020-September/032836.html,  we finally decide to not introduce it. just FYI. 
>> 
>>> However, this probably needs to be consistent with the jmap command and the attach API protocol, which is being discussed in #2261.
>> 
>> if just introducing new option like "parallel" or "noparallel", I think we don't need to bother about attach API protocol. we can preprocess it in JMap.java and then pass the value of "0" or "1" as parallel_thread_number, just like what it is implemented at present, no compatibility issue introduced :-)
>>  
>> 
>> Moreover, I am thinking maybe we could print a meesage like "inspected heap parallelly with `parallel_numer` threads" in the result,  just like -dump's output "Heap dump file created [18904360 bytes in 0.039 secs]"
>> 
>> Thanks, 
>> Lin
>
>> > * Default to not parallel. Allow the user to specify `-parallel`, but not specify the thread count. They will get the default number of threads just like `parallel=0`
>> > * Default to parallel using the default number of threads. Allow the user to turn parallel off with a `-noparallel` option.
>> 
>> I would prefer the -noparallel option that enable parallel by default. IMHO, the parallel heap inspection is a little bit like parallelGCThreads - which allowing the hotspot to decide the parallel thread number based on the platfrom by default.
>> 
> 
> Hi Chris, Lin,
> Thanks for discussion.
> I'm OK with either options, both ways simplify the spec and hide details from users.
> 
>> And I remember Serguei (@sspitsyn) and I discussed the "-parallel" option at https://mail.openjdk.java.net/pipermail/serviceability-dev/2020-September/032836.html, we finally decide to not introduce it. just FYI.
>> 
>> > However, this probably needs to be consistent with the jmap command and the attach API protocol, which is being discussed in #2261.
>> 
>> if just introducing new option like "parallel" or "noparallel", I think we don't need to bother about attach API protocol. we can preprocess it in JMap.java and then pass the value of "0" or "1" as parallel_thread_number, just like what it is implemented at present, no compatibility issue introduced :-)
> 
> If we decide to take either of above ways, then we should modify the uint to bool, it's more clear.
> 
>> 
>> Moreover, I am thinking maybe we could print a meesage like "inspected heap parallelly with `parallel_numer` threads" in the result, just like -dump's output "Heap dump file created [18904360 bytes in 0.039 secs]"
> 
> Agree, it helps.
> 
> BTW, I think we have mixed several threads(jcmd, jmap histo/dump) together. How about we address jmap -histo first (I filed a new bug at https://bugs.openjdk.java.net/browse/JDK-8261482), then I adjust the behavior of jcmd accordingly?
> 
> Thanks.

Hi Hamlin,

> If we decide to take either of above ways, then we should modify the uint to bool, it's more clear.

Sorry that I am a little confuse about it:
- Does it mean to disable "parallel=" option to not let user tuning the parallel thread number?  
- Or just add a "parallel" or "noparallel" option to change the default behavior? 

Both looks fine with me. But IMHO, regardless the ablility of "tunning", disabling the "parallel=" option maybe cause more backward ability issue. User of JDK16 may get error when using option like "parallel=1".  Although I am not sure how this is important since the parallel options was just introduced to JDK16 and it is not LTS.

BTW, I am not sure whether adding "parallel" requre a new CSR as there already have "parallel=" option. And seems like adding "noparallel" require one, right?  
 
> BTW, I think we have mixed several threads(jcmd, jmap histo/dump) together. How about we address jmap -histo first (I filed a new bug at https://bugs.openjdk.java.net/browse/JDK-8261482), then I adjust the behavior of jcmd accordingly?

I agree, we could start with -histo first, maybe we can discuss in this thread first and then handle it in new PR? 

Thanks, 
Lin

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

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

From lzang at openjdk.java.net  Wed Feb 10 02:31:43 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Wed, 10 Feb 2021 02:31:43 GMT
Subject: RFR: 8257234 : Add gz option to SA jmap to write a gzipped heap
 dump [v19]
In-Reply-To: <eARm7FTSUIV7R-gZ4J99XdTsdohBdixSwg-Q3AdNT0A=.b00a1c9c-e53d-4263-827b-ee4481f10b67@github.com>
References: <oTMRc7LWvx9_Uov01HPX9UgyEqFmXt_nMG920HUQBIM=.3651754b-e1f1-46f8-9f44-c118a5c56dbe@github.com>
 <PwRMr_66t_JDfAzP3aaqAB-R5HI3_YqRQMxBJTqrM08=.ceb346ca-b46b-46af-b25d-98fb7ebc0d1a@github.com>
 <eARm7FTSUIV7R-gZ4J99XdTsdohBdixSwg-Q3AdNT0A=.b00a1c9c-e53d-4263-827b-ee4481f10b67@github.com>
Message-ID: <9dyyZNLBtzI8Kj13hVIVvJgCjUDjKM-Ss5zIwYJkFm0=.544d64d3-9d64-465a-813a-32cf14aa1080@github.com>

On Wed, 10 Feb 2021 01:53:38 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> Lin Zang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   refine code in test.
>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java line 1504:
> 
>> 1502:             segmentBuffer[segmentWritten++] = (byte)(v >>>  8);
>> 1503:             segmentBuffer[segmentWritten++] = (byte)(v >>>  0);
>> 1504:         }
> 
> I'm not familiar to hprof format, but I guess we need to write them with big endian.
> Can we use `ByteBuffer::putInt` and `ByteBuffer::order` at here? I guess it makes ease to maintenance.

Nice Catch! I will make the change, Thanks @YaSuenag !

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

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

From lzang at openjdk.java.net  Wed Feb 10 02:45:43 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Wed, 10 Feb 2021 02:45:43 GMT
Subject: RFR: 8257234 : Add gz option to SA jmap to write a gzipped heap
 dump [v19]
In-Reply-To: <eARm7FTSUIV7R-gZ4J99XdTsdohBdixSwg-Q3AdNT0A=.b00a1c9c-e53d-4263-827b-ee4481f10b67@github.com>
References: <oTMRc7LWvx9_Uov01HPX9UgyEqFmXt_nMG920HUQBIM=.3651754b-e1f1-46f8-9f44-c118a5c56dbe@github.com>
 <PwRMr_66t_JDfAzP3aaqAB-R5HI3_YqRQMxBJTqrM08=.ceb346ca-b46b-46af-b25d-98fb7ebc0d1a@github.com>
 <eARm7FTSUIV7R-gZ4J99XdTsdohBdixSwg-Q3AdNT0A=.b00a1c9c-e53d-4263-827b-ee4481f10b67@github.com>
Message-ID: <2mZUx0Sg8rk0nukNcL3OwZqYNcmYaL6iAwNqSee0bIA=.85cf1d3a-61e8-414d-beb5-b517218e31a7@github.com>

On Wed, 10 Feb 2021 01:53:38 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> Lin Zang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   refine code in test.
>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java line 1504:
> 
>> 1502:             segmentBuffer[segmentWritten++] = (byte)(v >>>  8);
>> 1503:             segmentBuffer[segmentWritten++] = (byte)(v >>>  0);
>> 1504:         }
> 
> I'm not familiar to hprof format, but I guess we need to write them with big endian.
> Can we use `ByteBuffer::putInt` and `ByteBuffer::order` at here? I guess it makes ease to maintenance.

Hi @YaSuenag, 
I found there is also similar code in the original implement, in function fillInHeapRecordLength(). 
` fos.write((dumpLen >>> 24) & 0xFF);`
`  fos.write((dumpLen >>> 16) & 0xFF);`
` fos.write((dumpLen >>> 8) & 0xFF);`       
`  fos.write((dumpLen >>> 0) & 0xFF);`

Do you think it is ok to also change these codes? If my understanding is correct, the fileOutputStream does not have the process of big/little endian. 

Thanks,
Lin

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

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

From lzang at openjdk.java.net  Wed Feb 10 04:04:56 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Wed, 10 Feb 2021 04:04:56 GMT
Subject: RFR: 8257234 : Add gz option to SA jmap to write a gzipped heap
 dump [v20]
In-Reply-To: <oTMRc7LWvx9_Uov01HPX9UgyEqFmXt_nMG920HUQBIM=.3651754b-e1f1-46f8-9f44-c118a5c56dbe@github.com>
References: <oTMRc7LWvx9_Uov01HPX9UgyEqFmXt_nMG920HUQBIM=.3651754b-e1f1-46f8-9f44-c118a5c56dbe@github.com>
Message-ID: <G_Lbe4FPO42wiU-W7Y_UkV53JzqVCql2sUWJAFObFm0=.74a3d2a7-fb24-4dc7-bac4-da347b61d98f@github.com>

> 8257234 : Add gz option to SA jmap to write a gzipped heap dump

Lin Zang has updated the pull request incrementally with two additional commits since the last revision:

 - fix indentation isue
 - fix help message issue and Use ByteBuffer for integer writing

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1712/files
  - new: https://git.openjdk.java.net/jdk/pull/1712/files/6fe0f79b..7c25d58c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1712&range=19
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1712&range=18-19

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

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

From ysuenaga at openjdk.java.net  Wed Feb 10 04:26:44 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Wed, 10 Feb 2021 04:26:44 GMT
Subject: RFR: 8257234 : Add gz option to SA jmap to write a gzipped heap
 dump [v19]
In-Reply-To: <2mZUx0Sg8rk0nukNcL3OwZqYNcmYaL6iAwNqSee0bIA=.85cf1d3a-61e8-414d-beb5-b517218e31a7@github.com>
References: <oTMRc7LWvx9_Uov01HPX9UgyEqFmXt_nMG920HUQBIM=.3651754b-e1f1-46f8-9f44-c118a5c56dbe@github.com>
 <PwRMr_66t_JDfAzP3aaqAB-R5HI3_YqRQMxBJTqrM08=.ceb346ca-b46b-46af-b25d-98fb7ebc0d1a@github.com>
 <eARm7FTSUIV7R-gZ4J99XdTsdohBdixSwg-Q3AdNT0A=.b00a1c9c-e53d-4263-827b-ee4481f10b67@github.com>
 <2mZUx0Sg8rk0nukNcL3OwZqYNcmYaL6iAwNqSee0bIA=.85cf1d3a-61e8-414d-beb5-b517218e31a7@github.com>
Message-ID: <z_QuiI-owuFsRtBefgcHiKl0iPxIFG3TjgWterAhM74=.a5e4a566-ec7c-4cbc-8122-e743e6a3a90f@github.com>

On Wed, 10 Feb 2021 02:42:26 GMT, Lin Zang <lzang at openjdk.org> wrote:

> Do you think it is ok to also change these codes? If my understanding is correct, the fileOutputStream does not have the process of big/little endian.

Yes, I agree with your latest change. It looks good to me.

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

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

From ysuenaga at openjdk.java.net  Wed Feb 10 04:26:44 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Wed, 10 Feb 2021 04:26:44 GMT
Subject: RFR: 8257234 : Add gz option to SA jmap to write a gzipped heap
 dump [v20]
In-Reply-To: <G_Lbe4FPO42wiU-W7Y_UkV53JzqVCql2sUWJAFObFm0=.74a3d2a7-fb24-4dc7-bac4-da347b61d98f@github.com>
References: <oTMRc7LWvx9_Uov01HPX9UgyEqFmXt_nMG920HUQBIM=.3651754b-e1f1-46f8-9f44-c118a5c56dbe@github.com>
 <G_Lbe4FPO42wiU-W7Y_UkV53JzqVCql2sUWJAFObFm0=.74a3d2a7-fb24-4dc7-bac4-da347b61d98f@github.com>
Message-ID: <oGY-ppesG-r0OhxPxXkiK5TIz9flvHj5LB-7DnielCc=.eb6b75b6-5799-4d54-9e38-c72e2aa009b8@github.com>

On Wed, 10 Feb 2021 04:04:56 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> 8257234 : Add gz option to SA jmap to write a gzipped heap dump
>
> Lin Zang has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - fix indentation isue
>  - fix help message issue and Use ByteBuffer for integer writing

Marked as reviewed by ysuenaga (Reviewer).

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

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

From mli at openjdk.java.net  Wed Feb 10 08:16:43 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Wed, 10 Feb 2021 08:16:43 GMT
Subject: RFR: JDK-8261034: improve jcmd GC.class_histogram to support
 parallel
In-Reply-To: <C47zxVTOUeIMyATz4LgWhTZsmZ6Nk5ncQRbgNKSvTxg=.7570353c-862e-428d-b6bf-aed24b461ea9@github.com>
References: <VKzVY-01CEXUbQdlKMhDWjtjxUgpxs_6487x232VsAI=.3b9c5d8a-972b-4997-9f75-1951f98e1751@github.com>
 <X_7cTwpI8cxsVTCMi6oe6f1Fy6yPcw7b0-Pa-Ayou2Y=.69cba9c8-f6e4-40b4-a180-3eb79428692b@github.com>
 <EQm4vRIvMgIFwt3dwYO3YTdbCLyQEKjISTt-QudCNbE=.f2366e5b-b9fa-456d-bafa-6531293b2cc2@github.com>
 <gBKEb-EMtCvqvSZiS1ImsYpQg63tg6R8KaizkL-BrlE=.f51a4335-251c-4041-bd71-75ec13f0591d@github.com>
 <v4SsYZMv2DVW2v8KDDDrCMa-JlyDX6Nsa20ue9JZKqs=.2617d216-b696-48c9-b34e-b0a97bb3bf12@github.com>
 <C47zxVTOUeIMyATz4LgWhTZsmZ6Nk5ncQRbgNKSvTxg=.7570353c-862e-428d-b6bf-aed24b461ea9@github.com>
Message-ID: <oNo87kApGGMUT6MJYpvDAlyjBzza1-GmLNZSwAGrmEc=.d8669c88-6882-4744-8a05-5cadaa48404f@github.com>

On Wed, 10 Feb 2021 02:21:03 GMT, Lin Zang <lzang at openjdk.org> wrote:

>>> > * Default to not parallel. Allow the user to specify `-parallel`, but not specify the thread count. They will get the default number of threads just like `parallel=0`
>>> > * Default to parallel using the default number of threads. Allow the user to turn parallel off with a `-noparallel` option.
>>> 
>>> I would prefer the -noparallel option that enable parallel by default. IMHO, the parallel heap inspection is a little bit like parallelGCThreads - which allowing the hotspot to decide the parallel thread number based on the platfrom by default.
>>> 
>> 
>> Hi Chris, Lin,
>> Thanks for discussion.
>> I'm OK with either options, both ways simplify the spec and hide details from users.
>> 
>>> And I remember Serguei (@sspitsyn) and I discussed the "-parallel" option at https://mail.openjdk.java.net/pipermail/serviceability-dev/2020-September/032836.html, we finally decide to not introduce it. just FYI.
>>> 
>>> > However, this probably needs to be consistent with the jmap command and the attach API protocol, which is being discussed in #2261.
>>> 
>>> if just introducing new option like "parallel" or "noparallel", I think we don't need to bother about attach API protocol. we can preprocess it in JMap.java and then pass the value of "0" or "1" as parallel_thread_number, just like what it is implemented at present, no compatibility issue introduced :-)
>> 
>> If we decide to take either of above ways, then we should modify the uint to bool, it's more clear.
>> 
>>> 
>>> Moreover, I am thinking maybe we could print a meesage like "inspected heap parallelly with `parallel_numer` threads" in the result, just like -dump's output "Heap dump file created [18904360 bytes in 0.039 secs]"
>> 
>> Agree, it helps.
>> 
>> BTW, I think we have mixed several threads(jcmd, jmap histo/dump) together. How about we address jmap -histo first (I filed a new bug at https://bugs.openjdk.java.net/browse/JDK-8261482), then I adjust the behavior of jcmd accordingly?
>> 
>> Thanks.
>
> Hi Hamlin,
> 
>> If we decide to take either of above ways, then we should modify the uint to bool, it's more clear.
> 
> Sorry that I am a little confuse about it:
> - Does it mean to disable "parallel=" option to not let user tuning the parallel thread number?  
> - Or just add a "parallel" or "noparallel" option to change the default behavior? 
> 
> Both looks fine with me. But IMHO, regardless the ablility of "tunning", disabling the "parallel=" option maybe cause more backward ability issue. User of JDK16 may get error when using option like "parallel=1".  Although I am not sure how this is important since the parallel options was just introduced to JDK16 and it is not LTS.
> 
> BTW, I am not sure whether adding "parallel" requre a new CSR as there already have "parallel=" option. And seems like adding "noparallel" require one, right?  
>  
>> BTW, I think we have mixed several threads(jcmd, jmap histo/dump) together. How about we address jmap -histo first (I filed a new bug at https://bugs.openjdk.java.net/browse/JDK-8261482), then I adjust the behavior of jcmd accordingly?
> 
> I agree, we could start with -histo first, maybe we can discuss in this thread first and then handle it in new PR? 
> 
> Thanks, 
> Lin

Hi Lin,
Sure, let's discuss -histo in this thread first.

Hi @sspitsyn @plummercj @linzang 
IMHO, maybe we could make the option simple and automatically speed up heap scan by disabling "parallel=" option and adding "noparallel" at the same time? From user's point of view, "noparallel" will speed up their histo/dump automatically, if they are migrating from jdk15 or prior to jdk15, and also give them a way to fall back to previous serial scan if they would like to do that.
Although This way will introduce the compability issue, fortunately JDK16 is not LTS, and maybe we could backport to 16 updates if necessary?
How do you think about it? Thanks for discussion.

( BTW, I might not be able to response timely, as it will be long public holiday the next few days, I'm sorry for the inconvenience. )

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

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

From sgehwolf at openjdk.java.net  Wed Feb 10 08:52:36 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Wed, 10 Feb 2021 08:52:36 GMT
Subject: RFR: 8254001: [Metrics] Enhance parsing of cgroup interface files
 for version detection
In-Reply-To: <oGVjtCZ-VkXvuxH0oR8BWwE09Q2r3z6vM1j6YPwwRvE=.30e018b1-2b96-484e-b2e7-fcafb36c13f2@github.com>
References: <52vN8j9B_6s6amMHb8b_1QKyhwjCvThIz5T17aNix28=.31113ef4-61d0-4525-a3df-9aa20d408935@github.com>
 <Ynmw17EfEzNeUK5w2ABmHkXqqXo98GTcYTnZFGoAYIk=.1079ee11-c9e7-443f-b74b-d94838206a2a@github.com>
 <eFFokFwfdmu0YTyAhvPJ7xBFo0ypjHw3MyC_9-aTS6g=.80ad5876-3ae3-4ca3-96b5-08db53ed6627@github.com>
 <COWzygAauFzmvgYYP6DVjIg0MH6EDyIMx0ZzeTRHol0=.8a01079b-6e40-4b1b-bb75-e693f89d8871@github.com>
 <iT7Ltrm52E9skv98tAKIYPB1ZCaXw8ep-YSegjEnhxc=.68635047-f51c-4c60-9731-0da103e56a39@github.com>
 <m1iurC4l1M904NY7lj5eVIB8jgCfBLR2sh8XrQzhJUM=.c2c5c01f-c29a-4b22-922b-e56472e951ec@github.com>
 <Mat51HIuUYISDvMtuz4R7LJ2R1aBeGASWCyBWAXFlAI=.f3329041-9c29-4b4b-ba66-163233764fb9@github.com>
 <oGVjtCZ-VkXvuxH0oR8BWwE09Q2r3z6vM1j6YPwwRvE=.30e018b1-2b96-484e-b2e7-fcafb36c13f2@github.com>
Message-ID: <BtLX5BzcVtLRV5vwyBrN7Ia7fZPDUlHAavkSBi6h4B8=.49419748-ad8e-4b2b-9abb-6de1ad1f82f7@github.com>

On Mon, 1 Feb 2021 20:26:54 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

>> Anybody willing to review this?
>
>> Anybody willing to review this?
> 
> I can have a go.
> 
> I have two main concerns:
> 
> 1. There seems to be little documentation on the new additions. I'm particularly concerned about things like CgroupV1Subsystem.java where a big chunk of documentation on the formats being read is removed and I don't see it being moved elsewhere. Documentation on the new getInstance methods would be helpful too.
> 2. With the new volatile fields, I think it would be better if the lock being held to initialise them was only held when necessary to perform the assignment. Holding it while performing an extensive process of parsing multiple files that could potentially fail seems a little dangerous. i.e. something like:
> if (INSTANCE == null) { CGroupV1Subsystem tmp = initSubSystem(infos); synchronized (CgroupV1Subsystem.class) { if (INSTANCE == null) { INSTANCE = tmp; } } }

@gnu-andrew  Let me know what you think of the updated patch! Thanks.

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

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

From kevinw at openjdk.java.net  Wed Feb 10 09:18:37 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Wed, 10 Feb 2021 09:18:37 GMT
Subject: RFR: 8261431: SA: Add comments about load address of executable
In-Reply-To: <tTSRlEL6jGzU4fHk36ARVR3NTssnQQIvDwTXH8xHZAs=.95bf2519-5f16-41aa-b24e-8b9cf600fa7a@github.com>
References: <tTSRlEL6jGzU4fHk36ARVR3NTssnQQIvDwTXH8xHZAs=.95bf2519-5f16-41aa-b24e-8b9cf600fa7a@github.com>
Message-ID: <dIlXvyzUNaarNWnZKLeF6KEYc8A4FVP6G8I-e0VT1hI=.5b5884c8-a743-4be2-a0fa-421b596652ae@github.com>

On Tue, 9 Feb 2021 12:22:00 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> I removed the comment about load address of executable in [JDK-8248876](https://bugs.openjdk.java.net/browse/JDK-8248876) (#2366), but it contained useful information for maintenance.
> 
> So I re-add them, and add comment for the change in JDK-8248876. Please see https://github.com/openjdk/jdk/pull/2366#issuecomment-775362982

Marked as reviewed by kevinw (Committer).

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

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

From ysuenaga at openjdk.java.net  Wed Feb 10 11:57:42 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Wed, 10 Feb 2021 11:57:42 GMT
Subject: RFR: 8261431: SA: Add comments about load address of executable
In-Reply-To: <dIlXvyzUNaarNWnZKLeF6KEYc8A4FVP6G8I-e0VT1hI=.5b5884c8-a743-4be2-a0fa-421b596652ae@github.com>
References: <tTSRlEL6jGzU4fHk36ARVR3NTssnQQIvDwTXH8xHZAs=.95bf2519-5f16-41aa-b24e-8b9cf600fa7a@github.com>
 <dIlXvyzUNaarNWnZKLeF6KEYc8A4FVP6G8I-e0VT1hI=.5b5884c8-a743-4be2-a0fa-421b596652ae@github.com>
Message-ID: <6DVPmrjbhPswjkwtuc-G3zRoOV87koR98xMA4gFWbLk=.1b7ef0f8-8e6e-44d7-a7a6-ad9aeb6310df@github.com>

On Wed, 10 Feb 2021 09:15:23 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> I removed the comment about load address of executable in [JDK-8248876](https://bugs.openjdk.java.net/browse/JDK-8248876) (#2366), but it contained useful information for maintenance.
>> 
>> So I re-add them, and add comment for the change in JDK-8248876. Please see https://github.com/openjdk/jdk/pull/2366#issuecomment-775362982
>
> Marked as reviewed by kevinw (Committer).

Thanks @kevinjwalls !

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

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

From kevinw at openjdk.java.net  Wed Feb 10 17:56:39 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Wed, 10 Feb 2021 17:56:39 GMT
Subject: RFR: 8247514: Improve clhsdb 'findpc' ability to determine what
 an address points to by improving PointerFinder and PointerLocation classes
In-Reply-To: <4YKNpyXQ9QGrLhR61tkh71Q3A7VvCj5Ete_4OvzAA-o=.28b7be8c-6f05-42d4-892b-87ebea907b24@github.com>
References: <4YKNpyXQ9QGrLhR61tkh71Q3A7VvCj5Ete_4OvzAA-o=.28b7be8c-6f05-42d4-892b-87ebea907b24@github.com>
Message-ID: <jGQzriJOk89MStnvek6uh8KfpX5HKm7gbWIuhnYPoCU=.917470a4-d1be-401b-aeda-3a4d475668f6@github.com>

On Sun, 17 Jan 2021 03:57:59 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> See the bug for most details. A few notes here about some implementation details:
> 
> In the `PointerLocation` class, I added more consistency w.r.t. whether or not a newline is printed. It used to for some address types, but not others. Now it always does. And if you see a comment something like the following:
> 
> `         getTLAB().printOn(tty); // includes "\n" `
> 
> That's just clarifying whether or not the `printOn()` method called will include the newline. Some do and some don't, and knowing what the various `printOn()` methods do makes getting the proper inclusion of the newline easier to understand.
> 
> I added `verbose` and `printAddress` boolean arguments to `PointerLocation.printOn()`. Currently they are always `true`. The false arguments will be used when I complete [JDK-8250801](https://bugs.openjdk.java.net/browse/JDK-8250801), which will use `PointerFinder/Location` to show what each register points to.
> 
> The CR mentions that the main motivation for this work is for eventual replacement of the old clhsdb `whatis` command, which was implemented in javascript. It used to resolve DSO symbols, whereas `findpc` did not. The `whatis` code did this with the following:
> 
>   var dso = loadObjectContainingPC(addr);
>   if (dso == null) {
>     return ptrLoc.toString();
>   }
>   var sym = dso.closestSymbolToPC(addr);
>   if (sym != null) {
>     return sym.name + '+' + sym.offset;
>   }
> And now you'll see something similar in the PointerFinder code:
> 
>         loc.loadObject = cdbg.loadObjectContainingPC(a);
>         if (loc.loadObject != null) {
>             loc.nativeSymbol = loc.loadObject.closestSymbolToPC(a);
>             return loc;
>         } 
> Note that now that `findpc` does everything that `whatis` used to (and more), we don't really need to add a java version of `whatis`, but I'll probably do so anyway just help out people who are used to using the `whatis` command. That will be done using [JDK-8244670](https://bugs.openjdk.java.net/browse/JDK-8244670)

Looks good, thanks.
(Comment in PointerLocation.java, treat as you see fit.)

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/PointerLocation.java line 247:

> 245:                        stackThread.getStackBase(), stackThread.lastSPDbg(),
> 246:                        stackThread.getStackBase().addOffsetTo(-stackThread.getStackSize()),
> 247:                        stackThread);

When we print a JavaThread, in the verbose block,
the final argument to tty.format in line 247, I wonder what that prints?

We then call printThreadInfoOn() which will first print the quoted thread name,
so maybe we don't need that item.
Or maybe we want the JavaThread.toString()?

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

Marked as reviewed by kevinw (Committer).

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

From cjplummer at openjdk.java.net  Wed Feb 10 21:14:43 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 10 Feb 2021 21:14:43 GMT
Subject: RFR: 8247514: Improve clhsdb 'findpc' ability to determine what
 an address points to by improving PointerFinder and PointerLocation classes
In-Reply-To: <jGQzriJOk89MStnvek6uh8KfpX5HKm7gbWIuhnYPoCU=.917470a4-d1be-401b-aeda-3a4d475668f6@github.com>
References: <4YKNpyXQ9QGrLhR61tkh71Q3A7VvCj5Ete_4OvzAA-o=.28b7be8c-6f05-42d4-892b-87ebea907b24@github.com>
 <jGQzriJOk89MStnvek6uh8KfpX5HKm7gbWIuhnYPoCU=.917470a4-d1be-401b-aeda-3a4d475668f6@github.com>
Message-ID: <3oj2UVlWuk4yylfNEKxWcKSqUAw7p0oG9C9QsGxYidc=.6ddd8f76-bba7-43b4-b508-c55ab893c7d1@github.com>

On Wed, 10 Feb 2021 17:52:59 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> See the bug for most details. A few notes here about some implementation details:
>> 
>> In the `PointerLocation` class, I added more consistency w.r.t. whether or not a newline is printed. It used to for some address types, but not others. Now it always does. And if you see a comment something like the following:
>> 
>> `         getTLAB().printOn(tty); // includes "\n" `
>> 
>> That's just clarifying whether or not the `printOn()` method called will include the newline. Some do and some don't, and knowing what the various `printOn()` methods do makes getting the proper inclusion of the newline easier to understand.
>> 
>> I added `verbose` and `printAddress` boolean arguments to `PointerLocation.printOn()`. Currently they are always `true`. The false arguments will be used when I complete [JDK-8250801](https://bugs.openjdk.java.net/browse/JDK-8250801), which will use `PointerFinder/Location` to show what each register points to.
>> 
>> The CR mentions that the main motivation for this work is for eventual replacement of the old clhsdb `whatis` command, which was implemented in javascript. It used to resolve DSO symbols, whereas `findpc` did not. The `whatis` code did this with the following:
>> 
>>   var dso = loadObjectContainingPC(addr);
>>   if (dso == null) {
>>     return ptrLoc.toString();
>>   }
>>   var sym = dso.closestSymbolToPC(addr);
>>   if (sym != null) {
>>     return sym.name + '+' + sym.offset;
>>   }
>> And now you'll see something similar in the PointerFinder code:
>> 
>>         loc.loadObject = cdbg.loadObjectContainingPC(a);
>>         if (loc.loadObject != null) {
>>             loc.nativeSymbol = loc.loadObject.closestSymbolToPC(a);
>>             return loc;
>>         } 
>> Note that now that `findpc` does everything that `whatis` used to (and more), we don't really need to add a java version of `whatis`, but I'll probably do so anyway just help out people who are used to using the `whatis` command. That will be done using [JDK-8244670](https://bugs.openjdk.java.net/browse/JDK-8244670)
>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/PointerLocation.java line 247:
> 
>> 245:                        stackThread.getStackBase(), stackThread.lastSPDbg(),
>> 246:                        stackThread.getStackBase().addOffsetTo(-stackThread.getStackSize()),
>> 247:                        stackThread);
> 
> When we print a JavaThread, in the verbose block,
> the final argument to tty.format in line 247, I wonder what that prints?
> 
> We then call printThreadInfoOn() which will first print the quoted thread name,
> so maybe we don't need that item.
> Or maybe we want the JavaThread.toString()?

`stackThread.toString()` ends up in `VMObject.toString()`:

  public String toString() {
    return getClass().getName() + "@" + addr;
  }
And here's an example output:
hsdb> + findpc 0x0000152f45df6000
Address 0x0000152f45df6000: In java stack [0x0000152f45df8000,0x0000152f45df6580,0x0000152f45cf7000] for thread sun.jvm.hotspot.runtime.JavaThread at 0x0000152f3c026f70:
   "main" #1 prio=5 tid=0x0000152f3c026f70 nid=0x308e waiting on condition [0x0000152f45df6000]
   java.lang.Thread.State: TIMED_WAITING (sleeping)
   JavaThread state: _thread_blocked
So I think the `stackThread` argument is doing what was intended, and there is no duplication in the output.

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

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

From amenkov at openjdk.java.net  Wed Feb 10 22:20:39 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Wed, 10 Feb 2021 22:20:39 GMT
Subject: Integrated: 8248162:
 serviceability/attach/RemovingUnixDomainSocketTest.java failed
In-Reply-To: <mw3-hXbMOC5XQQyQX5ySpBaWT3kEck9diGpIi_q1fJ0=.a82d3ce3-0cc5-40fa-9b43-99c7f5d090e2@github.com>
References: <mw3-hXbMOC5XQQyQX5ySpBaWT3kEck9diGpIi_q1fJ0=.a82d3ce3-0cc5-40fa-9b43-99c7f5d090e2@github.com>
Message-ID: <8-EowkT38dD06lkbg7--JIrLieliLWJzgXpmGJq2pzM=.5d572a0d-018b-4b47-932b-9605dcec60fd@github.com>

On Fri, 5 Feb 2021 21:09:37 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> JDK-8258917 fixed non-java launchers ("wrong launcher" VM warning for tools).
> The fix un-problemlists RemovingUnixDomainSocketTest and changes serviceability tests to use OutputAnalyzer.stderrShouldBeEmptyIgnoreDeprecatedWarnings instead of stderrShouldBeEmptyIgnoreVMWarnings

This pull request has now been integrated.

Changeset: cc5691c6
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/cc5691c6
Stats:     11 lines in 7 files changed: 0 ins; 2 del; 9 mod

8248162: serviceability/attach/RemovingUnixDomainSocketTest.java failed

Reviewed-by: cjplummer, sspitsyn

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

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

From cjplummer at openjdk.java.net  Wed Feb 10 22:50:46 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 10 Feb 2021 22:50:46 GMT
Subject: RFR: JDK-8261034: improve jcmd GC.class_histogram to support
 parallel
In-Reply-To: <oNo87kApGGMUT6MJYpvDAlyjBzza1-GmLNZSwAGrmEc=.d8669c88-6882-4744-8a05-5cadaa48404f@github.com>
References: <VKzVY-01CEXUbQdlKMhDWjtjxUgpxs_6487x232VsAI=.3b9c5d8a-972b-4997-9f75-1951f98e1751@github.com>
 <X_7cTwpI8cxsVTCMi6oe6f1Fy6yPcw7b0-Pa-Ayou2Y=.69cba9c8-f6e4-40b4-a180-3eb79428692b@github.com>
 <EQm4vRIvMgIFwt3dwYO3YTdbCLyQEKjISTt-QudCNbE=.f2366e5b-b9fa-456d-bafa-6531293b2cc2@github.com>
 <gBKEb-EMtCvqvSZiS1ImsYpQg63tg6R8KaizkL-BrlE=.f51a4335-251c-4041-bd71-75ec13f0591d@github.com>
 <v4SsYZMv2DVW2v8KDDDrCMa-JlyDX6Nsa20ue9JZKqs=.2617d216-b696-48c9-b34e-b0a97bb3bf12@github.com>
 <C47zxVTOUeIMyATz4LgWhTZsmZ6Nk5ncQRbgNKSvTxg=.7570353c-862e-428d-b6bf-aed24b461ea9@github.com>
 <oNo87kApGGMUT6MJYpvDAlyjBzza1-GmLNZSwAGrmEc=.d8669c88-6882-4744-8a05-5cadaa48404f@github.com>
Message-ID: <A-u0xkGoB54J-q4yyOu-fXBqvXkTRLnmje8qh1KUTTE=.75f97621-8e70-4ab4-b54f-f45b37bd84f5@github.com>

On Wed, 10 Feb 2021 08:13:33 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi Hamlin,
>> 
>>> If we decide to take either of above ways, then we should modify the uint to bool, it's more clear.
>> 
>> Sorry that I am a little confuse about it:
>> - Does it mean to disable "parallel=" option to not let user tuning the parallel thread number?  
>> - Or just add a "parallel" or "noparallel" option to change the default behavior? 
>> 
>> Both looks fine with me. But IMHO, regardless the ablility of "tunning", disabling the "parallel=" option maybe cause more backward ability issue. User of JDK16 may get error when using option like "parallel=1".  Although I am not sure how this is important since the parallel options was just introduced to JDK16 and it is not LTS.
>> 
>> BTW, I am not sure whether adding "parallel" requre a new CSR as there already have "parallel=" option. And seems like adding "noparallel" require one, right?  
>>  
>>> BTW, I think we have mixed several threads(jcmd, jmap histo/dump) together. How about we address jmap -histo first (I filed a new bug at https://bugs.openjdk.java.net/browse/JDK-8261482), then I adjust the behavior of jcmd accordingly?
>> 
>> I agree, we could start with -histo first, maybe we can discuss in this thread first and then handle it in new PR? 
>> 
>> Thanks, 
>> Lin
>
> Hi Lin,
> Sure, let's discuss -histo in this thread first.
> 
> Hi @sspitsyn @plummercj @linzang 
> My following point is based on my humble opinion that parallel=N is not necessary for user and we should use the largest parallel capability of JVM to do heap histo when user intend to do it in parallel. But if you think this basic opinion is not that correct, please kindly ignore following opinion. :-)
> IMHO, maybe we could make the option simple and automatically speed up heap scan by disabling "parallel=" option and adding "noparallel" at the same time? From user's point of view, "noparallel" will speed up their histo/dump automatically, if they are migrating from jdk15 or prior to jdk15, and also give them a way to fall back to previous serial scan if they would like to do that. Although This way will introduce the compability issue, fortunately JDK16 is not LTS, and maybe we could backport to 16 updates if necessary?
> How do you think about it? Thanks for discussion.
> 
> ( BTW, I might not be able to response timely, as it will be long public holiday the next few days, I'm sorry for the inconvenience. )

I'm in favor of just having a `noparallel` option (default to using parallel) instead of using `parallel=<n>`. This would be for both the histo and heap dump features, and for both the `jmap` and `jcmd` support of these features.

As for the current `parallel=<n>` support for jmap histo already in JDK 16, hopefully there would be no objections to removing that in JDK 17 in favor of the `noparallel` approach, but I think the CSR for that change should get some good scrutiny. I think it would good to get approval from @AlanBateman and/or @dholmes-ora since they are both in the CSR group and have good serviceability knowledge.

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

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

From cjplummer at openjdk.java.net  Thu Feb 11 00:06:48 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 11 Feb 2021 00:06:48 GMT
Subject: RFR: 8247514: Improve clhsdb 'findpc' ability to determine what
 an address points to by improving PointerFinder and PointerLocation classes
 [v2]
In-Reply-To: <4YKNpyXQ9QGrLhR61tkh71Q3A7VvCj5Ete_4OvzAA-o=.28b7be8c-6f05-42d4-892b-87ebea907b24@github.com>
References: <4YKNpyXQ9QGrLhR61tkh71Q3A7VvCj5Ete_4OvzAA-o=.28b7be8c-6f05-42d4-892b-87ebea907b24@github.com>
Message-ID: <eoZ1S-OYf5nHIyil8AsGRUNE7l2_I6KzgegItpHlYUQ=.f43e7ab6-db04-4dc0-8971-a96a354c8ba9@github.com>

> See the bug for most details. A few notes here about some implementation details:
> 
> In the `PointerLocation` class, I added more consistency w.r.t. whether or not a newline is printed. It used to for some address types, but not others. Now it always does. And if you see a comment something like the following:
> 
> `         getTLAB().printOn(tty); // includes "\n" `
> 
> That's just clarifying whether or not the `printOn()` method called will include the newline. Some do and some don't, and knowing what the various `printOn()` methods do makes getting the proper inclusion of the newline easier to understand.
> 
> I added `verbose` and `printAddress` boolean arguments to `PointerLocation.printOn()`. Currently they are always `true`. The false arguments will be used when I complete [JDK-8250801](https://bugs.openjdk.java.net/browse/JDK-8250801), which will use `PointerFinder/Location` to show what each register points to.
> 
> The CR mentions that the main motivation for this work is for eventual replacement of the old clhsdb `whatis` command, which was implemented in javascript. It used to resolve DSO symbols, whereas `findpc` did not. The `whatis` code did this with the following:
> 
>   var dso = loadObjectContainingPC(addr);
>   if (dso == null) {
>     return ptrLoc.toString();
>   }
>   var sym = dso.closestSymbolToPC(addr);
>   if (sym != null) {
>     return sym.name + '+' + sym.offset;
>   }
> And now you'll see something similar in the PointerFinder code:
> 
>         loc.loadObject = cdbg.loadObjectContainingPC(a);
>         if (loc.loadObject != null) {
>             loc.nativeSymbol = loc.loadObject.closestSymbolToPC(a);
>             return loc;
>         } 
> Note that now that `findpc` does everything that `whatis` used to (and more), we don't really need to add a java version of `whatis`, but I'll probably do so anyway just help out people who are used to using the `whatis` command. That will be done using [JDK-8244670](https://bugs.openjdk.java.net/browse/JDK-8244670)

Chris Plummer 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 master
 - Improvements for PointerFinder and findpc command.

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

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

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

From lzang at openjdk.java.net  Thu Feb 11 02:40:47 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Thu, 11 Feb 2021 02:40:47 GMT
Subject: RFR: 8261482: Adjust jmap -histo to accept noparallel option to
 inspect heap serially
Message-ID: <friAzRs8vnY7hHEUc-fiL0KSGmEiAnZ9Lckg76-t8cM=.9bf22703-d312-4bad-bd28-2571170637af@github.com>

8261482: Adjust jmap -histo to accept noparallel option to inspect heap serially

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

Commit messages:
 - 8261482: Adjust jmap -histo to accept noparallel option to inspect heap serially

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

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

From lzang at openjdk.java.net  Thu Feb 11 02:42:45 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Thu, 11 Feb 2021 02:42:45 GMT
Subject: RFR: JDK-8261034: improve jcmd GC.class_histogram to support
 parallel
In-Reply-To: <A-u0xkGoB54J-q4yyOu-fXBqvXkTRLnmje8qh1KUTTE=.75f97621-8e70-4ab4-b54f-f45b37bd84f5@github.com>
References: <VKzVY-01CEXUbQdlKMhDWjtjxUgpxs_6487x232VsAI=.3b9c5d8a-972b-4997-9f75-1951f98e1751@github.com>
 <X_7cTwpI8cxsVTCMi6oe6f1Fy6yPcw7b0-Pa-Ayou2Y=.69cba9c8-f6e4-40b4-a180-3eb79428692b@github.com>
 <EQm4vRIvMgIFwt3dwYO3YTdbCLyQEKjISTt-QudCNbE=.f2366e5b-b9fa-456d-bafa-6531293b2cc2@github.com>
 <gBKEb-EMtCvqvSZiS1ImsYpQg63tg6R8KaizkL-BrlE=.f51a4335-251c-4041-bd71-75ec13f0591d@github.com>
 <v4SsYZMv2DVW2v8KDDDrCMa-JlyDX6Nsa20ue9JZKqs=.2617d216-b696-48c9-b34e-b0a97bb3bf12@github.com>
 <C47zxVTOUeIMyATz4LgWhTZsmZ6Nk5ncQRbgNKSvTxg=.7570353c-862e-428d-b6bf-aed24b461ea9@github.com>
 <oNo87kApGGMUT6MJYpvDAlyjBzza1-GmLNZSwAGrmEc=.d8669c88-6882-4744-8a05-5cadaa48404f@github.com>
 <A-u0xkGoB54J-q4yyOu-fXBqvXkTRLnmje8qh1KUTTE=.75f97621-8e70-4ab4-b54f-f45b37bd84f5@github.com>
Message-ID: <hZpMlhWW1rB89tC-Wj_DH9R05YcOFOaqkFprf9MwBD4=.755ccfc2-b743-4037-8f0c-69c078937c5e@github.com>

On Wed, 10 Feb 2021 22:47:28 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Hi Lin,
>> Sure, let's discuss -histo in this thread first.
>> 
>> Hi @sspitsyn @plummercj @linzang 
>> My following point is based on my humble opinion that parallel=N is not necessary for user and we should use the largest parallel capability of JVM to do heap histo when user intend to do it in parallel. But if you think this basic opinion is not that correct, please kindly ignore following opinion. :-)
>> IMHO, maybe we could make the option simple and automatically speed up heap scan by disabling "parallel=" option and adding "noparallel" at the same time? From user's point of view, "noparallel" will speed up their histo/dump automatically, if they are migrating from jdk15 or prior to jdk15, and also give them a way to fall back to previous serial scan if they would like to do that. Although This way will introduce the compability issue, fortunately JDK16 is not LTS, and maybe we could backport to 16 updates if necessary?
>> How do you think about it? Thanks for discussion.
>> 
>> ( BTW, I might not be able to response timely, as it will be long public holiday the next few days, I'm sorry for the inconvenience. )
>
> I'm in favor of just having a `noparallel` option (default to using parallel) instead of using `parallel=<n>`. This would be for both the histo and heap dump features, and for both the `jmap` and `jcmd` support of these features.
> 
> As for the current `parallel=<n>` support for jmap histo already in JDK 16, hopefully there would be no objections to removing that in JDK 17 in favor of the `noparallel` approach, but I think the CSR for that change should get some good scrutiny. I think it would good to get approval from @AlanBateman and/or @dholmes-ora since they are both in the CSR group and have good serviceability knowledge.
> 
> For reference, the JDK 16 CSR for adding `parallel=<n>` support to `jmap -histo` is [8239290](https://bugs.openjdk.java.net/browse/JDK-8239290), and the bug to change this to a `noparallel` opiton in JDK 17 is [JDK-8261482](https://bugs.openjdk.java.net/browse/JDK-8261482). I don't think there is a CSR yet.

Dear All, 
I took the liberity to create a PR (#2519) for the "noparallel" option. Maybe we could discuss there.  And I also found @Hamlin-Li has created a CSR for that. Thanks a lot!

BRs,
Lin

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

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

From lzang at openjdk.java.net  Thu Feb 11 02:46:38 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Thu, 11 Feb 2021 02:46:38 GMT
Subject: RFR: 8261482: Adjust jmap histo command to accept noparallel
 option to inspect heap serially
In-Reply-To: <friAzRs8vnY7hHEUc-fiL0KSGmEiAnZ9Lckg76-t8cM=.9bf22703-d312-4bad-bd28-2571170637af@github.com>
References: <friAzRs8vnY7hHEUc-fiL0KSGmEiAnZ9Lckg76-t8cM=.9bf22703-d312-4bad-bd28-2571170637af@github.com>
Message-ID: <Tw5mfybEuzyGsoqGNDMD3ZAVc4m-m3Pq2aJIshAphZc=.a904f0ce-a8f8-4a03-80fb-29e3b33dcd6d@github.com>

On Thu, 11 Feb 2021 02:36:01 GMT, Lin Zang <lzang at openjdk.org> wrote:

> 8261482: Adjust jmap histo command to accept noparallel option to inspect heap serially

Dear All,
     Stories and discussions related with this PR could be found at #2379 and #2261.  Just FYI.
BRs,
Lin

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

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

From kevinw at openjdk.java.net  Thu Feb 11 09:00:44 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 11 Feb 2021 09:00:44 GMT
Subject: RFR: 8247514: Improve clhsdb 'findpc' ability to determine what
 an address points to by improving PointerFinder and PointerLocation classes
 [v2]
In-Reply-To: <3oj2UVlWuk4yylfNEKxWcKSqUAw7p0oG9C9QsGxYidc=.6ddd8f76-bba7-43b4-b508-c55ab893c7d1@github.com>
References: <4YKNpyXQ9QGrLhR61tkh71Q3A7VvCj5Ete_4OvzAA-o=.28b7be8c-6f05-42d4-892b-87ebea907b24@github.com>
 <jGQzriJOk89MStnvek6uh8KfpX5HKm7gbWIuhnYPoCU=.917470a4-d1be-401b-aeda-3a4d475668f6@github.com>
 <3oj2UVlWuk4yylfNEKxWcKSqUAw7p0oG9C9QsGxYidc=.6ddd8f76-bba7-43b4-b508-c55ab893c7d1@github.com>
Message-ID: <ee8IbsXsZr-APDonDPg2rVCS9ENj8h2OLeIPHNXOKOs=.04d5e337-b130-448b-b3d3-c410a3e98d99@github.com>

On Wed, 10 Feb 2021 21:12:19 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/PointerLocation.java line 247:
>> 
>>> 245:                        stackThread.getStackBase(), stackThread.lastSPDbg(),
>>> 246:                        stackThread.getStackBase().addOffsetTo(-stackThread.getStackSize()),
>>> 247:                        stackThread);
>> 
>> When we print a JavaThread, in the verbose block,
>> the final argument to tty.format in line 247, I wonder what that prints?
>> 
>> We then call printThreadInfoOn() which will first print the quoted thread name,
>> so maybe we don't need that item.
>> Or maybe we want the JavaThread.toString()?
>
> `stackThread.toString()` ends up in `VMObject.toString()`:
> 
>   public String toString() {
>     return getClass().getName() + "@" + addr;
>   }
> And here's an example output:
> hsdb> + findpc 0x0000152f45df6000
> Address 0x0000152f45df6000: In java stack [0x0000152f45df8000,0x0000152f45df6580,0x0000152f45cf7000] for thread sun.jvm.hotspot.runtime.JavaThread at 0x0000152f3c026f70:
>    "main" #1 prio=5 tid=0x0000152f3c026f70 nid=0x308e waiting on condition [0x0000152f45df6000]
>    java.lang.Thread.State: TIMED_WAITING (sleeping)
>    JavaThread state: _thread_blocked
> So I think the `stackThread` argument is doing what was intended, and there is no duplication in the output.

Great, thanks.

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

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

From ysuenaga at openjdk.java.net  Thu Feb 11 15:00:46 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Thu, 11 Feb 2021 15:00:46 GMT
Subject: Integrated: 8261431: SA: Add comments about load address of executable
In-Reply-To: <tTSRlEL6jGzU4fHk36ARVR3NTssnQQIvDwTXH8xHZAs=.95bf2519-5f16-41aa-b24e-8b9cf600fa7a@github.com>
References: <tTSRlEL6jGzU4fHk36ARVR3NTssnQQIvDwTXH8xHZAs=.95bf2519-5f16-41aa-b24e-8b9cf600fa7a@github.com>
Message-ID: <envXqQmNFu72MSgezozhK4D_MGf-9n3zpMW3E7MCyNQ=.9f38c992-fb0d-451f-a303-f2accf606937@github.com>

On Tue, 9 Feb 2021 12:22:00 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> I removed the comment about load address of executable in [JDK-8248876](https://bugs.openjdk.java.net/browse/JDK-8248876) (#2366), but it contained useful information for maintenance.
> 
> So I re-add them, and add comment for the change in JDK-8248876. Please see https://github.com/openjdk/jdk/pull/2366#issuecomment-775362982

This pull request has now been integrated.

Changeset: c342323c
Author:    Yasumasa Suenaga <ysuenaga at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c342323c
Stats:     4 lines in 1 file changed: 4 ins; 0 del; 0 mod

8261431: SA: Add comments about load address of executable

Reviewed-by: sspitsyn, kevinw

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

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

From hseigel at openjdk.java.net  Thu Feb 11 19:54:44 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Thu, 11 Feb 2021 19:54:44 GMT
Subject: RFR: 8254001: [Metrics] Enhance parsing of cgroup interface files
 for version detection [v4]
In-Reply-To: <3x47AFywS6_XcwXLLRw-js174URG35nifn1_G19vsKc=.b5ad4fdc-e040-44bc-a7fd-6fe7268dc341@github.com>
References: <52vN8j9B_6s6amMHb8b_1QKyhwjCvThIz5T17aNix28=.31113ef4-61d0-4525-a3df-9aa20d408935@github.com>
 <3x47AFywS6_XcwXLLRw-js174URG35nifn1_G19vsKc=.b5ad4fdc-e040-44bc-a7fd-6fe7268dc341@github.com>
Message-ID: <rXq1Ad-_1c9NU7PI8ukyb1OG0XbEvQKi_krW6I2NAJQ=.732d2731-d617-4808-be1a-41a243a2d9c3@github.com>

On Tue, 9 Feb 2021 13:31:25 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> This is an enhancement which solves two issues:
>> 
>> 1. Multiple reads of relevant cgroup interface files. Now interface files are only read once per file (just like Hotspot).
>> 2. Proxies creation of the impl specific subsystem via `determineType()` as before, but now reads all relevant interface files: `/proc/cgroups`, `/proc/self/mountinfo` and `/proc/self/cgroup`. Once read it passes the parsed information to the impl specific subsystem classes for instantiation. This allows for more flexibility of testing as interface files can be mocked and, thus, more cases can be tested that way without having access to these specific systems. For example, proper regression tests for JDK-8217766 and JDK-8253435 have been added now with this in place.
>> 
>> * [x] Tested on Linux x86_64 on cgroups v1 and cgroups v2. Container tests pass.
>
> Severin Gehwolf 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:
> 
>  - Fix jcheck
>  - Add documentation and reduce code running in the critical section
>  - Add some documentation
>  - Merge branch 'master' into jdk-8254001-enhance-file-parsing-java-metrics
>  - Merge branch 'master' into jdk-8254001-enhance-file-parsing-java-metrics
>  - Merge branch 'master' into jdk-8254001-enhance-file-parsing-java-metrics
>  - 8254001: [Metrics] Enhance parsing of cgroup interface files for version detection

Hi Severin,
Thanks for doing this!  Sorry for taking so long to review this change.  The change looks good.  Before pushing it, could you add a comment explaining what the code in lines 185-194 of CgroupSubsystemFactory.java is doing?  Also, please don't overwrite the fix for JDK-8257746.
Thanks again! Harold

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

Marked as reviewed by hseigel (Reviewer).

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

From dcubed at openjdk.java.net  Thu Feb 11 22:11:46 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 11 Feb 2021 22:11:46 GMT
Subject: RFR: 8241403: JavaThread::get_thread_name() should be
 ThreadSMR-aware
In-Reply-To: <wRdcRQurtpybntK9Qpji-6zVY-EcHKw3q87xpD0eoS4=.a6dc32f4-2919-42e9-80c3-5a264067f0e2@github.com>
References: <wRdcRQurtpybntK9Qpji-6zVY-EcHKw3q87xpD0eoS4=.a6dc32f4-2919-42e9-80c3-5a264067f0e2@github.com>
Message-ID: <xQoZYSsTFwrQsKmPBUYXFiTK-cMTcir0GHh-Fkf3KN4=.7dccb719-46b0-491c-af11-48c0379d1363@github.com>

On Thu, 11 Feb 2021 22:04:53 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A minor fix to add a new function:
> 
>     bool Thread::is_JavaThread_protected(const JavaThread* p)
> 
> that returns true when the target JavaThread* is protected and false
> otherwise. Update JavaThread::get_thread_name() to create a
> ThreadsListHandle and use the new is_JavaThread_protected(). Also
> update JvmtiTrace::safe_get_thread_name() to use the new
> is_JavaThread_protected().

@dholmes-ora and @fisk - It looks like both of you are interested
in this fix. @robehn - This one is Thread-SMR related so you might
also want to take a look.

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

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

From dcubed at openjdk.java.net  Thu Feb 11 22:11:46 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 11 Feb 2021 22:11:46 GMT
Subject: RFR: 8241403: JavaThread::get_thread_name() should be ThreadSMR-aware
Message-ID: <wRdcRQurtpybntK9Qpji-6zVY-EcHKw3q87xpD0eoS4=.a6dc32f4-2919-42e9-80c3-5a264067f0e2@github.com>

A minor fix to add a new function:

    bool Thread::is_JavaThread_protected(const JavaThread* p)

that returns true when the target JavaThread* is protected and false
otherwise. Update JavaThread::get_thread_name() to create a
ThreadsListHandle and use the new is_JavaThread_protected(). Also
update JvmtiTrace::safe_get_thread_name() to use the new
is_JavaThread_protected().

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

Commit messages:
 - 8241403: JavaThread::get_thread_name() should be ThreadSMR-aware

Changes: https://git.openjdk.java.net/jdk/pull/2535/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2535&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8241403
  Stats: 51 lines in 4 files changed: 26 ins; 9 del; 16 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2535.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2535/head:pull/2535

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

From dcubed at openjdk.java.net  Thu Feb 11 22:11:46 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 11 Feb 2021 22:11:46 GMT
Subject: RFR: 8241403: JavaThread::get_thread_name() should be
 ThreadSMR-aware
In-Reply-To: <xQoZYSsTFwrQsKmPBUYXFiTK-cMTcir0GHh-Fkf3KN4=.7dccb719-46b0-491c-af11-48c0379d1363@github.com>
References: <wRdcRQurtpybntK9Qpji-6zVY-EcHKw3q87xpD0eoS4=.a6dc32f4-2919-42e9-80c3-5a264067f0e2@github.com>
 <xQoZYSsTFwrQsKmPBUYXFiTK-cMTcir0GHh-Fkf3KN4=.7dccb719-46b0-491c-af11-48c0379d1363@github.com>
Message-ID: <BN-6c1oHUGj2OvyldIo0nIDE-EF_SvZ8xwJwMBQ_nf0=.38749866-2a4a-4474-908f-e30f2e18dea8@github.com>

On Thu, 11 Feb 2021 22:07:22 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> A minor fix to add a new function:
>> 
>>     bool Thread::is_JavaThread_protected(const JavaThread* p)
>> 
>> that returns true when the target JavaThread* is protected and false
>> otherwise. Update JavaThread::get_thread_name() to create a
>> ThreadsListHandle and use the new is_JavaThread_protected(). Also
>> update JvmtiTrace::safe_get_thread_name() to use the new
>> is_JavaThread_protected().
>
> @dholmes-ora and @fisk - It looks like both of you are interested
> in this fix. @robehn - This one is Thread-SMR related so you might
> also want to take a look.

@sspitsyn - I'm making a minor JVM/TI tracing tweak here so this
might also interest you.

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

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

From cjplummer at openjdk.java.net  Thu Feb 11 22:53:41 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 11 Feb 2021 22:53:41 GMT
Subject: RFR: JDK-8261034: improve jcmd GC.class_histogram to support
 parallel
In-Reply-To: <hZpMlhWW1rB89tC-Wj_DH9R05YcOFOaqkFprf9MwBD4=.755ccfc2-b743-4037-8f0c-69c078937c5e@github.com>
References: <VKzVY-01CEXUbQdlKMhDWjtjxUgpxs_6487x232VsAI=.3b9c5d8a-972b-4997-9f75-1951f98e1751@github.com>
 <X_7cTwpI8cxsVTCMi6oe6f1Fy6yPcw7b0-Pa-Ayou2Y=.69cba9c8-f6e4-40b4-a180-3eb79428692b@github.com>
 <EQm4vRIvMgIFwt3dwYO3YTdbCLyQEKjISTt-QudCNbE=.f2366e5b-b9fa-456d-bafa-6531293b2cc2@github.com>
 <gBKEb-EMtCvqvSZiS1ImsYpQg63tg6R8KaizkL-BrlE=.f51a4335-251c-4041-bd71-75ec13f0591d@github.com>
 <v4SsYZMv2DVW2v8KDDDrCMa-JlyDX6Nsa20ue9JZKqs=.2617d216-b696-48c9-b34e-b0a97bb3bf12@github.com>
 <C47zxVTOUeIMyATz4LgWhTZsmZ6Nk5ncQRbgNKSvTxg=.7570353c-862e-428d-b6bf-aed24b461ea9@github.com>
 <oNo87kApGGMUT6MJYpvDAlyjBzza1-GmLNZSwAGrmEc=.d8669c88-6882-4744-8a05-5cadaa48404f@github.com>
 <A-u0xkGoB54J-q4yyOu-fXBqvXkTRLnmje8qh1KUTTE=.75f97621-8e70-4ab4-b54f-f45b37bd84f5@github.com>
 <hZpMlhWW1rB89tC-Wj_DH9R05YcOFOaqkFprf9MwBD4=.755ccfc2-b743-4037-8f0c-69c078937c5e@github.com>
Message-ID: <-mAEJ8TjIlhEHKFP0ybmVgqjhCIr8YoAz4Q-GilpZgs=.d1b01b4c-3c14-43ad-8203-b1cd4d2f7ad4@github.com>

On Thu, 11 Feb 2021 02:39:55 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> I'm in favor of just having a `noparallel` option (default to using parallel) instead of using `parallel=<n>`. This would be for both the histo and heap dump features, and for both the `jmap` and `jcmd` support of these features.
>> 
>> As for the current `parallel=<n>` support for jmap histo already in JDK 16, hopefully there would be no objections to removing that in JDK 17 in favor of the `noparallel` approach, but I think the CSR for that change should get some good scrutiny. I think it would good to get approval from @AlanBateman and/or @dholmes-ora since they are both in the CSR group and have good serviceability knowledge.
>> 
>> For reference, the JDK 16 CSR for adding `parallel=<n>` support to `jmap -histo` is [8239290](https://bugs.openjdk.java.net/browse/JDK-8239290), and the bug to change this to a `noparallel` opiton in JDK 17 is [JDK-8261482](https://bugs.openjdk.java.net/browse/JDK-8261482). The CSR is [JDK-8261543](https://bugs.openjdk.java.net/browse/JDK-8261543).
>
> Dear All, 
> I took the liberity to create a PR (#2519) for the "noparallel" option. Maybe we could discuss there.  And I also found @Hamlin-Li has created a CSR for that. Thanks a lot!
> 
> BRs,
> Lin

There is still one minor issue with this `noparallel` support, and that is we still run into the problem of `jmap -dump` not being able to pass a 4th argument via the attach API. We could just say that's fine, and require using the `jcmd` to do the heap dump if the user wants to override the default of having parallel enabled, but then it seems we should do the same for `jmap -histo` to be consistent. So in other words, no support in `jmap` for disabling parallel support, but we do have the support in `jcmd`. Thoughts?

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

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

From amenkov at openjdk.java.net  Thu Feb 11 22:53:43 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Thu, 11 Feb 2021 22:53:43 GMT
Subject: RFR: 8260431: com/sun/jdi/JdbOptions.java failed with
 "RuntimeException: 'prop[boo] = >foo<' missing from stdout/stderr" [v2]
In-Reply-To: <e5aNkqtAFEMi4w1WUvTzFuuXX_i6uOum0co4_2nyPsU=.a184c206-be43-4839-bbb1-1cedea21ac3a@github.com>
References: <yJAqWSrjL-E2p_2vZUEcmwznaodNn-KsbGOntHWwkZs=.5ac1e125-8932-4c09-b3a6-d7838b28e5dd@github.com>
 <KM9yOr-DSCAn9507z_YhmQD7vVcrWVD9rUm7cxM6_J0=.fe92e1f3-0456-4af8-84ad-85e6575f4cd0@github.com>
 <e5aNkqtAFEMi4w1WUvTzFuuXX_i6uOum0co4_2nyPsU=.a184c206-be43-4839-bbb1-1cedea21ac3a@github.com>
Message-ID: <_tj2czj5EgGQfX8OhuwPQTI9nnITugRjAQ0iEPlSiT4=.741e2aa8-400b-4487-8c80-d9a8192c6345@github.com>

On Wed, 3 Feb 2021 23:28:50 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   separated debuggee class name and args
>
> test/jdk/com/sun/jdi/JdbOptions.java line 91:
> 
>> 89:         // the simplest case
>> 90:         test("-connect",
>> 91:                 "com.sun.jdi.CommandLineLaunch:vmexec=java,options=-client -XX:+PrintVMOptions,main=" + targ + outFileArg)
> 
> Not to be too nit picky, but I was assuming that the " " would be here and not in outFileName. That would make it much more obvious how the args are separated (eg we are not using commas here).

@plummercj are you ok with the latest version?

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

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

From cjplummer at openjdk.java.net  Thu Feb 11 23:13:38 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 11 Feb 2021 23:13:38 GMT
Subject: RFR: 8260431: com/sun/jdi/JdbOptions.java failed with
 "RuntimeException: 'prop[boo] = >foo<' missing from stdout/stderr" [v3]
In-Reply-To: <GGP9KSTi-pAH23UbJ3Wmo0oZqJDpVtRMg4zzWcVkCek=.5db672d2-9416-4eaa-a435-29101a09d046@github.com>
References: <yJAqWSrjL-E2p_2vZUEcmwznaodNn-KsbGOntHWwkZs=.5ac1e125-8932-4c09-b3a6-d7838b28e5dd@github.com>
 <GGP9KSTi-pAH23UbJ3Wmo0oZqJDpVtRMg4zzWcVkCek=.5db672d2-9416-4eaa-a435-29101a09d046@github.com>
Message-ID: <JC-hDq8VchMTcpCY_Q0Vx0gdPJJ-pP8wQpxmQZ9rByY=.4034c5d2-01ae-4456-b5e8-bc9a9316653b@github.com>

On Thu, 4 Feb 2021 00:36:57 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The test expects debuggee output in jdb output stream.
>> But jdb redirects debuggee output asynchronously so sometimes it's incomplete or mixed with jdb output.
>> The fix updates debuggee to print output to file and read/analyze it after jdb (and debuggee) exits.
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   made command line generation more explicit

Marked as reviewed by cjplummer (Reviewer).

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

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

From cjplummer at openjdk.java.net  Thu Feb 11 23:13:40 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 11 Feb 2021 23:13:40 GMT
Subject: RFR: 8260431: com/sun/jdi/JdbOptions.java failed with
 "RuntimeException: 'prop[boo] = >foo<' missing from stdout/stderr" [v2]
In-Reply-To: <e5aNkqtAFEMi4w1WUvTzFuuXX_i6uOum0co4_2nyPsU=.a184c206-be43-4839-bbb1-1cedea21ac3a@github.com>
References: <yJAqWSrjL-E2p_2vZUEcmwznaodNn-KsbGOntHWwkZs=.5ac1e125-8932-4c09-b3a6-d7838b28e5dd@github.com>
 <KM9yOr-DSCAn9507z_YhmQD7vVcrWVD9rUm7cxM6_J0=.fe92e1f3-0456-4af8-84ad-85e6575f4cd0@github.com>
 <e5aNkqtAFEMi4w1WUvTzFuuXX_i6uOum0co4_2nyPsU=.a184c206-be43-4839-bbb1-1cedea21ac3a@github.com>
Message-ID: <qvtImgrqbxjdYxxE8kBRmDTGA5977TIi5qYkPifFVBc=.3083cbb9-9651-49fc-8cb5-f99708559ee5@github.com>

On Wed, 3 Feb 2021 23:28:50 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   separated debuggee class name and args
>
> test/jdk/com/sun/jdi/JdbOptions.java line 91:
> 
>> 89:         // the simplest case
>> 90:         test("-connect",
>> 91:                 "com.sun.jdi.CommandLineLaunch:vmexec=java,options=-client -XX:+PrintVMOptions,main=" + targ + outFileArg)
> 
> Not to be too nit picky, but I was assuming that the " " would be here and not in outFileName. That would make it much more obvious how the args are separated (eg we are not using commas here).

> @plummercj are you ok with the latest version?

Yes. thank you

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

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

From amenkov at openjdk.java.net  Thu Feb 11 23:34:38 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Thu, 11 Feb 2021 23:34:38 GMT
Subject: Integrated: 8260431: com/sun/jdi/JdbOptions.java failed with
 "RuntimeException: 'prop[boo] = >foo<' missing from stdout/stderr"
In-Reply-To: <yJAqWSrjL-E2p_2vZUEcmwznaodNn-KsbGOntHWwkZs=.5ac1e125-8932-4c09-b3a6-d7838b28e5dd@github.com>
References: <yJAqWSrjL-E2p_2vZUEcmwznaodNn-KsbGOntHWwkZs=.5ac1e125-8932-4c09-b3a6-d7838b28e5dd@github.com>
Message-ID: <cxOTmfk953TK4UshVBNO6EktK4WVKoO89fAZ1pNPCQg=.cf9332b7-54f7-4b0a-b2ab-73b124ebbdc3@github.com>

On Sat, 30 Jan 2021 00:15:04 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The test expects debuggee output in jdb output stream.
> But jdb redirects debuggee output asynchronously so sometimes it's incomplete or mixed with jdb output.
> The fix updates debuggee to print output to file and read/analyze it after jdb (and debuggee) exits.

This pull request has now been integrated.

Changeset: 60a2072a
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/60a2072a
Stats:     53 lines in 1 file changed: 32 ins; 3 del; 18 mod

8260431: com/sun/jdi/JdbOptions.java failed with "RuntimeException: 'prop[boo] = >foo<' missing from stdout/stderr"

Reviewed-by: sspitsyn, cjplummer

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

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

From cjplummer at openjdk.java.net  Thu Feb 11 23:52:58 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 11 Feb 2021 23:52:58 GMT
Subject: RFR: 8247514: Improve clhsdb 'findpc' ability to determine what
 an address points to by improving PointerFinder and PointerLocation classes
 [v3]
In-Reply-To: <4YKNpyXQ9QGrLhR61tkh71Q3A7VvCj5Ete_4OvzAA-o=.28b7be8c-6f05-42d4-892b-87ebea907b24@github.com>
References: <4YKNpyXQ9QGrLhR61tkh71Q3A7VvCj5Ete_4OvzAA-o=.28b7be8c-6f05-42d4-892b-87ebea907b24@github.com>
Message-ID: <qOKGdXHLJsSnChvrqzkP2yy0FCSk5AROiWXVTWko7OU=.1e508216-3ac9-493f-8867-7a4b0a27f9be@github.com>

> See the bug for most details. A few notes here about some implementation details:
> 
> In the `PointerLocation` class, I added more consistency w.r.t. whether or not a newline is printed. It used to for some address types, but not others. Now it always does. And if you see a comment something like the following:
> 
> `         getTLAB().printOn(tty); // includes "\n" `
> 
> That's just clarifying whether or not the `printOn()` method called will include the newline. Some do and some don't, and knowing what the various `printOn()` methods do makes getting the proper inclusion of the newline easier to understand.
> 
> I added `verbose` and `printAddress` boolean arguments to `PointerLocation.printOn()`. Currently they are always `true`. The false arguments will be used when I complete [JDK-8250801](https://bugs.openjdk.java.net/browse/JDK-8250801), which will use `PointerFinder/Location` to show what each register points to.
> 
> The CR mentions that the main motivation for this work is for eventual replacement of the old clhsdb `whatis` command, which was implemented in javascript. It used to resolve DSO symbols, whereas `findpc` did not. The `whatis` code did this with the following:
> 
>   var dso = loadObjectContainingPC(addr);
>   if (dso == null) {
>     return ptrLoc.toString();
>   }
>   var sym = dso.closestSymbolToPC(addr);
>   if (sym != null) {
>     return sym.name + '+' + sym.offset;
>   }
> And now you'll see something similar in the PointerFinder code:
> 
>         loc.loadObject = cdbg.loadObjectContainingPC(a);
>         if (loc.loadObject != null) {
>             loc.nativeSymbol = loc.loadObject.closestSymbolToPC(a);
>             return loc;
>         } 
> Note that now that `findpc` does everything that `whatis` used to (and more), we don't really need to add a java version of `whatis`, but I'll probably do so anyway just help out people who are used to using the `whatis` command. That will be done using [JDK-8244670](https://bugs.openjdk.java.net/browse/JDK-8244670)

Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:

  Fix issue with parsing 'examine' output when there is unexecptected output due to CDS logging or -Xcheck:jni warnings.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2111/files
  - new: https://git.openjdk.java.net/jdk/pull/2111/files/69a8ae59..79cb1080

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

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

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

From cjplummer at openjdk.java.net  Fri Feb 12 00:05:39 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Fri, 12 Feb 2021 00:05:39 GMT
Subject: RFR: 8247514: Improve clhsdb 'findpc' ability to determine what
 an address points to by improving PointerFinder and PointerLocation classes
 [v3]
In-Reply-To: <-09XRqbxFbZGkzqDVewiXrJjVNjuLMdZqfxjnxJf3Oc=.2da660b7-a5c1-40e1-81af-8dc814e199ca@github.com>
References: <4YKNpyXQ9QGrLhR61tkh71Q3A7VvCj5Ete_4OvzAA-o=.28b7be8c-6f05-42d4-892b-87ebea907b24@github.com>
 <-09XRqbxFbZGkzqDVewiXrJjVNjuLMdZqfxjnxJf3Oc=.2da660b7-a5c1-40e1-81af-8dc814e199ca@github.com>
Message-ID: <Tri_E-J5sYrPX6s0PHUcD6K4oxau4nHE-yrblcVcaEI=.0878ae95-2509-4685-a823-1e58c992ca11@github.com>

On Tue, 2 Feb 2021 23:21:50 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix issue with parsing 'examine' output when there is unexecptected output due to CDS logging or -Xcheck:jni warnings.
>
> LGTM

@YaSuenag and @kevinjwalls I had to make a minor fix to the test. Can you please review it. The issued turned up when I ran some higher test tiers, one of which enabled CDS with some tracing and the other enabled `-Xcheck:jni`, which produced output due to [JDK-8261607](https://bugs.openjdk.java.net/browse/JDK-8261607). Both caused extra output  that resulted in improperly parsing the `examine` output and not actually finding that address that it produced. This was because there were lines of output before even issuing the `examine` command that matched the pattern being looked for. I made the pattern more specific by including the tid of the thread. I also cleaned up the comments around that code a bit. thanks.

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

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

From lzang at openjdk.java.net  Fri Feb 12 00:52:54 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Fri, 12 Feb 2021 00:52:54 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v6]
In-Reply-To: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
Message-ID: <lTp1kb6kzNbh3UtuCudnbIu0f2OSiTzMdkcbYyyv4Mg=.d5276096-e5af-4777-85dc-cf0ea32a9060@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:

  Add dumpheapext command for extra argument passing

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2261/files
  - new: https://git.openjdk.java.net/jdk/pull/2261/files/016218ba..b4776658

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

  Stats: 120 lines in 2 files changed: 111 ins; 0 del; 9 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  Fri Feb 12 01:07:38 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Fri, 12 Feb 2021 01:07:38 GMT
Subject: RFR: JDK-8261034: improve jcmd GC.class_histogram to support
 parallel
In-Reply-To: <-mAEJ8TjIlhEHKFP0ybmVgqjhCIr8YoAz4Q-GilpZgs=.d1b01b4c-3c14-43ad-8203-b1cd4d2f7ad4@github.com>
References: <VKzVY-01CEXUbQdlKMhDWjtjxUgpxs_6487x232VsAI=.3b9c5d8a-972b-4997-9f75-1951f98e1751@github.com>
 <X_7cTwpI8cxsVTCMi6oe6f1Fy6yPcw7b0-Pa-Ayou2Y=.69cba9c8-f6e4-40b4-a180-3eb79428692b@github.com>
 <EQm4vRIvMgIFwt3dwYO3YTdbCLyQEKjISTt-QudCNbE=.f2366e5b-b9fa-456d-bafa-6531293b2cc2@github.com>
 <gBKEb-EMtCvqvSZiS1ImsYpQg63tg6R8KaizkL-BrlE=.f51a4335-251c-4041-bd71-75ec13f0591d@github.com>
 <v4SsYZMv2DVW2v8KDDDrCMa-JlyDX6Nsa20ue9JZKqs=.2617d216-b696-48c9-b34e-b0a97bb3bf12@github.com>
 <C47zxVTOUeIMyATz4LgWhTZsmZ6Nk5ncQRbgNKSvTxg=.7570353c-862e-428d-b6bf-aed24b461ea9@github.com>
 <oNo87kApGGMUT6MJYpvDAlyjBzza1-GmLNZSwAGrmEc=.d8669c88-6882-4744-8a05-5cadaa48404f@github.com>
 <A-u0xkGoB54J-q4yyOu-fXBqvXkTRLnmje8qh1KUTTE=.75f97621-8e70-4ab4-b54f-f45b37bd84f5@github.com>
 <hZpMlhWW1rB89tC-Wj_DH9R05YcOFOaqkFprf9MwBD4=.755ccfc2-b743-4037-8f0c-69c078937c5e@github.com>
 <-mAEJ8TjIlhEHKFP0ybmVgqjhCIr8YoAz4Q-GilpZgs=.d1b01b4c-3c14-43ad-8203-b1cd4d2f7ad4@github.com>
Message-ID: <6APNXM7Ih9TxHMNEPD-uOla7-w08UxJeP4ef3-f3joA=.77a8b309-1973-471d-87d7-f682b3ebdb32@github.com>

On Thu, 11 Feb 2021 22:50:50 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Dear All, 
>> I took the liberity to create a PR (#2519) for the "noparallel" option. Maybe we could discuss there.  And I also found @Hamlin-Li has created a CSR for that. Thanks a lot!
>> 
>> BRs,
>> Lin
>
> There is still one minor issue with this `noparallel` support, and that is we still run into the problem of `jmap -dump` not being able to pass a 4th argument via the attach API. We could just say that's fine, and require using the `jcmd` to do the heap dump if the user wants to override the default of having parallel enabled, but then it seems we should do the same for `jmap -histo` to be consistent. So in other words, no support in `jmap` for disabling parallel support, but we do have the support in `jcmd`. Thoughts?

Hi Chris, 

> There is still one minor issue with this `noparallel` support, and that is we still run into the problem of `jmap -dump` not being able to pass a 4th argument via the attach API. We could just say that's fine, and require using the `jcmd` to do the heap dump if the user wants to override the default of having parallel enabled, but then it seems we should do the same for `jmap -histo` to be consistent. So in other words, no support in `jmap` for disabling parallel support, but we do have the support in `jcmd`. Thoughts?

I just updated the #2261 which introduce a new command "dumpheapext" that could handle more arguments (as you suggested the idea :-> ). I think maybe that kind of change is acceptable. Moreover, this way also allow us to add more options in future.

So maybe we have two choice here:
- Add a new command for argument extension.   so jcmd and jmap could be consisitent.
- Remove the "parallel" option in jmap, and leave the control to jcmd.

I prefer the first one as it may be more clearer for users to have consisitent usage of jcmd and jmap tools as they were before. 

Thanks!
Lin

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

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

From cjplummer at openjdk.java.net  Fri Feb 12 06:28:42 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Fri, 12 Feb 2021 06:28:42 GMT
Subject: RFR: JDK-8261034: improve jcmd GC.class_histogram to support
 parallel
In-Reply-To: <6APNXM7Ih9TxHMNEPD-uOla7-w08UxJeP4ef3-f3joA=.77a8b309-1973-471d-87d7-f682b3ebdb32@github.com>
References: <VKzVY-01CEXUbQdlKMhDWjtjxUgpxs_6487x232VsAI=.3b9c5d8a-972b-4997-9f75-1951f98e1751@github.com>
 <X_7cTwpI8cxsVTCMi6oe6f1Fy6yPcw7b0-Pa-Ayou2Y=.69cba9c8-f6e4-40b4-a180-3eb79428692b@github.com>
 <EQm4vRIvMgIFwt3dwYO3YTdbCLyQEKjISTt-QudCNbE=.f2366e5b-b9fa-456d-bafa-6531293b2cc2@github.com>
 <gBKEb-EMtCvqvSZiS1ImsYpQg63tg6R8KaizkL-BrlE=.f51a4335-251c-4041-bd71-75ec13f0591d@github.com>
 <v4SsYZMv2DVW2v8KDDDrCMa-JlyDX6Nsa20ue9JZKqs=.2617d216-b696-48c9-b34e-b0a97bb3bf12@github.com>
 <C47zxVTOUeIMyATz4LgWhTZsmZ6Nk5ncQRbgNKSvTxg=.7570353c-862e-428d-b6bf-aed24b461ea9@github.com>
 <oNo87kApGGMUT6MJYpvDAlyjBzza1-GmLNZSwAGrmEc=.d8669c88-6882-4744-8a05-5cadaa48404f@github.com>
 <A-u0xkGoB54J-q4yyOu-fXBqvXkTRLnmje8qh1KUTTE=.75f97621-8e70-4ab4-b54f-f45b37bd84f5@github.com>
 <hZpMlhWW1rB89tC-Wj_DH9R05YcOFOaqkFprf9MwBD4=.755ccfc2-b743-4037-8f0c-69c078937c5e@github.com>
 <-mAEJ8TjIlhEHKFP0ybmVgqjhCIr8YoAz4Q-GilpZgs=.d1b01b4c-3c14-43ad-8203-b1cd4d2f7ad4@github.com>
 <6APNXM7Ih9TxHMNEPD-uOla7-w08UxJeP4e
 f3-f3joA=.77a8b309-1973-471d-87d7-f682b3ebdb32@github.com>
Message-ID: <L8t5llrzyxpof_frsgyaf8jznTCckZF-h0t7rM8eAX8=.bb67bcc3-d8db-45a5-a365-7cc05faf27da@github.com>

On Fri, 12 Feb 2021 01:03:28 GMT, Lin Zang <lzang at openjdk.org> wrote:

> So maybe we have two choice here:
>     * Add a new command for argument extension.   so jcmd and jmap could be consisitent.
>     * Remove the "parallel" option in jmap, and leave the control to jcmd.

Yes, I suppose we can still do the `dumpheapext` approach to allow for having 4 args. It's a bit of a hack, but at least it is hidden from the user, and allows `jmap` and `jcmd` to both support `noparallel`

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

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

From rehn at openjdk.java.net  Fri Feb 12 07:38:38 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Fri, 12 Feb 2021 07:38:38 GMT
Subject: RFR: 8241403: JavaThread::get_thread_name() should be
 ThreadSMR-aware
In-Reply-To: <wRdcRQurtpybntK9Qpji-6zVY-EcHKw3q87xpD0eoS4=.a6dc32f4-2919-42e9-80c3-5a264067f0e2@github.com>
References: <wRdcRQurtpybntK9Qpji-6zVY-EcHKw3q87xpD0eoS4=.a6dc32f4-2919-42e9-80c3-5a264067f0e2@github.com>
Message-ID: <jC5265wuttjBLyw48NYqci5mOu9pHC2ujfsJZ3Stgoc=.1b49888d-4572-442f-a744-aa0634d26527@github.com>

On Thu, 11 Feb 2021 22:04:53 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A minor fix to add a new function:
> 
>     bool Thread::is_JavaThread_protected(const JavaThread* p)
> 
> that returns true when the target JavaThread* is protected and false
> otherwise. Update JavaThread::get_thread_name() to create a
> ThreadsListHandle and use the new is_JavaThread_protected(). Also
> update JvmtiTrace::safe_get_thread_name() to use the new
> is_JavaThread_protected().
> 
> This fix is tested via a Mach5 Tier[1-8] run.

Seems alright.

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

Marked as reviewed by rehn (Reviewer).

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

From ysuenaga at openjdk.java.net  Fri Feb 12 09:38:46 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Fri, 12 Feb 2021 09:38:46 GMT
Subject: RFR: 8247514: Improve clhsdb 'findpc' ability to determine what
 an address points to by improving PointerFinder and PointerLocation classes
 [v3]
In-Reply-To: <qOKGdXHLJsSnChvrqzkP2yy0FCSk5AROiWXVTWko7OU=.1e508216-3ac9-493f-8867-7a4b0a27f9be@github.com>
References: <4YKNpyXQ9QGrLhR61tkh71Q3A7VvCj5Ete_4OvzAA-o=.28b7be8c-6f05-42d4-892b-87ebea907b24@github.com>
 <qOKGdXHLJsSnChvrqzkP2yy0FCSk5AROiWXVTWko7OU=.1e508216-3ac9-493f-8867-7a4b0a27f9be@github.com>
Message-ID: <aqONsYu3A1QEnkHtEc9HHHWU0z7s9nd4FSFwKO4qD5Y=.46663b1e-6d26-4e41-8b97-5491b18d4d06@github.com>

On Thu, 11 Feb 2021 23:52:58 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> See the bug for most details. A few notes here about some implementation details:
>> 
>> In the `PointerLocation` class, I added more consistency w.r.t. whether or not a newline is printed. It used to for some address types, but not others. Now it always does. And if you see a comment something like the following:
>> 
>> `         getTLAB().printOn(tty); // includes "\n" `
>> 
>> That's just clarifying whether or not the `printOn()` method called will include the newline. Some do and some don't, and knowing what the various `printOn()` methods do makes getting the proper inclusion of the newline easier to understand.
>> 
>> I added `verbose` and `printAddress` boolean arguments to `PointerLocation.printOn()`. Currently they are always `true`. The false arguments will be used when I complete [JDK-8250801](https://bugs.openjdk.java.net/browse/JDK-8250801), which will use `PointerFinder/Location` to show what each register points to.
>> 
>> The CR mentions that the main motivation for this work is for eventual replacement of the old clhsdb `whatis` command, which was implemented in javascript. It used to resolve DSO symbols, whereas `findpc` did not. The `whatis` code did this with the following:
>> 
>>   var dso = loadObjectContainingPC(addr);
>>   if (dso == null) {
>>     return ptrLoc.toString();
>>   }
>>   var sym = dso.closestSymbolToPC(addr);
>>   if (sym != null) {
>>     return sym.name + '+' + sym.offset;
>>   }
>> And now you'll see something similar in the PointerFinder code:
>> 
>>         loc.loadObject = cdbg.loadObjectContainingPC(a);
>>         if (loc.loadObject != null) {
>>             loc.nativeSymbol = loc.loadObject.closestSymbolToPC(a);
>>             return loc;
>>         } 
>> Note that now that `findpc` does everything that `whatis` used to (and more), we don't really need to add a java version of `whatis`, but I'll probably do so anyway just help out people who are used to using the `whatis` command. That will be done using [JDK-8244670](https://bugs.openjdk.java.net/browse/JDK-8244670)
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix issue with parsing 'examine' output when there is unexecptected output due to CDS logging or -Xcheck:jni warnings.

LGTM

We may be able to use regex to collect any addresses from jstack output, but I'm not sure it makes the test code simpler...

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

Marked as reviewed by ysuenaga (Reviewer).

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

From kevinw at openjdk.java.net  Fri Feb 12 09:38:46 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Fri, 12 Feb 2021 09:38:46 GMT
Subject: RFR: 8247514: Improve clhsdb 'findpc' ability to determine what
 an address points to by improving PointerFinder and PointerLocation classes
 [v3]
In-Reply-To: <qOKGdXHLJsSnChvrqzkP2yy0FCSk5AROiWXVTWko7OU=.1e508216-3ac9-493f-8867-7a4b0a27f9be@github.com>
References: <4YKNpyXQ9QGrLhR61tkh71Q3A7VvCj5Ete_4OvzAA-o=.28b7be8c-6f05-42d4-892b-87ebea907b24@github.com>
 <qOKGdXHLJsSnChvrqzkP2yy0FCSk5AROiWXVTWko7OU=.1e508216-3ac9-493f-8867-7a4b0a27f9be@github.com>
Message-ID: <IZkIml0OM7AZK-I5W34LQLDXnIERTbbj-lpq7_kiqUo=.34299bd7-6ca9-4066-84d8-841f84f5c9d0@github.com>

On Thu, 11 Feb 2021 23:52:58 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> See the bug for most details. A few notes here about some implementation details:
>> 
>> In the `PointerLocation` class, I added more consistency w.r.t. whether or not a newline is printed. It used to for some address types, but not others. Now it always does. And if you see a comment something like the following:
>> 
>> `         getTLAB().printOn(tty); // includes "\n" `
>> 
>> That's just clarifying whether or not the `printOn()` method called will include the newline. Some do and some don't, and knowing what the various `printOn()` methods do makes getting the proper inclusion of the newline easier to understand.
>> 
>> I added `verbose` and `printAddress` boolean arguments to `PointerLocation.printOn()`. Currently they are always `true`. The false arguments will be used when I complete [JDK-8250801](https://bugs.openjdk.java.net/browse/JDK-8250801), which will use `PointerFinder/Location` to show what each register points to.
>> 
>> The CR mentions that the main motivation for this work is for eventual replacement of the old clhsdb `whatis` command, which was implemented in javascript. It used to resolve DSO symbols, whereas `findpc` did not. The `whatis` code did this with the following:
>> 
>>   var dso = loadObjectContainingPC(addr);
>>   if (dso == null) {
>>     return ptrLoc.toString();
>>   }
>>   var sym = dso.closestSymbolToPC(addr);
>>   if (sym != null) {
>>     return sym.name + '+' + sym.offset;
>>   }
>> And now you'll see something similar in the PointerFinder code:
>> 
>>         loc.loadObject = cdbg.loadObjectContainingPC(a);
>>         if (loc.loadObject != null) {
>>             loc.nativeSymbol = loc.loadObject.closestSymbolToPC(a);
>>             return loc;
>>         } 
>> Note that now that `findpc` does everything that `whatis` used to (and more), we don't really need to add a java version of `whatis`, but I'll probably do so anyway just help out people who are used to using the `whatis` command. That will be done using [JDK-8244670](https://bugs.openjdk.java.net/browse/JDK-8244670)
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix issue with parsing 'examine' output when there is unexecptected output due to CDS logging or -Xcheck:jni warnings.

Yes, joy of text processing.  Looks good.

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

Marked as reviewed by kevinw (Committer).

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

From sgehwolf at openjdk.java.net  Fri Feb 12 10:21:48 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Fri, 12 Feb 2021 10:21:48 GMT
Subject: RFR: 8254001: [Metrics] Enhance parsing of cgroup interface files
 for version detection [v4]
In-Reply-To: <rXq1Ad-_1c9NU7PI8ukyb1OG0XbEvQKi_krW6I2NAJQ=.732d2731-d617-4808-be1a-41a243a2d9c3@github.com>
References: <52vN8j9B_6s6amMHb8b_1QKyhwjCvThIz5T17aNix28=.31113ef4-61d0-4525-a3df-9aa20d408935@github.com>
 <3x47AFywS6_XcwXLLRw-js174URG35nifn1_G19vsKc=.b5ad4fdc-e040-44bc-a7fd-6fe7268dc341@github.com>
 <rXq1Ad-_1c9NU7PI8ukyb1OG0XbEvQKi_krW6I2NAJQ=.732d2731-d617-4808-be1a-41a243a2d9c3@github.com>
Message-ID: <bRbPXPcV1Ouis3yX6AqUcz4G3bWsxP7G5kUAGPRlilA=.50d3cdb7-5e2c-48f4-ba64-cd2ae99e8d22@github.com>

On Thu, 11 Feb 2021 19:51:43 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Severin Gehwolf 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:
>> 
>>  - Fix jcheck
>>  - Add documentation and reduce code running in the critical section
>>  - Add some documentation
>>  - Merge branch 'master' into jdk-8254001-enhance-file-parsing-java-metrics
>>  - Merge branch 'master' into jdk-8254001-enhance-file-parsing-java-metrics
>>  - Merge branch 'master' into jdk-8254001-enhance-file-parsing-java-metrics
>>  - 8254001: [Metrics] Enhance parsing of cgroup interface files for version detection
>
> Hi Severin,
> Thanks for doing this!  Sorry for taking so long to review this change.  The change looks good.  Before pushing it, could you add a comment explaining what the code in lines 185-194 of CgroupSubsystemFactory.java is doing?  Also, please don't overwrite the fix for JDK-8257746.
> Thanks again! Harold

Setting reviewers to 2 since I want @gnu-andrew to be OK with it too.

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

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

From vkempik at openjdk.java.net  Fri Feb 12 11:45:49 2021
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Fri, 12 Feb 2021 11:45:49 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v10]
In-Reply-To: <9Nasu4m7orJoGYjX4EYCuz5-aevYNno3Ru3jPHgwkvc=.168cfdf0-648b-46e4-9cb4-b24956eeba7d@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>
Message-ID: <hwBUUi7NHd91Sc9fpH0hTqLXvp2H8ax9-YGqCo4fC2g=.bb995b11-1795-42e8-8a9a-d95406ed8513@github.com>

On Thu, 4 Feb 2021 21:59:02 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 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 is better here ?

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

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

From lucy at openjdk.java.net  Fri Feb 12 12:01:38 2021
From: lucy at openjdk.java.net (Lutz Schmidt)
Date: Fri, 12 Feb 2021 12:01:38 GMT
Subject: RFR: 8261447: MethodInvocationCounters frequently run into
 overflow [v2]
In-Reply-To: <7S5jdlFpZ5m2xtFinD92jQEQm6hgbQXjHR5N-3XbXkc=.fe75978e-860a-4bcc-b5b4-3e4b4246d706@github.com>
References: <FsHAKG6KwqJeHLIhE6JroDUjiebdevi1asoLi-7pQ1s=.15d96719-36f2-4f9b-ae80-fcb17a3b6659@github.com>
 <VGY2qZPofTF4kvhoh2eb-gEVskrAllfc2qUGniHve9w=.a1bbf3d0-a7d5-4362-8511-13e6ad3f5b6d@github.com>
 <uGFfe_CAI9XwHObEA-aFoqIK3Q5IjyyU7Zon9Kbwu9U=.fc24b09f-7cd6-4cba-84f4-2e265fe94e7c@github.com>
 <P43LJp7pLJb8s3r1UsNiCMDTkbp_sTKER_4rG_ng2n0=.f150cfaa-d21e-45da-ad4f-0e2943df4903@github.com>
 <vf7HwmzLTAIky5AgfmR3V8tkK4YNDalAuUrF_wTuLSo=.319ec36f-a143-470f-bf88-9398678818f2@github.com>
 <7S5jdlFpZ5m2xtFinD92jQEQm6hgbQXjHR5N-3XbXkc=.fe75978e-860a-4bcc-b5b4-3e4b4246d706@github.com>
Message-ID: <CYjuoGXt_uPG61kL7K3H_hn5_FhZOFJcRDoBqrdmA2E=.cead0f6d-f1e3-4684-a061-9c98e3ae38e9@github.com>

On Fri, 12 Feb 2021 08:29:37 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:

>> I don't really like these .*64 suffixes. Can we just make the counter 64 bit, update the SA as Tobias suggested and keep the existing method names? Or is there a reason for doing this that eludes me?
>
> I introduced the *64 suffixes to not break anything that still uses the old calls. As old uses disappear step by step, I'm more than happy to remove the suffixes. I will have a look into SA and try to make it 64bit counter ready. There may be no new version before the weekend is over.

This is a request for help. Could someone with SA knowledge please check if my assumption is correct?

In hotspot code, the field Method::_compiled_invocation_count is annotated with a comment that it is used by SA. The field is also exposed via vmStructs.cpp to enable such use. I have scanned SA code in OpenJDK11 and OpenJDK head but found no evidence that this particular field is accessed. Is this finding/assumption correct? 

If so, I could just stop exposing the field, making my life easier. Thanks!

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

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

From vkempik at openjdk.java.net  Fri Feb 12 12:07:52 2021
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Fri, 12 Feb 2021 12:07:52 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: <QR_25LvtuoaR4anc7mZFE3PngUtbChh_bbRWL1jvvgo=.b0b20887-eb7f-41d3-9eb5-74fb631506bb@github.com>

On Tue, 2 Feb 2021 22:07:15 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/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.

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

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

From vkempik at openjdk.java.net  Fri Feb 12 12:25:47 2021
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Fri, 12 Feb 2021 12:25:47 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
In-Reply-To: <UnSWIprKrFiPt4vWX36CgseOH4-iJVexy8UBjsGUJ4k=.67e5231b-a1f0-4ded-9852-6ea7fcbff05a@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>
 <UnSWIprKrFiPt4vWX36CgseOH4-iJVexy8UBjsGUJ4k=.67e5231b-a1f0-4ded-9852-6ea7fcbff05a@github.com>
Message-ID: <quhwE-hqPgo6HXXf4D7o2FRIu48a_H9Fsd8TSqJrbE0=.e5ec4863-c3b4-4fd5-bf5d-f95cd1245770@github.com>

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

>> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 363:
>> 
>>> 361:     address pc = os::Posix::ucontext_get_pc(uc);
>>> 362: 
>>> 363:     if (pc != addr && uc->context_esr == 0x9200004F) { //TODO: figure out what this value means
>> 
>> Is this TODO going to be resolved by this port?
>
> Where did this come from - some snippet/example/tech note code? Maybe other people can help figure it out if we provide more info.

This is the version of w^x on-demand switch implemented by microsoft guys. This is enabled only for debug builds.
@lewurm could you comment here please

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

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

From vkempik at openjdk.java.net  Fri Feb 12 12:25:48 2021
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Fri, 12 Feb 2021 12:25:48 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: <WI3MFWpvxNdYp4WRkhkagyWSmnIIAfvYWl3nS8AW_Y0=.b09073dd-cec3-4dbd-88c4-974d46b01737@github.com>

On Tue, 2 Feb 2021 22:12:07 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/os_bsd_aarch64.cpp line 435:
> 
>> 433: //    |                        |\  Java thread created by VM does not have glibc
>> 434: //    |    glibc guard page    | - guard, attached Java thread usually has
>> 435: //    |                        |/  1 glibc guard page.
> 
> Is this code going to be built by GCC (with glibc) or will only
> macOS compilers and libraries be used?

only macos comiplers

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

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

From fweimer at openjdk.java.net  Fri Feb 12 12:42:48 2021
From: fweimer at openjdk.java.net (Florian Weimer)
Date: Fri, 12 Feb 2021 12:42:48 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
In-Reply-To: <WI3MFWpvxNdYp4WRkhkagyWSmnIIAfvYWl3nS8AW_Y0=.b09073dd-cec3-4dbd-88c4-974d46b01737@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>
Message-ID: <gYlruHfPt3n_2sFsFzadoB-H9J1sZJQsspB9AjKeO2o=.ca9e5f03-7181-42cb-b2d9-4f3490f05235@github.com>

On Fri, 12 Feb 2021 12:22:44 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

>> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 435:
>> 
>>> 433: //    |                        |\  Java thread created by VM does not have glibc
>>> 434: //    |    glibc guard page    | - guard, attached Java thread usually has
>>> 435: //    |                        |/  1 glibc guard page.
>> 
>> Is this code going to be built by GCC (with glibc) or will only
>> macOS compilers and libraries be used?
>
> 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.

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

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

From sgehwolf at openjdk.java.net  Fri Feb 12 12:49:01 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Fri, 12 Feb 2021 12:49:01 GMT
Subject: RFR: 8254001: [Metrics] Enhance parsing of cgroup interface files
 for version detection [v5]
In-Reply-To: <52vN8j9B_6s6amMHb8b_1QKyhwjCvThIz5T17aNix28=.31113ef4-61d0-4525-a3df-9aa20d408935@github.com>
References: <52vN8j9B_6s6amMHb8b_1QKyhwjCvThIz5T17aNix28=.31113ef4-61d0-4525-a3df-9aa20d408935@github.com>
Message-ID: <BM4m3jWxpZgdvU9DgoXcz4iftbqkWzL1q-uTqzly258=.4f268544-d629-47fe-bd18-2c4fea02e495@github.com>

> This is an enhancement which solves two issues:
> 
> 1. Multiple reads of relevant cgroup interface files. Now interface files are only read once per file (just like Hotspot).
> 2. Proxies creation of the impl specific subsystem via `determineType()` as before, but now reads all relevant interface files: `/proc/cgroups`, `/proc/self/mountinfo` and `/proc/self/cgroup`. Once read it passes the parsed information to the impl specific subsystem classes for instantiation. This allows for more flexibility of testing as interface files can be mocked and, thus, more cases can be tested that way without having access to these specific systems. For example, proper regression tests for JDK-8217766 and JDK-8253435 have been added now with this in place.
> 
> * [x] Tested on Linux x86_64 on cgroups v1 and cgroups v2. Container tests pass.

Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:

  Add comment to parsing logic of /proc/self/cgroup

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1393/files
  - new: https://git.openjdk.java.net/jdk/pull/1393/files/9a2d6a20..078e16db

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

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

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

From sgehwolf at openjdk.java.net  Fri Feb 12 12:51:41 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Fri, 12 Feb 2021 12:51:41 GMT
Subject: RFR: 8254001: [Metrics] Enhance parsing of cgroup interface files
 for version detection [v4]
In-Reply-To: <bRbPXPcV1Ouis3yX6AqUcz4G3bWsxP7G5kUAGPRlilA=.50d3cdb7-5e2c-48f4-ba64-cd2ae99e8d22@github.com>
References: <52vN8j9B_6s6amMHb8b_1QKyhwjCvThIz5T17aNix28=.31113ef4-61d0-4525-a3df-9aa20d408935@github.com>
 <3x47AFywS6_XcwXLLRw-js174URG35nifn1_G19vsKc=.b5ad4fdc-e040-44bc-a7fd-6fe7268dc341@github.com>
 <rXq1Ad-_1c9NU7PI8ukyb1OG0XbEvQKi_krW6I2NAJQ=.732d2731-d617-4808-be1a-41a243a2d9c3@github.com>
 <bRbPXPcV1Ouis3yX6AqUcz4G3bWsxP7G5kUAGPRlilA=.50d3cdb7-5e2c-48f4-ba64-cd2ae99e8d22@github.com>
Message-ID: <SvMY9wiRTmT3frc0g-IiS1zdT81lKoLyqn-fhF59FK8=.5aba8058-3c87-4c76-9586-5a3927d68675@github.com>

On Fri, 12 Feb 2021 10:19:03 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Hi Severin,
>> Thanks for doing this!  Sorry for taking so long to review this change.  The change looks good.  Before pushing it, could you add a comment explaining what the code in lines 185-194 of CgroupSubsystemFactory.java is doing?  Also, please don't overwrite the fix for JDK-8257746.
>> Thanks again! Harold
>
> Setting reviewers to 2 since I want @gnu-andrew to be OK with it too.

Hi Harold,

> Thanks for doing this! Sorry for taking so long to review this change. The change looks good.

Thanks for the review!

> Before pushing it, could you add a comment explaining what the code in lines 185-194 of CgroupSubsystemFactory.java is doing?

Done.

> Also, please don't overwrite the fix for JDK-8257746.

AFAIK this patch doesn't touch this code. So this should not happen (overwrite of the fix). FWIW, once this is in I intend to propose a patch which adds a regression test for JDK-8257746. It would depend on this change.

Thanks,
Severin

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

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

From vkempik at openjdk.java.net  Fri Feb 12 13:35:48 2021
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Fri, 12 Feb 2021 13:35:48 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: <Ymv3QSLaT5H6CuKXfwuUkep_PKnO3Zj54kSQA0jcc6s=.59dc4d6d-a8d0-4016-8a59-a4d6cb8b57ac@github.com>

On Tue, 2 Feb 2021 22:14:42 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/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, 8020753 was originally your fix, do you know if it still needed on intel-mac ?

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

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

From akozlov at openjdk.java.net  Fri Feb 12 13:46:09 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Fri, 12 Feb 2021 13:46:09 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v13]
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: <mer_ngrSSihxOcyEUTu0S-Lij5FbD9bHAk1TUYdlGL8=.3d3ba0c3-279c-4e6d-b72e-7e5d93863d61@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:

  JDK-8257882: oops, fixed 7fe50a996b6f436932452d220b351c73153ed945

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2200/files
  - new: https://git.openjdk.java.net/jdk/pull/2200/files/0d0e9baf..ad4e4c65

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

  Stats: 1 line in 1 file changed: 0 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 akozlov at openjdk.java.net  Fri Feb 12 13:50:49 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Fri, 12 Feb 2021 13:50:49 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
In-Reply-To: <N_-2fM_jiKpNy74POTcXmRWWkYevnfQ-pLQA9C49B6I=.e3a78aa0-dde9-429e-9de7-5d64037378a9@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>
 <N_-2fM_jiKpNy74POTcXmRWWkYevnfQ-pLQA9C49B6I=.e3a78aa0-dde9-429e-9de7-5d64037378a9@github.com>
Message-ID: <D7cEGLpjWpe33p1n0ueI8oJF21U23yCTiTV-mnVSyyE=.8cfaa9b3-aeb6-41d8-bde8-1076ec394670@github.com>

On Wed, 3 Feb 2021 09:11:50 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 323:
>> 
>>> 321:   str(zr, Address(rthread, JavaThread::last_Java_pc_offset()));
>>> 322: 
>>> 323:   str(zr, Address(rthread, JavaFrameAnchor::saved_fp_address_offset()));
>> 
>> I don't think this switch from `JavaThread::saved_fp_address_offset()`
>> to `JavaFrameAnchor::saved_fp_address_offset()` is correct since
>> `rthread` is still used and is a JavaThread*. The new code will give you:
>> 
>>     `rthread` + offset of the `saved_fp_address` field in a JavaFrameAnchor
>> 
>> The old code gave you:
>> 
>>     `rthread` + offset of the `saved_fp_address` field in the JavaFrameAnchor field in the JavaThread
>> 
>> Those are not the same things.
>
> I agree, I don't understand why this change was made.

Wow, this is scary. I don't understand how I've merged JDK-8257882 like this. I've reviewed cpu/aarch64 changes again, there is nothing suspicious besides this. Thank you very much for catching, fixed.

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

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

From vkempik at openjdk.java.net  Fri Feb 12 14:07:51 2021
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Fri, 12 Feb 2021 14:07: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: <abgxKZGmxCcsondSN3T65vG8BFULcsnmCluAh78gOXU=.ef2df30e-6034-4b40-af66-22afe2bd6387@github.com>

On Tue, 2 Feb 2021 22:08:14 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/os_bsd_aarch64.cpp line 221:
> 
>> 219:     assert(sig == info->si_signo, "bad siginfo");
>> 220:   }
>> 221: */
> 
> Should this code be deleted? From here and from where it was copied
> from if it is also commented out there...

Thanks, will fix in bsd_aarch64 soon, as for bsd_x86 I've filled new bug and pr - https://github.com/openjdk/jdk/pull/2547

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

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

From cjplummer at openjdk.java.net  Fri Feb 12 14:26:44 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Fri, 12 Feb 2021 14:26:44 GMT
Subject: RFR: JDK-8261034: improve jcmd GC.class_histogram to support
 parallel
In-Reply-To: <L8t5llrzyxpof_frsgyaf8jznTCckZF-h0t7rM8eAX8=.bb67bcc3-d8db-45a5-a365-7cc05faf27da@github.com>
References: <VKzVY-01CEXUbQdlKMhDWjtjxUgpxs_6487x232VsAI=.3b9c5d8a-972b-4997-9f75-1951f98e1751@github.com>
 <X_7cTwpI8cxsVTCMi6oe6f1Fy6yPcw7b0-Pa-Ayou2Y=.69cba9c8-f6e4-40b4-a180-3eb79428692b@github.com>
 <EQm4vRIvMgIFwt3dwYO3YTdbCLyQEKjISTt-QudCNbE=.f2366e5b-b9fa-456d-bafa-6531293b2cc2@github.com>
 <gBKEb-EMtCvqvSZiS1ImsYpQg63tg6R8KaizkL-BrlE=.f51a4335-251c-4041-bd71-75ec13f0591d@github.com>
 <v4SsYZMv2DVW2v8KDDDrCMa-JlyDX6Nsa20ue9JZKqs=.2617d216-b696-48c9-b34e-b0a97bb3bf12@github.com>
 <C47zxVTOUeIMyATz4LgWhTZsmZ6Nk5ncQRbgNKSvTxg=.7570353c-862e-428d-b6bf-aed24b461ea9@github.com>
 <oNo87kApGGMUT6MJYpvDAlyjBzza1-GmLNZSwAGrmEc=.d8669c88-6882-4744-8a05-5cadaa48404f@github.com>
 <A-u0xkGoB54J-q4yyOu-fXBqvXkTRLnmje8qh1KUTTE=.75f97621-8e70-4ab4-b54f-f45b37bd84f5@github.com>
 <hZpMlhWW1rB89tC-Wj_DH9R05YcOFOaqkFprf9MwBD4=.755ccfc2-b743-4037-8f0c-69c078937c5e@github.com>
 <-mAEJ8TjIlhEHKFP0ybmVgqjhCIr8YoAz4Q-GilpZgs=.d1b01b4c-3c14-43ad-8203-b1cd4d2f7ad4@github.com>
 <6APNXM7Ih9TxHMNEPD-uOla7-w08UxJeP4e
 f3-f3joA=.77a8b309-1973-471d-87d7-f682b3ebdb32@github.com>
 <L8t5llrzyxpof_frsgyaf8jznTCckZF-h0t7rM8eAX8=.bb67bcc3-d8db-45a5-a365-7cc05faf27da@github.com>
Message-ID: <BX2O5NH7WOa57DlDNDgWefirxYUBT7nsCnPhqjchfs0=.6df0ae15-a16b-4cbe-ba5c-02c10d4c332f@github.com>

On Fri, 12 Feb 2021 06:25:41 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Hi Chris, 
>> 
>>> There is still one minor issue with this `noparallel` support, and that is we still run into the problem of `jmap -dump` not being able to pass a 4th argument via the attach API. We could just say that's fine, and require using the `jcmd` to do the heap dump if the user wants to override the default of having parallel enabled, but then it seems we should do the same for `jmap -histo` to be consistent. So in other words, no support in `jmap` for disabling parallel support, but we do have the support in `jcmd`. Thoughts?
>> 
>> I just updated the #2261 which introduce a new command "dumpheapext" that could handle more arguments (as you suggested the idea :-> ). I think maybe that kind of change is acceptable. Moreover, this way also allow us to add more options in future.
>> 
>> So maybe we have two choice here:
>> - Add a new command for argument extension.   so jcmd and jmap could be consisitent.
>> - Remove the "parallel" option in jmap, and leave the control to jcmd.
>> 
>> I prefer the first one as it may be more clearer for users to have consisitent usage of jcmd and jmap tools as they were before. 
>> 
>> Thanks!
>> Lin
>
>> So maybe we have two choice here:
>>     * Add a new command for argument extension.   so jcmd and jmap could be consisitent.
>>     * Remove the "parallel" option in jmap, and leave the control to jcmd.
> 
> Yes, I suppose we can still do the `dumpheapext` approach to allow for having 4 args. It's a bit of a hack, but at least it is hidden from the user, and allows `jmap` and `jcmd` to both support `noparallel`

Sigh, I've keep debating this with myself, and keep having second thoughts on what is best. I'm now leaning towards just sticking with `parallel=<n>`, and for any n > 1, at most we just say the user will need to experiment to see what works best (if we even say that). This way we avoid any headaches with the the JDK 16 support for `parallel=<n>` with `jmap -histo`. I know this isn't ideal, but I'm guessing for the most part users will just leave this option alone anyway, and will get the default number of threads. But, my current feelings here also hinge on adding `dumpheapext` so `-dump` and `-histo` both support parallel options.

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

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

From lzang at openjdk.java.net  Fri Feb 12 14:26:44 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Fri, 12 Feb 2021 14:26:44 GMT
Subject: RFR: JDK-8261034: improve jcmd GC.class_histogram to support
 parallel
In-Reply-To: <BX2O5NH7WOa57DlDNDgWefirxYUBT7nsCnPhqjchfs0=.6df0ae15-a16b-4cbe-ba5c-02c10d4c332f@github.com>
References: <VKzVY-01CEXUbQdlKMhDWjtjxUgpxs_6487x232VsAI=.3b9c5d8a-972b-4997-9f75-1951f98e1751@github.com>
 <X_7cTwpI8cxsVTCMi6oe6f1Fy6yPcw7b0-Pa-Ayou2Y=.69cba9c8-f6e4-40b4-a180-3eb79428692b@github.com>
 <EQm4vRIvMgIFwt3dwYO3YTdbCLyQEKjISTt-QudCNbE=.f2366e5b-b9fa-456d-bafa-6531293b2cc2@github.com>
 <gBKEb-EMtCvqvSZiS1ImsYpQg63tg6R8KaizkL-BrlE=.f51a4335-251c-4041-bd71-75ec13f0591d@github.com>
 <v4SsYZMv2DVW2v8KDDDrCMa-JlyDX6Nsa20ue9JZKqs=.2617d216-b696-48c9-b34e-b0a97bb3bf12@github.com>
 <C47zxVTOUeIMyATz4LgWhTZsmZ6Nk5ncQRbgNKSvTxg=.7570353c-862e-428d-b6bf-aed24b461ea9@github.com>
 <oNo87kApGGMUT6MJYpvDAlyjBzza1-GmLNZSwAGrmEc=.d8669c88-6882-4744-8a05-5cadaa48404f@github.com>
 <A-u0xkGoB54J-q4yyOu-fXBqvXkTRLnmje8qh1KUTTE=.75f97621-8e70-4ab4-b54f-f45b37bd84f5@github.com>
 <hZpMlhWW1rB89tC-Wj_DH9R05YcOFOaqkFprf9MwBD4=.755ccfc2-b743-4037-8f0c-69c078937c5e@github.com>
 <-mAEJ8TjIlhEHKFP0ybmVgqjhCIr8YoAz4Q-GilpZgs=.d1b01b4c-3c14-43ad-8203-b1cd4d2f7ad4@github.com>
 <6APNXM7Ih9TxHMNEPD-uOla7-w08UxJeP4e
 f3-f3joA=.77a8b309-1973-471d-87d7-f682b3ebdb32@github.com>
 <L8t5llrzyxpof_frsgyaf8jznTCckZF-h0t7rM8eAX8=.bb67bcc3-d8db-45a5-a365-7cc05faf27da@github.com>
 <BX2O5NH7WOa57DlDNDgWefirxYUBT7nsCnPhqjchfs0=.6df0ae15-a16b-4cbe-ba5c-02c10d4c332f@github.com>
Message-ID: <uIKLse-ugmKBUDcOM37UbZkziorlrzcMFJAZa25eqTE=.9ad0afaa-37e6-4ee1-885a-936c60bfad7f@github.com>

On Fri, 12 Feb 2021 06:55:18 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>>> So maybe we have two choice here:
>>>     * Add a new command for argument extension.   so jcmd and jmap could be consisitent.
>>>     * Remove the "parallel" option in jmap, and leave the control to jcmd.
>> 
>> Yes, I suppose we can still do the `dumpheapext` approach to allow for having 4 args. It's a bit of a hack, but at least it is hidden from the user, and allows `jmap` and `jcmd` to both support `noparallel`
>
> Sigh, I've keep debating this with myself, and keep having second thoughts on what is best. I'm now leaning towards just sticking with `parallel=<n>`, and for any n > 1, at most we just say the user will need to experiment to see what works best (if we even say that). This way we avoid any headaches with the the JDK 16 support for `parallel=<n>` with `jmap -histo`. I know this isn't ideal, but I'm guessing for the most part users will just leave this option alone anyway, and will get the default number of threads. But, my current feelings here also hinge on adding `dumpheapext` so `-dump` and `-histo` both support parallel options.

Hi Chris, 

> at most we just say the user will need to experiment to see what works best (if we even say that). This way we avoid any headaches with the the JDK 16 support for `parallel=<n>` with `jmap -histo`

I agree. what came in my mind when introducing `parallel=<n>` is that tuning maybe required when user works on multi-processes scenario, for which more parallel threads may affect other processes and disabling parallel may not be affordable when heap is large.

So having seen that there is a solution of 'passing more than 4 agruments' issue, IMO it is fine to keep consistency between jmap and jcmd. Therefore I think we have following choices for `parallel` of jmap and jcmd.

1 - Introduce `noparallel` option, use parallel by default and remove `parallel=<n>`.  It hides the detail info about parallel thread number and hence disable the tuning ability. But it makes user easier to use, just use `noparallel` to control parallalism. And also there is incompatibility issue between JDK16 and the latest JDK.
 
2 - Same as 1, but keep `parallel=<n>` option, and print the threads number for parallel heap inspection at the end. It gives user the ability to tune the parallel thread number, and also reduce the incompatibility between JDK16  and later version since there is no options removed.  But it introduces complexity for user to use `parallel=<n>` and `noparallel` options. (Please note that most users may not care about the parallel thread number in most scenario, just use the default one).

I prefer 2 as for me option 1 is like a subset of option 2, and 2 doesn't introduce backward-compatibility issues 

Thanks 
Lin

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

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

From dcubed at openjdk.java.net  Fri Feb 12 14:54:47 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 12 Feb 2021 14:54:47 GMT
Subject: RFR: 8241403: JavaThread::get_thread_name() should be
 ThreadSMR-aware
In-Reply-To: <jC5265wuttjBLyw48NYqci5mOu9pHC2ujfsJZ3Stgoc=.1b49888d-4572-442f-a744-aa0634d26527@github.com>
References: <wRdcRQurtpybntK9Qpji-6zVY-EcHKw3q87xpD0eoS4=.a6dc32f4-2919-42e9-80c3-5a264067f0e2@github.com>
 <jC5265wuttjBLyw48NYqci5mOu9pHC2ujfsJZ3Stgoc=.1b49888d-4572-442f-a744-aa0634d26527@github.com>
Message-ID: <BveaOO2zmDtZqMXtfrlYh7Wpxj9ESR5ZEt8rkWI_k1w=.255f08bc-f4a8-444c-96f7-e0a5d803b823@github.com>

On Fri, 12 Feb 2021 07:36:06 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> A minor fix to add a new function:
>> 
>>     bool Thread::is_JavaThread_protected(const JavaThread* p)
>> 
>> that returns true when the target JavaThread* is protected and false
>> otherwise. Update JavaThread::get_thread_name() to create a
>> ThreadsListHandle and use the new is_JavaThread_protected(). Also
>> update JvmtiTrace::safe_get_thread_name() to use the new
>> is_JavaThread_protected().
>> 
>> This fix is tested via a Mach5 Tier[1-8] run.
>
> Seems alright.

@robehn - Thanks for the review!

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

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

From vkempik at openjdk.java.net  Fri Feb 12 15:25:54 2021
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Fri, 12 Feb 2021 15:25:54 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v10]
In-Reply-To: <i9UArB35vpHowW6HbtTkKLQX-wwfSx1dg1NKLHIRdGs=.5e08a151-8ad3-46cc-b006-34d750410c47@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>
Message-ID: <-PhzrEcgREcbXuZ5GrxAfVa6Uwil9YoOkZULt1154rw=.9689a79e-cf61-4f79-9b36-a3295fecab7b@github.com>

On Thu, 4 Feb 2021 22:49:23 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 297:
> 
>> 295:           stub = SharedRuntime::handle_unsafe_access(thread, next_pc);
>> 296:         }
>> 297:       } else if (sig == SIGILL && nativeInstruction_at(pc)->is_stop()) {
> 
> Can we add a comment here describing what this case means?

this arm64 specific part came as is from linux_aarch64 and I can't add any meaning comments here.

> 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

> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 403:
> 
>> 401:   }
>> 402: 
>> 403:   return false; // Mute compiler
> 
> Is this comment needed?

this part came as is from linux_aarch64 as well and was supposed to mean something there.

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

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

From cjplummer at openjdk.java.net  Fri Feb 12 20:47:40 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Fri, 12 Feb 2021 20:47:40 GMT
Subject: RFR: JDK-8261034: improve jcmd GC.class_histogram to support
 parallel
In-Reply-To: <uIKLse-ugmKBUDcOM37UbZkziorlrzcMFJAZa25eqTE=.9ad0afaa-37e6-4ee1-885a-936c60bfad7f@github.com>
References: <VKzVY-01CEXUbQdlKMhDWjtjxUgpxs_6487x232VsAI=.3b9c5d8a-972b-4997-9f75-1951f98e1751@github.com>
 <X_7cTwpI8cxsVTCMi6oe6f1Fy6yPcw7b0-Pa-Ayou2Y=.69cba9c8-f6e4-40b4-a180-3eb79428692b@github.com>
 <EQm4vRIvMgIFwt3dwYO3YTdbCLyQEKjISTt-QudCNbE=.f2366e5b-b9fa-456d-bafa-6531293b2cc2@github.com>
 <gBKEb-EMtCvqvSZiS1ImsYpQg63tg6R8KaizkL-BrlE=.f51a4335-251c-4041-bd71-75ec13f0591d@github.com>
 <v4SsYZMv2DVW2v8KDDDrCMa-JlyDX6Nsa20ue9JZKqs=.2617d216-b696-48c9-b34e-b0a97bb3bf12@github.com>
 <C47zxVTOUeIMyATz4LgWhTZsmZ6Nk5ncQRbgNKSvTxg=.7570353c-862e-428d-b6bf-aed24b461ea9@github.com>
 <oNo87kApGGMUT6MJYpvDAlyjBzza1-GmLNZSwAGrmEc=.d8669c88-6882-4744-8a05-5cadaa48404f@github.com>
 <A-u0xkGoB54J-q4yyOu-fXBqvXkTRLnmje8qh1KUTTE=.75f97621-8e70-4ab4-b54f-f45b37bd84f5@github.com>
 <hZpMlhWW1rB89tC-Wj_DH9R05YcOFOaqkFprf9MwBD4=.755ccfc2-b743-4037-8f0c-69c078937c5e@github.com>
 <-mAEJ8TjIlhEHKFP0ybmVgqjhCIr8YoAz4Q-GilpZgs=.d1b01b4c-3c14-43ad-8203-b1cd4d2f7ad4@github.com>
 <6APNXM7Ih9TxHMNEPD-uOla7-w08UxJeP4e
 f3-f3joA=.77a8b309-1973-471d-87d7-f682b3ebdb32@github.com>
 <L8t5llrzyxpof_frsgyaf8jznTCckZF-h0t7rM8eAX8=.bb67bcc3-d8db-45a5-a365-7cc05faf27da@github.com>
 <BX2O5NH7WOa57DlDNDgWefirxYUBT7nsCnPhqjchfs0=.6df0ae15-a16b-4cbe-ba5c-02c10d4c332f@github.com>
 <uIKLse-ugmKBUDcOM37UbZkziorlrzcMFJAZa25eqTE=.9ad0afaa-37e6-4ee1-885a-936c60bfad7f@github.com>
Message-ID: <Ze8CKZ6Auw1oW4J-XKuMpO7n7NTedBBmj0O2UKrOH6o=.a16e8ebb-1a0b-499b-a913-92375c486d76@github.com>

On Fri, 12 Feb 2021 14:24:28 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> Sigh, I've keep debating this with myself, and keep having second thoughts on what is best. I'm now leaning towards just sticking with `parallel=<n>`, and for any n > 1, at most we just say the user will need to experiment to see what works best (if we even say that). This way we avoid any headaches with the the JDK 16 support for `parallel=<n>` with `jmap -histo`. I know this isn't ideal, but I'm guessing for the most part users will just leave this option alone anyway, and will get the default number of threads. But, my current feelings here also hinge on adding `dumpheapext` so `-dump` and `-histo` both support parallel options.
>
> Hi Chris, 
> 
>> at most we just say the user will need to experiment to see what works best (if we even say that). This way we avoid any headaches with the the JDK 16 support for `parallel=<n>` with `jmap -histo`
> 
> I agree. what came in my mind when introducing `parallel=<n>` is that tuning maybe required when user works on multi-processes scenario, for which more parallel threads may affect other processes and disabling parallel may not be affordable when heap is large.
> 
> So having seen that there is a solution of 'passing more than 4 agruments' issue, IMO it is fine to keep consistency between jmap and jcmd. Therefore I think we have following choices for `parallel` of jmap and jcmd.
> 
> 1 - Introduce `noparallel` option, use parallel by default and remove `parallel=<n>`.  It hides the detail info about parallel thread number and hence disable the tuning ability. But it makes user easier to use, just use `noparallel` to control parallalism. And also there is incompatibility issue between JDK16 and the latest JDK.
>  
> 2 - Same as 1, but keep `parallel=<n>` option, and print the threads number for parallel heap inspection at the end. It gives user the ability to tune the parallel thread number, and also reduce the incompatibility between JDK16  and later version since there is no options removed.  But it introduces complexity for user to use `parallel=<n>` and `noparallel` options. (Please note that most users may not care about the parallel thread number in most scenario, just use the default one).
> 
> I prefer 2 as for me option 1 is like a subset of option 2, and 2 doesn't introduce backward-compatibility issues 
> 
> Thanks 
> Lin

Yeah, I'm now thinking just stick with `parallel=<n>`. Sorry about all the noise, but I feel better about this approach now that we've explored all the options. We still need to get `heapdumpext` approved. It might be worth sending out an email to serviceablity-dev just to discuss that one topic, rather than having it in a PR discussion. Among other things, there might be suggestions for a better name to use.

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

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

From github.com+741251+turbanoff at openjdk.java.net  Fri Feb 12 21:09:41 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Fri, 12 Feb 2021 21:09:41 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v8]
In-Reply-To: <_uFXfNAzlG3COOLDN_bJBEH4n0xtk52RH4jgW0MYF_w=.358107f1-fa87-4b5a-8ded-08248080678f@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <KcO_olP0uhrkPxSvala6b0MN3zsFy0_Skl06Oq6Gla0=.398341c8-a9c6-4186-ab43-df19bec9d544@github.com>
 <cONOB0wrdWjjltXXAuaH_SYz_ay7AgllB3SN64c8K_I=.d711bc68-c800-45fd-9de5-5bd1c5621430@github.com>
 <SNPiblXpzCPdmntADzdMMqFCO6eSjKOltzwD5MWnipc=.814578a6-ea9b-40b1-bfd8-199324b7281e@github.com>
 <_uFXfNAzlG3COOLDN_bJBEH4n0xtk52RH4jgW0MYF_w=.358107f1-fa87-4b5a-8ded-08248080678f@github.com>
Message-ID: <JzpZmZbaq1b-bBgth2Wq1YTVQKpP3DbToT4h8N7ofTE=.4490859d-21a1-4cc9-8e8c-a8d067c82989@github.com>

On Fri, 12 Feb 2021 21:03:04 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> I've updated the issue summary to better reflect the changes, the PR summary should be renamed accordingly. 
>> As mentioned earlier, have you run the tests for the affected areas? Here's some information on how to do that: http://openjdk.java.net/guide/#testing-the-jdk
>
> I rebased my changes onto master. (commit 837bd8930d0a010110f1318b947c036609d3aa33)
> and checked tier2 and tier3.
> What I got:
> 
>     ==============================
>     Test summary
>     ==============================
>        TEST                                              TOTAL  PASS  FAIL ERROR   
>     >> jtreg:test/jdk:tier2                               3698  3690     6     2 <<
>     >> jtreg:test/langtools:tier2                           12    11     1     0 <<
>        jtreg:test/jaxp:tier2                               450   450     0     0   
>     ==============================
>     TEST FAILURE
> 
> 
> 
> 
>     ==============================
>     Test summary
>     ==============================
>        TEST                                              TOTAL  PASS  FAIL ERROR   
>     >> jtreg:test/jdk:tier3                               1190  1188     2     0 <<
>        jtreg:test/langtools:tier3                            0     0     0     0   
>        jtreg:test/jaxp:tier3                                 0     0     0     0   
>     ==============================
>     TEST FAILURE
> 
> 
> Failed tests:
> 
>      tier2:
>      java/io/File/GetXSpace.java                                                                         Failed. Execution failed: `main' threw exception: java.nio.file.InvalidPathException: Illegal char <:> at index 0: :
>      java/net/MulticastSocket/MulticastAddresses.java                                                    Failed. Execution failed: `main' threw exception: java.lang.Exception: 1 test(s) failed - see log file.
>      java/net/MulticastSocket/SetLoopbackMode.java                                                       Failed. Execution failed: `main' threw exception: java.net.NoRouteToHostException: No route to host: no further information
>      java/nio/file/Files/CopyAndMove.java                                                                Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: AtomicMoveNotSupportedException expected
>      java/security/AccessController/DoPrivAccompliceTest.java                                            Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: 'user' found in stderr
>      tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java                                        Failed. Execution failed: `main' threw exception: jdk.jpackage.test.Functional$ExceptionBox: java.lang.RuntimeException: 2 FAILED TESTS
>      
>      sun/security/tools/jarsigner/TimestampCheck.java                                                    Error. Agent error: java.lang.Exception: Agent 72 timed out with a timeout of 2400 seconds; check console log for any additional details
>      sun/security/tools/keytool/DefaultOptions.java                                                      Error. Agent error: java.lang.Exception: Agent 77 timed out with a timeout of 480 seconds; check console log for any additional details
>      
>      jdk/jshell/ToolBasicTest.java                              Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 1
>      
>      tier3:
>      sanity/client/SwingSet/src/SwingSet2DemoTest.java                                                                  Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 1
>      sanity/client/SwingSet/src/ColorChooserDemoTest.java                                                               Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 1

Then I tried to run tests separately:
## java/io/File/GetXSpace.java


    make test TEST="jtreg:test/jdk/java/io/File/GetXSpace.java"

    STDERR:
    java.nio.file.InvalidPathException: Illegal char <:> at index 0: :
            at java.base/sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182)
            at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153)
            at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77)
            at java.base/sun.nio.fs.WindowsPath.parse(WindowsPath.java:92)
            at java.base/sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:230)
            at java.base/java.io.File.toPath(File.java:2316)
            at GetXSpace.compare(GetXSpace.java:219)
            at GetXSpace.testDF(GetXSpace.java:394)
            at GetXSpace.main(GetXSpace.java:428)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
            at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
            at java.base/java.lang.reflect.Method.invoke(Method.java:566)
            at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
            at java.base/java.lang.Thread.run(Thread.java:831)

    JavaTest Message: Test threw exception: java.nio.file.InvalidPathException
    JavaTest Message: shutting down test

    STDOUT:
    --- Testing df
    C:/Programs/cygwin64   350809332  172573816 178235516      50% /
    D:                    3702215676 2812548988 889666688      76% /cygdrive/d
    E:                    3906885628 3544182676 362702952      91% /cygdrive/e
    F:                     250057724  240917056   9140668      97% /cygdrive/f


    SecurityManager = null
    C:/Programs/cygwin64:
      df   total= 359228755968 free =            0 usable = 182513168384
      getX total= 359228755968 free = 182513168384 usable = 182513168384
    ::
      df   total= 3791068852224 free =            0 usable = 911018688512
      getX total=            0 free =            0 usable =            0

    TEST RESULT: Failed. Execution failed: `main' threw exception: java.nio.file.InvalidPathException: Illegal char <:> at index 0: :
--------------------------------------------------


https://bugs.openjdk.java.net/browse/JDK-8251466 looks like there is already known bug for similar cygwin output.

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

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

From github.com+741251+turbanoff at openjdk.java.net  Fri Feb 12 21:09:41 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Fri, 12 Feb 2021 21:09:41 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v8]
In-Reply-To: <JzpZmZbaq1b-bBgth2Wq1YTVQKpP3DbToT4h8N7ofTE=.4490859d-21a1-4cc9-8e8c-a8d067c82989@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <KcO_olP0uhrkPxSvala6b0MN3zsFy0_Skl06Oq6Gla0=.398341c8-a9c6-4186-ab43-df19bec9d544@github.com>
 <cONOB0wrdWjjltXXAuaH_SYz_ay7AgllB3SN64c8K_I=.d711bc68-c800-45fd-9de5-5bd1c5621430@github.com>
 <SNPiblXpzCPdmntADzdMMqFCO6eSjKOltzwD5MWnipc=.814578a6-ea9b-40b1-bfd8-199324b7281e@github.com>
 <_uFXfNAzlG3COOLDN_bJBEH4n0xtk52RH4jgW0MYF_w=.358107f1-fa87-4b5a-8ded-08248080678f@github.com>
 <JzpZmZbaq1b-bBgth2Wq1YTVQKpP3DbToT4h8N7ofTE=.4490859d-21a1-4cc9-8e8c-a8d067c82989@github.com>
Message-ID: <y0ZtJNDhwp3A2Jzsszmio6fg0sGSxvk49eZw2cR_kss=.16bf1d32-b7df-4b5b-a3cc-fd8b2d0bebbe@github.com>

On Fri, 12 Feb 2021 21:04:54 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> I rebased my changes onto master. (commit 837bd8930d0a010110f1318b947c036609d3aa33)
>> and checked tier2 and tier3.
>> What I got:
>> 
>>     ==============================
>>     Test summary
>>     ==============================
>>        TEST                                              TOTAL  PASS  FAIL ERROR   
>>     >> jtreg:test/jdk:tier2                               3698  3690     6     2 <<
>>     >> jtreg:test/langtools:tier2                           12    11     1     0 <<
>>        jtreg:test/jaxp:tier2                               450   450     0     0   
>>     ==============================
>>     TEST FAILURE
>> 
>> 
>> 
>> 
>>     ==============================
>>     Test summary
>>     ==============================
>>        TEST                                              TOTAL  PASS  FAIL ERROR   
>>     >> jtreg:test/jdk:tier3                               1190  1188     2     0 <<
>>        jtreg:test/langtools:tier3                            0     0     0     0   
>>        jtreg:test/jaxp:tier3                                 0     0     0     0   
>>     ==============================
>>     TEST FAILURE
>> 
>> 
>> Failed tests:
>> 
>>      tier2:
>>      java/io/File/GetXSpace.java                                                                         Failed. Execution failed: `main' threw exception: java.nio.file.InvalidPathException: Illegal char <:> at index 0: :
>>      java/net/MulticastSocket/MulticastAddresses.java                                                    Failed. Execution failed: `main' threw exception: java.lang.Exception: 1 test(s) failed - see log file.
>>      java/net/MulticastSocket/SetLoopbackMode.java                                                       Failed. Execution failed: `main' threw exception: java.net.NoRouteToHostException: No route to host: no further information
>>      java/nio/file/Files/CopyAndMove.java                                                                Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: AtomicMoveNotSupportedException expected
>>      java/security/AccessController/DoPrivAccompliceTest.java                                            Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: 'user' found in stderr
>>      tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java                                        Failed. Execution failed: `main' threw exception: jdk.jpackage.test.Functional$ExceptionBox: java.lang.RuntimeException: 2 FAILED TESTS
>>      
>>      sun/security/tools/jarsigner/TimestampCheck.java                                                    Error. Agent error: java.lang.Exception: Agent 72 timed out with a timeout of 2400 seconds; check console log for any additional details
>>      sun/security/tools/keytool/DefaultOptions.java                                                      Error. Agent error: java.lang.Exception: Agent 77 timed out with a timeout of 480 seconds; check console log for any additional details
>>      
>>      jdk/jshell/ToolBasicTest.java                              Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 1
>>      
>>      tier3:
>>      sanity/client/SwingSet/src/SwingSet2DemoTest.java                                                                  Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 1
>>      sanity/client/SwingSet/src/ColorChooserDemoTest.java                                                               Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 1
>
> Then I tried to run tests separately:
> ## java/io/File/GetXSpace.java
> 
> 
>     make test TEST="jtreg:test/jdk/java/io/File/GetXSpace.java"
> 
>     STDERR:
>     java.nio.file.InvalidPathException: Illegal char <:> at index 0: :
>             at java.base/sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182)
>             at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153)
>             at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77)
>             at java.base/sun.nio.fs.WindowsPath.parse(WindowsPath.java:92)
>             at java.base/sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:230)
>             at java.base/java.io.File.toPath(File.java:2316)
>             at GetXSpace.compare(GetXSpace.java:219)
>             at GetXSpace.testDF(GetXSpace.java:394)
>             at GetXSpace.main(GetXSpace.java:428)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>             at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
>             at java.base/java.lang.Thread.run(Thread.java:831)
> 
>     JavaTest Message: Test threw exception: java.nio.file.InvalidPathException
>     JavaTest Message: shutting down test
> 
>     STDOUT:
>     --- Testing df
>     C:/Programs/cygwin64   350809332  172573816 178235516      50% /
>     D:                    3702215676 2812548988 889666688      76% /cygdrive/d
>     E:                    3906885628 3544182676 362702952      91% /cygdrive/e
>     F:                     250057724  240917056   9140668      97% /cygdrive/f
> 
> 
>     SecurityManager = null
>     C:/Programs/cygwin64:
>       df   total= 359228755968 free =            0 usable = 182513168384
>       getX total= 359228755968 free = 182513168384 usable = 182513168384
>     ::
>       df   total= 3791068852224 free =            0 usable = 911018688512
>       getX total=            0 free =            0 usable =            0
> 
>     TEST RESULT: Failed. Execution failed: `main' threw exception: java.nio.file.InvalidPathException: Illegal char <:> at index 0: :
> --------------------------------------------------
> 
> 
> https://bugs.openjdk.java.net/browse/JDK-8251466 looks like there is already known bug for similar cygwin output.

## java/net/MulticastSocket/MulticastAddresses.java

    make test TEST="jtreg:test/jdk/java/net/MulticastSocket/MulticastAddresses.java"

    STDOUT:
    Test: /224.80.80.80  ni: name:eth1 (PANGP Virtual Ethernet Adapter)
        joinGroup(InetAddress)     Passed.
        joinGroup(InetAddress,NetworkInterface)     Passed.
    Test: /129.1.1.1
        joinGroup(InetAddress)
        Passed: Not a multicast address
    Test: /ff01:0:0:0:0:0:0:1  ni: name:eth10 (VirtualBox Host-Only Ethernet Adapter)
        joinGroup(InetAddress) Failed: No route to host: no further information
    Test: /ff02:0:0:0:0:0:0:1234  ni: name:eth10 (VirtualBox Host-Only Ethernet Adapter)
        joinGroup(InetAddress)     Passed.
        joinGroup(InetAddress,NetworkInterface)     Passed.
    Test: /ff05:0:0:0:0:0:0:a  ni: name:eth10 (VirtualBox Host-Only Ethernet Adapter)
        joinGroup(InetAddress)     Passed.
        joinGroup(InetAddress,NetworkInterface)     Passed.
    Test: /ff0e:0:0:0:0:0:1234:a  ni: name:eth10 (VirtualBox Host-Only Ethernet Adapter)
        joinGroup(InetAddress)     Passed.
        joinGroup(InetAddress,NetworkInterface)     Passed.
    Test: /0:0:0:0:0:0:0:1
        joinGroup(InetAddress)
        Passed: Not a multicast address
    Test: /0:0:0:0:0:0:8101:101
        joinGroup(InetAddress)
        Passed: Not a multicast address
    Test: /fe80:0:0:0:a00:20ff:fee5:bc02
        joinGroup(InetAddress)
        Passed: Not a multicast address
    STDERR:
    java.lang.Exception: 1 test(s) failed - see log file.
            at MulticastAddresses.runTest(MulticastAddresses.java:93)
            at MulticastAddresses.main(MulticastAddresses.java:138)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
            at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
            at java.base/java.lang.reflect.Method.invoke(Method.java:566)
            at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
            at java.base/java.lang.Thread.run(Thread.java:831)

    JavaTest Message: Test threw exception: java.lang.Exception
    JavaTest Message: shutting down test


    TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.Exception: 1 test(s) failed - see log file.


I connected debbuger and got this stack trace:

    java.net.NoRouteToHostException: No route to host: no further information
        at java.base/sun.nio.ch.Net.joinOrDrop6(Native Method)
        at java.base/sun.nio.ch.Net.join6(Net.java:734)
        at java.base/sun.nio.ch.DatagramChannelImpl.innerJoin(DatagramChannelImpl.java:1515)
        at java.base/sun.nio.ch.DatagramChannelImpl.join(DatagramChannelImpl.java:1551)
        at java.base/sun.nio.ch.DatagramSocketAdaptor.joinGroup(DatagramSocketAdaptor.java:532)
        at java.base/sun.nio.ch.DatagramSocketAdaptor.joinGroup(DatagramSocketAdaptor.java:479)
        at java.base/java.net.MulticastSocket.joinGroup(MulticastSocket.java:318)
        at MulticastAddresses.runTest(MulticastAddresses.java:56)
        at MulticastAddresses.main(MulticastAddresses.java:138)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:566)
        at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
        at java.base/java.lang.Thread.run(Thread.java:831)
        
Not sure what actual cause. Will investigate further.

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

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

From github.com+741251+turbanoff at openjdk.java.net  Fri Feb 12 21:09:41 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Fri, 12 Feb 2021 21:09:41 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v8]
In-Reply-To: <SNPiblXpzCPdmntADzdMMqFCO6eSjKOltzwD5MWnipc=.814578a6-ea9b-40b1-bfd8-199324b7281e@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <KcO_olP0uhrkPxSvala6b0MN3zsFy0_Skl06Oq6Gla0=.398341c8-a9c6-4186-ab43-df19bec9d544@github.com>
 <cONOB0wrdWjjltXXAuaH_SYz_ay7AgllB3SN64c8K_I=.d711bc68-c800-45fd-9de5-5bd1c5621430@github.com>
 <SNPiblXpzCPdmntADzdMMqFCO6eSjKOltzwD5MWnipc=.814578a6-ea9b-40b1-bfd8-199324b7281e@github.com>
Message-ID: <_uFXfNAzlG3COOLDN_bJBEH4n0xtk52RH4jgW0MYF_w=.358107f1-fa87-4b5a-8ded-08248080678f@github.com>

On Mon, 8 Feb 2021 16:39:55 GMT, Julia Boes <jboes at openjdk.org> wrote:

>> The other security-related code changes look good to me.
>
> I've updated the issue summary to better reflect the changes, the PR summary should be renamed accordingly. 
> As mentioned earlier, have you run the tests for the affected areas? Here's some information on how to do that: http://openjdk.java.net/guide/#testing-the-jdk

I rebased my changes onto master. (commit 837bd8930d0a010110f1318b947c036609d3aa33)
and checked tier2 and tier3.
What I got:

    ==============================
    Test summary
    ==============================
       TEST                                              TOTAL  PASS  FAIL ERROR   
    >> jtreg:test/jdk:tier2                               3698  3690     6     2 <<
    >> jtreg:test/langtools:tier2                           12    11     1     0 <<
       jtreg:test/jaxp:tier2                               450   450     0     0   
    ==============================
    TEST FAILURE




    ==============================
    Test summary
    ==============================
       TEST                                              TOTAL  PASS  FAIL ERROR   
    >> jtreg:test/jdk:tier3                               1190  1188     2     0 <<
       jtreg:test/langtools:tier3                            0     0     0     0   
       jtreg:test/jaxp:tier3                                 0     0     0     0   
    ==============================
    TEST FAILURE


Failed tests:

     tier2:
     java/io/File/GetXSpace.java                                                                         Failed. Execution failed: `main' threw exception: java.nio.file.InvalidPathException: Illegal char <:> at index 0: :
     java/net/MulticastSocket/MulticastAddresses.java                                                    Failed. Execution failed: `main' threw exception: java.lang.Exception: 1 test(s) failed - see log file.
     java/net/MulticastSocket/SetLoopbackMode.java                                                       Failed. Execution failed: `main' threw exception: java.net.NoRouteToHostException: No route to host: no further information
     java/nio/file/Files/CopyAndMove.java                                                                Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: AtomicMoveNotSupportedException expected
     java/security/AccessController/DoPrivAccompliceTest.java                                            Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: 'user' found in stderr
     tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java                                        Failed. Execution failed: `main' threw exception: jdk.jpackage.test.Functional$ExceptionBox: java.lang.RuntimeException: 2 FAILED TESTS
     
     sun/security/tools/jarsigner/TimestampCheck.java                                                    Error. Agent error: java.lang.Exception: Agent 72 timed out with a timeout of 2400 seconds; check console log for any additional details
     sun/security/tools/keytool/DefaultOptions.java                                                      Error. Agent error: java.lang.Exception: Agent 77 timed out with a timeout of 480 seconds; check console log for any additional details
     
     jdk/jshell/ToolBasicTest.java                              Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 1
     
     tier3:
     sanity/client/SwingSet/src/SwingSet2DemoTest.java                                                                  Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 1
     sanity/client/SwingSet/src/ColorChooserDemoTest.java                                                               Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 1

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

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

From github.com+741251+turbanoff at openjdk.java.net  Fri Feb 12 21:14:40 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Fri, 12 Feb 2021 21:14:40 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v8]
In-Reply-To: <y0ZtJNDhwp3A2Jzsszmio6fg0sGSxvk49eZw2cR_kss=.16bf1d32-b7df-4b5b-a3cc-fd8b2d0bebbe@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <KcO_olP0uhrkPxSvala6b0MN3zsFy0_Skl06Oq6Gla0=.398341c8-a9c6-4186-ab43-df19bec9d544@github.com>
 <cONOB0wrdWjjltXXAuaH_SYz_ay7AgllB3SN64c8K_I=.d711bc68-c800-45fd-9de5-5bd1c5621430@github.com>
 <SNPiblXpzCPdmntADzdMMqFCO6eSjKOltzwD5MWnipc=.814578a6-ea9b-40b1-bfd8-199324b7281e@github.com>
 <_uFXfNAzlG3COOLDN_bJBEH4n0xtk52RH4jgW0MYF_w=.358107f1-fa87-4b5a-8ded-08248080678f@github.com>
 <JzpZmZbaq1b-bBgth2Wq1YTVQKpP3DbToT4h8N7ofTE=.4490859d-21a1-4cc9-8e8c-a8d067c82989@github.com>
 <y0ZtJNDhwp3A2Jzsszmio6fg0sGSxvk49eZw2cR_kss=.16bf1d32-b7df-4b5b-a3cc-fd8b2d0bebbe@github.com>
Message-ID: <9ueMq5ar7LfXsQ5hV2wMnVVethu_2kyzuelDPv_8tfk=.b40c37bb-604e-478f-bc01-428694f0d4c9@github.com>

On Fri, 12 Feb 2021 21:06:24 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> Then I tried to run tests separately:
>> ## java/io/File/GetXSpace.java
>> 
>> 
>>     make test TEST="jtreg:test/jdk/java/io/File/GetXSpace.java"
>> 
>>     STDERR:
>>     java.nio.file.InvalidPathException: Illegal char <:> at index 0: :
>>             at java.base/sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182)
>>             at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153)
>>             at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77)
>>             at java.base/sun.nio.fs.WindowsPath.parse(WindowsPath.java:92)
>>             at java.base/sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:230)
>>             at java.base/java.io.File.toPath(File.java:2316)
>>             at GetXSpace.compare(GetXSpace.java:219)
>>             at GetXSpace.testDF(GetXSpace.java:394)
>>             at GetXSpace.main(GetXSpace.java:428)
>>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>>             at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
>>             at java.base/java.lang.Thread.run(Thread.java:831)
>> 
>>     JavaTest Message: Test threw exception: java.nio.file.InvalidPathException
>>     JavaTest Message: shutting down test
>> 
>>     STDOUT:
>>     --- Testing df
>>     C:/Programs/cygwin64   350809332  172573816 178235516      50% /
>>     D:                    3702215676 2812548988 889666688      76% /cygdrive/d
>>     E:                    3906885628 3544182676 362702952      91% /cygdrive/e
>>     F:                     250057724  240917056   9140668      97% /cygdrive/f
>> 
>> 
>>     SecurityManager = null
>>     C:/Programs/cygwin64:
>>       df   total= 359228755968 free =            0 usable = 182513168384
>>       getX total= 359228755968 free = 182513168384 usable = 182513168384
>>     ::
>>       df   total= 3791068852224 free =            0 usable = 911018688512
>>       getX total=            0 free =            0 usable =            0
>> 
>>     TEST RESULT: Failed. Execution failed: `main' threw exception: java.nio.file.InvalidPathException: Illegal char <:> at index 0: :
>> --------------------------------------------------
>> 
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8251466 looks like there is already known bug for similar cygwin output.
>
> ## java/net/MulticastSocket/MulticastAddresses.java
> 
>     make test TEST="jtreg:test/jdk/java/net/MulticastSocket/MulticastAddresses.java"
> 
>     STDOUT:
>     Test: /224.80.80.80  ni: name:eth1 (PANGP Virtual Ethernet Adapter)
>         joinGroup(InetAddress)     Passed.
>         joinGroup(InetAddress,NetworkInterface)     Passed.
>     Test: /129.1.1.1
>         joinGroup(InetAddress)
>         Passed: Not a multicast address
>     Test: /ff01:0:0:0:0:0:0:1  ni: name:eth10 (VirtualBox Host-Only Ethernet Adapter)
>         joinGroup(InetAddress) Failed: No route to host: no further information
>     Test: /ff02:0:0:0:0:0:0:1234  ni: name:eth10 (VirtualBox Host-Only Ethernet Adapter)
>         joinGroup(InetAddress)     Passed.
>         joinGroup(InetAddress,NetworkInterface)     Passed.
>     Test: /ff05:0:0:0:0:0:0:a  ni: name:eth10 (VirtualBox Host-Only Ethernet Adapter)
>         joinGroup(InetAddress)     Passed.
>         joinGroup(InetAddress,NetworkInterface)     Passed.
>     Test: /ff0e:0:0:0:0:0:1234:a  ni: name:eth10 (VirtualBox Host-Only Ethernet Adapter)
>         joinGroup(InetAddress)     Passed.
>         joinGroup(InetAddress,NetworkInterface)     Passed.
>     Test: /0:0:0:0:0:0:0:1
>         joinGroup(InetAddress)
>         Passed: Not a multicast address
>     Test: /0:0:0:0:0:0:8101:101
>         joinGroup(InetAddress)
>         Passed: Not a multicast address
>     Test: /fe80:0:0:0:a00:20ff:fee5:bc02
>         joinGroup(InetAddress)
>         Passed: Not a multicast address
>     STDERR:
>     java.lang.Exception: 1 test(s) failed - see log file.
>             at MulticastAddresses.runTest(MulticastAddresses.java:93)
>             at MulticastAddresses.main(MulticastAddresses.java:138)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>             at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
>             at java.base/java.lang.Thread.run(Thread.java:831)
> 
>     JavaTest Message: Test threw exception: java.lang.Exception
>     JavaTest Message: shutting down test
> 
> 
>     TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.Exception: 1 test(s) failed - see log file.
> 
> 
> I connected debbuger and got this stack trace:
> 
>     java.net.NoRouteToHostException: No route to host: no further information
>         at java.base/sun.nio.ch.Net.joinOrDrop6(Native Method)
>         at java.base/sun.nio.ch.Net.join6(Net.java:734)
>         at java.base/sun.nio.ch.DatagramChannelImpl.innerJoin(DatagramChannelImpl.java:1515)
>         at java.base/sun.nio.ch.DatagramChannelImpl.join(DatagramChannelImpl.java:1551)
>         at java.base/sun.nio.ch.DatagramSocketAdaptor.joinGroup(DatagramSocketAdaptor.java:532)
>         at java.base/sun.nio.ch.DatagramSocketAdaptor.joinGroup(DatagramSocketAdaptor.java:479)
>         at java.base/java.net.MulticastSocket.joinGroup(MulticastSocket.java:318)
>         at MulticastAddresses.runTest(MulticastAddresses.java:56)
>         at MulticastAddresses.main(MulticastAddresses.java:138)
>         at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>         at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>         at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>         at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
>         at java.base/java.lang.Thread.run(Thread.java:831)
>         
> Not sure what actual cause. Will investigate further.

## java/net/MulticastSocket/SetLoopbackMode.java

    make test TEST="jtreg:test/jdk/java/net/MulticastSocket/SetLoopbackMode.java"
    
    
    STDOUT:
    IPv6 can be used
    Default network interface: null

    Test will use multicast group: /ff01:0:0:0:0:0:0:1
    NetworkInterface.getByInetAddress(grp): null
    STDERR:
    java.net.NoRouteToHostException: No route to host: no further information
            at java.base/sun.nio.ch.Net.joinOrDrop6(Native Method)
            at java.base/sun.nio.ch.Net.join6(Net.java:734)
            at java.base/sun.nio.ch.DatagramChannelImpl.innerJoin(DatagramChannelImpl.java:1515)
            at java.base/sun.nio.ch.DatagramChannelImpl.join(DatagramChannelImpl.java:1551)
            at java.base/sun.nio.ch.DatagramSocketAdaptor.joinGroup(DatagramSocketAdaptor.java:532)
            at java.base/sun.nio.ch.DatagramSocketAdaptor.joinGroup(DatagramSocketAdaptor.java:479)
            at java.base/java.net.MulticastSocket.joinGroup(MulticastSocket.java:318)
            at SetLoopbackMode.main(SetLoopbackMode.java:132)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
            at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
            at java.base/java.lang.reflect.Method.invoke(Method.java:566)
            at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
            at java.base/java.lang.Thread.run(Thread.java:831)

    JavaTest Message: Test threw exception: java.net.NoRouteToHostException: No route to host: no further information
    JavaTest Message: shutting down test

    STATUS:Failed.`main' threw exception: java.net.NoRouteToHostException: No route to host: no further information
    
Cause looks similar to `MulticastAddresses`: virtualbox network interface:
Test: /ff01:0:0:0:0:0:0:1  ni: name:eth10 (VirtualBox Host-Only Ethernet Adapter)
    joinGroup(InetAddress) Failed: No route to host: no further information
Will investigate futher.

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

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

From github.com+741251+turbanoff at openjdk.java.net  Fri Feb 12 21:34:41 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Fri, 12 Feb 2021 21:34:41 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v8]
In-Reply-To: <9ueMq5ar7LfXsQ5hV2wMnVVethu_2kyzuelDPv_8tfk=.b40c37bb-604e-478f-bc01-428694f0d4c9@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <KcO_olP0uhrkPxSvala6b0MN3zsFy0_Skl06Oq6Gla0=.398341c8-a9c6-4186-ab43-df19bec9d544@github.com>
 <cONOB0wrdWjjltXXAuaH_SYz_ay7AgllB3SN64c8K_I=.d711bc68-c800-45fd-9de5-5bd1c5621430@github.com>
 <SNPiblXpzCPdmntADzdMMqFCO6eSjKOltzwD5MWnipc=.814578a6-ea9b-40b1-bfd8-199324b7281e@github.com>
 <_uFXfNAzlG3COOLDN_bJBEH4n0xtk52RH4jgW0MYF_w=.358107f1-fa87-4b5a-8ded-08248080678f@github.com>
 <JzpZmZbaq1b-bBgth2Wq1YTVQKpP3DbToT4h8N7ofTE=.4490859d-21a1-4cc9-8e8c-a8d067c82989@github.com>
 <y0ZtJNDhwp3A2Jzsszmio6fg0sGSxvk49eZw2cR_kss=.16bf1d32-b7df-4b5b-a3cc-fd8b2d0bebbe@github.com>
 <9ueMq5ar7LfXsQ5hV2wMnVVethu_2kyzuelDPv_8tfk=.b40c37bb-604e-478f-bc01-428694f0d4c9@github.com>
Message-ID: <KctKgE0hs5s-qmGmNe_tJwW5C-IrvK5i72mO06GZ3v4=.f48f8a2d-a4a9-4074-9350-7cd443f73373@github.com>

On Fri, 12 Feb 2021 21:12:14 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> ## java/net/MulticastSocket/MulticastAddresses.java
>> 
>>     make test TEST="jtreg:test/jdk/java/net/MulticastSocket/MulticastAddresses.java"
>> 
>>     STDOUT:
>>     Test: /224.80.80.80  ni: name:eth1 (PANGP Virtual Ethernet Adapter)
>>         joinGroup(InetAddress)     Passed.
>>         joinGroup(InetAddress,NetworkInterface)     Passed.
>>     Test: /129.1.1.1
>>         joinGroup(InetAddress)
>>         Passed: Not a multicast address
>>     Test: /ff01:0:0:0:0:0:0:1  ni: name:eth10 (VirtualBox Host-Only Ethernet Adapter)
>>         joinGroup(InetAddress) Failed: No route to host: no further information
>>     Test: /ff02:0:0:0:0:0:0:1234  ni: name:eth10 (VirtualBox Host-Only Ethernet Adapter)
>>         joinGroup(InetAddress)     Passed.
>>         joinGroup(InetAddress,NetworkInterface)     Passed.
>>     Test: /ff05:0:0:0:0:0:0:a  ni: name:eth10 (VirtualBox Host-Only Ethernet Adapter)
>>         joinGroup(InetAddress)     Passed.
>>         joinGroup(InetAddress,NetworkInterface)     Passed.
>>     Test: /ff0e:0:0:0:0:0:1234:a  ni: name:eth10 (VirtualBox Host-Only Ethernet Adapter)
>>         joinGroup(InetAddress)     Passed.
>>         joinGroup(InetAddress,NetworkInterface)     Passed.
>>     Test: /0:0:0:0:0:0:0:1
>>         joinGroup(InetAddress)
>>         Passed: Not a multicast address
>>     Test: /0:0:0:0:0:0:8101:101
>>         joinGroup(InetAddress)
>>         Passed: Not a multicast address
>>     Test: /fe80:0:0:0:a00:20ff:fee5:bc02
>>         joinGroup(InetAddress)
>>         Passed: Not a multicast address
>>     STDERR:
>>     java.lang.Exception: 1 test(s) failed - see log file.
>>             at MulticastAddresses.runTest(MulticastAddresses.java:93)
>>             at MulticastAddresses.main(MulticastAddresses.java:138)
>>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>>             at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
>>             at java.base/java.lang.Thread.run(Thread.java:831)
>> 
>>     JavaTest Message: Test threw exception: java.lang.Exception
>>     JavaTest Message: shutting down test
>> 
>> 
>>     TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.Exception: 1 test(s) failed - see log file.
>> 
>> 
>> I connected debbuger and got this stack trace:
>> 
>>     java.net.NoRouteToHostException: No route to host: no further information
>>         at java.base/sun.nio.ch.Net.joinOrDrop6(Native Method)
>>         at java.base/sun.nio.ch.Net.join6(Net.java:734)
>>         at java.base/sun.nio.ch.DatagramChannelImpl.innerJoin(DatagramChannelImpl.java:1515)
>>         at java.base/sun.nio.ch.DatagramChannelImpl.join(DatagramChannelImpl.java:1551)
>>         at java.base/sun.nio.ch.DatagramSocketAdaptor.joinGroup(DatagramSocketAdaptor.java:532)
>>         at java.base/sun.nio.ch.DatagramSocketAdaptor.joinGroup(DatagramSocketAdaptor.java:479)
>>         at java.base/java.net.MulticastSocket.joinGroup(MulticastSocket.java:318)
>>         at MulticastAddresses.runTest(MulticastAddresses.java:56)
>>         at MulticastAddresses.main(MulticastAddresses.java:138)
>>         at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>         at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>>         at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>         at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>>         at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
>>         at java.base/java.lang.Thread.run(Thread.java:831)
>>         
>> Not sure what actual cause. Will investigate further.
>
> ## java/net/MulticastSocket/SetLoopbackMode.java
> 
>     make test TEST="jtreg:test/jdk/java/net/MulticastSocket/SetLoopbackMode.java"
>     
>     
>     STDOUT:
>     IPv6 can be used
>     Default network interface: null
> 
>     Test will use multicast group: /ff01:0:0:0:0:0:0:1
>     NetworkInterface.getByInetAddress(grp): null
>     STDERR:
>     java.net.NoRouteToHostException: No route to host: no further information
>             at java.base/sun.nio.ch.Net.joinOrDrop6(Native Method)
>             at java.base/sun.nio.ch.Net.join6(Net.java:734)
>             at java.base/sun.nio.ch.DatagramChannelImpl.innerJoin(DatagramChannelImpl.java:1515)
>             at java.base/sun.nio.ch.DatagramChannelImpl.join(DatagramChannelImpl.java:1551)
>             at java.base/sun.nio.ch.DatagramSocketAdaptor.joinGroup(DatagramSocketAdaptor.java:532)
>             at java.base/sun.nio.ch.DatagramSocketAdaptor.joinGroup(DatagramSocketAdaptor.java:479)
>             at java.base/java.net.MulticastSocket.joinGroup(MulticastSocket.java:318)
>             at SetLoopbackMode.main(SetLoopbackMode.java:132)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>             at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>             at java.base/java.lang.Thread.run(Thread.java:831)
> 
>     JavaTest Message: Test threw exception: java.net.NoRouteToHostException: No route to host: no further information
>     JavaTest Message: shutting down test
> 
>     STATUS:Failed.`main' threw exception: java.net.NoRouteToHostException: No route to host: no further information
>     
> Cause looks similar to `MulticastAddresses`: virtualbox network interface:
> Test: /ff01:0:0:0:0:0:0:1  ni: name:eth10 (VirtualBox Host-Only Ethernet Adapter)
>     joinGroup(InetAddress) Failed: No route to host: no further information
> Will investigate futher.

## java/nio/file/Files/CopyAndMove.java    
    
    make test TEST="jtreg:java/nio/file/Files/CopyAndMove.java"
    
    STDOUT:
    Seed from RandomFactory = 704532001916725417L
    STDERR:
    dir1: f:\projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_nio_file_Files_CopyAndMove_java\tmp\name9678927043623070601 (NTFS)
    dir2: .\name1900089232270637553 (NTFS)
    java.lang.RuntimeException: AtomicMoveNotSupportedException expected
            at CopyAndMove.testMove(CopyAndMove.java:369)
            at CopyAndMove.main(CopyAndMove.java:74)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
            at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
            at java.base/java.lang.reflect.Method.invoke(Method.java:566)
            at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
            at java.base/java.lang.Thread.run(Thread.java:831)

    JavaTest Message: Test threw exception: java.lang.RuntimeException: AtomicMoveNotSupportedException expected
    JavaTest Message: shutting down test

    STATUS:Failed.`main' threw exception: java.lang.RuntimeException: AtomicMoveNotSupportedException expected

Checked in debugger:

    Files.getFileStore(dir1) = {WindowsFileStore at 1211} "ssd (f:)"
    Files.getFileStore(dir2) = {WindowsFileStore at 1213} "ssd (F:)"
    sameDevice = false

https://bugs.openjdk.java.net/browse/JDK-8219644 looks like there is already known bug this test.

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

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

From github.com+741251+turbanoff at openjdk.java.net  Fri Feb 12 21:55:43 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Fri, 12 Feb 2021 21:55:43 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v8]
In-Reply-To: <KctKgE0hs5s-qmGmNe_tJwW5C-IrvK5i72mO06GZ3v4=.f48f8a2d-a4a9-4074-9350-7cd443f73373@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <KcO_olP0uhrkPxSvala6b0MN3zsFy0_Skl06Oq6Gla0=.398341c8-a9c6-4186-ab43-df19bec9d544@github.com>
 <cONOB0wrdWjjltXXAuaH_SYz_ay7AgllB3SN64c8K_I=.d711bc68-c800-45fd-9de5-5bd1c5621430@github.com>
 <SNPiblXpzCPdmntADzdMMqFCO6eSjKOltzwD5MWnipc=.814578a6-ea9b-40b1-bfd8-199324b7281e@github.com>
 <_uFXfNAzlG3COOLDN_bJBEH4n0xtk52RH4jgW0MYF_w=.358107f1-fa87-4b5a-8ded-08248080678f@github.com>
 <JzpZmZbaq1b-bBgth2Wq1YTVQKpP3DbToT4h8N7ofTE=.4490859d-21a1-4cc9-8e8c-a8d067c82989@github.com>
 <y0ZtJNDhwp3A2Jzsszmio6fg0sGSxvk49eZw2cR_kss=.16bf1d32-b7df-4b5b-a3cc-fd8b2d0bebbe@github.com>
 <9ueMq5ar7LfXsQ5hV2wMnVVethu_2kyzuelDPv_8tfk=.b40c37bb-604e-478f-bc01-428694f0d4c9@github.com>
 <KctKgE0hs5s-qmGmNe_tJwW5C-IrvK5i72mO06GZ3v4=.f48f8a2d-a4a9-4074-9350-7cd443f73373@github.com>
Message-ID: <hGiSvYyNa6D0BuKfIh-3CkelapBMNrFaQ_prF3xzPQQ=.64336055-18e5-4428-bc5b-40d484ed18ba@github.com>

On Fri, 12 Feb 2021 21:32:04 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> ## java/net/MulticastSocket/SetLoopbackMode.java
>> 
>>     make test TEST="jtreg:test/jdk/java/net/MulticastSocket/SetLoopbackMode.java"
>>     
>>     
>>     STDOUT:
>>     IPv6 can be used
>>     Default network interface: null
>> 
>>     Test will use multicast group: /ff01:0:0:0:0:0:0:1
>>     NetworkInterface.getByInetAddress(grp): null
>>     STDERR:
>>     java.net.NoRouteToHostException: No route to host: no further information
>>             at java.base/sun.nio.ch.Net.joinOrDrop6(Native Method)
>>             at java.base/sun.nio.ch.Net.join6(Net.java:734)
>>             at java.base/sun.nio.ch.DatagramChannelImpl.innerJoin(DatagramChannelImpl.java:1515)
>>             at java.base/sun.nio.ch.DatagramChannelImpl.join(DatagramChannelImpl.java:1551)
>>             at java.base/sun.nio.ch.DatagramSocketAdaptor.joinGroup(DatagramSocketAdaptor.java:532)
>>             at java.base/sun.nio.ch.DatagramSocketAdaptor.joinGroup(DatagramSocketAdaptor.java:479)
>>             at java.base/java.net.MulticastSocket.joinGroup(MulticastSocket.java:318)
>>             at SetLoopbackMode.main(SetLoopbackMode.java:132)
>>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>>             at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>>             at java.base/java.lang.Thread.run(Thread.java:831)
>> 
>>     JavaTest Message: Test threw exception: java.net.NoRouteToHostException: No route to host: no further information
>>     JavaTest Message: shutting down test
>> 
>>     STATUS:Failed.`main' threw exception: java.net.NoRouteToHostException: No route to host: no further information
>>     
>> Cause looks similar to `MulticastAddresses`: virtualbox network interface:
>> Test: /ff01:0:0:0:0:0:0:1  ni: name:eth10 (VirtualBox Host-Only Ethernet Adapter)
>>     joinGroup(InetAddress) Failed: No route to host: no further information
>> Will investigate futher.
>
> ## java/nio/file/Files/CopyAndMove.java    
>     
>     make test TEST="jtreg:java/nio/file/Files/CopyAndMove.java"
>     
>     STDOUT:
>     Seed from RandomFactory = 704532001916725417L
>     STDERR:
>     dir1: f:\projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_nio_file_Files_CopyAndMove_java\tmp\name9678927043623070601 (NTFS)
>     dir2: .\name1900089232270637553 (NTFS)
>     java.lang.RuntimeException: AtomicMoveNotSupportedException expected
>             at CopyAndMove.testMove(CopyAndMove.java:369)
>             at CopyAndMove.main(CopyAndMove.java:74)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>             at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>             at java.base/java.lang.Thread.run(Thread.java:831)
> 
>     JavaTest Message: Test threw exception: java.lang.RuntimeException: AtomicMoveNotSupportedException expected
>     JavaTest Message: shutting down test
> 
>     STATUS:Failed.`main' threw exception: java.lang.RuntimeException: AtomicMoveNotSupportedException expected
> 
> Checked in debugger:
> 
>     Files.getFileStore(dir1) = {WindowsFileStore at 1211} "ssd (f:)"
>     Files.getFileStore(dir2) = {WindowsFileStore at 1213} "ssd (F:)"
>     sameDevice = false
> 
> https://bugs.openjdk.java.net/browse/JDK-8219644 looks like there is already known bug this test.

## java/security/AccessController/DoPrivAccompliceTest.java

    make test TEST="jtreg:java/security/AccessController/DoPrivAccompliceTest.java"

    STDOUT:
    Adding DoPrivAccomplice.class to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar

    Created jar file F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar
    Adding DoPrivTest.class to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar

    Created jar file F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar
    Created policy for F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar
    Command line: [f:\projects\official_openjdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe -cp F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\classes\0\java\security\AccessController\DoPrivAccompliceTest.d;F:\Projects\official_openjdk\test\jdk\java\security\AccessController;F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\classes\0\test\lib;F:\Projects\official_openjdk\test\lib;C:\Programs\jtreg-4.2.0-tip\jtreg\lib\javatest.jar;C:\Programs\jtreg-4.2.0-tip\jtreg\lib\jtreg.jar -Xmx512m -XX:MaxRAMPercentage=6 -Djava.io.tmpdir=f:\projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\tmp -ea -esa -Djava.security.manager -Djava.security.policy=F:\Projects\official_openjdk\build\win
 dows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\java.policy -classpath F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar;F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar DoPrivTest ]
    [2021-02-12T21:42:29.297091800Z] Gathering output for process 12712
    [2021-02-12T21:42:29.544092Z] Waiting for completion for process 12712
    [2021-02-12T21:42:29.544092Z] Waiting for completion finished for process 12712
    Output and diagnostic info for process 12712 was saved into 'pid-12712-output.log'
    [2021-02-12T21:42:29.547092500Z] Waiting for completion for process 12712
    [2021-02-12T21:42:29.547092500Z] Waiting for completion finished for process 12712
    Created policy for F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar
    Command line: [f:\projects\official_openjdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe -cp F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\classes\0\java\security\AccessController\DoPrivAccompliceTest.d;F:\Projects\official_openjdk\test\jdk\java\security\AccessController;F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\classes\0\test\lib;F:\Projects\official_openjdk\test\lib;C:\Programs\jtreg-4.2.0-tip\jtreg\lib\javatest.jar;C:\Programs\jtreg-4.2.0-tip\jtreg\lib\jtreg.jar -Xmx512m -XX:MaxRAMPercentage=6 -Djava.io.tmpdir=f:\projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\tmp -ea -esa -Djava.security.manager -Djava.security.policy=F:\Projects\official_openjdk\build\win
 dows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\java.policy -classpath F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar;F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar DoPrivTest ]
    [2021-02-12T21:42:29.553092400Z] Gathering output for process 10560
    [2021-02-12T21:42:29.783092500Z] Waiting for completion for process 10560
    [2021-02-12T21:42:29.783092500Z] Waiting for completion finished for process 10560
    Output and diagnostic info for process 10560 was saved into 'pid-10560-output.log'
    [2021-02-12T21:42:29.785092800Z] Waiting for completion for process 10560
    [2021-02-12T21:42:29.785092800Z] Waiting for completion finished for process 10560
    [2021-02-12T21:42:29.785092800Z] Waiting for completion for process 10560
    [2021-02-12T21:42:29.785092800Z] Waiting for completion finished for process 10560
    STDERR:
     stdout: [];
     stderr: [Exception in thread "main" java.security.AccessControlException: access denied ("java.util.PropertyPermission" "user.name" "read")
            at java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
            at java.base/java.security.AccessController.checkPermission(AccessController.java:1036)
            at java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:408)
            at java.base/java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1152)
            at java.base/java.lang.System.getProperty(System.java:833)
            at DoPrivAccomplice.lambda$go$0(DoPrivAccomplice.java:31)
            at java.base/java.security.AccessController.doPrivileged(AccessController.java:312)
            at DoPrivAccomplice.go(DoPrivAccomplice.java:30)
            at DoPrivTest.main(DoPrivTest.java:29)
    ]
     exitValue = 1

    java.lang.RuntimeException: 'user' found in stderr

            at jdk.test.lib.process.OutputAnalyzer.shouldNotContain(OutputAnalyzer.java:256)
            at DoPrivAccompliceTest.main(DoPrivAccompliceTest.java:112)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
            at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
            at java.base/java.lang.reflect.Method.invoke(Method.java:566)
            at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
            at java.base/java.lang.Thread.run(Thread.java:831)

    JavaTest Message: Test threw exception: java.lang.RuntimeException: 'user' found in stderr

    JavaTest Message: shutting down test

    STATUS:Failed.`main' threw exception: java.lang.RuntimeException: 'user' found in stderr
    
Looks like test is not ready for username `user`, which I use locally.

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

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

From cjplummer at openjdk.java.net  Fri Feb 12 22:04:41 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Fri, 12 Feb 2021 22:04:41 GMT
Subject: Integrated: 8247514: Improve clhsdb 'findpc' ability to determine
 what an address points to by improving PointerFinder and PointerLocation
 classes
In-Reply-To: <4YKNpyXQ9QGrLhR61tkh71Q3A7VvCj5Ete_4OvzAA-o=.28b7be8c-6f05-42d4-892b-87ebea907b24@github.com>
References: <4YKNpyXQ9QGrLhR61tkh71Q3A7VvCj5Ete_4OvzAA-o=.28b7be8c-6f05-42d4-892b-87ebea907b24@github.com>
Message-ID: <qIpvWgLScMfQanI7LgfHoM9BgueEiFDofQqwmsddd0o=.84935d49-f1ec-4116-88c0-3ccb1a031f19@github.com>

On Sun, 17 Jan 2021 03:57:59 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> See the bug for most details. A few notes here about some implementation details:
> 
> In the `PointerLocation` class, I added more consistency w.r.t. whether or not a newline is printed. It used to for some address types, but not others. Now it always does. And if you see a comment something like the following:
> 
> `         getTLAB().printOn(tty); // includes "\n" `
> 
> That's just clarifying whether or not the `printOn()` method called will include the newline. Some do and some don't, and knowing what the various `printOn()` methods do makes getting the proper inclusion of the newline easier to understand.
> 
> I added `verbose` and `printAddress` boolean arguments to `PointerLocation.printOn()`. Currently they are always `true`. The false arguments will be used when I complete [JDK-8250801](https://bugs.openjdk.java.net/browse/JDK-8250801), which will use `PointerFinder/Location` to show what each register points to.
> 
> The CR mentions that the main motivation for this work is for eventual replacement of the old clhsdb `whatis` command, which was implemented in javascript. It used to resolve DSO symbols, whereas `findpc` did not. The `whatis` code did this with the following:
> 
>   var dso = loadObjectContainingPC(addr);
>   if (dso == null) {
>     return ptrLoc.toString();
>   }
>   var sym = dso.closestSymbolToPC(addr);
>   if (sym != null) {
>     return sym.name + '+' + sym.offset;
>   }
> And now you'll see something similar in the PointerFinder code:
> 
>         loc.loadObject = cdbg.loadObjectContainingPC(a);
>         if (loc.loadObject != null) {
>             loc.nativeSymbol = loc.loadObject.closestSymbolToPC(a);
>             return loc;
>         } 
> Note that now that `findpc` does everything that `whatis` used to (and more), we don't really need to add a java version of `whatis`, but I'll probably do so anyway just help out people who are used to using the `whatis` command. That will be done using [JDK-8244670](https://bugs.openjdk.java.net/browse/JDK-8244670)

This pull request has now been integrated.

Changeset: e29c560a
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e29c560a
Stats:     292 lines in 5 files changed: 238 ins; 8 del; 46 mod

8247514: Improve clhsdb 'findpc' ability to determine what an address points to by improving PointerFinder and PointerLocation classes

Reviewed-by: ysuenaga, kevinw

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

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

From coleenp at openjdk.java.net  Fri Feb 12 22:06:40 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Fri, 12 Feb 2021 22:06:40 GMT
Subject: RFR: 8241403: JavaThread::get_thread_name() should be
 ThreadSMR-aware
In-Reply-To: <wRdcRQurtpybntK9Qpji-6zVY-EcHKw3q87xpD0eoS4=.a6dc32f4-2919-42e9-80c3-5a264067f0e2@github.com>
References: <wRdcRQurtpybntK9Qpji-6zVY-EcHKw3q87xpD0eoS4=.a6dc32f4-2919-42e9-80c3-5a264067f0e2@github.com>
Message-ID: <Uke4223ee6tPQRFdiMkUsIF7oRrz6bm4LMk1FpnmR-k=.190befb3-4d2b-44cf-81c7-2f2d147bd784@github.com>

On Thu, 11 Feb 2021 22:04:53 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A minor fix to add a new function:
> 
>     bool Thread::is_JavaThread_protected(const JavaThread* p)
> 
> that returns true when the target JavaThread* is protected and false
> otherwise. Update JavaThread::get_thread_name() to create a
> ThreadsListHandle and use the new is_JavaThread_protected(). Also
> update JvmtiTrace::safe_get_thread_name() to use the new
> is_JavaThread_protected().
> 
> This fix is tested via a Mach5 Tier[1-8] run.

This looks good, I have a change - could you see if you agree.
It's nice not to have to take Threads_lock to get the name of the thread.

src/hotspot/share/runtime/thread.hpp line 1692:

> 1690:   const char* get_thread_name() const;
> 1691:  protected:
> 1692:   friend class JvmtiTrace;  // so get_thread_name_string() can be called

I was trying to think of a way to not have JvmtiTrace not be a friend of JavaThread for this, maybe by adding a default value parameter to return "<NOT FILLED IN\>" rather than Thread::name.
is_JavaThread_protected only seems to be called by JvmtiTrace also, so should be private (with the friend, which also makes the friend unfortunate).

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

Changes requested by coleenp (Reviewer).

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

From github.com+741251+turbanoff at openjdk.java.net  Fri Feb 12 22:15:43 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Fri, 12 Feb 2021 22:15:43 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v8]
In-Reply-To: <hGiSvYyNa6D0BuKfIh-3CkelapBMNrFaQ_prF3xzPQQ=.64336055-18e5-4428-bc5b-40d484ed18ba@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <KcO_olP0uhrkPxSvala6b0MN3zsFy0_Skl06Oq6Gla0=.398341c8-a9c6-4186-ab43-df19bec9d544@github.com>
 <cONOB0wrdWjjltXXAuaH_SYz_ay7AgllB3SN64c8K_I=.d711bc68-c800-45fd-9de5-5bd1c5621430@github.com>
 <SNPiblXpzCPdmntADzdMMqFCO6eSjKOltzwD5MWnipc=.814578a6-ea9b-40b1-bfd8-199324b7281e@github.com>
 <_uFXfNAzlG3COOLDN_bJBEH4n0xtk52RH4jgW0MYF_w=.358107f1-fa87-4b5a-8ded-08248080678f@github.com>
 <JzpZmZbaq1b-bBgth2Wq1YTVQKpP3DbToT4h8N7ofTE=.4490859d-21a1-4cc9-8e8c-a8d067c82989@github.com>
 <y0ZtJNDhwp3A2Jzsszmio6fg0sGSxvk49eZw2cR_kss=.16bf1d32-b7df-4b5b-a3cc-fd8b2d0bebbe@github.com>
 <9ueMq5ar7LfXsQ5hV2wMnVVethu_2kyzuelDPv_8tfk=.b40c37bb-604e-478f-bc01-428694f0d4c9@github.com>
 <KctKgE0hs5s-qmGmNe_tJwW5C-IrvK5i72mO06GZ3v4=.f48f8a2d-a4a9-4074-9350-7cd443f73373@github.com>
 <hGiSvYyNa6D0BuKfIh-3CkelapBMNrFaQ_prF3xzPQQ=.64336055-18e5-4428-bc5b-40d484ed18ba@github.com>
Message-ID: <ADR73RPzLPNb5SY61wNVAQNB0JdNFrXgwmsdteeicVU=.1c5f04db-c639-4028-b472-c56999c4746c@github.com>

On Fri, 12 Feb 2021 21:53:13 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> ## java/nio/file/Files/CopyAndMove.java    
>>     
>>     make test TEST="jtreg:java/nio/file/Files/CopyAndMove.java"
>>     
>>     STDOUT:
>>     Seed from RandomFactory = 704532001916725417L
>>     STDERR:
>>     dir1: f:\projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_nio_file_Files_CopyAndMove_java\tmp\name9678927043623070601 (NTFS)
>>     dir2: .\name1900089232270637553 (NTFS)
>>     java.lang.RuntimeException: AtomicMoveNotSupportedException expected
>>             at CopyAndMove.testMove(CopyAndMove.java:369)
>>             at CopyAndMove.main(CopyAndMove.java:74)
>>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>>             at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>>             at java.base/java.lang.Thread.run(Thread.java:831)
>> 
>>     JavaTest Message: Test threw exception: java.lang.RuntimeException: AtomicMoveNotSupportedException expected
>>     JavaTest Message: shutting down test
>> 
>>     STATUS:Failed.`main' threw exception: java.lang.RuntimeException: AtomicMoveNotSupportedException expected
>> 
>> Checked in debugger:
>> 
>>     Files.getFileStore(dir1) = {WindowsFileStore at 1211} "ssd (f:)"
>>     Files.getFileStore(dir2) = {WindowsFileStore at 1213} "ssd (F:)"
>>     sameDevice = false
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8219644 looks like there is already known bug this test.
>
> ## java/security/AccessController/DoPrivAccompliceTest.java
> 
>     make test TEST="jtreg:java/security/AccessController/DoPrivAccompliceTest.java"
> 
>     STDOUT:
>     Adding DoPrivAccomplice.class to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar
> 
>     Created jar file F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar
>     Adding DoPrivTest.class to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar
> 
>     Created jar file F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar
>     Created policy for F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar
>     Command line: [f:\projects\official_openjdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe -cp F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\classes\0\java\security\AccessController\DoPrivAccompliceTest.d;F:\Projects\official_openjdk\test\jdk\java\security\AccessController;F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\classes\0\test\lib;F:\Projects\official_openjdk\test\lib;C:\Programs\jtreg-4.2.0-tip\jtreg\lib\javatest.jar;C:\Programs\jtreg-4.2.0-tip\jtreg\lib\jtreg.jar -Xmx512m -XX:MaxRAMPercentage=6 -Djava.io.tmpdir=f:\projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\tmp -ea -esa -Djava.security.manager -Djava.security.policy=F:\Projects\official_openjdk\build\w
 indows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\java.policy -classpath F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar;F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar DoPrivTest ]
>     [2021-02-12T21:42:29.297091800Z] Gathering output for process 12712
>     [2021-02-12T21:42:29.544092Z] Waiting for completion for process 12712
>     [2021-02-12T21:42:29.544092Z] Waiting for completion finished for process 12712
>     Output and diagnostic info for process 12712 was saved into 'pid-12712-output.log'
>     [2021-02-12T21:42:29.547092500Z] Waiting for completion for process 12712
>     [2021-02-12T21:42:29.547092500Z] Waiting for completion finished for process 12712
>     Created policy for F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar
>     Command line: [f:\projects\official_openjdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe -cp F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\classes\0\java\security\AccessController\DoPrivAccompliceTest.d;F:\Projects\official_openjdk\test\jdk\java\security\AccessController;F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\classes\0\test\lib;F:\Projects\official_openjdk\test\lib;C:\Programs\jtreg-4.2.0-tip\jtreg\lib\javatest.jar;C:\Programs\jtreg-4.2.0-tip\jtreg\lib\jtreg.jar -Xmx512m -XX:MaxRAMPercentage=6 -Djava.io.tmpdir=f:\projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\tmp -ea -esa -Djava.security.manager -Djava.security.policy=F:\Projects\official_openjdk\build\w
 indows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\java.policy -classpath F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar;F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar DoPrivTest ]
>     [2021-02-12T21:42:29.553092400Z] Gathering output for process 10560
>     [2021-02-12T21:42:29.783092500Z] Waiting for completion for process 10560
>     [2021-02-12T21:42:29.783092500Z] Waiting for completion finished for process 10560
>     Output and diagnostic info for process 10560 was saved into 'pid-10560-output.log'
>     [2021-02-12T21:42:29.785092800Z] Waiting for completion for process 10560
>     [2021-02-12T21:42:29.785092800Z] Waiting for completion finished for process 10560
>     [2021-02-12T21:42:29.785092800Z] Waiting for completion for process 10560
>     [2021-02-12T21:42:29.785092800Z] Waiting for completion finished for process 10560
>     STDERR:
>      stdout: [];
>      stderr: [Exception in thread "main" java.security.AccessControlException: access denied ("java.util.PropertyPermission" "user.name" "read")
>             at java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
>             at java.base/java.security.AccessController.checkPermission(AccessController.java:1036)
>             at java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:408)
>             at java.base/java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1152)
>             at java.base/java.lang.System.getProperty(System.java:833)
>             at DoPrivAccomplice.lambda$go$0(DoPrivAccomplice.java:31)
>             at java.base/java.security.AccessController.doPrivileged(AccessController.java:312)
>             at DoPrivAccomplice.go(DoPrivAccomplice.java:30)
>             at DoPrivTest.main(DoPrivTest.java:29)
>     ]
>      exitValue = 1
> 
>     java.lang.RuntimeException: 'user' found in stderr
> 
>             at jdk.test.lib.process.OutputAnalyzer.shouldNotContain(OutputAnalyzer.java:256)
>             at DoPrivAccompliceTest.main(DoPrivAccompliceTest.java:112)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>             at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>             at java.base/java.lang.Thread.run(Thread.java:831)
> 
>     JavaTest Message: Test threw exception: java.lang.RuntimeException: 'user' found in stderr
> 
>     JavaTest Message: shutting down test
> 
>     STATUS:Failed.`main' threw exception: java.lang.RuntimeException: 'user' found in stderr
>     
> Looks like test is not ready for username `user`, which I use locally.

## tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java

    make test TEST="jtreg:tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java"

    STDOUT:
    [00:56:54.598] Parsing [--jpt-run=jdk.jpackage.tests.UnicodeArgsTest]...
    [00:56:54.650] jdk.jpackage.tests.UnicodeArgsTest.test8246042 -> [public void jdk.jpackage.tests.UnicodeArgsTest.test8246042(boolean)]
    [00:56:54.682] Create: UnicodeArgsTest.test8246042(true)
    [00:56:54.684] Create: UnicodeArgsTest.test8246042(false)
    [00:56:54.688] [ RUN      ] UnicodeArgsTest.test8246042(false)
    [00:56:54.693] TRACE: Test string code points: [0x00e9]
    [00:56:54.875] TRACE: exec: Execute tool provider [javac -d .\test8246042.9782d070\jar-workdir F:\Projects\official_openjdk\test\jdk\tools\jpackage\apps\image\Hello.java](4)...
    [00:56:55.996] TRACE: exec: Done. Exit code: 0
    [00:56:55.997] TRACE: assertEquals(0): Check command tool provider [javac -d .\test8246042.9782d070\jar-workdir F:\Projects\official_openjdk\test\jdk\tools\jpackage\apps\image\Hello.java](4) exited with 0 code
    [00:56:56.014] TRACE: exec: Execute tool provider [jar -c -f .\test8246042.9782d070\input\hello.jar -C .\test8246042.9782d070\jar-workdir .](7)...
    [00:56:56.188] TRACE: exec: Done. Exit code: 0
    [00:56:56.188] TRACE: assertEquals(0): Check command tool provider [jar -c -f .\test8246042.9782d070\input\hello.jar -C .\test8246042.9782d070\jar-workdir .](7) exited with 0 code
    [00:56:56.196] TRACE: exec: Execute tool provider [jpackage --input .\test8246042.9782d070\input --dest .\test8246042.9782d070\output --name 8246042UnicodeArgsTest --type app-image --main-jar hello.jar --main-class Hello --win-console --arguments ? --verbose](17)...
    [00:56:56.225] Creating app package: 8246042UnicodeArgsTest in F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.9782d070\output
    [00:57:07.680] Command:
        jlink --output .\test8246042.9782d070\output\8246042UnicodeArgsTest\runtime --module-path f:\\projects\\official_openjdk\\build\\windows-x86_64-server-release\\images\\jdk\\jmods --add-modules jdk.management.jfr,java.rmi,jdk.jdi,jdk.charsets,java.xml,jdk.xml.dom,java.datatransfer,jdk.jstatd,jdk.httpserver,java.desktop,java.security.sasl,jdk.zipfs,java.base,jdk.crypto.ec,jdk.javadoc,jdk.management.agent,jdk.jshell,jdk.editpad,java.sql.rowset,jdk.jsobject,jdk.sctp,java.smartcardio,jdk.jlink,jdk.unsupported,java.security.jgss,java.compiler,jdk.nio.mapmode,jdk.dynalink,jdk.unsupported.desktop,jdk.accessibility,jdk.security.jgss,java.sql,jdk.incubator.vector,java.xml.crypto,java.logging,java.transaction.xa,jdk.jfr,jdk.crypto.cryptoki,jdk.net,java.naming,jdk.internal.ed,java.prefs,java.net.http,jdk.compiler,jdk.naming.rmi,jdk.internal.opt,jdk.jconsole,jdk.attach,jdk.crypto.mscapi,jdk.internal.le,java.management,jdk.jdwp.agent,jdk.internal.jvmstat,jdk.incubator.foreign,java.instrume
 nt,jdk.management,jdk.security.auth,java.scripting,jdk.jdeps,jdk.jartool,java.management.rmi,jdk.jpackage,jdk.naming.dns,jdk.localedata --strip-native-commands --strip-debug --no-man-pages --no-header-files
    [00:57:07.680] Output:
        WARNING: Using incubator modules: jdk.incubator.vector, jdk.incubator.foreign

    [00:57:07.681] Returned: 0

    [00:57:07.685] Using default package resource java48.ico [icon] (add 8246042UnicodeArgsTest.ico to the resource-dir to customize).
    [00:57:07.707] Warning: Windows Defender may prevent jpackage from functioning. If there is an issue, it can be addressed by either disabling realtime monitoring, or adding an exclusion for the directory "f:\projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\tmp\jdk.jpackage16485063537873697224".
    [00:57:07.712] Using default package resource WinLauncher.template [Template for creating executable properties file] (add 8246042UnicodeArgsTest.properties to the resource-dir to customize).
    [00:57:07.746] Succeeded in building Windows Application Image package
    [00:57:07.748] TRACE: exec: Done. Exit code: 0
    [00:57:07.748] TRACE: assertEquals(0): Check command tool provider [jpackage --input .\test8246042.9782d070\input --dest .\test8246042.9782d070\output --name 8246042UnicodeArgsTest --type app-image --main-jar hello.jar --main-class Hello --win-console --arguments ? --verbose](17) exited with 0 code
    [00:57:07.766] TRACE: assertStringListEquals(): Check there is only one file with [.jpackage.xml] name in the package
    [00:57:07.768] TRACE: assertStringListEquals(1, .\test8246042.9782d070\output\8246042UnicodeArgsTest\app.jpackage.xml)
    [00:57:07.769] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\runtime] path exists
    [00:57:07.769] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\runtime] is a directory
    [00:57:07.770] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] path exists
    [00:57:07.770] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] is a file
    [00:57:07.770] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] file is executable
    [00:57:07.771] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\app\8246042UnicodeArgsTest.cfg] path exists
    [00:57:07.771] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\app\8246042UnicodeArgsTest.cfg] is a file
    [00:57:07.780] TRACE: Clearing PATH in environment
    [00:57:07.780] TRACE: exec: Execute [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.9782d070\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe](1); inherit I/O; in directory [.\test8246042.9782d070]...
    hello: Environment supports a display
    hello: Environment supports a desktop
    [0x0065]
    jpackage test application
    args.length: 1
    e
    hello: Output file: [appOutput.txt]
    [00:57:09.302] TRACE: exec: Done. Exit code: 0
    [00:57:09.302] TRACE: assertEquals(0): Check command [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.9782d070\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe](1) exited with 0 code
    [00:57:09.303] TRACE: assertTrue(): Check [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.9782d070\appOutput.txt] path exists
    [00:57:09.303] TRACE: assertTrue(): Check [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.9782d070\appOutput.txt] is a file
    [00:57:09.305] TRACE: assertStringListEquals(): Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.9782d070\appOutput.txt] file
    [00:57:09.305] TRACE: assertStringListEquals(1, jpackage test application)
    [00:57:09.306] TRACE: assertStringListEquals(2, args.length: 1)
    [00:57:09.307] ERROR: (3) Expected [?]. Actual [e]: Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.9782d070\appOutput.txt] file
    [00:57:09.308] [  FAILED  ] UnicodeArgsTest.test8246042(false); checks=15
    [00:57:09.310] [ RUN      ] UnicodeArgsTest.test8246042(true)
    [00:57:09.312] TRACE: Test string code points: [0x00e9]
    [00:57:09.314] TRACE: exec: Execute tool provider [javac -d .\test8246042.b31bae11\jar-workdir F:\Projects\official_openjdk\test\jdk\tools\jpackage\apps\image\Hello.java](4)...
    [00:57:09.658] TRACE: exec: Done. Exit code: 0
    [00:57:09.659] TRACE: assertEquals(0): Check command tool provider [javac -d .\test8246042.b31bae11\jar-workdir F:\Projects\official_openjdk\test\jdk\tools\jpackage\apps\image\Hello.java](4) exited with 0 code
    [00:57:09.661] TRACE: exec: Execute tool provider [jar -c -f .\test8246042.b31bae11\input\hello.jar -C .\test8246042.b31bae11\jar-workdir .](7)...
    [00:57:09.667] TRACE: exec: Done. Exit code: 0
    [00:57:09.667] TRACE: assertEquals(0): Check command tool provider [jar -c -f .\test8246042.b31bae11\input\hello.jar -C .\test8246042.b31bae11\jar-workdir .](7) exited with 0 code
    [00:57:09.670] TRACE: exec: Execute tool provider [jpackage --input .\test8246042.b31bae11\input --dest .\test8246042.b31bae11\output --name 8246042UnicodeArgsTest --type app-image --main-jar hello.jar --main-class Hello --win-console --verbose](15)...
    [00:57:09.670]
    jpackage argument list:
    [--input, .\test8246042.b31bae11\input, --dest, .\test8246042.b31bae11\output, --name, 8246042UnicodeArgsTest, --type, app-image, --main-jar, hello.jar, --main-class, Hello, --win-console, --verbose]

    [00:57:09.679] Creating app package: 8246042UnicodeArgsTest in F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.b31bae11\output
    [00:57:18.770] Command:
        jlink --output .\test8246042.b31bae11\output\8246042UnicodeArgsTest\runtime --module-path f:\\projects\\official_openjdk\\build\\windows-x86_64-server-release\\images\\jdk\\jmods --add-modules jdk.management.jfr,java.rmi,jdk.jdi,jdk.charsets,jdk.xml.dom,java.xml,java.datatransfer,jdk.jstatd,jdk.httpserver,java.desktop,java.security.sasl,jdk.zipfs,java.base,jdk.crypto.ec,jdk.javadoc,jdk.management.agent,jdk.jshell,jdk.editpad,jdk.sctp,jdk.jsobject,java.sql.rowset,jdk.jlink,java.smartcardio,jdk.unsupported,java.security.jgss,java.compiler,jdk.nio.mapmode,jdk.dynalink,jdk.unsupported.desktop,jdk.accessibility,jdk.security.jgss,java.sql,jdk.incubator.vector,java.xml.crypto,java.logging,java.transaction.xa,jdk.jfr,jdk.crypto.cryptoki,jdk.net,java.naming,jdk.internal.ed,java.prefs,java.net.http,jdk.compiler,jdk.internal.opt,jdk.naming.rmi,jdk.jconsole,jdk.attach,jdk.crypto.mscapi,jdk.internal.le,java.management,jdk.jdwp.agent,jdk.incubator.foreign,jdk.internal.jvmstat,java.instrume
 nt,jdk.management,jdk.security.auth,java.scripting,jdk.jdeps,jdk.jartool,jdk.jpackage,java.management.rmi,jdk.naming.dns,jdk.localedata --strip-native-commands --strip-debug --no-man-pages --no-header-files
    [00:57:18.770] Output:
        WARNING: Using incubator modules: jdk.incubator.vector, jdk.incubator.foreign

    [00:57:18.770] Returned: 0

    [00:57:18.771] Using default package resource java48.ico [icon] (add 8246042UnicodeArgsTest.ico to the resource-dir to customize).
    [00:57:18.778] Warning: Windows Defender may prevent jpackage from functioning. If there is an issue, it can be addressed by either disabling realtime monitoring, or adding an exclusion for the directory "f:\projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\tmp\jdk.jpackage8738450931736312275".
    [00:57:18.779] Using default package resource WinLauncher.template [Template for creating executable properties file] (add 8246042UnicodeArgsTest.properties to the resource-dir to customize).
    [00:57:18.787] Succeeded in building Windows Application Image package
    [00:57:18.788] TRACE: exec: Done. Exit code: 0
    [00:57:18.789] TRACE: assertEquals(0): Check command tool provider [jpackage --input .\test8246042.b31bae11\input --dest .\test8246042.b31bae11\output --name 8246042UnicodeArgsTest --type app-image --main-jar hello.jar --main-class Hello --win-console --verbose](15) exited with 0 code
    [00:57:18.804] TRACE: assertStringListEquals(): Check there is only one file with [.jpackage.xml] name in the package
    [00:57:18.804] TRACE: assertStringListEquals(1, .\test8246042.b31bae11\output\8246042UnicodeArgsTest\app.jpackage.xml)
    [00:57:18.805] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\runtime] path exists
    [00:57:18.805] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\runtime] is a directory
    [00:57:18.806] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] path exists
    [00:57:18.806] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] is a file
    [00:57:18.806] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] file is executable
    [00:57:18.807] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\app\8246042UnicodeArgsTest.cfg] path exists
    [00:57:18.807] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\app\8246042UnicodeArgsTest.cfg] is a file
    [00:57:18.808] TRACE: Clearing PATH in environment
    [00:57:18.808] TRACE: exec: Execute [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.b31bae11\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe ?](2); inherit I/O; in directory [.\test8246042.b31bae11]...
    hello: Environment supports a display
    hello: Environment supports a desktop
    [0x0065]
    jpackage test application
    args.length: 1
    e
    hello: Output file: [appOutput.txt]
    [00:57:20.327] TRACE: exec: Done. Exit code: 0
    [00:57:20.328] TRACE: assertEquals(0): Check command [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.b31bae11\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe ?](2) exited with 0 code
    [00:57:20.328] TRACE: assertTrue(): Check [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.b31bae11\appOutput.txt] path exists
    [00:57:20.329] TRACE: assertTrue(): Check [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.b31bae11\appOutput.txt] is a file
    [00:57:20.330] TRACE: assertStringListEquals(): Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.b31bae11\appOutput.txt] file
    [00:57:20.330] TRACE: assertStringListEquals(1, jpackage test application)
    [00:57:20.330] TRACE: assertStringListEquals(2, args.length: 1)
    [00:57:20.330] ERROR: (3) Expected [?]. Actual [e]: Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.b31bae11\appOutput.txt] file
    [00:57:20.331] [  FAILED  ] UnicodeArgsTest.test8246042(true); checks=15
    [00:57:20.332] [==========] 2 tests ran
    [00:57:20.333] [  PASSED  ] 0 tests
    [00:57:20.334] [  FAILED  ] 2 tests, listed below
    [00:57:20.335] [  FAILED  ] UnicodeArgsTest.test8246042(false); workDir=[.\test8246042.9782d070]
    [00:57:20.335] [  FAILED  ] UnicodeArgsTest.test8246042(true); workDir=[.\test8246042.b31bae11]
    [00:57:20.336] 2 FAILED TESTS
    STDERR:
    java.lang.AssertionError: (3) Expected [?]. Actual [e]: Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.9782d070\appOutput.txt] file
            at jdk.jpackage.test.TKit.error(TKit.java:293)
            at jdk.jpackage.test.TKit.lambda$assertStringListEquals$20(TKit.java:765)
            at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
            at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179)
            at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625)
            at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
            at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
            at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
            at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
            at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
            at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:596)
            at jdk.jpackage.test.TKit.assertStringListEquals(TKit.java:759)
            at jdk.jpackage.test.HelloApp.verifyOutputFile(HelloApp.java:225)
            at jdk.jpackage.test.HelloApp.verifyOutputFile(HelloApp.java:204)
            at jdk.jpackage.test.HelloApp$AppOutputVerifier.executeAndVerifyOutput(HelloApp.java:405)
            at jdk.jpackage.test.HelloApp$AppOutputVerifier.executeAndVerifyOutput(HelloApp.java:417)
            at jdk.jpackage.test.HelloApp.executeLauncherAndVerifyOutput(HelloApp.java:319)
            at jdk.jpackage.tests.UnicodeArgsTest.test8246042(UnicodeArgsTest.java:67)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
            at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
            at java.base/java.lang.reflect.Method.invoke(Method.java:566)
            at jdk.jpackage.test.MethodCall.accept(MethodCall.java:145)
            at jdk.jpackage.test.TestInstance.run(TestInstance.java:230)
            at jdk.jpackage.test.TKit.lambda$ignoreExceptions$6(TKit.java:155)
            at jdk.jpackage.test.TKit.lambda$runTests$4(TKit.java:140)
            at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625)
            at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:762)
            at jdk.jpackage.test.TKit.lambda$runTests$5(TKit.java:137)
            at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105)
            at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:123)
            at jdk.jpackage.test.TKit.runTests(TKit.java:136)
            at jdk.jpackage.test.Main.runTests(Main.java:79)
            at jdk.jpackage.test.Main.lambda$main$2(Main.java:75)
            at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105)
            at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:123)
            at jdk.jpackage.test.Main.main(Main.java:75)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
            at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
            at java.base/java.lang.reflect.Method.invoke(Method.java:566)
            at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
            at java.base/java.lang.Thread.run(Thread.java:831)
    java.lang.AssertionError: (3) Expected [?]. Actual [e]: Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.b31bae11\appOutput.txt] file
            at jdk.jpackage.test.TKit.error(TKit.java:293)
            at jdk.jpackage.test.TKit.lambda$assertStringListEquals$20(TKit.java:765)
            at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
            at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179)
            at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625)
            at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
            at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
            at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
            at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
            at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
            at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:596)
            at jdk.jpackage.test.TKit.assertStringListEquals(TKit.java:759)
            at jdk.jpackage.test.HelloApp.verifyOutputFile(HelloApp.java:225)
            at jdk.jpackage.test.HelloApp.verifyOutputFile(HelloApp.java:204)
            at jdk.jpackage.test.HelloApp$AppOutputVerifier.executeAndVerifyOutput(HelloApp.java:405)
            at jdk.jpackage.test.HelloApp$AppOutputVerifier.executeAndVerifyOutput(HelloApp.java:417)
            at jdk.jpackage.test.HelloApp.executeLauncherAndVerifyOutput(HelloApp.java:319)
            at jdk.jpackage.tests.UnicodeArgsTest.test8246042(UnicodeArgsTest.java:65)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
            at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
            at java.base/java.lang.reflect.Method.invoke(Method.java:566)
            at jdk.jpackage.test.MethodCall.accept(MethodCall.java:145)
            at jdk.jpackage.test.TestInstance.run(TestInstance.java:230)
            at jdk.jpackage.test.TKit.lambda$ignoreExceptions$6(TKit.java:155)
            at jdk.jpackage.test.TKit.lambda$runTests$4(TKit.java:140)
            at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625)
            at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:762)
            at jdk.jpackage.test.TKit.lambda$runTests$5(TKit.java:137)
            at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105)
            at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:123)
            at jdk.jpackage.test.TKit.runTests(TKit.java:136)
            at jdk.jpackage.test.Main.runTests(Main.java:79)
            at jdk.jpackage.test.Main.lambda$main$2(Main.java:75)
            at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105)
            at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:123)
            at jdk.jpackage.test.Main.main(Main.java:75)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
            at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
            at java.base/java.lang.reflect.Method.invoke(Method.java:566)
            at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
            at java.base/java.lang.Thread.run(Thread.java:831)
    jdk.jpackage.test.Functional$ExceptionBox: java.lang.RuntimeException: 2 FAILED TESTS
            at jdk.jpackage.test.Functional.rethrowUnchecked(Functional.java:161)
            at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:107)
            at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:123)
            at jdk.jpackage.test.Main.main(Main.java:75)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
            at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
            at java.base/java.lang.reflect.Method.invoke(Method.java:566)
            at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
            at java.base/java.lang.Thread.run(Thread.java:831)
    Caused by: java.lang.RuntimeException: 2 FAILED TESTS
            at jdk.jpackage.test.Main.reportSummary(Main.java:130)
            at jdk.jpackage.test.Main.runTests(Main.java:90)
            at jdk.jpackage.test.Main.lambda$main$2(Main.java:75)
            at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105)
            ... 8 more

    JavaTest Message: Test threw exception: jdk.jpackage.test.Functional$ExceptionBox: java.lang.RuntimeException: 2 FAILED TESTS
    JavaTest Message: shutting down test

    STATUS:Failed.`main' threw exception: jdk.jpackage.test.Functional$ExceptionBox: java.lang.RuntimeException: 2 FAILED TESTS

Oh. This one is tricky. Will investigate later.

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

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

From dcubed at openjdk.java.net  Fri Feb 12 22:17:41 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 12 Feb 2021 22:17:41 GMT
Subject: RFR: 8241403: JavaThread::get_thread_name() should be
 ThreadSMR-aware
In-Reply-To: <Uke4223ee6tPQRFdiMkUsIF7oRrz6bm4LMk1FpnmR-k=.190befb3-4d2b-44cf-81c7-2f2d147bd784@github.com>
References: <wRdcRQurtpybntK9Qpji-6zVY-EcHKw3q87xpD0eoS4=.a6dc32f4-2919-42e9-80c3-5a264067f0e2@github.com>
 <Uke4223ee6tPQRFdiMkUsIF7oRrz6bm4LMk1FpnmR-k=.190befb3-4d2b-44cf-81c7-2f2d147bd784@github.com>
Message-ID: <AlPMnCZ8HBODRqVtHHXpUZKwO-yoAI724D0qNz3H4Qk=.ea8de8e2-dcfb-42c6-83a6-bc0626ed2fec@github.com>

On Fri, 12 Feb 2021 22:02:18 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> A minor fix to add a new function:
>> 
>>     bool Thread::is_JavaThread_protected(const JavaThread* p)
>> 
>> that returns true when the target JavaThread* is protected and false
>> otherwise. Update JavaThread::get_thread_name() to create a
>> ThreadsListHandle and use the new is_JavaThread_protected(). Also
>> update JvmtiTrace::safe_get_thread_name() to use the new
>> is_JavaThread_protected().
>> 
>> This fix is tested via a Mach5 Tier[1-8] run.
>
> src/hotspot/share/runtime/thread.hpp line 1692:
> 
>> 1690:   const char* get_thread_name() const;
>> 1691:  protected:
>> 1692:   friend class JvmtiTrace;  // so get_thread_name_string() can be called
> 
> I was trying to think of a way to not have JvmtiTrace not be a friend of JavaThread for this, maybe by adding a default value parameter to return "<NOT FILLED IN\>" rather than Thread::name.
> is_JavaThread_protected only seems to be called by JvmtiTrace also, so should be private (with the friend, which also makes the friend unfortunate).

JavaThread::get_thread_name() also calls is_JavaThread_protected().

The "friend" is so that JvmtiTrace can call get_thread_name_string()
and we can get rid of the JvmtiTrace version of the logic. I kept the
"<NOT FILLED IN>" rather than figure out a way to call Thread::name()
so we don't introduce the possibility of a compatibility issue for any
code that might depend on that hand rolled string value...

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

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

From coleenp at openjdk.java.net  Fri Feb 12 23:44:44 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Fri, 12 Feb 2021 23:44:44 GMT
Subject: RFR: 8241403: JavaThread::get_thread_name() should be
 ThreadSMR-aware
In-Reply-To: <AlPMnCZ8HBODRqVtHHXpUZKwO-yoAI724D0qNz3H4Qk=.ea8de8e2-dcfb-42c6-83a6-bc0626ed2fec@github.com>
References: <wRdcRQurtpybntK9Qpji-6zVY-EcHKw3q87xpD0eoS4=.a6dc32f4-2919-42e9-80c3-5a264067f0e2@github.com>
 <Uke4223ee6tPQRFdiMkUsIF7oRrz6bm4LMk1FpnmR-k=.190befb3-4d2b-44cf-81c7-2f2d147bd784@github.com>
 <AlPMnCZ8HBODRqVtHHXpUZKwO-yoAI724D0qNz3H4Qk=.ea8de8e2-dcfb-42c6-83a6-bc0626ed2fec@github.com>
Message-ID: <JB_2ExyxLfCaR-W0ejdB6EMpSXORpKtIBE8PhkN_rGM=.7bd6fda1-6149-4f93-85a1-64e1981dd5c7@github.com>

On Fri, 12 Feb 2021 22:14:35 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> src/hotspot/share/runtime/thread.hpp line 1692:
>> 
>>> 1690:   const char* get_thread_name() const;
>>> 1691:  protected:
>>> 1692:   friend class JvmtiTrace;  // so get_thread_name_string() can be called
>> 
>> I was trying to think of a way to not have JvmtiTrace not be a friend of JavaThread for this, maybe by adding a default value parameter to return "<NOT FILLED IN\>" rather than Thread::name.
>> is_JavaThread_protected only seems to be called by JvmtiTrace also, so should be private (with the friend, which also makes the friend unfortunate).
>
> JavaThread::get_thread_name() also calls is_JavaThread_protected().
> 
> The "friend" is so that JvmtiTrace can call get_thread_name_string()
> and we can get rid of the JvmtiTrace version of the logic. I kept the
> "<NOT FILLED IN>" rather than figure out a way to call Thread::name()
> so we don't introduce the possibility of a compatibility issue for any
> code that might depend on that hand rolled string value...

So Thread::is_JavaThread_protected() should be "protected" then, not public.
yes, I was suggesting adding a default last parameter like
    JavaThread::get_thread_name(char* default = Thread::name());
and pass "<NOT_FILLED_IN\>" from JVMTI. Then JVMTI doesn't have to be a friend and have more visibility to the JavaThread class than it should have.

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

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

From sspitsyn at openjdk.java.net  Sat Feb 13 03:39:43 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Sat, 13 Feb 2021 03:39:43 GMT
Subject: RFR: 8241403: JavaThread::get_thread_name() should be
 ThreadSMR-aware
In-Reply-To: <wRdcRQurtpybntK9Qpji-6zVY-EcHKw3q87xpD0eoS4=.a6dc32f4-2919-42e9-80c3-5a264067f0e2@github.com>
References: <wRdcRQurtpybntK9Qpji-6zVY-EcHKw3q87xpD0eoS4=.a6dc32f4-2919-42e9-80c3-5a264067f0e2@github.com>
Message-ID: <OJ-4pBj0Tz0qLPbJusUG2yKrBC1o1qWyO5spEo01P34=.9c4773da-4dc9-483b-970e-8e63b32c55e1@github.com>

On Thu, 11 Feb 2021 22:04:53 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A minor fix to add a new function:
> 
>     bool Thread::is_JavaThread_protected(const JavaThread* p)
> 
> that returns true when the target JavaThread* is protected and false
> otherwise. Update JavaThread::get_thread_name() to create a
> ThreadsListHandle and use the new is_JavaThread_protected(). Also
> update JvmtiTrace::safe_get_thread_name() to use the new
> is_JavaThread_protected().
> 
> This fix is tested via a Mach5 Tier[1-8] run.

Hi Dan,
It looks good to me modulo your your discussion with Coleen on JvmtiTrace being a friend.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

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

From sspitsyn at openjdk.java.net  Sat Feb 13 03:53:40 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Sat, 13 Feb 2021 03:53:40 GMT
Subject: RFR: JDK-8261034: improve jcmd GC.class_histogram to support
 parallel
In-Reply-To: <Ze8CKZ6Auw1oW4J-XKuMpO7n7NTedBBmj0O2UKrOH6o=.a16e8ebb-1a0b-499b-a913-92375c486d76@github.com>
References: <VKzVY-01CEXUbQdlKMhDWjtjxUgpxs_6487x232VsAI=.3b9c5d8a-972b-4997-9f75-1951f98e1751@github.com>
 <X_7cTwpI8cxsVTCMi6oe6f1Fy6yPcw7b0-Pa-Ayou2Y=.69cba9c8-f6e4-40b4-a180-3eb79428692b@github.com>
 <EQm4vRIvMgIFwt3dwYO3YTdbCLyQEKjISTt-QudCNbE=.f2366e5b-b9fa-456d-bafa-6531293b2cc2@github.com>
 <gBKEb-EMtCvqvSZiS1ImsYpQg63tg6R8KaizkL-BrlE=.f51a4335-251c-4041-bd71-75ec13f0591d@github.com>
 <v4SsYZMv2DVW2v8KDDDrCMa-JlyDX6Nsa20ue9JZKqs=.2617d216-b696-48c9-b34e-b0a97bb3bf12@github.com>
 <C47zxVTOUeIMyATz4LgWhTZsmZ6Nk5ncQRbgNKSvTxg=.7570353c-862e-428d-b6bf-aed24b461ea9@github.com>
 <oNo87kApGGMUT6MJYpvDAlyjBzza1-GmLNZSwAGrmEc=.d8669c88-6882-4744-8a05-5cadaa48404f@github.com>
 <A-u0xkGoB54J-q4yyOu-fXBqvXkTRLnmje8qh1KUTTE=.75f97621-8e70-4ab4-b54f-f45b37bd84f5@github.com>
 <hZpMlhWW1rB89tC-Wj_DH9R05YcOFOaqkFprf9MwBD4=.755ccfc2-b743-4037-8f0c-69c078937c5e@github.com>
 <-mAEJ8TjIlhEHKFP0ybmVgqjhCIr8YoAz4Q-GilpZgs=.d1b01b4c-3c14-43ad-8203-b1cd4d2f7ad4@github.com>
 <6APNXM7Ih9TxHMNEPD-uOla7-w08UxJeP4e
 f3-f3joA=.77a8b309-1973-471d-87d7-f682b3ebdb32@github.com>
 <L8t5llrzyxpof_frsgyaf8jznTCckZF-h0t7rM8eAX8=.bb67bcc3-d8db-45a5-a365-7cc05faf27da@github.com>
 <BX2O5NH7WOa57DlDNDgWefirxYUBT7nsCnPhqjchfs0=.6df0ae15-a16b-4cbe-ba5c-02c10d4c332f@github.com>
 <uIKLse-ugmKBUDcOM37UbZkziorlrzcMFJAZa25eqTE=.9ad0afaa-37e6-4ee1-885a-936c60bfad7f@github.com>
 <Ze8CKZ6Auw1oW4J-XKuMpO7n7NTedBBmj0O2UKrOH6o=.a16e8ebb-1a0b-499b-a913-92375c486d76@github.com>
Message-ID: <ZXHKiFA6-hVma_2MXvCzHMLUFspOl3coMjZ5-u2LBA4=.adbb69ca-f7e0-4189-8951-8619403cf835@github.com>

On Fri, 12 Feb 2021 20:44:55 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Hi Chris, 
>> 
>>> at most we just say the user will need to experiment to see what works best (if we even say that). This way we avoid any headaches with the the JDK 16 support for `parallel=<n>` with `jmap -histo`
>> 
>> I agree. what came in my mind when introducing `parallel=<n>` is that tuning maybe required when user works on multi-processes scenario, for which more parallel threads may affect other processes and disabling parallel may not be affordable when heap is large.
>> 
>> So having seen that there is a solution of 'passing more than 4 agruments' issue, IMO it is fine to keep consistency between jmap and jcmd. Therefore I think we have following choices for `parallel` of jmap and jcmd.
>> 
>> 1 - Introduce `noparallel` option, use parallel by default and remove `parallel=<n>`.  It hides the detail info about parallel thread number and hence disable the tuning ability. But it makes user easier to use, just use `noparallel` to control parallalism. And also there is incompatibility issue between JDK16 and the latest JDK.
>>  
>> 2 - Same as 1, but keep `parallel=<n>` option, and print the threads number for parallel heap inspection at the end. It gives user the ability to tune the parallel thread number, and also reduce the incompatibility between JDK16  and later version since there is no options removed.  But it introduces complexity for user to use `parallel=<n>` and `noparallel` options. (Please note that most users may not care about the parallel thread number in most scenario, just use the default one).
>> 
>> I prefer 2 as for me option 1 is like a subset of option 2, and 2 doesn't introduce backward-compatibility issues 
>> 
>> Thanks 
>> Lin
>
> Yeah, I'm now thinking just stick with `parallel=<n>`. Sorry about all the noise, but I feel better about this approach now that we've explored all the options. We still need to get `heapdumpext` approved. It might be worth sending out an email to serviceablity-dev just to discuss that one topic, rather than having it in a PR discussion. Among other things, there might be suggestions for a better name to use.

I also think, it is better to stick with `parallel=<n>`.
Then it has to be explained what is the default number of parallel threads for the option `-parallel=0`.
Also, I'd prefer define some limit for the parameter `<n>`.
Would it be okay to specify it as 9? My assumption is that a real max would be the default number of parallel threads.
If it is too high then it is possible to pick any number between 1 and 9.

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

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

From cjplummer at openjdk.java.net  Sat Feb 13 04:14:40 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Sat, 13 Feb 2021 04:14:40 GMT
Subject: RFR: JDK-8261034: improve jcmd GC.class_histogram to support
 parallel
In-Reply-To: <ZXHKiFA6-hVma_2MXvCzHMLUFspOl3coMjZ5-u2LBA4=.adbb69ca-f7e0-4189-8951-8619403cf835@github.com>
References: <VKzVY-01CEXUbQdlKMhDWjtjxUgpxs_6487x232VsAI=.3b9c5d8a-972b-4997-9f75-1951f98e1751@github.com>
 <X_7cTwpI8cxsVTCMi6oe6f1Fy6yPcw7b0-Pa-Ayou2Y=.69cba9c8-f6e4-40b4-a180-3eb79428692b@github.com>
 <EQm4vRIvMgIFwt3dwYO3YTdbCLyQEKjISTt-QudCNbE=.f2366e5b-b9fa-456d-bafa-6531293b2cc2@github.com>
 <gBKEb-EMtCvqvSZiS1ImsYpQg63tg6R8KaizkL-BrlE=.f51a4335-251c-4041-bd71-75ec13f0591d@github.com>
 <v4SsYZMv2DVW2v8KDDDrCMa-JlyDX6Nsa20ue9JZKqs=.2617d216-b696-48c9-b34e-b0a97bb3bf12@github.com>
 <C47zxVTOUeIMyATz4LgWhTZsmZ6Nk5ncQRbgNKSvTxg=.7570353c-862e-428d-b6bf-aed24b461ea9@github.com>
 <oNo87kApGGMUT6MJYpvDAlyjBzza1-GmLNZSwAGrmEc=.d8669c88-6882-4744-8a05-5cadaa48404f@github.com>
 <A-u0xkGoB54J-q4yyOu-fXBqvXkTRLnmje8qh1KUTTE=.75f97621-8e70-4ab4-b54f-f45b37bd84f5@github.com>
 <hZpMlhWW1rB89tC-Wj_DH9R05YcOFOaqkFprf9MwBD4=.755ccfc2-b743-4037-8f0c-69c078937c5e@github.com>
 <-mAEJ8TjIlhEHKFP0ybmVgqjhCIr8YoAz4Q-GilpZgs=.d1b01b4c-3c14-43ad-8203-b1cd4d2f7ad4@github.com>
 <6APNXM7Ih9TxHMNEPD-uOla7-w08UxJeP4e
 f3-f3joA=.77a8b309-1973-471d-87d7-f682b3ebdb32@github.com>
 <L8t5llrzyxpof_frsgyaf8jznTCckZF-h0t7rM8eAX8=.bb67bcc3-d8db-45a5-a365-7cc05faf27da@github.com>
 <BX2O5NH7WOa57DlDNDgWefirxYUBT7nsCnPhqjchfs0=.6df0ae15-a16b-4cbe-ba5c-02c10d4c332f@github.com>
 <uIKLse-ugmKBUDcOM37UbZkziorlrzcMFJAZa25eqTE=.9ad0afaa-37e6-4ee1-885a-936c60bfad7f@github.com>
 <Ze8CKZ6Auw1oW4J-XKuMpO7n7NTedBBmj0O2UKrOH6o=.a16e8ebb-1a0b-499b-a913-92375c486d76@github.com>
 <ZXHKiFA6-hVma_2MXvCzHMLUFspOl3coMjZ5-u2LBA4=.adbb69ca-f7e0-4189-8951-8619403cf835@github.com>
Message-ID: <uYzejCgfjq5-bRCKx7RaZWH1zUPsDjBMFeBVIaM4B7o=.5a71658f-9431-4bcb-bde9-37970fbf6823@github.com>

On Sat, 13 Feb 2021 03:51:10 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> I also think, it is better to stick with `parallel=<n>`.
> Then it has to be explained what is the default number of parallel threads for the option `-parallel=0`.
> It can be specified as some implementation-dependent number of thread executors or alike.
> Also, I'd prefer to define some upper limit for the parameter `<n>`.
> Would it be okay to specify it as 9? My assumption is that a real maximum would be the default number of parallel threads.
> If it is too high then it is possible to pick any number between 1 and 9.

I worry about having to define what the default number or parallel threads is, because it's a (somewhat) complex formula based on the number of processors, plus also has to take into account `-XX:ParallelGCThreads`. Cramming this all into the short help is probably counterproductive. I think basically if you choose something other than 0 or 1, you shouldn't expect to be able to pick a good value for <n> without doing some experimenting.

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

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

From linzang at tencent.com  Sat Feb 13 04:18:57 2021
From: linzang at tencent.com (=?utf-8?B?bGluemFuZyjoh6fnkLMp?=)
Date: Sat, 13 Feb 2021 04:18:57 +0000
Subject: RFD: Add new jcmd internal command - dumpheapext to solve the attach
 API's argument number limitation
Message-ID: <E0E574AA-D63A-4B23-B378-E467C95D0E1F@tencent.com>

Dear All,
            I want to get your suggestion about adding a new internal command to solve the argument passing problem of jmap alike tools.

             We recently encounter a problem when adding the 4th option (?parallel?) to jmap -dump, it failed because there is limitation of max number of arguments passed to JVM in attach API. As limited by arguments length at https://github.com/openjdk/jdk/blob/95d73129ce5074d3510710e7e238761a9af9ef3a/src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java#L144  and arg_count_max at https://github.com/openjdk/jdk/blob/95d73129ce5074d3510710e7e238761a9af9ef3a/src/hotspot/share/services/attachListener.hpp#L138.

             And simply enlarge this  limitation is not acceptable because it cause old version of jmap command hang when working with new JVM, which has been encountered and disscussed before at https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-February/027240.html, However the problem was not fix at that time because the limitation is modified unnecessarily and simply revert the change is ok.

            As mentioned, now we are facing the problem when developing the parallel heap dump, which introduced the 4th argument ?parallel=<N>? into jmap -dump command. We (Chris, Serguei, Hamlin and I) recently discussed it and Chris has suggested a solution to fix this kind of issue by introducing a new internal command ?dumpheapext?. When ?jmap -dump? command work with ?parallel? option, it issues ?dumpheapext? command instead of ?dumpheap? command, and this dumpheapext has same argument passing protocal with JVM ? e.g. ?all arguments passed is combined into one string, passing the whole string to jvm, and the jvm parse it to get correct ones?.

            With this change, old jvm will print error like ?Operation dumpheapext not recognized!? when work with new ?jmap -dump:parallel=<n>? command.  IMO this is not perfact as error message like ?unsupported argument parallel=<n>?, but the command behaves correctly and in this way there is no severe compatibility issue introduced.

            Here are some of the discussions before, FYI:

  1.  https://github.com/openjdk/jdk/pull/2261 - Parallel heap dump PR, with latest commit of dumpheapext command prototype. Also some history of the story included in this PR.
  2.  https://github.com/openjdk/jdk/pull/2379 -  improve jcmd GC.class_histogram to support parallel, we also discussed serveral solution here.
  3.  https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-February/027240.html The problem encountered proviously, and also discussions related.



BRs,
Lin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20210213/73fae276/attachment.htm>

From lzang at openjdk.java.net  Sat Feb 13 04:25:38 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Sat, 13 Feb 2021 04:25:38 GMT
Subject: RFR: JDK-8261034: improve jcmd GC.class_histogram to support
 parallel
In-Reply-To: <uYzejCgfjq5-bRCKx7RaZWH1zUPsDjBMFeBVIaM4B7o=.5a71658f-9431-4bcb-bde9-37970fbf6823@github.com>
References: <VKzVY-01CEXUbQdlKMhDWjtjxUgpxs_6487x232VsAI=.3b9c5d8a-972b-4997-9f75-1951f98e1751@github.com>
 <X_7cTwpI8cxsVTCMi6oe6f1Fy6yPcw7b0-Pa-Ayou2Y=.69cba9c8-f6e4-40b4-a180-3eb79428692b@github.com>
 <EQm4vRIvMgIFwt3dwYO3YTdbCLyQEKjISTt-QudCNbE=.f2366e5b-b9fa-456d-bafa-6531293b2cc2@github.com>
 <gBKEb-EMtCvqvSZiS1ImsYpQg63tg6R8KaizkL-BrlE=.f51a4335-251c-4041-bd71-75ec13f0591d@github.com>
 <v4SsYZMv2DVW2v8KDDDrCMa-JlyDX6Nsa20ue9JZKqs=.2617d216-b696-48c9-b34e-b0a97bb3bf12@github.com>
 <C47zxVTOUeIMyATz4LgWhTZsmZ6Nk5ncQRbgNKSvTxg=.7570353c-862e-428d-b6bf-aed24b461ea9@github.com>
 <oNo87kApGGMUT6MJYpvDAlyjBzza1-GmLNZSwAGrmEc=.d8669c88-6882-4744-8a05-5cadaa48404f@github.com>
 <A-u0xkGoB54J-q4yyOu-fXBqvXkTRLnmje8qh1KUTTE=.75f97621-8e70-4ab4-b54f-f45b37bd84f5@github.com>
 <hZpMlhWW1rB89tC-Wj_DH9R05YcOFOaqkFprf9MwBD4=.755ccfc2-b743-4037-8f0c-69c078937c5e@github.com>
 <-mAEJ8TjIlhEHKFP0ybmVgqjhCIr8YoAz4Q-GilpZgs=.d1b01b4c-3c14-43ad-8203-b1cd4d2f7ad4@github.com>
 <6APNXM7Ih9TxHMNEPD-uOla7-w08UxJeP4e
 f3-f3joA=.77a8b309-1973-471d-87d7-f682b3ebdb32@github.com>
 <L8t5llrzyxpof_frsgyaf8jznTCckZF-h0t7rM8eAX8=.bb67bcc3-d8db-45a5-a365-7cc05faf27da@github.com>
 <BX2O5NH7WOa57DlDNDgWefirxYUBT7nsCnPhqjchfs0=.6df0ae15-a16b-4cbe-ba5c-02c10d4c332f@github.com>
 <uIKLse-ugmKBUDcOM37UbZkziorlrzcMFJAZa25eqTE=.9ad0afaa-37e6-4ee1-885a-936c60bfad7f@github.com>
 <Ze8CKZ6Auw1oW4J-XKuMpO7n7NTedBBmj0O2UKrOH6o=.a16e8ebb-1a0b-499b-a913-92375c486d76@github.com>
 <ZXHKiFA6-hVma_2MXvCzHMLUFspOl3coMjZ5-u2LBA4=.adbb69ca-f7e0-4189-8951-8619403cf835@github.com>
 <uYzejCgfjq5-bRCKx7RaZWH1zUPsDjBMFeBVIaM4B7o=.5a71658f-9431-4bcb-bde9-37970fbf6823@github.com>
Message-ID: <LXv3U99qPkiJQxlV7UHbRMC9cDYwacPbF6pCVsA2jwg=.dd0dce40-490d-438e-905c-f6fc35c040b7@github.com>

On Sat, 13 Feb 2021 04:11:55 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> I also think, it is better to stick with `parallel=<n>`.
>> Then it has to be explained what is the default number of parallel threads for the option `-parallel=0`.
>> It can be specified as some implementation-dependent number of thread executors or alike.
>> Also, I'd prefer to define some upper limit for the parameter `<n>`.
>> Would it be okay to specify it as 9? My assumption is that a real maximum would be the default number of parallel threads.
>> If it is too high then it is possible to pick any number between 1 and 9.
>
>> I also think, it is better to stick with `parallel=<n>`.
>> Then it has to be explained what is the default number of parallel threads for the option `-parallel=0`.
>> It can be specified as some implementation-dependent number of thread executors or alike.
>> Also, I'd prefer to define some upper limit for the parameter `<n>`.
>> Would it be okay to specify it as 9? My assumption is that a real maximum would be the default number of parallel threads.
>> If it is too high then it is possible to pick any number between 1 and 9.
> 
> I worry about having to define what the default number or parallel threads is, because it's a (somewhat) complex formula based on the number of processors, plus also has to take into account `-XX:ParallelGCThreads`. Cramming this all into the short help is probably counterproductive. I think basically if you choose something other than 0 or 1, you shouldn't expect to be able to pick a good value for <n> without doing some experimenting.

Just send out a email in serviceability-dev. we can discuss the dumpheapext topic there. 

There is a limitation of parallel thread number so that it never exceed the total_workers defined in hotspot.
so how about we just print how many threads worked on parallel heap insecption and then user get the clue to tune it?

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

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

From chris.plummer at oracle.com  Sat Feb 13 04:29:50 2021
From: chris.plummer at oracle.com (Chris Plummer)
Date: Fri, 12 Feb 2021 20:29:50 -0800
Subject: [External] : RFD: Add new jcmd internal command - dumpheapext to
 solve the attach API's argument number limitation
In-Reply-To: <E0E574AA-D63A-4B23-B378-E467C95D0E1F@tencent.com>
References: <E0E574AA-D63A-4B23-B378-E467C95D0E1F@tencent.com>
Message-ID: <f204d0ed-8f1b-64ef-c275-e80722d445e6@oracle.com>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20210212/36d15fab/attachment.htm>

From dcubed at openjdk.java.net  Sat Feb 13 04:33:39 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sat, 13 Feb 2021 04:33:39 GMT
Subject: RFR: 8241403: JavaThread::get_thread_name() should be
 ThreadSMR-aware
In-Reply-To: <JB_2ExyxLfCaR-W0ejdB6EMpSXORpKtIBE8PhkN_rGM=.7bd6fda1-6149-4f93-85a1-64e1981dd5c7@github.com>
References: <wRdcRQurtpybntK9Qpji-6zVY-EcHKw3q87xpD0eoS4=.a6dc32f4-2919-42e9-80c3-5a264067f0e2@github.com>
 <Uke4223ee6tPQRFdiMkUsIF7oRrz6bm4LMk1FpnmR-k=.190befb3-4d2b-44cf-81c7-2f2d147bd784@github.com>
 <AlPMnCZ8HBODRqVtHHXpUZKwO-yoAI724D0qNz3H4Qk=.ea8de8e2-dcfb-42c6-83a6-bc0626ed2fec@github.com>
 <JB_2ExyxLfCaR-W0ejdB6EMpSXORpKtIBE8PhkN_rGM=.7bd6fda1-6149-4f93-85a1-64e1981dd5c7@github.com>
Message-ID: <u85rI973YRBpkQJWidXqQ3xk3MeZzSvotZvD594jUsI=.97a1db27-db13-4a44-a13f-f6cba026ff1b@github.com>

On Fri, 12 Feb 2021 23:37:40 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> JavaThread::get_thread_name() also calls is_JavaThread_protected().
>> 
>> The "friend" is so that JvmtiTrace can call get_thread_name_string()
>> and we can get rid of the JvmtiTrace version of the logic. I kept the
>> "<NOT FILLED IN>" rather than figure out a way to call Thread::name()
>> so we don't introduce the possibility of a compatibility issue for any
>> code that might depend on that hand rolled string value...
>
> So Thread::is_JavaThread_protected() should be "protected" then, not public.
> yes, I was suggesting adding a default last parameter like
>     JavaThread::get_thread_name(char* default = Thread::name());
> and pass "<NOT_FILLED_IN\>" from JVMTI. Then JVMTI doesn't have to be a friend and have more visibility to the JavaThread class than it should have.

Ahhh.... I think I finally understand what you mean...
I'll look in the AM after I've had some coffee... :-)

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

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

From cjplummer at openjdk.java.net  Sat Feb 13 04:41:38 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Sat, 13 Feb 2021 04:41:38 GMT
Subject: RFR: JDK-8261034: improve jcmd GC.class_histogram to support
 parallel
In-Reply-To: <LXv3U99qPkiJQxlV7UHbRMC9cDYwacPbF6pCVsA2jwg=.dd0dce40-490d-438e-905c-f6fc35c040b7@github.com>
References: <VKzVY-01CEXUbQdlKMhDWjtjxUgpxs_6487x232VsAI=.3b9c5d8a-972b-4997-9f75-1951f98e1751@github.com>
 <X_7cTwpI8cxsVTCMi6oe6f1Fy6yPcw7b0-Pa-Ayou2Y=.69cba9c8-f6e4-40b4-a180-3eb79428692b@github.com>
 <EQm4vRIvMgIFwt3dwYO3YTdbCLyQEKjISTt-QudCNbE=.f2366e5b-b9fa-456d-bafa-6531293b2cc2@github.com>
 <gBKEb-EMtCvqvSZiS1ImsYpQg63tg6R8KaizkL-BrlE=.f51a4335-251c-4041-bd71-75ec13f0591d@github.com>
 <v4SsYZMv2DVW2v8KDDDrCMa-JlyDX6Nsa20ue9JZKqs=.2617d216-b696-48c9-b34e-b0a97bb3bf12@github.com>
 <C47zxVTOUeIMyATz4LgWhTZsmZ6Nk5ncQRbgNKSvTxg=.7570353c-862e-428d-b6bf-aed24b461ea9@github.com>
 <oNo87kApGGMUT6MJYpvDAlyjBzza1-GmLNZSwAGrmEc=.d8669c88-6882-4744-8a05-5cadaa48404f@github.com>
 <A-u0xkGoB54J-q4yyOu-fXBqvXkTRLnmje8qh1KUTTE=.75f97621-8e70-4ab4-b54f-f45b37bd84f5@github.com>
 <hZpMlhWW1rB89tC-Wj_DH9R05YcOFOaqkFprf9MwBD4=.755ccfc2-b743-4037-8f0c-69c078937c5e@github.com>
 <-mAEJ8TjIlhEHKFP0ybmVgqjhCIr8YoAz4Q-GilpZgs=.d1b01b4c-3c14-43ad-8203-b1cd4d2f7ad4@github.com>
 <6APNXM7Ih9TxHMNEPD-uOla7-w08UxJeP4e
 f3-f3joA=.77a8b309-1973-471d-87d7-f682b3ebdb32@github.com>
 <L8t5llrzyxpof_frsgyaf8jznTCckZF-h0t7rM8eAX8=.bb67bcc3-d8db-45a5-a365-7cc05faf27da@github.com>
 <BX2O5NH7WOa57DlDNDgWefirxYUBT7nsCnPhqjchfs0=.6df0ae15-a16b-4cbe-ba5c-02c10d4c332f@github.com>
 <uIKLse-ugmKBUDcOM37UbZkziorlrzcMFJAZa25eqTE=.9ad0afaa-37e6-4ee1-885a-936c60bfad7f@github.com>
 <Ze8CKZ6Auw1oW4J-XKuMpO7n7NTedBBmj0O2UKrOH6o=.a16e8ebb-1a0b-499b-a913-92375c486d76@github.com>
 <ZXHKiFA6-hVma_2MXvCzHMLUFspOl3coMjZ5-u2LBA4=.adbb69ca-f7e0-4189-8951-8619403cf835@github.com>
 <uYzejCgfjq5-bRCKx7RaZWH1zUPsDjBMFeBVIaM4B7o=.5a71658f-9431-4bcb-bde9-37970fbf6823@github.com>
 <LXv3U99qPkiJQxlV7UHbRMC9cDYwacPbF6pCVsA2jwg=.dd0dce40-490d-438e-905c-f6fc35c040b7@github.com>
Message-ID: <mA-4bFE2CPUhPK00SY8G9DC9hjU3y_aJsxdMoy5Z9bA=.ab46dfe9-49c9-4bf2-bf42-d3e6ff81a712@github.com>

On Sat, 13 Feb 2021 04:22:52 GMT, Lin Zang <lzang at openjdk.org> wrote:

> There is a limitation of parallel thread number so that it never exceed the total_workers defined in hotspot.
> so how about we just print how many threads worked on parallel heap insecption and then user get the clue to tune it?

How to we print the number of threads? It's not know to jmap.

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

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

From lzang at openjdk.java.net  Sat Feb 13 05:08:40 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Sat, 13 Feb 2021 05:08:40 GMT
Subject: RFR: JDK-8261034: improve jcmd GC.class_histogram to support
 parallel
In-Reply-To: <mA-4bFE2CPUhPK00SY8G9DC9hjU3y_aJsxdMoy5Z9bA=.ab46dfe9-49c9-4bf2-bf42-d3e6ff81a712@github.com>
References: <VKzVY-01CEXUbQdlKMhDWjtjxUgpxs_6487x232VsAI=.3b9c5d8a-972b-4997-9f75-1951f98e1751@github.com>
 <X_7cTwpI8cxsVTCMi6oe6f1Fy6yPcw7b0-Pa-Ayou2Y=.69cba9c8-f6e4-40b4-a180-3eb79428692b@github.com>
 <EQm4vRIvMgIFwt3dwYO3YTdbCLyQEKjISTt-QudCNbE=.f2366e5b-b9fa-456d-bafa-6531293b2cc2@github.com>
 <gBKEb-EMtCvqvSZiS1ImsYpQg63tg6R8KaizkL-BrlE=.f51a4335-251c-4041-bd71-75ec13f0591d@github.com>
 <v4SsYZMv2DVW2v8KDDDrCMa-JlyDX6Nsa20ue9JZKqs=.2617d216-b696-48c9-b34e-b0a97bb3bf12@github.com>
 <C47zxVTOUeIMyATz4LgWhTZsmZ6Nk5ncQRbgNKSvTxg=.7570353c-862e-428d-b6bf-aed24b461ea9@github.com>
 <oNo87kApGGMUT6MJYpvDAlyjBzza1-GmLNZSwAGrmEc=.d8669c88-6882-4744-8a05-5cadaa48404f@github.com>
 <A-u0xkGoB54J-q4yyOu-fXBqvXkTRLnmje8qh1KUTTE=.75f97621-8e70-4ab4-b54f-f45b37bd84f5@github.com>
 <hZpMlhWW1rB89tC-Wj_DH9R05YcOFOaqkFprf9MwBD4=.755ccfc2-b743-4037-8f0c-69c078937c5e@github.com>
 <-mAEJ8TjIlhEHKFP0ybmVgqjhCIr8YoAz4Q-GilpZgs=.d1b01b4c-3c14-43ad-8203-b1cd4d2f7ad4@github.com>
 <6APNXM7Ih9TxHMNEPD-uOla7-w08UxJeP4e
 f3-f3joA=.77a8b309-1973-471d-87d7-f682b3ebdb32@github.com>
 <L8t5llrzyxpof_frsgyaf8jznTCckZF-h0t7rM8eAX8=.bb67bcc3-d8db-45a5-a365-7cc05faf27da@github.com>
 <BX2O5NH7WOa57DlDNDgWefirxYUBT7nsCnPhqjchfs0=.6df0ae15-a16b-4cbe-ba5c-02c10d4c332f@github.com>
 <uIKLse-ugmKBUDcOM37UbZkziorlrzcMFJAZa25eqTE=.9ad0afaa-37e6-4ee1-885a-936c60bfad7f@github.com>
 <Ze8CKZ6Auw1oW4J-XKuMpO7n7NTedBBmj0O2UKrOH6o=.a16e8ebb-1a0b-499b-a913-92375c486d76@github.com>
 <ZXHKiFA6-hVma_2MXvCzHMLUFspOl3coMjZ5-u2LBA4=.adbb69ca-f7e0-4189-8951-8619403cf835@github.com>
 <uYzejCgfjq5-bRCKx7RaZWH1zUPsDjBMFeBVIaM4B7o=.5a71658f-9431-4bcb-bde9-37970fbf6823@github.com>
 <LXv3U99qPkiJQxlV7UHbRMC9cDYwacPbF6pCVsA2jwg=.dd0dce40-490d-438e-905c-f6fc35c040b7@github.com>
 <mA-4bFE2CPUhPK00SY8G9DC9hjU3y_aJsxdMoy5Z9bA=.ab46dfe9-49c9-4bf2-bf42-d3e6ff81a712@github.com>
Message-ID: <HFeNprAvlRyaSkwWJO7U8n4u9w8YwZpOCs-8ONl1a3o=.cd41fd5c-d90d-4931-a029-7a2156364eda@github.com>

On Sat, 13 Feb 2021 04:39:04 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> > There is a limitation of parallel thread number so that it never exceed the total_workers defined in hotspot.
> > so how about we just print how many threads worked on parallel heap insecption and then user get the clue to tune it?
> 
> How to we print the number of threads? It's not know to jmap.

Yes, It is not known at present, but the heapInspect and heapDumper accept an outputStream, and the actual parallel thread number can be got by gang->active_workers() after WithUpdatedActiveWorkers.  Then maybe some code can be added there to record the actual number and finally print to outputStream at the end.

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

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

From cjplummer at openjdk.java.net  Sat Feb 13 05:49:39 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Sat, 13 Feb 2021 05:49:39 GMT
Subject: RFR: JDK-8261034: improve jcmd GC.class_histogram to support
 parallel
In-Reply-To: <HFeNprAvlRyaSkwWJO7U8n4u9w8YwZpOCs-8ONl1a3o=.cd41fd5c-d90d-4931-a029-7a2156364eda@github.com>
References: <VKzVY-01CEXUbQdlKMhDWjtjxUgpxs_6487x232VsAI=.3b9c5d8a-972b-4997-9f75-1951f98e1751@github.com>
 <X_7cTwpI8cxsVTCMi6oe6f1Fy6yPcw7b0-Pa-Ayou2Y=.69cba9c8-f6e4-40b4-a180-3eb79428692b@github.com>
 <EQm4vRIvMgIFwt3dwYO3YTdbCLyQEKjISTt-QudCNbE=.f2366e5b-b9fa-456d-bafa-6531293b2cc2@github.com>
 <gBKEb-EMtCvqvSZiS1ImsYpQg63tg6R8KaizkL-BrlE=.f51a4335-251c-4041-bd71-75ec13f0591d@github.com>
 <v4SsYZMv2DVW2v8KDDDrCMa-JlyDX6Nsa20ue9JZKqs=.2617d216-b696-48c9-b34e-b0a97bb3bf12@github.com>
 <C47zxVTOUeIMyATz4LgWhTZsmZ6Nk5ncQRbgNKSvTxg=.7570353c-862e-428d-b6bf-aed24b461ea9@github.com>
 <oNo87kApGGMUT6MJYpvDAlyjBzza1-GmLNZSwAGrmEc=.d8669c88-6882-4744-8a05-5cadaa48404f@github.com>
 <A-u0xkGoB54J-q4yyOu-fXBqvXkTRLnmje8qh1KUTTE=.75f97621-8e70-4ab4-b54f-f45b37bd84f5@github.com>
 <hZpMlhWW1rB89tC-Wj_DH9R05YcOFOaqkFprf9MwBD4=.755ccfc2-b743-4037-8f0c-69c078937c5e@github.com>
 <-mAEJ8TjIlhEHKFP0ybmVgqjhCIr8YoAz4Q-GilpZgs=.d1b01b4c-3c14-43ad-8203-b1cd4d2f7ad4@github.com>
 <6APNXM7Ih9TxHMNEPD-uOla7-w08UxJeP4e
 f3-f3joA=.77a8b309-1973-471d-87d7-f682b3ebdb32@github.com>
 <L8t5llrzyxpof_frsgyaf8jznTCckZF-h0t7rM8eAX8=.bb67bcc3-d8db-45a5-a365-7cc05faf27da@github.com>
 <BX2O5NH7WOa57DlDNDgWefirxYUBT7nsCnPhqjchfs0=.6df0ae15-a16b-4cbe-ba5c-02c10d4c332f@github.com>
 <uIKLse-ugmKBUDcOM37UbZkziorlrzcMFJAZa25eqTE=.9ad0afaa-37e6-4ee1-885a-936c60bfad7f@github.com>
 <Ze8CKZ6Auw1oW4J-XKuMpO7n7NTedBBmj0O2UKrOH6o=.a16e8ebb-1a0b-499b-a913-92375c486d76@github.com>
 <ZXHKiFA6-hVma_2MXvCzHMLUFspOl3coMjZ5-u2LBA4=.adbb69ca-f7e0-4189-8951-8619403cf835@github.com>
 <uYzejCgfjq5-bRCKx7RaZWH1zUPsDjBMFeBVIaM4B7o=.5a71658f-9431-4bcb-bde9-37970fbf6823@github.com>
 <LXv3U99qPkiJQxlV7UHbRMC9cDYwacPbF6pCVsA2jwg=.dd0dce40-490d-438e-905c-f6fc35c040b7@github.com>
 <mA-4bFE2CPUhPK00SY8G9DC9hjU3y_aJsxdMoy5Z9bA=.ab46dfe9-49c9-4bf2-bf42-d3e6ff81a712@github.com>
 <HFeNprAvlRyaSkwWJO7U8n4u9w8YwZpOCs-8ONl1a3o=.cd41fd5c-d90d-4931-a029-7a2156364eda@github.com>
Message-ID: <jiD1W4vuwLTeiiZZvCYgiEl-w5XPErcvUeYUxZ1G5QA=.a4b665af-f973-4ec2-befb-e40ff332dee8@github.com>

On Sat, 13 Feb 2021 05:05:48 GMT, Lin Zang <lzang at openjdk.org> wrote:

> Yes, It is not known at present, but the heapInspect and heapDumper accept an outputStream, and the actual parallel thread number can be got by gang->active_workers() after WithUpdatedActiveWorkers. Then maybe some code can be added there to record the actual number and finally print to outputStream at the end.

So you are proposing having the attach "heapdumpext" and "inspectheap" commands always print the number of threads used? I'm not so sure that is a good idea since there are probably existing tools and tests that parse the output, and changing its format could break them.

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

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

From lzang at openjdk.java.net  Sat Feb 13 06:40:42 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Sat, 13 Feb 2021 06:40:42 GMT
Subject: RFR: JDK-8261034: improve jcmd GC.class_histogram to support
 parallel
In-Reply-To: <jiD1W4vuwLTeiiZZvCYgiEl-w5XPErcvUeYUxZ1G5QA=.a4b665af-f973-4ec2-befb-e40ff332dee8@github.com>
References: <VKzVY-01CEXUbQdlKMhDWjtjxUgpxs_6487x232VsAI=.3b9c5d8a-972b-4997-9f75-1951f98e1751@github.com>
 <X_7cTwpI8cxsVTCMi6oe6f1Fy6yPcw7b0-Pa-Ayou2Y=.69cba9c8-f6e4-40b4-a180-3eb79428692b@github.com>
 <EQm4vRIvMgIFwt3dwYO3YTdbCLyQEKjISTt-QudCNbE=.f2366e5b-b9fa-456d-bafa-6531293b2cc2@github.com>
 <gBKEb-EMtCvqvSZiS1ImsYpQg63tg6R8KaizkL-BrlE=.f51a4335-251c-4041-bd71-75ec13f0591d@github.com>
 <v4SsYZMv2DVW2v8KDDDrCMa-JlyDX6Nsa20ue9JZKqs=.2617d216-b696-48c9-b34e-b0a97bb3bf12@github.com>
 <C47zxVTOUeIMyATz4LgWhTZsmZ6Nk5ncQRbgNKSvTxg=.7570353c-862e-428d-b6bf-aed24b461ea9@github.com>
 <oNo87kApGGMUT6MJYpvDAlyjBzza1-GmLNZSwAGrmEc=.d8669c88-6882-4744-8a05-5cadaa48404f@github.com>
 <A-u0xkGoB54J-q4yyOu-fXBqvXkTRLnmje8qh1KUTTE=.75f97621-8e70-4ab4-b54f-f45b37bd84f5@github.com>
 <hZpMlhWW1rB89tC-Wj_DH9R05YcOFOaqkFprf9MwBD4=.755ccfc2-b743-4037-8f0c-69c078937c5e@github.com>
 <-mAEJ8TjIlhEHKFP0ybmVgqjhCIr8YoAz4Q-GilpZgs=.d1b01b4c-3c14-43ad-8203-b1cd4d2f7ad4@github.com>
 <6APNXM7Ih9TxHMNEPD-uOla7-w08UxJeP4e
 f3-f3joA=.77a8b309-1973-471d-87d7-f682b3ebdb32@github.com>
 <L8t5llrzyxpof_frsgyaf8jznTCckZF-h0t7rM8eAX8=.bb67bcc3-d8db-45a5-a365-7cc05faf27da@github.com>
 <BX2O5NH7WOa57DlDNDgWefirxYUBT7nsCnPhqjchfs0=.6df0ae15-a16b-4cbe-ba5c-02c10d4c332f@github.com>
 <uIKLse-ugmKBUDcOM37UbZkziorlrzcMFJAZa25eqTE=.9ad0afaa-37e6-4ee1-885a-936c60bfad7f@github.com>
 <Ze8CKZ6Auw1oW4J-XKuMpO7n7NTedBBmj0O2UKrOH6o=.a16e8ebb-1a0b-499b-a913-92375c486d76@github.com>
 <ZXHKiFA6-hVma_2MXvCzHMLUFspOl3coMjZ5-u2LBA4=.adbb69ca-f7e0-4189-8951-8619403cf835@github.com>
 <uYzejCgfjq5-bRCKx7RaZWH1zUPsDjBMFeBVIaM4B7o=.5a71658f-9431-4bcb-bde9-37970fbf6823@github.com>
 <LXv3U99qPkiJQxlV7UHbRMC9cDYwacPbF6pCVsA2jwg=.dd0dce40-490d-438e-905c-f6fc35c040b7@github.com>
 <mA-4bFE2CPUhPK00SY8G9DC9hjU3y_aJsxdMoy5Z9bA=.ab46dfe9-49c9-4bf2-bf42-d3e6ff81a712@github.com>
 <HFeNprAvlRyaSkwWJO7U8n4u9w8YwZpOCs-8ONl1a3o=.cd41fd5c-d90d-4931-a029-7a2156364eda@github.com>
 <jiD1W4vuwLTeiiZZvCYgiEl-w5XPErcvUeYUxZ1G5QA=.a4b665af-f973-4ec2-befb-e40ff332dee8@
 github.com>
Message-ID: <BdD2NhK4j3NDO6MEPdgBqrjeqoMkLnLNdpY8Msbmt70=.bb352cad-388a-4d65-b672-dc9c3e2133ac@github.com>

On Sat, 13 Feb 2021 05:46:32 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> > Yes, It is not known at present, but the heapInspect and heapDumper accept an outputStream, and the actual parallel thread number can be got by gang->active_workers() after WithUpdatedActiveWorkers. Then maybe some code can be added there to record the actual number and finally print to outputStream at the end.
> 
> So you are proposing having the attach "heapdumpext" and "inspectheap" commands always print the number of threads used? I'm not so sure that is a good idea since there are probably existing tools and tests that parse the output, and changing its format could break them.

Correct? if there is parsing tools (which I think there alreay are.), they will be broken.
So I am afraid user can only tuning the thread number by expriments and some common sense such as the core number of their server or the multi-processing scenario.

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

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

From cjplummer at openjdk.java.net  Sat Feb 13 07:12:44 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Sat, 13 Feb 2021 07:12:44 GMT
Subject: RFR: JDK-8261034: improve jcmd GC.class_histogram to support
 parallel
In-Reply-To: <BdD2NhK4j3NDO6MEPdgBqrjeqoMkLnLNdpY8Msbmt70=.bb352cad-388a-4d65-b672-dc9c3e2133ac@github.com>
References: <VKzVY-01CEXUbQdlKMhDWjtjxUgpxs_6487x232VsAI=.3b9c5d8a-972b-4997-9f75-1951f98e1751@github.com>
 <X_7cTwpI8cxsVTCMi6oe6f1Fy6yPcw7b0-Pa-Ayou2Y=.69cba9c8-f6e4-40b4-a180-3eb79428692b@github.com>
 <EQm4vRIvMgIFwt3dwYO3YTdbCLyQEKjISTt-QudCNbE=.f2366e5b-b9fa-456d-bafa-6531293b2cc2@github.com>
 <gBKEb-EMtCvqvSZiS1ImsYpQg63tg6R8KaizkL-BrlE=.f51a4335-251c-4041-bd71-75ec13f0591d@github.com>
 <v4SsYZMv2DVW2v8KDDDrCMa-JlyDX6Nsa20ue9JZKqs=.2617d216-b696-48c9-b34e-b0a97bb3bf12@github.com>
 <C47zxVTOUeIMyATz4LgWhTZsmZ6Nk5ncQRbgNKSvTxg=.7570353c-862e-428d-b6bf-aed24b461ea9@github.com>
 <oNo87kApGGMUT6MJYpvDAlyjBzza1-GmLNZSwAGrmEc=.d8669c88-6882-4744-8a05-5cadaa48404f@github.com>
 <A-u0xkGoB54J-q4yyOu-fXBqvXkTRLnmje8qh1KUTTE=.75f97621-8e70-4ab4-b54f-f45b37bd84f5@github.com>
 <hZpMlhWW1rB89tC-Wj_DH9R05YcOFOaqkFprf9MwBD4=.755ccfc2-b743-4037-8f0c-69c078937c5e@github.com>
 <-mAEJ8TjIlhEHKFP0ybmVgqjhCIr8YoAz4Q-GilpZgs=.d1b01b4c-3c14-43ad-8203-b1cd4d2f7ad4@github.com>
 <6APNXM7Ih9TxHMNEPD-uOla7-w08UxJeP4e
 f3-f3joA=.77a8b309-1973-471d-87d7-f682b3ebdb32@github.com>
 <L8t5llrzyxpof_frsgyaf8jznTCckZF-h0t7rM8eAX8=.bb67bcc3-d8db-45a5-a365-7cc05faf27da@github.com>
 <BX2O5NH7WOa57DlDNDgWefirxYUBT7nsCnPhqjchfs0=.6df0ae15-a16b-4cbe-ba5c-02c10d4c332f@github.com>
 <uIKLse-ugmKBUDcOM37UbZkziorlrzcMFJAZa25eqTE=.9ad0afaa-37e6-4ee1-885a-936c60bfad7f@github.com>
 <Ze8CKZ6Auw1oW4J-XKuMpO7n7NTedBBmj0O2UKrOH6o=.a16e8ebb-1a0b-499b-a913-92375c486d76@github.com>
 <ZXHKiFA6-hVma_2MXvCzHMLUFspOl3coMjZ5-u2LBA4=.adbb69ca-f7e0-4189-8951-8619403cf835@github.com>
 <uYzejCgfjq5-bRCKx7RaZWH1zUPsDjBMFeBVIaM4B7o=.5a71658f-9431-4bcb-bde9-37970fbf6823@github.com>
 <LXv3U99qPkiJQxlV7UHbRMC9cDYwacPbF6pCVsA2jwg=.dd0dce40-490d-438e-905c-f6fc35c040b7@github.com>
 <mA-4bFE2CPUhPK00SY8G9DC9hjU3y_aJsxdMoy5Z9bA=.ab46dfe9-49c9-4bf2-bf42-d3e6ff81a712@github.com>
 <HFeNprAvlRyaSkwWJO7U8n4u9w8YwZpOCs-8ONl1a3o=.cd41fd5c-d90d-4931-a029-7a2156364eda@github.com>
 <jiD1W4vuwLTeiiZZvCYgiEl-w5XPErcvUeYUxZ1G5QA=.a4b665af-f973-4ec2-befb-e40ff332dee8@
 github.com>
 <BdD2NhK4j3NDO6MEPdgBqrjeqoMkLnLNdpY8Msbmt70=.bb352cad-388a-4d65-b672-dc9c3e2133ac@github.com>
Message-ID: <FIfmotGSNufKVt5sEnmE2UlvdnokbdJbIbxmVlWa868=.623032fb-1a5e-40e4-8f92-e965a1cd381a@github.com>

On Sat, 13 Feb 2021 06:37:54 GMT, Lin Zang <lzang at openjdk.org> wrote:

> Correct? if there is parsing tools (which I think there alreay are.), they will be broken.
> So I am afraid user can only tuning the thread number by expriments and some common sense such as the core number of their server or the multi-processing scenario.

I'm ok with that. I think the other options we've explored are more trouble than they are worth.

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

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

From github.com+741251+turbanoff at openjdk.java.net  Sat Feb 13 10:23:43 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Sat, 13 Feb 2021 10:23:43 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v8]
In-Reply-To: <ADR73RPzLPNb5SY61wNVAQNB0JdNFrXgwmsdteeicVU=.1c5f04db-c639-4028-b472-c56999c4746c@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <KcO_olP0uhrkPxSvala6b0MN3zsFy0_Skl06Oq6Gla0=.398341c8-a9c6-4186-ab43-df19bec9d544@github.com>
 <cONOB0wrdWjjltXXAuaH_SYz_ay7AgllB3SN64c8K_I=.d711bc68-c800-45fd-9de5-5bd1c5621430@github.com>
 <SNPiblXpzCPdmntADzdMMqFCO6eSjKOltzwD5MWnipc=.814578a6-ea9b-40b1-bfd8-199324b7281e@github.com>
 <_uFXfNAzlG3COOLDN_bJBEH4n0xtk52RH4jgW0MYF_w=.358107f1-fa87-4b5a-8ded-08248080678f@github.com>
 <JzpZmZbaq1b-bBgth2Wq1YTVQKpP3DbToT4h8N7ofTE=.4490859d-21a1-4cc9-8e8c-a8d067c82989@github.com>
 <y0ZtJNDhwp3A2Jzsszmio6fg0sGSxvk49eZw2cR_kss=.16bf1d32-b7df-4b5b-a3cc-fd8b2d0bebbe@github.com>
 <9ueMq5ar7LfXsQ5hV2wMnVVethu_2kyzuelDPv_8tfk=.b40c37bb-604e-478f-bc01-428694f0d4c9@github.com>
 <KctKgE0hs5s-qmGmNe_tJwW5C-IrvK5i72mO06GZ3v4=.f48f8a2d-a4a9-4074-9350-7cd443f73373@github.com>
 <hGiSvYyNa6D0BuKfIh-3CkelapBMNrFaQ_prF3xzPQQ=.64336055-18e5-4428-bc5b-40d484ed18ba@github.com>
 <ADR73RPzLPNb5SY61wNVAQNB0JdNFrXgwms
 dteeicVU=.1c5f04db-c639-4028-b472-c56999c4746c@github.com>
Message-ID: <h1cjvuqNbm9Chz7atbi8daeCmDWgzzAKdFoHdgngjR8=.543211a7-9513-4d5f-8f45-9b0d300cdf00@github.com>

On Fri, 12 Feb 2021 22:12:29 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> ## java/security/AccessController/DoPrivAccompliceTest.java
>> 
>>     make test TEST="jtreg:java/security/AccessController/DoPrivAccompliceTest.java"
>> 
>>     STDOUT:
>>     Adding DoPrivAccomplice.class to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar
>> 
>>     Created jar file F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar
>>     Adding DoPrivTest.class to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar
>> 
>>     Created jar file F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar
>>     Created policy for F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar
>>     Command line: [f:\projects\official_openjdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe -cp F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\classes\0\java\security\AccessController\DoPrivAccompliceTest.d;F:\Projects\official_openjdk\test\jdk\java\security\AccessController;F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\classes\0\test\lib;F:\Projects\official_openjdk\test\lib;C:\Programs\jtreg-4.2.0-tip\jtreg\lib\javatest.jar;C:\Programs\jtreg-4.2.0-tip\jtreg\lib\jtreg.jar -Xmx512m -XX:MaxRAMPercentage=6 -Djava.io.tmpdir=f:\projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\tmp -ea -esa -Djava.security.manager -Djava.security.policy=F:\Projects\official_openjdk\build\
 windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\java.policy -classpath F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar;F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar DoPrivTest ]
>>     [2021-02-12T21:42:29.297091800Z] Gathering output for process 12712
>>     [2021-02-12T21:42:29.544092Z] Waiting for completion for process 12712
>>     [2021-02-12T21:42:29.544092Z] Waiting for completion finished for process 12712
>>     Output and diagnostic info for process 12712 was saved into 'pid-12712-output.log'
>>     [2021-02-12T21:42:29.547092500Z] Waiting for completion for process 12712
>>     [2021-02-12T21:42:29.547092500Z] Waiting for completion finished for process 12712
>>     Created policy for F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar
>>     Command line: [f:\projects\official_openjdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe -cp F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\classes\0\java\security\AccessController\DoPrivAccompliceTest.d;F:\Projects\official_openjdk\test\jdk\java\security\AccessController;F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\classes\0\test\lib;F:\Projects\official_openjdk\test\lib;C:\Programs\jtreg-4.2.0-tip\jtreg\lib\javatest.jar;C:\Programs\jtreg-4.2.0-tip\jtreg\lib\jtreg.jar -Xmx512m -XX:MaxRAMPercentage=6 -Djava.io.tmpdir=f:\projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\tmp -ea -esa -Djava.security.manager -Djava.security.policy=F:\Projects\official_openjdk\build\
 windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\java.policy -classpath F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar;F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar DoPrivTest ]
>>     [2021-02-12T21:42:29.553092400Z] Gathering output for process 10560
>>     [2021-02-12T21:42:29.783092500Z] Waiting for completion for process 10560
>>     [2021-02-12T21:42:29.783092500Z] Waiting for completion finished for process 10560
>>     Output and diagnostic info for process 10560 was saved into 'pid-10560-output.log'
>>     [2021-02-12T21:42:29.785092800Z] Waiting for completion for process 10560
>>     [2021-02-12T21:42:29.785092800Z] Waiting for completion finished for process 10560
>>     [2021-02-12T21:42:29.785092800Z] Waiting for completion for process 10560
>>     [2021-02-12T21:42:29.785092800Z] Waiting for completion finished for process 10560
>>     STDERR:
>>      stdout: [];
>>      stderr: [Exception in thread "main" java.security.AccessControlException: access denied ("java.util.PropertyPermission" "user.name" "read")
>>             at java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
>>             at java.base/java.security.AccessController.checkPermission(AccessController.java:1036)
>>             at java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:408)
>>             at java.base/java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1152)
>>             at java.base/java.lang.System.getProperty(System.java:833)
>>             at DoPrivAccomplice.lambda$go$0(DoPrivAccomplice.java:31)
>>             at java.base/java.security.AccessController.doPrivileged(AccessController.java:312)
>>             at DoPrivAccomplice.go(DoPrivAccomplice.java:30)
>>             at DoPrivTest.main(DoPrivTest.java:29)
>>     ]
>>      exitValue = 1
>> 
>>     java.lang.RuntimeException: 'user' found in stderr
>> 
>>             at jdk.test.lib.process.OutputAnalyzer.shouldNotContain(OutputAnalyzer.java:256)
>>             at DoPrivAccompliceTest.main(DoPrivAccompliceTest.java:112)
>>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>>             at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>>             at java.base/java.lang.Thread.run(Thread.java:831)
>> 
>>     JavaTest Message: Test threw exception: java.lang.RuntimeException: 'user' found in stderr
>> 
>>     JavaTest Message: shutting down test
>> 
>>     STATUS:Failed.`main' threw exception: java.lang.RuntimeException: 'user' found in stderr
>>     
>> Looks like test is not ready for username `user`, which I use locally.
>
> ## tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java
> 
>     make test TEST="jtreg:tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java"
> 
>     STDOUT:
>     [00:56:54.598] Parsing [--jpt-run=jdk.jpackage.tests.UnicodeArgsTest]...
>     [00:56:54.650] jdk.jpackage.tests.UnicodeArgsTest.test8246042 -> [public void jdk.jpackage.tests.UnicodeArgsTest.test8246042(boolean)]
>     [00:56:54.682] Create: UnicodeArgsTest.test8246042(true)
>     [00:56:54.684] Create: UnicodeArgsTest.test8246042(false)
>     [00:56:54.688] [ RUN      ] UnicodeArgsTest.test8246042(false)
>     [00:56:54.693] TRACE: Test string code points: [0x00e9]
>     [00:56:54.875] TRACE: exec: Execute tool provider [javac -d .\test8246042.9782d070\jar-workdir F:\Projects\official_openjdk\test\jdk\tools\jpackage\apps\image\Hello.java](4)...
>     [00:56:55.996] TRACE: exec: Done. Exit code: 0
>     [00:56:55.997] TRACE: assertEquals(0): Check command tool provider [javac -d .\test8246042.9782d070\jar-workdir F:\Projects\official_openjdk\test\jdk\tools\jpackage\apps\image\Hello.java](4) exited with 0 code
>     [00:56:56.014] TRACE: exec: Execute tool provider [jar -c -f .\test8246042.9782d070\input\hello.jar -C .\test8246042.9782d070\jar-workdir .](7)...
>     [00:56:56.188] TRACE: exec: Done. Exit code: 0
>     [00:56:56.188] TRACE: assertEquals(0): Check command tool provider [jar -c -f .\test8246042.9782d070\input\hello.jar -C .\test8246042.9782d070\jar-workdir .](7) exited with 0 code
>     [00:56:56.196] TRACE: exec: Execute tool provider [jpackage --input .\test8246042.9782d070\input --dest .\test8246042.9782d070\output --name 8246042UnicodeArgsTest --type app-image --main-jar hello.jar --main-class Hello --win-console --arguments ? --verbose](17)...
>     [00:56:56.225] Creating app package: 8246042UnicodeArgsTest in F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.9782d070\output
>     [00:57:07.680] Command:
>         jlink --output .\test8246042.9782d070\output\8246042UnicodeArgsTest\runtime --module-path f:\\projects\\official_openjdk\\build\\windows-x86_64-server-release\\images\\jdk\\jmods --add-modules jdk.management.jfr,java.rmi,jdk.jdi,jdk.charsets,java.xml,jdk.xml.dom,java.datatransfer,jdk.jstatd,jdk.httpserver,java.desktop,java.security.sasl,jdk.zipfs,java.base,jdk.crypto.ec,jdk.javadoc,jdk.management.agent,jdk.jshell,jdk.editpad,java.sql.rowset,jdk.jsobject,jdk.sctp,java.smartcardio,jdk.jlink,jdk.unsupported,java.security.jgss,java.compiler,jdk.nio.mapmode,jdk.dynalink,jdk.unsupported.desktop,jdk.accessibility,jdk.security.jgss,java.sql,jdk.incubator.vector,java.xml.crypto,java.logging,java.transaction.xa,jdk.jfr,jdk.crypto.cryptoki,jdk.net,java.naming,jdk.internal.ed,java.prefs,java.net.http,jdk.compiler,jdk.naming.rmi,jdk.internal.opt,jdk.jconsole,jdk.attach,jdk.crypto.mscapi,jdk.internal.le,java.management,jdk.jdwp.agent,jdk.internal.jvmstat,jdk.incubator.foreign,java.instru
 ment,jdk.management,jdk.security.auth,java.scripting,jdk.jdeps,jdk.jartool,java.management.rmi,jdk.jpackage,jdk.naming.dns,jdk.localedata --strip-native-commands --strip-debug --no-man-pages --no-header-files
>     [00:57:07.680] Output:
>         WARNING: Using incubator modules: jdk.incubator.vector, jdk.incubator.foreign
> 
>     [00:57:07.681] Returned: 0
> 
>     [00:57:07.685] Using default package resource java48.ico [icon] (add 8246042UnicodeArgsTest.ico to the resource-dir to customize).
>     [00:57:07.707] Warning: Windows Defender may prevent jpackage from functioning. If there is an issue, it can be addressed by either disabling realtime monitoring, or adding an exclusion for the directory "f:\projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\tmp\jdk.jpackage16485063537873697224".
>     [00:57:07.712] Using default package resource WinLauncher.template [Template for creating executable properties file] (add 8246042UnicodeArgsTest.properties to the resource-dir to customize).
>     [00:57:07.746] Succeeded in building Windows Application Image package
>     [00:57:07.748] TRACE: exec: Done. Exit code: 0
>     [00:57:07.748] TRACE: assertEquals(0): Check command tool provider [jpackage --input .\test8246042.9782d070\input --dest .\test8246042.9782d070\output --name 8246042UnicodeArgsTest --type app-image --main-jar hello.jar --main-class Hello --win-console --arguments ? --verbose](17) exited with 0 code
>     [00:57:07.766] TRACE: assertStringListEquals(): Check there is only one file with [.jpackage.xml] name in the package
>     [00:57:07.768] TRACE: assertStringListEquals(1, .\test8246042.9782d070\output\8246042UnicodeArgsTest\app.jpackage.xml)
>     [00:57:07.769] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\runtime] path exists
>     [00:57:07.769] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\runtime] is a directory
>     [00:57:07.770] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] path exists
>     [00:57:07.770] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] is a file
>     [00:57:07.770] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] file is executable
>     [00:57:07.771] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\app\8246042UnicodeArgsTest.cfg] path exists
>     [00:57:07.771] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\app\8246042UnicodeArgsTest.cfg] is a file
>     [00:57:07.780] TRACE: Clearing PATH in environment
>     [00:57:07.780] TRACE: exec: Execute [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.9782d070\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe](1); inherit I/O; in directory [.\test8246042.9782d070]...
>     hello: Environment supports a display
>     hello: Environment supports a desktop
>     [0x0065]
>     jpackage test application
>     args.length: 1
>     e
>     hello: Output file: [appOutput.txt]
>     [00:57:09.302] TRACE: exec: Done. Exit code: 0
>     [00:57:09.302] TRACE: assertEquals(0): Check command [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.9782d070\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe](1) exited with 0 code
>     [00:57:09.303] TRACE: assertTrue(): Check [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.9782d070\appOutput.txt] path exists
>     [00:57:09.303] TRACE: assertTrue(): Check [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.9782d070\appOutput.txt] is a file
>     [00:57:09.305] TRACE: assertStringListEquals(): Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.9782d070\appOutput.txt] file
>     [00:57:09.305] TRACE: assertStringListEquals(1, jpackage test application)
>     [00:57:09.306] TRACE: assertStringListEquals(2, args.length: 1)
>     [00:57:09.307] ERROR: (3) Expected [?]. Actual [e]: Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.9782d070\appOutput.txt] file
>     [00:57:09.308] [  FAILED  ] UnicodeArgsTest.test8246042(false); checks=15
>     [00:57:09.310] [ RUN      ] UnicodeArgsTest.test8246042(true)
>     [00:57:09.312] TRACE: Test string code points: [0x00e9]
>     [00:57:09.314] TRACE: exec: Execute tool provider [javac -d .\test8246042.b31bae11\jar-workdir F:\Projects\official_openjdk\test\jdk\tools\jpackage\apps\image\Hello.java](4)...
>     [00:57:09.658] TRACE: exec: Done. Exit code: 0
>     [00:57:09.659] TRACE: assertEquals(0): Check command tool provider [javac -d .\test8246042.b31bae11\jar-workdir F:\Projects\official_openjdk\test\jdk\tools\jpackage\apps\image\Hello.java](4) exited with 0 code
>     [00:57:09.661] TRACE: exec: Execute tool provider [jar -c -f .\test8246042.b31bae11\input\hello.jar -C .\test8246042.b31bae11\jar-workdir .](7)...
>     [00:57:09.667] TRACE: exec: Done. Exit code: 0
>     [00:57:09.667] TRACE: assertEquals(0): Check command tool provider [jar -c -f .\test8246042.b31bae11\input\hello.jar -C .\test8246042.b31bae11\jar-workdir .](7) exited with 0 code
>     [00:57:09.670] TRACE: exec: Execute tool provider [jpackage --input .\test8246042.b31bae11\input --dest .\test8246042.b31bae11\output --name 8246042UnicodeArgsTest --type app-image --main-jar hello.jar --main-class Hello --win-console --verbose](15)...
>     [00:57:09.670]
>     jpackage argument list:
>     [--input, .\test8246042.b31bae11\input, --dest, .\test8246042.b31bae11\output, --name, 8246042UnicodeArgsTest, --type, app-image, --main-jar, hello.jar, --main-class, Hello, --win-console, --verbose]
> 
>     [00:57:09.679] Creating app package: 8246042UnicodeArgsTest in F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.b31bae11\output
>     [00:57:18.770] Command:
>         jlink --output .\test8246042.b31bae11\output\8246042UnicodeArgsTest\runtime --module-path f:\\projects\\official_openjdk\\build\\windows-x86_64-server-release\\images\\jdk\\jmods --add-modules jdk.management.jfr,java.rmi,jdk.jdi,jdk.charsets,jdk.xml.dom,java.xml,java.datatransfer,jdk.jstatd,jdk.httpserver,java.desktop,java.security.sasl,jdk.zipfs,java.base,jdk.crypto.ec,jdk.javadoc,jdk.management.agent,jdk.jshell,jdk.editpad,jdk.sctp,jdk.jsobject,java.sql.rowset,jdk.jlink,java.smartcardio,jdk.unsupported,java.security.jgss,java.compiler,jdk.nio.mapmode,jdk.dynalink,jdk.unsupported.desktop,jdk.accessibility,jdk.security.jgss,java.sql,jdk.incubator.vector,java.xml.crypto,java.logging,java.transaction.xa,jdk.jfr,jdk.crypto.cryptoki,jdk.net,java.naming,jdk.internal.ed,java.prefs,java.net.http,jdk.compiler,jdk.internal.opt,jdk.naming.rmi,jdk.jconsole,jdk.attach,jdk.crypto.mscapi,jdk.internal.le,java.management,jdk.jdwp.agent,jdk.incubator.foreign,jdk.internal.jvmstat,java.instru
 ment,jdk.management,jdk.security.auth,java.scripting,jdk.jdeps,jdk.jartool,jdk.jpackage,java.management.rmi,jdk.naming.dns,jdk.localedata --strip-native-commands --strip-debug --no-man-pages --no-header-files
>     [00:57:18.770] Output:
>         WARNING: Using incubator modules: jdk.incubator.vector, jdk.incubator.foreign
> 
>     [00:57:18.770] Returned: 0
> 
>     [00:57:18.771] Using default package resource java48.ico [icon] (add 8246042UnicodeArgsTest.ico to the resource-dir to customize).
>     [00:57:18.778] Warning: Windows Defender may prevent jpackage from functioning. If there is an issue, it can be addressed by either disabling realtime monitoring, or adding an exclusion for the directory "f:\projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\tmp\jdk.jpackage8738450931736312275".
>     [00:57:18.779] Using default package resource WinLauncher.template [Template for creating executable properties file] (add 8246042UnicodeArgsTest.properties to the resource-dir to customize).
>     [00:57:18.787] Succeeded in building Windows Application Image package
>     [00:57:18.788] TRACE: exec: Done. Exit code: 0
>     [00:57:18.789] TRACE: assertEquals(0): Check command tool provider [jpackage --input .\test8246042.b31bae11\input --dest .\test8246042.b31bae11\output --name 8246042UnicodeArgsTest --type app-image --main-jar hello.jar --main-class Hello --win-console --verbose](15) exited with 0 code
>     [00:57:18.804] TRACE: assertStringListEquals(): Check there is only one file with [.jpackage.xml] name in the package
>     [00:57:18.804] TRACE: assertStringListEquals(1, .\test8246042.b31bae11\output\8246042UnicodeArgsTest\app.jpackage.xml)
>     [00:57:18.805] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\runtime] path exists
>     [00:57:18.805] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\runtime] is a directory
>     [00:57:18.806] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] path exists
>     [00:57:18.806] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] is a file
>     [00:57:18.806] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] file is executable
>     [00:57:18.807] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\app\8246042UnicodeArgsTest.cfg] path exists
>     [00:57:18.807] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\app\8246042UnicodeArgsTest.cfg] is a file
>     [00:57:18.808] TRACE: Clearing PATH in environment
>     [00:57:18.808] TRACE: exec: Execute [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.b31bae11\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe ?](2); inherit I/O; in directory [.\test8246042.b31bae11]...
>     hello: Environment supports a display
>     hello: Environment supports a desktop
>     [0x0065]
>     jpackage test application
>     args.length: 1
>     e
>     hello: Output file: [appOutput.txt]
>     [00:57:20.327] TRACE: exec: Done. Exit code: 0
>     [00:57:20.328] TRACE: assertEquals(0): Check command [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.b31bae11\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe ?](2) exited with 0 code
>     [00:57:20.328] TRACE: assertTrue(): Check [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.b31bae11\appOutput.txt] path exists
>     [00:57:20.329] TRACE: assertTrue(): Check [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.b31bae11\appOutput.txt] is a file
>     [00:57:20.330] TRACE: assertStringListEquals(): Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.b31bae11\appOutput.txt] file
>     [00:57:20.330] TRACE: assertStringListEquals(1, jpackage test application)
>     [00:57:20.330] TRACE: assertStringListEquals(2, args.length: 1)
>     [00:57:20.330] ERROR: (3) Expected [?]. Actual [e]: Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.b31bae11\appOutput.txt] file
>     [00:57:20.331] [  FAILED  ] UnicodeArgsTest.test8246042(true); checks=15
>     [00:57:20.332] [==========] 2 tests ran
>     [00:57:20.333] [  PASSED  ] 0 tests
>     [00:57:20.334] [  FAILED  ] 2 tests, listed below
>     [00:57:20.335] [  FAILED  ] UnicodeArgsTest.test8246042(false); workDir=[.\test8246042.9782d070]
>     [00:57:20.335] [  FAILED  ] UnicodeArgsTest.test8246042(true); workDir=[.\test8246042.b31bae11]
>     [00:57:20.336] 2 FAILED TESTS
>     STDERR:
>     java.lang.AssertionError: (3) Expected [?]. Actual [e]: Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.9782d070\appOutput.txt] file
>             at jdk.jpackage.test.TKit.error(TKit.java:293)
>             at jdk.jpackage.test.TKit.lambda$assertStringListEquals$20(TKit.java:765)
>             at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
>             at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179)
>             at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625)
>             at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
>             at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
>             at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
>             at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
>             at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
>             at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:596)
>             at jdk.jpackage.test.TKit.assertStringListEquals(TKit.java:759)
>             at jdk.jpackage.test.HelloApp.verifyOutputFile(HelloApp.java:225)
>             at jdk.jpackage.test.HelloApp.verifyOutputFile(HelloApp.java:204)
>             at jdk.jpackage.test.HelloApp$AppOutputVerifier.executeAndVerifyOutput(HelloApp.java:405)
>             at jdk.jpackage.test.HelloApp$AppOutputVerifier.executeAndVerifyOutput(HelloApp.java:417)
>             at jdk.jpackage.test.HelloApp.executeLauncherAndVerifyOutput(HelloApp.java:319)
>             at jdk.jpackage.tests.UnicodeArgsTest.test8246042(UnicodeArgsTest.java:67)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>             at jdk.jpackage.test.MethodCall.accept(MethodCall.java:145)
>             at jdk.jpackage.test.TestInstance.run(TestInstance.java:230)
>             at jdk.jpackage.test.TKit.lambda$ignoreExceptions$6(TKit.java:155)
>             at jdk.jpackage.test.TKit.lambda$runTests$4(TKit.java:140)
>             at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625)
>             at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:762)
>             at jdk.jpackage.test.TKit.lambda$runTests$5(TKit.java:137)
>             at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105)
>             at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:123)
>             at jdk.jpackage.test.TKit.runTests(TKit.java:136)
>             at jdk.jpackage.test.Main.runTests(Main.java:79)
>             at jdk.jpackage.test.Main.lambda$main$2(Main.java:75)
>             at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105)
>             at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:123)
>             at jdk.jpackage.test.Main.main(Main.java:75)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>             at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>             at java.base/java.lang.Thread.run(Thread.java:831)
>     java.lang.AssertionError: (3) Expected [?]. Actual [e]: Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.b31bae11\appOutput.txt] file
>             at jdk.jpackage.test.TKit.error(TKit.java:293)
>             at jdk.jpackage.test.TKit.lambda$assertStringListEquals$20(TKit.java:765)
>             at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
>             at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179)
>             at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625)
>             at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
>             at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
>             at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
>             at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
>             at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
>             at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:596)
>             at jdk.jpackage.test.TKit.assertStringListEquals(TKit.java:759)
>             at jdk.jpackage.test.HelloApp.verifyOutputFile(HelloApp.java:225)
>             at jdk.jpackage.test.HelloApp.verifyOutputFile(HelloApp.java:204)
>             at jdk.jpackage.test.HelloApp$AppOutputVerifier.executeAndVerifyOutput(HelloApp.java:405)
>             at jdk.jpackage.test.HelloApp$AppOutputVerifier.executeAndVerifyOutput(HelloApp.java:417)
>             at jdk.jpackage.test.HelloApp.executeLauncherAndVerifyOutput(HelloApp.java:319)
>             at jdk.jpackage.tests.UnicodeArgsTest.test8246042(UnicodeArgsTest.java:65)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>             at jdk.jpackage.test.MethodCall.accept(MethodCall.java:145)
>             at jdk.jpackage.test.TestInstance.run(TestInstance.java:230)
>             at jdk.jpackage.test.TKit.lambda$ignoreExceptions$6(TKit.java:155)
>             at jdk.jpackage.test.TKit.lambda$runTests$4(TKit.java:140)
>             at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625)
>             at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:762)
>             at jdk.jpackage.test.TKit.lambda$runTests$5(TKit.java:137)
>             at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105)
>             at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:123)
>             at jdk.jpackage.test.TKit.runTests(TKit.java:136)
>             at jdk.jpackage.test.Main.runTests(Main.java:79)
>             at jdk.jpackage.test.Main.lambda$main$2(Main.java:75)
>             at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105)
>             at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:123)
>             at jdk.jpackage.test.Main.main(Main.java:75)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>             at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>             at java.base/java.lang.Thread.run(Thread.java:831)
>     jdk.jpackage.test.Functional$ExceptionBox: java.lang.RuntimeException: 2 FAILED TESTS
>             at jdk.jpackage.test.Functional.rethrowUnchecked(Functional.java:161)
>             at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:107)
>             at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:123)
>             at jdk.jpackage.test.Main.main(Main.java:75)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>             at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>             at java.base/java.lang.Thread.run(Thread.java:831)
>     Caused by: java.lang.RuntimeException: 2 FAILED TESTS
>             at jdk.jpackage.test.Main.reportSummary(Main.java:130)
>             at jdk.jpackage.test.Main.runTests(Main.java:90)
>             at jdk.jpackage.test.Main.lambda$main$2(Main.java:75)
>             at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105)
>             ... 8 more
> 
>     JavaTest Message: Test threw exception: jdk.jpackage.test.Functional$ExceptionBox: java.lang.RuntimeException: 2 FAILED TESTS
>     JavaTest Message: shutting down test
> 
>     STATUS:Failed.`main' threw exception: jdk.jpackage.test.Functional$ExceptionBox: java.lang.RuntimeException: 2 FAILED TESTS
> 
> Oh. This one is tricky. Will investigate later.

This fours tests pass without problems, when I run them separately.

## sun/security/tools/jarsigner/TimestampCheck.java
## sun/security/tools/keytool/DefaultOptions.java
## sanity/client/SwingSet/src/ColorChooserDemoTest.java
## sanity/client/SwingSet/src/SwingSet2DemoTest.java

    make test TEST="jtreg:sun/security/tools/jarsigner/TimestampCheck.java sun/security/tools/keytool/DefaultOptions.java sanity/client/SwingSet/src/SwingSet2DemoTest.java sanity/client/SwingSet/src/ColorChooserDemoTest.java"
    
    Building target 'test' in configuration 'windows-x86_64-server-release'
    Test selection 'jtreg:sun/security/tools/jarsigner/TimestampCheck.java sun/security/tools/keytool/DefaultOptions.java sanity/client/SwingSet/src/SwingSet2DemoTest.java sanity/client/SwingSet/src/ColorChooserDemoTest.java', will run:
    * jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java
    * jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java
    * jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java
    * jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java

    Running test 'jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java'
    Passed: sun/security/tools/jarsigner/TimestampCheck.java
    Test results: passed: 1
    Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sun_security_tools_jarsigner_TimestampCheck_java\html\report.html
    Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sun_security_tools_jarsigner_TimestampCheck_java
    Finished running test 'jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java'
    Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sun_security_tools_jarsigner_TimestampCheck_java

    Running test 'jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java'
    Passed: sun/security/tools/keytool/DefaultOptions.java
    Test results: passed: 1
    Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sun_security_tools_keytool_DefaultOptions_java\html\report.html
    Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sun_security_tools_keytool_DefaultOptions_java
    Finished running test 'jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java'
    Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sun_security_tools_keytool_DefaultOptions_java

    Running test 'jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java'
    Passed: sanity/client/SwingSet/src/SwingSet2DemoTest.java
    Test results: passed: 1
    Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sanity_client_SwingSet_src_SwingSet2DemoTest_java\html\report.html
    Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sanity_client_SwingSet_src_SwingSet2DemoTest_java
    Finished running test 'jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java'
    Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sanity_client_SwingSet_src_SwingSet2DemoTest_java

    Running test 'jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java'
    Passed: sanity/client/SwingSet/src/ColorChooserDemoTest.java
    Test results: passed: 1
    Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sanity_client_SwingSet_src_ColorChooserDemoTest_java\html\report.html
    Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sanity_client_SwingSet_src_ColorChooserDemoTest_java
    Finished running test 'jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java'
    Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sanity_client_SwingSet_src_ColorChooserDemoTest_java

    ==============================
    Test summary
    ==============================
       TEST                                              TOTAL  PASS  FAIL ERROR
       jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java
                                                             1     1     0     0
       jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java
                                                             1     1     0     0
       jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java
                                                             1     1     0     0
       jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java
                                                             1     1     0     0
    ==============================
    TEST SUCCESS

    Finished building target 'test' in configuration 'windows-x86_64-server-release'

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

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

From github.com+741251+turbanoff at openjdk.java.net  Sat Feb 13 10:59:38 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Sat, 13 Feb 2021 10:59:38 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v8]
In-Reply-To: <h1cjvuqNbm9Chz7atbi8daeCmDWgzzAKdFoHdgngjR8=.543211a7-9513-4d5f-8f45-9b0d300cdf00@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <KcO_olP0uhrkPxSvala6b0MN3zsFy0_Skl06Oq6Gla0=.398341c8-a9c6-4186-ab43-df19bec9d544@github.com>
 <cONOB0wrdWjjltXXAuaH_SYz_ay7AgllB3SN64c8K_I=.d711bc68-c800-45fd-9de5-5bd1c5621430@github.com>
 <SNPiblXpzCPdmntADzdMMqFCO6eSjKOltzwD5MWnipc=.814578a6-ea9b-40b1-bfd8-199324b7281e@github.com>
 <_uFXfNAzlG3COOLDN_bJBEH4n0xtk52RH4jgW0MYF_w=.358107f1-fa87-4b5a-8ded-08248080678f@github.com>
 <JzpZmZbaq1b-bBgth2Wq1YTVQKpP3DbToT4h8N7ofTE=.4490859d-21a1-4cc9-8e8c-a8d067c82989@github.com>
 <y0ZtJNDhwp3A2Jzsszmio6fg0sGSxvk49eZw2cR_kss=.16bf1d32-b7df-4b5b-a3cc-fd8b2d0bebbe@github.com>
 <9ueMq5ar7LfXsQ5hV2wMnVVethu_2kyzuelDPv_8tfk=.b40c37bb-604e-478f-bc01-428694f0d4c9@github.com>
 <KctKgE0hs5s-qmGmNe_tJwW5C-IrvK5i72mO06GZ3v4=.f48f8a2d-a4a9-4074-9350-7cd443f73373@github.com>
 <hGiSvYyNa6D0BuKfIh-3CkelapBMNrFaQ_prF3xzPQQ=.64336055-18e5-4428-bc5b-40d484ed18ba@github.com>
 <ADR73RPzLPNb5SY61wNVAQNB0JdNFrXgwms
 dteeicVU=.1c5f04db-c639-4028-b472-c56999c4746c@github.com>
 <h1cjvuqNbm9Chz7atbi8daeCmDWgzzAKdFoHdgngjR8=.543211a7-9513-4d5f-8f45-9b0d300cdf00@github.com>
Message-ID: <emFkGJxXluWeFGg6QcYXtftGN-MGDOgEAcZu-mKF9Lk=.38224ed4-2847-4947-bed4-09d3e437d58b@github.com>

On Sat, 13 Feb 2021 10:20:29 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> ## tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java
>> 
>>     make test TEST="jtreg:tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java"
>> 
>>     STDOUT:
>>     [00:56:54.598] Parsing [--jpt-run=jdk.jpackage.tests.UnicodeArgsTest]...
>>     [00:56:54.650] jdk.jpackage.tests.UnicodeArgsTest.test8246042 -> [public void jdk.jpackage.tests.UnicodeArgsTest.test8246042(boolean)]
>>     [00:56:54.682] Create: UnicodeArgsTest.test8246042(true)
>>     [00:56:54.684] Create: UnicodeArgsTest.test8246042(false)
>>     [00:56:54.688] [ RUN      ] UnicodeArgsTest.test8246042(false)
>>     [00:56:54.693] TRACE: Test string code points: [0x00e9]
>>     [00:56:54.875] TRACE: exec: Execute tool provider [javac -d .\test8246042.9782d070\jar-workdir F:\Projects\official_openjdk\test\jdk\tools\jpackage\apps\image\Hello.java](4)...
>>     [00:56:55.996] TRACE: exec: Done. Exit code: 0
>>     [00:56:55.997] TRACE: assertEquals(0): Check command tool provider [javac -d .\test8246042.9782d070\jar-workdir F:\Projects\official_openjdk\test\jdk\tools\jpackage\apps\image\Hello.java](4) exited with 0 code
>>     [00:56:56.014] TRACE: exec: Execute tool provider [jar -c -f .\test8246042.9782d070\input\hello.jar -C .\test8246042.9782d070\jar-workdir .](7)...
>>     [00:56:56.188] TRACE: exec: Done. Exit code: 0
>>     [00:56:56.188] TRACE: assertEquals(0): Check command tool provider [jar -c -f .\test8246042.9782d070\input\hello.jar -C .\test8246042.9782d070\jar-workdir .](7) exited with 0 code
>>     [00:56:56.196] TRACE: exec: Execute tool provider [jpackage --input .\test8246042.9782d070\input --dest .\test8246042.9782d070\output --name 8246042UnicodeArgsTest --type app-image --main-jar hello.jar --main-class Hello --win-console --arguments ? --verbose](17)...
>>     [00:56:56.225] Creating app package: 8246042UnicodeArgsTest in F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.9782d070\output
>>     [00:57:07.680] Command:
>>         jlink --output .\test8246042.9782d070\output\8246042UnicodeArgsTest\runtime --module-path f:\\projects\\official_openjdk\\build\\windows-x86_64-server-release\\images\\jdk\\jmods --add-modules jdk.management.jfr,java.rmi,jdk.jdi,jdk.charsets,java.xml,jdk.xml.dom,java.datatransfer,jdk.jstatd,jdk.httpserver,java.desktop,java.security.sasl,jdk.zipfs,java.base,jdk.crypto.ec,jdk.javadoc,jdk.management.agent,jdk.jshell,jdk.editpad,java.sql.rowset,jdk.jsobject,jdk.sctp,java.smartcardio,jdk.jlink,jdk.unsupported,java.security.jgss,java.compiler,jdk.nio.mapmode,jdk.dynalink,jdk.unsupported.desktop,jdk.accessibility,jdk.security.jgss,java.sql,jdk.incubator.vector,java.xml.crypto,java.logging,java.transaction.xa,jdk.jfr,jdk.crypto.cryptoki,jdk.net,java.naming,jdk.internal.ed,java.prefs,java.net.http,jdk.compiler,jdk.naming.rmi,jdk.internal.opt,jdk.jconsole,jdk.attach,jdk.crypto.mscapi,jdk.internal.le,java.management,jdk.jdwp.agent,jdk.internal.jvmstat,jdk.incubator.foreign,java.instr
 ument,jdk.management,jdk.security.auth,java.scripting,jdk.jdeps,jdk.jartool,java.management.rmi,jdk.jpackage,jdk.naming.dns,jdk.localedata --strip-native-commands --strip-debug --no-man-pages --no-header-files
>>     [00:57:07.680] Output:
>>         WARNING: Using incubator modules: jdk.incubator.vector, jdk.incubator.foreign
>> 
>>     [00:57:07.681] Returned: 0
>> 
>>     [00:57:07.685] Using default package resource java48.ico [icon] (add 8246042UnicodeArgsTest.ico to the resource-dir to customize).
>>     [00:57:07.707] Warning: Windows Defender may prevent jpackage from functioning. If there is an issue, it can be addressed by either disabling realtime monitoring, or adding an exclusion for the directory "f:\projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\tmp\jdk.jpackage16485063537873697224".
>>     [00:57:07.712] Using default package resource WinLauncher.template [Template for creating executable properties file] (add 8246042UnicodeArgsTest.properties to the resource-dir to customize).
>>     [00:57:07.746] Succeeded in building Windows Application Image package
>>     [00:57:07.748] TRACE: exec: Done. Exit code: 0
>>     [00:57:07.748] TRACE: assertEquals(0): Check command tool provider [jpackage --input .\test8246042.9782d070\input --dest .\test8246042.9782d070\output --name 8246042UnicodeArgsTest --type app-image --main-jar hello.jar --main-class Hello --win-console --arguments ? --verbose](17) exited with 0 code
>>     [00:57:07.766] TRACE: assertStringListEquals(): Check there is only one file with [.jpackage.xml] name in the package
>>     [00:57:07.768] TRACE: assertStringListEquals(1, .\test8246042.9782d070\output\8246042UnicodeArgsTest\app.jpackage.xml)
>>     [00:57:07.769] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\runtime] path exists
>>     [00:57:07.769] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\runtime] is a directory
>>     [00:57:07.770] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] path exists
>>     [00:57:07.770] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] is a file
>>     [00:57:07.770] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] file is executable
>>     [00:57:07.771] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\app\8246042UnicodeArgsTest.cfg] path exists
>>     [00:57:07.771] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\app\8246042UnicodeArgsTest.cfg] is a file
>>     [00:57:07.780] TRACE: Clearing PATH in environment
>>     [00:57:07.780] TRACE: exec: Execute [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.9782d070\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe](1); inherit I/O; in directory [.\test8246042.9782d070]...
>>     hello: Environment supports a display
>>     hello: Environment supports a desktop
>>     [0x0065]
>>     jpackage test application
>>     args.length: 1
>>     e
>>     hello: Output file: [appOutput.txt]
>>     [00:57:09.302] TRACE: exec: Done. Exit code: 0
>>     [00:57:09.302] TRACE: assertEquals(0): Check command [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.9782d070\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe](1) exited with 0 code
>>     [00:57:09.303] TRACE: assertTrue(): Check [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.9782d070\appOutput.txt] path exists
>>     [00:57:09.303] TRACE: assertTrue(): Check [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.9782d070\appOutput.txt] is a file
>>     [00:57:09.305] TRACE: assertStringListEquals(): Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.9782d070\appOutput.txt] file
>>     [00:57:09.305] TRACE: assertStringListEquals(1, jpackage test application)
>>     [00:57:09.306] TRACE: assertStringListEquals(2, args.length: 1)
>>     [00:57:09.307] ERROR: (3) Expected [?]. Actual [e]: Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.9782d070\appOutput.txt] file
>>     [00:57:09.308] [  FAILED  ] UnicodeArgsTest.test8246042(false); checks=15
>>     [00:57:09.310] [ RUN      ] UnicodeArgsTest.test8246042(true)
>>     [00:57:09.312] TRACE: Test string code points: [0x00e9]
>>     [00:57:09.314] TRACE: exec: Execute tool provider [javac -d .\test8246042.b31bae11\jar-workdir F:\Projects\official_openjdk\test\jdk\tools\jpackage\apps\image\Hello.java](4)...
>>     [00:57:09.658] TRACE: exec: Done. Exit code: 0
>>     [00:57:09.659] TRACE: assertEquals(0): Check command tool provider [javac -d .\test8246042.b31bae11\jar-workdir F:\Projects\official_openjdk\test\jdk\tools\jpackage\apps\image\Hello.java](4) exited with 0 code
>>     [00:57:09.661] TRACE: exec: Execute tool provider [jar -c -f .\test8246042.b31bae11\input\hello.jar -C .\test8246042.b31bae11\jar-workdir .](7)...
>>     [00:57:09.667] TRACE: exec: Done. Exit code: 0
>>     [00:57:09.667] TRACE: assertEquals(0): Check command tool provider [jar -c -f .\test8246042.b31bae11\input\hello.jar -C .\test8246042.b31bae11\jar-workdir .](7) exited with 0 code
>>     [00:57:09.670] TRACE: exec: Execute tool provider [jpackage --input .\test8246042.b31bae11\input --dest .\test8246042.b31bae11\output --name 8246042UnicodeArgsTest --type app-image --main-jar hello.jar --main-class Hello --win-console --verbose](15)...
>>     [00:57:09.670]
>>     jpackage argument list:
>>     [--input, .\test8246042.b31bae11\input, --dest, .\test8246042.b31bae11\output, --name, 8246042UnicodeArgsTest, --type, app-image, --main-jar, hello.jar, --main-class, Hello, --win-console, --verbose]
>> 
>>     [00:57:09.679] Creating app package: 8246042UnicodeArgsTest in F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.b31bae11\output
>>     [00:57:18.770] Command:
>>         jlink --output .\test8246042.b31bae11\output\8246042UnicodeArgsTest\runtime --module-path f:\\projects\\official_openjdk\\build\\windows-x86_64-server-release\\images\\jdk\\jmods --add-modules jdk.management.jfr,java.rmi,jdk.jdi,jdk.charsets,jdk.xml.dom,java.xml,java.datatransfer,jdk.jstatd,jdk.httpserver,java.desktop,java.security.sasl,jdk.zipfs,java.base,jdk.crypto.ec,jdk.javadoc,jdk.management.agent,jdk.jshell,jdk.editpad,jdk.sctp,jdk.jsobject,java.sql.rowset,jdk.jlink,java.smartcardio,jdk.unsupported,java.security.jgss,java.compiler,jdk.nio.mapmode,jdk.dynalink,jdk.unsupported.desktop,jdk.accessibility,jdk.security.jgss,java.sql,jdk.incubator.vector,java.xml.crypto,java.logging,java.transaction.xa,jdk.jfr,jdk.crypto.cryptoki,jdk.net,java.naming,jdk.internal.ed,java.prefs,java.net.http,jdk.compiler,jdk.internal.opt,jdk.naming.rmi,jdk.jconsole,jdk.attach,jdk.crypto.mscapi,jdk.internal.le,java.management,jdk.jdwp.agent,jdk.incubator.foreign,jdk.internal.jvmstat,java.instr
 ument,jdk.management,jdk.security.auth,java.scripting,jdk.jdeps,jdk.jartool,jdk.jpackage,java.management.rmi,jdk.naming.dns,jdk.localedata --strip-native-commands --strip-debug --no-man-pages --no-header-files
>>     [00:57:18.770] Output:
>>         WARNING: Using incubator modules: jdk.incubator.vector, jdk.incubator.foreign
>> 
>>     [00:57:18.770] Returned: 0
>> 
>>     [00:57:18.771] Using default package resource java48.ico [icon] (add 8246042UnicodeArgsTest.ico to the resource-dir to customize).
>>     [00:57:18.778] Warning: Windows Defender may prevent jpackage from functioning. If there is an issue, it can be addressed by either disabling realtime monitoring, or adding an exclusion for the directory "f:\projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\tmp\jdk.jpackage8738450931736312275".
>>     [00:57:18.779] Using default package resource WinLauncher.template [Template for creating executable properties file] (add 8246042UnicodeArgsTest.properties to the resource-dir to customize).
>>     [00:57:18.787] Succeeded in building Windows Application Image package
>>     [00:57:18.788] TRACE: exec: Done. Exit code: 0
>>     [00:57:18.789] TRACE: assertEquals(0): Check command tool provider [jpackage --input .\test8246042.b31bae11\input --dest .\test8246042.b31bae11\output --name 8246042UnicodeArgsTest --type app-image --main-jar hello.jar --main-class Hello --win-console --verbose](15) exited with 0 code
>>     [00:57:18.804] TRACE: assertStringListEquals(): Check there is only one file with [.jpackage.xml] name in the package
>>     [00:57:18.804] TRACE: assertStringListEquals(1, .\test8246042.b31bae11\output\8246042UnicodeArgsTest\app.jpackage.xml)
>>     [00:57:18.805] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\runtime] path exists
>>     [00:57:18.805] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\runtime] is a directory
>>     [00:57:18.806] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] path exists
>>     [00:57:18.806] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] is a file
>>     [00:57:18.806] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] file is executable
>>     [00:57:18.807] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\app\8246042UnicodeArgsTest.cfg] path exists
>>     [00:57:18.807] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\app\8246042UnicodeArgsTest.cfg] is a file
>>     [00:57:18.808] TRACE: Clearing PATH in environment
>>     [00:57:18.808] TRACE: exec: Execute [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.b31bae11\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe ?](2); inherit I/O; in directory [.\test8246042.b31bae11]...
>>     hello: Environment supports a display
>>     hello: Environment supports a desktop
>>     [0x0065]
>>     jpackage test application
>>     args.length: 1
>>     e
>>     hello: Output file: [appOutput.txt]
>>     [00:57:20.327] TRACE: exec: Done. Exit code: 0
>>     [00:57:20.328] TRACE: assertEquals(0): Check command [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.b31bae11\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe ?](2) exited with 0 code
>>     [00:57:20.328] TRACE: assertTrue(): Check [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.b31bae11\appOutput.txt] path exists
>>     [00:57:20.329] TRACE: assertTrue(): Check [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.b31bae11\appOutput.txt] is a file
>>     [00:57:20.330] TRACE: assertStringListEquals(): Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.b31bae11\appOutput.txt] file
>>     [00:57:20.330] TRACE: assertStringListEquals(1, jpackage test application)
>>     [00:57:20.330] TRACE: assertStringListEquals(2, args.length: 1)
>>     [00:57:20.330] ERROR: (3) Expected [?]. Actual [e]: Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.b31bae11\appOutput.txt] file
>>     [00:57:20.331] [  FAILED  ] UnicodeArgsTest.test8246042(true); checks=15
>>     [00:57:20.332] [==========] 2 tests ran
>>     [00:57:20.333] [  PASSED  ] 0 tests
>>     [00:57:20.334] [  FAILED  ] 2 tests, listed below
>>     [00:57:20.335] [  FAILED  ] UnicodeArgsTest.test8246042(false); workDir=[.\test8246042.9782d070]
>>     [00:57:20.335] [  FAILED  ] UnicodeArgsTest.test8246042(true); workDir=[.\test8246042.b31bae11]
>>     [00:57:20.336] 2 FAILED TESTS
>>     STDERR:
>>     java.lang.AssertionError: (3) Expected [?]. Actual [e]: Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.9782d070\appOutput.txt] file
>>             at jdk.jpackage.test.TKit.error(TKit.java:293)
>>             at jdk.jpackage.test.TKit.lambda$assertStringListEquals$20(TKit.java:765)
>>             at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
>>             at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179)
>>             at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625)
>>             at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
>>             at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
>>             at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
>>             at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
>>             at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
>>             at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:596)
>>             at jdk.jpackage.test.TKit.assertStringListEquals(TKit.java:759)
>>             at jdk.jpackage.test.HelloApp.verifyOutputFile(HelloApp.java:225)
>>             at jdk.jpackage.test.HelloApp.verifyOutputFile(HelloApp.java:204)
>>             at jdk.jpackage.test.HelloApp$AppOutputVerifier.executeAndVerifyOutput(HelloApp.java:405)
>>             at jdk.jpackage.test.HelloApp$AppOutputVerifier.executeAndVerifyOutput(HelloApp.java:417)
>>             at jdk.jpackage.test.HelloApp.executeLauncherAndVerifyOutput(HelloApp.java:319)
>>             at jdk.jpackage.tests.UnicodeArgsTest.test8246042(UnicodeArgsTest.java:67)
>>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>>             at jdk.jpackage.test.MethodCall.accept(MethodCall.java:145)
>>             at jdk.jpackage.test.TestInstance.run(TestInstance.java:230)
>>             at jdk.jpackage.test.TKit.lambda$ignoreExceptions$6(TKit.java:155)
>>             at jdk.jpackage.test.TKit.lambda$runTests$4(TKit.java:140)
>>             at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625)
>>             at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:762)
>>             at jdk.jpackage.test.TKit.lambda$runTests$5(TKit.java:137)
>>             at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105)
>>             at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:123)
>>             at jdk.jpackage.test.TKit.runTests(TKit.java:136)
>>             at jdk.jpackage.test.Main.runTests(Main.java:79)
>>             at jdk.jpackage.test.Main.lambda$main$2(Main.java:75)
>>             at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105)
>>             at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:123)
>>             at jdk.jpackage.test.Main.main(Main.java:75)
>>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>>             at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>>             at java.base/java.lang.Thread.run(Thread.java:831)
>>     java.lang.AssertionError: (3) Expected [?]. Actual [e]: Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.b31bae11\appOutput.txt] file
>>             at jdk.jpackage.test.TKit.error(TKit.java:293)
>>             at jdk.jpackage.test.TKit.lambda$assertStringListEquals$20(TKit.java:765)
>>             at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
>>             at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179)
>>             at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625)
>>             at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
>>             at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
>>             at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
>>             at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
>>             at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
>>             at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:596)
>>             at jdk.jpackage.test.TKit.assertStringListEquals(TKit.java:759)
>>             at jdk.jpackage.test.HelloApp.verifyOutputFile(HelloApp.java:225)
>>             at jdk.jpackage.test.HelloApp.verifyOutputFile(HelloApp.java:204)
>>             at jdk.jpackage.test.HelloApp$AppOutputVerifier.executeAndVerifyOutput(HelloApp.java:405)
>>             at jdk.jpackage.test.HelloApp$AppOutputVerifier.executeAndVerifyOutput(HelloApp.java:417)
>>             at jdk.jpackage.test.HelloApp.executeLauncherAndVerifyOutput(HelloApp.java:319)
>>             at jdk.jpackage.tests.UnicodeArgsTest.test8246042(UnicodeArgsTest.java:65)
>>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>>             at jdk.jpackage.test.MethodCall.accept(MethodCall.java:145)
>>             at jdk.jpackage.test.TestInstance.run(TestInstance.java:230)
>>             at jdk.jpackage.test.TKit.lambda$ignoreExceptions$6(TKit.java:155)
>>             at jdk.jpackage.test.TKit.lambda$runTests$4(TKit.java:140)
>>             at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625)
>>             at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:762)
>>             at jdk.jpackage.test.TKit.lambda$runTests$5(TKit.java:137)
>>             at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105)
>>             at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:123)
>>             at jdk.jpackage.test.TKit.runTests(TKit.java:136)
>>             at jdk.jpackage.test.Main.runTests(Main.java:79)
>>             at jdk.jpackage.test.Main.lambda$main$2(Main.java:75)
>>             at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105)
>>             at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:123)
>>             at jdk.jpackage.test.Main.main(Main.java:75)
>>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>>             at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>>             at java.base/java.lang.Thread.run(Thread.java:831)
>>     jdk.jpackage.test.Functional$ExceptionBox: java.lang.RuntimeException: 2 FAILED TESTS
>>             at jdk.jpackage.test.Functional.rethrowUnchecked(Functional.java:161)
>>             at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:107)
>>             at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:123)
>>             at jdk.jpackage.test.Main.main(Main.java:75)
>>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>>             at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>>             at java.base/java.lang.Thread.run(Thread.java:831)
>>     Caused by: java.lang.RuntimeException: 2 FAILED TESTS
>>             at jdk.jpackage.test.Main.reportSummary(Main.java:130)
>>             at jdk.jpackage.test.Main.runTests(Main.java:90)
>>             at jdk.jpackage.test.Main.lambda$main$2(Main.java:75)
>>             at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105)
>>             ... 8 more
>> 
>>     JavaTest Message: Test threw exception: jdk.jpackage.test.Functional$ExceptionBox: java.lang.RuntimeException: 2 FAILED TESTS
>>     JavaTest Message: shutting down test
>> 
>>     STATUS:Failed.`main' threw exception: jdk.jpackage.test.Functional$ExceptionBox: java.lang.RuntimeException: 2 FAILED TESTS
>> 
>> Oh. This one is tricky. Will investigate later.
>
> This fours tests pass without problems, when I run them separately.
> 
> ## sun/security/tools/jarsigner/TimestampCheck.java
> ## sun/security/tools/keytool/DefaultOptions.java
> ## sanity/client/SwingSet/src/ColorChooserDemoTest.java
> ## sanity/client/SwingSet/src/SwingSet2DemoTest.java
> 
>     make test TEST="jtreg:sun/security/tools/jarsigner/TimestampCheck.java sun/security/tools/keytool/DefaultOptions.java sanity/client/SwingSet/src/SwingSet2DemoTest.java sanity/client/SwingSet/src/ColorChooserDemoTest.java"
>     
>     Building target 'test' in configuration 'windows-x86_64-server-release'
>     Test selection 'jtreg:sun/security/tools/jarsigner/TimestampCheck.java sun/security/tools/keytool/DefaultOptions.java sanity/client/SwingSet/src/SwingSet2DemoTest.java sanity/client/SwingSet/src/ColorChooserDemoTest.java', will run:
>     * jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java
>     * jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java
>     * jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java
>     * jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java
> 
>     Running test 'jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java'
>     Passed: sun/security/tools/jarsigner/TimestampCheck.java
>     Test results: passed: 1
>     Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sun_security_tools_jarsigner_TimestampCheck_java\html\report.html
>     Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sun_security_tools_jarsigner_TimestampCheck_java
>     Finished running test 'jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java'
>     Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sun_security_tools_jarsigner_TimestampCheck_java
> 
>     Running test 'jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java'
>     Passed: sun/security/tools/keytool/DefaultOptions.java
>     Test results: passed: 1
>     Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sun_security_tools_keytool_DefaultOptions_java\html\report.html
>     Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sun_security_tools_keytool_DefaultOptions_java
>     Finished running test 'jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java'
>     Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sun_security_tools_keytool_DefaultOptions_java
> 
>     Running test 'jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java'
>     Passed: sanity/client/SwingSet/src/SwingSet2DemoTest.java
>     Test results: passed: 1
>     Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sanity_client_SwingSet_src_SwingSet2DemoTest_java\html\report.html
>     Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sanity_client_SwingSet_src_SwingSet2DemoTest_java
>     Finished running test 'jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java'
>     Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sanity_client_SwingSet_src_SwingSet2DemoTest_java
> 
>     Running test 'jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java'
>     Passed: sanity/client/SwingSet/src/ColorChooserDemoTest.java
>     Test results: passed: 1
>     Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sanity_client_SwingSet_src_ColorChooserDemoTest_java\html\report.html
>     Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sanity_client_SwingSet_src_ColorChooserDemoTest_java
>     Finished running test 'jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java'
>     Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sanity_client_SwingSet_src_ColorChooserDemoTest_java
> 
>     ==============================
>     Test summary
>     ==============================
>        TEST                                              TOTAL  PASS  FAIL ERROR
>        jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java
>                                                              1     1     0     0
>        jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java
>                                                              1     1     0     0
>        jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java
>                                                              1     1     0     0
>        jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java
>                                                              1     1     0     0
>     ==============================
>     TEST SUCCESS
> 
>     Finished building target 'test' in configuration 'windows-x86_64-server-release'

## jdk/jshell/ToolBasicTest.java
    
    make test TEST="jtreg:jdk/jshell/ToolBasicTest.java"

    STDOUT:
    [TestNG] Running:
      jdk/jshell/ToolBasicTest.java

    config ReplToolTesting.setUp(): success
    test ToolBasicTest.elideStartUpFromList(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.elideStartUpFromSave(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.test8142447(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testAddExports(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testBadClasspath(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testBadModulePath(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testBadSourceJarClasspath(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testClasspathDirectory(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testClasspathJar(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testClasspathUserHomeExpansion(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testConstrainedUpdates(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testCtrlD(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testEnvInStartUp(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testFeedbackNegative(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testFeedbackNormal(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testFeedbackSilent(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testHistoryReference(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testIndent(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testInterrupt(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testLoadingFromArgs(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testModulePath(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testModulePathUserHomeExpansion(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testOpen(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testOpenFileOverHttp(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testOpenLocalFileUrl(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testOpenResource(): failure
    java.lang.AssertionError: user output: printf("%4.2f", Math.PI).
     expected [3.14] but found [3,14]
            at org.testng.Assert.fail(Assert.java:94)
            at org.testng.Assert.failNotEquals(Assert.java:496)
            at org.testng.Assert.assertEquals(Assert.java:125)
            at org.testng.Assert.assertEquals(Assert.java:178)
            at ReplToolTesting.assertOutput(ReplToolTesting.java:529)
            at ReplToolTesting.assertCommand(ReplToolTesting.java:513)
            at ToolBasicTest.lambda$testOpenResource$118(ToolBasicTest.java:559)
            at ReplToolTesting$PromptedCommandOutputStream.write(ReplToolTesting.java:824)
            at java.base/java.io.PrintStream.write(PrintStream.java:536)
            at jdk.internal.le/jdk.internal.org.jline.terminal.impl.LineDisciplineTerminal.processOutputByte(LineDisciplineTerminal.java:253)
            at jdk.internal.le/jdk.internal.org.jline.terminal.impl.LineDisciplineTerminal$FilteringOutputStream.write(LineDisciplineTerminal.java:294)
            at java.base/sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:242)
            at java.base/sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:321)
            at java.base/sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:325)
            at java.base/sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:159)
            at java.base/java.io.OutputStreamWriter.flush(OutputStreamWriter.java:248)
            at java.base/java.io.PrintWriter.flush(PrintWriter.java:396)
            at jdk.internal.le/jdk.internal.org.jline.terminal.impl.AbstractTerminal.flush(AbstractTerminal.java:174)
            at jdk.internal.le/jdk.internal.org.jline.utils.Display.update(Display.java:336)
            at jdk.internal.le/jdk.internal.org.jline.reader.impl.LineReaderImpl.redisplay(LineReaderImpl.java:3943)
            at jdk.internal.le/jdk.internal.org.jline.reader.impl.LineReaderImpl.redisplay(LineReaderImpl.java:3803)
            at jdk.internal.le/jdk.internal.org.jline.reader.impl.LineReaderImpl.readLine(LineReaderImpl.java:626)
            at jdk.internal.le/jdk.internal.org.jline.reader.impl.LineReaderImpl.readLine(LineReaderImpl.java:454)
            at jdk.jshell/jdk.internal.jshell.tool.ConsoleIOContext.readLine(ConsoleIOContext.java:233)
            at jdk.jshell/jdk.internal.jshell.tool.JShellTool.getInput(JShellTool.java:1263)
            at jdk.jshell/jdk.internal.jshell.tool.JShellTool.run(JShellTool.java:1199)
            at jdk.jshell/jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:991)
            at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder.run(JShellToolBuilder.java:240)
            at ReplToolTesting.testRawRun(ReplToolTesting.java:313)
            at ReplToolTesting.testRaw(ReplToolTesting.java:296)
            at ReplToolTesting.test(ReplToolTesting.java:249)
            at ReplToolTesting.test(ReplToolTesting.java:233)
            at ReplToolTesting.test(ReplToolTesting.java:229)
            at ReplToolTesting.test(ReplToolTesting.java:225)
            at ToolBasicTest.testOpenResource(ToolBasicTest.java:555)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
            at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
            at java.base/java.lang.reflect.Method.invoke(Method.java:566)
            at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85)
            at org.testng.internal.Invoker.invokeMethod(Invoker.java:639)
            at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:821)
            at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1131)
            at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
            at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108)
            at org.testng.TestRunner.privateRun(TestRunner.java:773)
            at org.testng.TestRunner.run(TestRunner.java:623)
            at org.testng.SuiteRunner.runTest(SuiteRunner.java:357)
            at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:352)
            at org.testng.SuiteRunner.privateRun(SuiteRunner.java:310)
            at org.testng.SuiteRunner.run(SuiteRunner.java:259)
            at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
            at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
            at org.testng.TestNG.runSuitesSequentially(TestNG.java:1185)
            at org.testng.TestNG.runSuitesLocally(TestNG.java:1110)
            at org.testng.TestNG.run(TestNG.java:1018)
            at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
            at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
            at java.base/java.lang.reflect.Method.invoke(Method.java:566)
            at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
            at java.base/java.lang.Thread.run(Thread.java:831)
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testRedeclareVariableNoInit(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testRemoteExit(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testRerun(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testRerunIdRange(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testReset(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testSave(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testStartRetain(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testStartSave(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testStartupFileOption(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testStop(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testVarsWithNotActive(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testWarningUnchecked(): success

    ===============================================
    jdk/jshell/ToolBasicTest.java
    Total tests run: 38, Failures: 1, Skips: 0
    ===============================================

    STDERR:
    java.io.EOFException
            at java.base/java.io.DataInputStream.readInt(DataInputStream.java:398)
            at java.base/java.io.ObjectInputStream$BlockDataInputStream.readInt(ObjectInputStream.java:3381)
            at java.base/java.io.ObjectInputStream.readInt(ObjectInputStream.java:1113)
            at jdk.jshell/jdk.jshell.execution.StreamingExecutionControl.readAndReportExecutionResult(StreamingExecutionControl.java:277)
            at jdk.jshell/jdk.jshell.execution.StreamingExecutionControl.invoke(StreamingExecutionControl.java:99)
            at jdk.jshell/jdk.jshell.execution.JdiDefaultExecutionControl.invoke(JdiDefaultExecutionControl.java:160)
            at jdk.jshell/jdk.jshell.Eval.declare(Eval.java:943)
            at jdk.jshell/jdk.jshell.Eval.eval(Eval.java:139)
            at jdk.jshell/jdk.jshell.JShell.eval(JShell.java:493)
            at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processSource(JShellTool.java:3609)
            at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processSourceCatchingReset(JShellTool.java:1330)
            at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processInput(JShellTool.java:1228)
            at jdk.jshell/jdk.internal.jshell.tool.JShellTool.run(JShellTool.java:1201)
            at jdk.jshell/jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:991)
            at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder.run(JShellToolBuilder.java:240)
            at ReplToolTesting.testRawRun(ReplToolTesting.java:313)
            at ReplToolTesting.testRaw(ReplToolTesting.java:296)
            at ReplToolTesting.test(ReplToolTesting.java:249)
            at ReplToolTesting.test(ReplToolTesting.java:233)
            at ReplToolTesting.test(ReplToolTesting.java:229)
            at ReplToolTesting.test(ReplToolTesting.java:225)
            at ToolBasicTest.testRemoteExit(ToolBasicTest.java:680)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
            at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
            at java.base/java.lang.reflect.Method.invoke(Method.java:566)
            at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85)
            at org.testng.internal.Invoker.invokeMethod(Invoker.java:639)
            at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:821)
            at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1131)
            at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
            at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108)
            at org.testng.TestRunner.privateRun(TestRunner.java:773)
            at org.testng.TestRunner.run(TestRunner.java:623)
            at org.testng.SuiteRunner.runTest(SuiteRunner.java:357)
            at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:352)
            at org.testng.SuiteRunner.privateRun(SuiteRunner.java:310)
            at org.testng.SuiteRunner.run(SuiteRunner.java:259)
            at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
            at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
            at org.testng.TestNG.runSuitesSequentially(TestNG.java:1185)
            at org.testng.TestNG.runSuitesLocally(TestNG.java:1110)
            at org.testng.TestNG.run(TestNG.java:1018)
            at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
            at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
            at java.base/java.lang.reflect.Method.invoke(Method.java:566)
            at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
            at java.base/java.lang.Thread.run(Thread.java:831)
    java.lang.Exception: failures: 1
            at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:96)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
            at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
            at java.base/java.lang.reflect.Method.invoke(Method.java:566)
            at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
            at java.base/java.lang.Thread.run(Thread.java:831)

    JavaTest Message: Test threw exception: java.lang.Exception
    JavaTest Message: shutting down test


    TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 1

https://bugs.openjdk.java.net/browse/JDK-8212234 looks like there is already known bug this test.

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

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

From dcubed at openjdk.java.net  Sat Feb 13 15:16:37 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sat, 13 Feb 2021 15:16:37 GMT
Subject: RFR: 8241403: JavaThread::get_thread_name() should be
 ThreadSMR-aware
In-Reply-To: <u85rI973YRBpkQJWidXqQ3xk3MeZzSvotZvD594jUsI=.97a1db27-db13-4a44-a13f-f6cba026ff1b@github.com>
References: <wRdcRQurtpybntK9Qpji-6zVY-EcHKw3q87xpD0eoS4=.a6dc32f4-2919-42e9-80c3-5a264067f0e2@github.com>
 <Uke4223ee6tPQRFdiMkUsIF7oRrz6bm4LMk1FpnmR-k=.190befb3-4d2b-44cf-81c7-2f2d147bd784@github.com>
 <AlPMnCZ8HBODRqVtHHXpUZKwO-yoAI724D0qNz3H4Qk=.ea8de8e2-dcfb-42c6-83a6-bc0626ed2fec@github.com>
 <JB_2ExyxLfCaR-W0ejdB6EMpSXORpKtIBE8PhkN_rGM=.7bd6fda1-6149-4f93-85a1-64e1981dd5c7@github.com>
 <u85rI973YRBpkQJWidXqQ3xk3MeZzSvotZvD594jUsI=.97a1db27-db13-4a44-a13f-f6cba026ff1b@github.com>
Message-ID: <EUsIqjFQas0pSRZ5Bj6Pz-4ZUC-cqrKThA6pzc9YSRE=.eaded8c2-9ddd-4051-9c93-4e867b248e44@github.com>

On Sat, 13 Feb 2021 04:30:48 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> So Thread::is_JavaThread_protected() should be "protected" then, not public.
>> yes, I was suggesting adding a default last parameter like
>>     JavaThread::get_thread_name(char* default = Thread::name());
>> and pass "<NOT_FILLED_IN\>" from JVMTI. Then JVMTI doesn't have to be a friend and have more visibility to the JavaThread class than it should have.
>
> Ahhh.... I think I finally understand what you mean...
> I'll look in the AM after I've had some coffee... :-)

The name "default" is reserved so I went with "def_name".
You can't call Thread::name() from the declaration:
./open/src/hotspot/share/runtime/thread.hpp:1690:62: error: call to non-static member function without an object argument
  const char* get_thread_name(const char* def_name = Thread::name()) const;
                                                     ~~~~~~~~^~~~
so I went with setting `def_name = NULL` in the declaration and decoding that state in get_thread_name():
` return (def_name != NULL) ? def_name : Thread::name();`

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

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

From coleenp at openjdk.java.net  Sat Feb 13 15:30:40 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Sat, 13 Feb 2021 15:30:40 GMT
Subject: RFR: 8241403: JavaThread::get_thread_name() should be
 ThreadSMR-aware
In-Reply-To: <EUsIqjFQas0pSRZ5Bj6Pz-4ZUC-cqrKThA6pzc9YSRE=.eaded8c2-9ddd-4051-9c93-4e867b248e44@github.com>
References: <wRdcRQurtpybntK9Qpji-6zVY-EcHKw3q87xpD0eoS4=.a6dc32f4-2919-42e9-80c3-5a264067f0e2@github.com>
 <Uke4223ee6tPQRFdiMkUsIF7oRrz6bm4LMk1FpnmR-k=.190befb3-4d2b-44cf-81c7-2f2d147bd784@github.com>
 <AlPMnCZ8HBODRqVtHHXpUZKwO-yoAI724D0qNz3H4Qk=.ea8de8e2-dcfb-42c6-83a6-bc0626ed2fec@github.com>
 <JB_2ExyxLfCaR-W0ejdB6EMpSXORpKtIBE8PhkN_rGM=.7bd6fda1-6149-4f93-85a1-64e1981dd5c7@github.com>
 <u85rI973YRBpkQJWidXqQ3xk3MeZzSvotZvD594jUsI=.97a1db27-db13-4a44-a13f-f6cba026ff1b@github.com>
 <EUsIqjFQas0pSRZ5Bj6Pz-4ZUC-cqrKThA6pzc9YSRE=.eaded8c2-9ddd-4051-9c93-4e867b248e44@github.com>
Message-ID: <hWZhAOgWF5S-e79V4Ekcujvq7qXXkfn7RoTf3R2Z-ic=.e52284db-30de-4087-971d-c5aed702b4ca@github.com>

On Sat, 13 Feb 2021 15:13:44 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Ahhh.... I think I finally understand what you mean...
>> I'll look in the AM after I've had some coffee... :-)
>
> The name "default" is reserved so I went with "def_name".
> You can't call Thread::name() from the declaration:
> ./open/src/hotspot/share/runtime/thread.hpp:1690:62: error: call to non-static member function without an object argument
>   const char* get_thread_name(const char* def_name = Thread::name()) const;
>                                                      ~~~~~~~~^~~~
> so I went with setting `def_name = NULL` in the declaration and decoding that state in get_thread_name():
> ` return (def_name != NULL) ? def_name : Thread::name();`

default_name, it's not long enough to abbreviate...  but yes. thanks!

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

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

From dcubed at openjdk.java.net  Sat Feb 13 15:30:41 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sat, 13 Feb 2021 15:30:41 GMT
Subject: RFR: 8241403: JavaThread::get_thread_name() should be
 ThreadSMR-aware
In-Reply-To: <hWZhAOgWF5S-e79V4Ekcujvq7qXXkfn7RoTf3R2Z-ic=.e52284db-30de-4087-971d-c5aed702b4ca@github.com>
References: <wRdcRQurtpybntK9Qpji-6zVY-EcHKw3q87xpD0eoS4=.a6dc32f4-2919-42e9-80c3-5a264067f0e2@github.com>
 <Uke4223ee6tPQRFdiMkUsIF7oRrz6bm4LMk1FpnmR-k=.190befb3-4d2b-44cf-81c7-2f2d147bd784@github.com>
 <AlPMnCZ8HBODRqVtHHXpUZKwO-yoAI724D0qNz3H4Qk=.ea8de8e2-dcfb-42c6-83a6-bc0626ed2fec@github.com>
 <JB_2ExyxLfCaR-W0ejdB6EMpSXORpKtIBE8PhkN_rGM=.7bd6fda1-6149-4f93-85a1-64e1981dd5c7@github.com>
 <u85rI973YRBpkQJWidXqQ3xk3MeZzSvotZvD594jUsI=.97a1db27-db13-4a44-a13f-f6cba026ff1b@github.com>
 <EUsIqjFQas0pSRZ5Bj6Pz-4ZUC-cqrKThA6pzc9YSRE=.eaded8c2-9ddd-4051-9c93-4e867b248e44@github.com>
 <hWZhAOgWF5S-e79V4Ekcujvq7qXXkfn7RoTf3R2Z-ic=.e52284db-30de-4087-971d-c5aed702b4ca@github.com>
Message-ID: <brQU7T2_xzhayQLmemvJX9zjGNyS2fV8RdugpRSALlU=.6534ed80-a28f-4cd2-95fd-822954409e78@github.com>

On Sat, 13 Feb 2021 15:24:33 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The name "default" is reserved so I went with "def_name".
>> You can't call Thread::name() from the declaration:
>> ./open/src/hotspot/share/runtime/thread.hpp:1690:62: error: call to non-static member function without an object argument
>>   const char* get_thread_name(const char* def_name = Thread::name()) const;
>>                                                      ~~~~~~~~^~~~
>> so I went with setting `def_name = NULL` in the declaration and decoding that state in get_thread_name():
>> ` return (def_name != NULL) ? def_name : Thread::name();`
>
> default_name, it's not long enough to abbreviate...  but yes. thanks!

And it looks like making is_JavaThread_protected() a protected function doesn't work either since `JavaThread::get_thread_name()` can't call it:

./open/src/hotspot/share/runtime/thread.cpp:2857:15: error: 'is_JavaThread_protected' is a protected member of 'Thread'
  if (thread->is_JavaThread_protected(this)) {
              ^
./open/src/hotspot/share/runtime/thread.cpp:488:14: note: can only access this member on an object of type 'JavaThread'
bool Thread::is_JavaThread_protected(const JavaThread* p) {
             ^
1 error generated.

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

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

From dcubed at openjdk.java.net  Sat Feb 13 15:45:39 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sat, 13 Feb 2021 15:45:39 GMT
Subject: RFR: 8241403: JavaThread::get_thread_name() should be
 ThreadSMR-aware
In-Reply-To: <brQU7T2_xzhayQLmemvJX9zjGNyS2fV8RdugpRSALlU=.6534ed80-a28f-4cd2-95fd-822954409e78@github.com>
References: <wRdcRQurtpybntK9Qpji-6zVY-EcHKw3q87xpD0eoS4=.a6dc32f4-2919-42e9-80c3-5a264067f0e2@github.com>
 <Uke4223ee6tPQRFdiMkUsIF7oRrz6bm4LMk1FpnmR-k=.190befb3-4d2b-44cf-81c7-2f2d147bd784@github.com>
 <AlPMnCZ8HBODRqVtHHXpUZKwO-yoAI724D0qNz3H4Qk=.ea8de8e2-dcfb-42c6-83a6-bc0626ed2fec@github.com>
 <JB_2ExyxLfCaR-W0ejdB6EMpSXORpKtIBE8PhkN_rGM=.7bd6fda1-6149-4f93-85a1-64e1981dd5c7@github.com>
 <u85rI973YRBpkQJWidXqQ3xk3MeZzSvotZvD594jUsI=.97a1db27-db13-4a44-a13f-f6cba026ff1b@github.com>
 <EUsIqjFQas0pSRZ5Bj6Pz-4ZUC-cqrKThA6pzc9YSRE=.eaded8c2-9ddd-4051-9c93-4e867b248e44@github.com>
 <hWZhAOgWF5S-e79V4Ekcujvq7qXXkfn7RoTf3R2Z-ic=.e52284db-30de-4087-971d-c5aed702b4ca@github.com>
 <brQU7T2_xzhayQLmemvJX9zjGNyS2fV8RdugpRSALlU=.6534ed80-a28f-4cd2-95fd-822954409e78@github.com>
Message-ID: <KbdWt_86pRyMIKayliF7-NvoWufhF3FOw0RPLgMtPq0=.2e3f2904-06ca-4d15-ac87-0758db6d4f34@github.com>

On Sat, 13 Feb 2021 15:25:16 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> default_name, it's not long enough to abbreviate...  but yes. thanks!
>
> And it looks like making is_JavaThread_protected() a protected function doesn't work either since `JavaThread::get_thread_name()` can't call it:
> 
> ./open/src/hotspot/share/runtime/thread.cpp:2857:15: error: 'is_JavaThread_protected' is a protected member of 'Thread'
>   if (thread->is_JavaThread_protected(this)) {
>               ^
> ./open/src/hotspot/share/runtime/thread.cpp:488:14: note: can only access this member on an object of type 'JavaThread'
> bool Thread::is_JavaThread_protected(const JavaThread* p) {
>              ^
> 1 error generated.

`JavaThread::get_thread_name()` is calling `is_JavaThread_protected()` on the calling Thread and NOT on the `this` JavaThread so `protected` doesn't work.

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

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

From cjplummer at openjdk.java.net  Sat Feb 13 19:10:50 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Sat, 13 Feb 2021 19:10:50 GMT
Subject: RFR: 8261702: ClhsdbFindPC can fail due to PointerFinder incorrectly
 thinking an address is in a .so
Message-ID: <AFSFgu2cWGvCRDEq5jI67rk-Xwx1Xc3v2B3E81WjVJY=.3e2a4488-2e85-46b2-89f8-0da1bc349a99@github.com>

See bug description for details. The fix is simple and just a matter of moving some code to avoid incorrectly thinking an address is in a .so when it is in some other area of VM memory that occurs just after the last .so.

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

Commit messages:
 - Check if addr is in DSO last to avoid finding addr in DSO when it is not due to DSO.size() returning too large of a value.

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

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

From dcubed at openjdk.java.net  Sat Feb 13 21:53:51 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sat, 13 Feb 2021 21:53:51 GMT
Subject: RFR: 8241403: JavaThread::get_thread_name() should be
 ThreadSMR-aware [v2]
In-Reply-To: <wRdcRQurtpybntK9Qpji-6zVY-EcHKw3q87xpD0eoS4=.a6dc32f4-2919-42e9-80c3-5a264067f0e2@github.com>
References: <wRdcRQurtpybntK9Qpji-6zVY-EcHKw3q87xpD0eoS4=.a6dc32f4-2919-42e9-80c3-5a264067f0e2@github.com>
Message-ID: <UY810XwxI_xwVSwdtX4pcnH__prubKLOXJB-2fMK0n4=.154fa1e0-560f-405e-ac62-e143c9a36536@github.com>

> A minor fix to add a new function:
> 
>     bool Thread::is_JavaThread_protected(const JavaThread* p)
> 
> that returns true when the target JavaThread* is protected and false
> otherwise. Update JavaThread::get_thread_name() to create a
> ThreadsListHandle and use the new is_JavaThread_protected(). Also
> update JvmtiTrace::safe_get_thread_name() to use the new
> is_JavaThread_protected().
> 
> This fix is tested via a Mach5 Tier[1-8] run.

Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:

  Address coleenp CR0 comments.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2535/files
  - new: https://git.openjdk.java.net/jdk/pull/2535/files/185434a8..00e38868

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

  Stats: 18 lines in 3 files changed: 2 ins; 6 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2535.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2535/head:pull/2535

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

From dcubed at openjdk.java.net  Sat Feb 13 21:57:38 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sat, 13 Feb 2021 21:57:38 GMT
Subject: RFR: 8241403: JavaThread::get_thread_name() should be
 ThreadSMR-aware [v2]
In-Reply-To: <OJ-4pBj0Tz0qLPbJusUG2yKrBC1o1qWyO5spEo01P34=.9c4773da-4dc9-483b-970e-8e63b32c55e1@github.com>
References: <wRdcRQurtpybntK9Qpji-6zVY-EcHKw3q87xpD0eoS4=.a6dc32f4-2919-42e9-80c3-5a264067f0e2@github.com>
 <OJ-4pBj0Tz0qLPbJusUG2yKrBC1o1qWyO5spEo01P34=.9c4773da-4dc9-483b-970e-8e63b32c55e1@github.com>
Message-ID: <zYu2ydbnQyq81TzZaEf3LStQ-ybR2wa_SLz2u4XfKu4=.795c3409-20b9-4275-8a05-c7613601a4c7@github.com>

On Sat, 13 Feb 2021 03:36:32 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address coleenp CR0 comments.
>
> Hi Dan,
> It looks good to me modulo your your discussion with Coleen on JvmtiTrace being a friend.
> Thanks,
> Serguei

Mach5 Tier[1-8] testing on CR1 is in process:
- Mach5 Tier[1-3] - no failures
- Mach5 Tier4 - 2 unrelated, known failures - still running
- Mach5 Tier5 - 1 unrelated, known failure
- Mach5 Tier6 - no failures - still running
- Mach5 Tier7 - just started
- Mach5 Tier8 - just started

@robehn, @coleenp, @sspitsyn - please take a look when you get the chance.

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

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

From ysuenaga at openjdk.java.net  Sun Feb 14 02:49:38 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Sun, 14 Feb 2021 02:49:38 GMT
Subject: RFR: 8261702: ClhsdbFindPC can fail due to PointerFinder
 incorrectly thinking an address is in a .so
In-Reply-To: <AFSFgu2cWGvCRDEq5jI67rk-Xwx1Xc3v2B3E81WjVJY=.3e2a4488-2e85-46b2-89f8-0da1bc349a99@github.com>
References: <AFSFgu2cWGvCRDEq5jI67rk-Xwx1Xc3v2B3E81WjVJY=.3e2a4488-2e85-46b2-89f8-0da1bc349a99@github.com>
Message-ID: <8AyTBXtZlKhpFEDL9Tw2xZXp0XgRTUT5QUa88OXKbMI=.c1ed4e3a-f237-414f-ba3f-d8697a682df2@github.com>

On Sat, 13 Feb 2021 19:05:17 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> See bug description for details. The fix is simple and just a matter of moving some code to avoid incorrectly thinking an address is in a .so when it is in some other area of VM memory that occurs just after the last .so.

Your change looks good, but according to JBS description, should we change Linux DSO.java ? It can be separate this PR of course.

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

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

From cjplummer at openjdk.java.net  Sun Feb 14 04:36:39 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Sun, 14 Feb 2021 04:36:39 GMT
Subject: RFR: 8261702: ClhsdbFindPC can fail due to PointerFinder
 incorrectly thinking an address is in a .so
In-Reply-To: <8AyTBXtZlKhpFEDL9Tw2xZXp0XgRTUT5QUa88OXKbMI=.c1ed4e3a-f237-414f-ba3f-d8697a682df2@github.com>
References: <AFSFgu2cWGvCRDEq5jI67rk-Xwx1Xc3v2B3E81WjVJY=.3e2a4488-2e85-46b2-89f8-0da1bc349a99@github.com>
 <8AyTBXtZlKhpFEDL9Tw2xZXp0XgRTUT5QUa88OXKbMI=.c1ed4e3a-f237-414f-ba3f-d8697a682df2@github.com>
Message-ID: <y9Zcu5fQXkuLdgKj8RjQSjJHoiwXtTK65gdKMwPgk48=.46d17f70-a2d3-4905-8a7c-d07a2c9c6174@github.com>

On Sun, 14 Feb 2021 02:47:13 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> Your change looks good, but according to JBS description, should we change Linux DSO.java ? It can be separate this PR of course.

Thanks. I filed [JDK-8261710](https://bugs.openjdk.java.net/browse/JDK-8261710), but don't have any plans to work on it.

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

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

From ysuenaga at openjdk.java.net  Sun Feb 14 07:19:39 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Sun, 14 Feb 2021 07:19:39 GMT
Subject: RFR: 8261702: ClhsdbFindPC can fail due to PointerFinder
 incorrectly thinking an address is in a .so
In-Reply-To: <AFSFgu2cWGvCRDEq5jI67rk-Xwx1Xc3v2B3E81WjVJY=.3e2a4488-2e85-46b2-89f8-0da1bc349a99@github.com>
References: <AFSFgu2cWGvCRDEq5jI67rk-Xwx1Xc3v2B3E81WjVJY=.3e2a4488-2e85-46b2-89f8-0da1bc349a99@github.com>
Message-ID: <qMmq9fZXPive1ERc2uncYzCYRkugq3MTjd4r1uAmN50=.4d60daa0-1867-4d78-9d07-f29473e32ec1@github.com>

On Sat, 13 Feb 2021 19:05:17 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> See bug description for details. The fix is simple and just a matter of moving some code to avoid incorrectly thinking an address is in a .so when it is in some other area of VM memory that occurs just after the last .so.

Marked as reviewed by ysuenaga (Reviewer).

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

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

From ysuenaga at openjdk.java.net  Sun Feb 14 07:19:39 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Sun, 14 Feb 2021 07:19:39 GMT
Subject: RFR: 8261702: ClhsdbFindPC can fail due to PointerFinder
 incorrectly thinking an address is in a .so
In-Reply-To: <qMmq9fZXPive1ERc2uncYzCYRkugq3MTjd4r1uAmN50=.4d60daa0-1867-4d78-9d07-f29473e32ec1@github.com>
References: <AFSFgu2cWGvCRDEq5jI67rk-Xwx1Xc3v2B3E81WjVJY=.3e2a4488-2e85-46b2-89f8-0da1bc349a99@github.com>
 <qMmq9fZXPive1ERc2uncYzCYRkugq3MTjd4r1uAmN50=.4d60daa0-1867-4d78-9d07-f29473e32ec1@github.com>
Message-ID: <naOMzsTpbTcOTiYoFmmY4dQxgotLEiTxIaBOpP0_mbY=.c82d0bd5-70bd-4dbf-8fc0-8f364ef50dcb@github.com>

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

>> See bug description for details. The fix is simple and just a matter of moving some code to avoid incorrectly thinking an address is in a .so when it is in some other area of VM memory that occurs just after the last .so.
>
> Marked as reviewed by ysuenaga (Reviewer).

> Thanks. I filed [JDK-8261710](https://bugs.openjdk.java.net/browse/JDK-8261710), but don't have any plans to work on it.

Ok, I will send PR for  [JDK-8261710](https://bugs.openjdk.java.net/browse/JDK-8261710) ( #2563 ) if all pre-submit checks are passed.

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

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

From cjplummer at openjdk.java.net  Sun Feb 14 08:49:49 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Sun, 14 Feb 2021 08:49:49 GMT
Subject: RFR: 8261692:  Bugs in clhsdb history support
Message-ID: <3-9ngFZ9SzLX-MwIVN4fDjJAnbjqkt5Q0U8mah-tzHc=.ce625e90-080f-41b4-9227-771ea43b10b7@github.com>

See the CR for a description of the 3 issues fixed. There's also a new test added. I'll explain the fix related to quoting the '!' here since it's not that obvious how it works.

There's a complex pattern called `historyPattern` that is used to find various uses of ! to do expansion of commands and arguments in the history

    static Pattern historyPattern = Pattern.compile("([\\\]?)((!\*)|(!\$)|(!!-?)|(!-?[0-9][0-9]*)|(![a-zA-Z][^ ]*))");

I added the `([\\\]?)` part to handle allowing a '!' to be quoted with a backslash so it will just be treated as a '!' instead of being used for history expansion. This part of the pattern basically says match 1 backslash if present. Yes, you need 4 backslashes to do this. javac will reduce it to two, and then the pattern compilation reduces it down to just one backslash (not to be used for quoting).

The above pattern for searching for the backslash before a '!' is in the first pattern grouping, and the part that matches on the '!' and what follows is in the 2nd pattern grouping. Thus the code I added checks if the first pattern grouping matches something (and at most it will match just one backslash), and if so then we eat it and don't treat the '!' that follows as a history expansion:

                    if (m.group(1).length() != 0) {
                        // This means we matched a `` before the '!'. Don't do any history
                        // expansion in this case. Just capture what matched after the ``.
                        result.append(m.group(2));
                        continue;
                    }

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

Commit messages:
 - Fix 3 bugs in the clhsdb history support.

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

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

From cjplummer at openjdk.java.net  Sun Feb 14 09:19:56 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Sun, 14 Feb 2021 09:19:56 GMT
Subject: RFR: 8261711: Clhsdb "versioncheck true" throws NPE every time
Message-ID: <No2GR3rp5bVBhvfB2ztAqX9KWhT7RygtyPfTYijSMTs=.cc1a7cb3-4b95-4a1c-abbb-63bf52459ab2@github.com>

See CR for details. There's no test for `versioncheck`, and I don't think it's worth adding, especially for this trivial fix. Here's how I tested:
hsdb> versioncheck
versioncheck is true
hsdb> versioncheck false
hsdb> versioncheck
versioncheck is false
hsdb> versioncheck true
hsdb> versioncheck
versioncheck is true

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

Commit messages:
 - Use System.clearProperty rather than trying to set the property to null.

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

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

From ysuenaga at openjdk.java.net  Sun Feb 14 13:44:52 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Sun, 14 Feb 2021 13:44:52 GMT
Subject: RFR: 8261710: SA DSO objects have sizes that are too large
Message-ID: <rtxSvuvKLmHKrLtsnxf76vSK41b_HWPR_7Bn3wf9YuM=.cf1b54ae-f01d-48d5-9641-d7d9faa541f5@github.com>

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.

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

Commit messages:
 - Use entire of address range of shared library
 - 8261710: SA DSO objects have sizes that are too large

Changes: https://git.openjdk.java.net/jdk/pull/2563/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2563&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8261710
  Stats: 49 lines in 5 files changed: 27 ins; 3 del; 19 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2563.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2563/head:pull/2563

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

From cjplummer at openjdk.java.net  Mon Feb 15 05:55:52 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Mon, 15 Feb 2021 05:55:52 GMT
Subject: RFR: 8261098: Add clhsdb "findsym" command
Message-ID: <EcsJkvo_wYh085Hc1uRmViYzUrsfMeNLFOEsn0YSyXs=.8243bb41-62d6-40a0-8942-650a9cd8a497@github.com>

Add "findsym" to clhsdb. See the CR and CSR for details. The CSR still needs a reviewer.

There is one other somewhat unrelated fix in the test:

 -            String value = parts[1];
 +           String value = parts[1].split(linesep)[0];

This is suppose to capture just the value at the specified address, but it also captures the newline and some text after. The result if that when `findpc <value>` is executed, it also executes another command or two of garbage commands after that, which produce errors. They were not impacting the test, but were noticeable in the log. I first noticed it when similar code in the new part of the test had the same issue.

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

Commit messages:
 - Add clhsdb findsym command.

Changes: https://git.openjdk.java.net/jdk/pull/2567/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2567&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8261098
  Stats: 69 lines in 3 files changed: 61 ins; 0 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2567.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2567/head:pull/2567

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

From cjplummer at openjdk.java.net  Mon Feb 15 06:05:48 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Mon, 15 Feb 2021 06:05:48 GMT
Subject: RFR: 8261607: SA attach is exceeding JNI Local Refs capacity
Message-ID: <RoYVASDz0Y5cNK3fwa8MhvCxcN1S4hQNYFdRD60H5lE=.892a258a-5bb2-40f4-ad42-24a7bf365463@github.com>

Delete some localrefs to avoid -Xcheck:jni warnings. See CR for details.

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

Commit messages:
 - Fix SA -Xcheck:jni warnings and add some testing for the warnings.

Changes: https://git.openjdk.java.net/jdk/pull/2568/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2568&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8261607
  Stats: 23 lines in 4 files changed: 16 ins; 3 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2568.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2568/head:pull/2568

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

From cjplummer at openjdk.java.net  Mon Feb 15 06:46:38 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Mon, 15 Feb 2021 06:46:38 GMT
Subject: RFR: 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: <IlGty_H4BHMqmDRi0pWscIAKdyR_nKLI-Ceea9bcxTg=.e9a47c72-cfa8-41d1-8e05-ebde39ac1f24@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.

These changes look good, but it would be nice to fix OSX too. Fortunately it should be easier. As part of the fix for [JDK-8247515](https://bugs.openjdk.java.net/browse/JDK-8247515), I added a `lib_info->memsz` field. I think it is correct and is what you need. I needed it in order to properly scan .dylibs for symbols without scanning too far. It seems to be working. Unfortunately we don't really have a good tests for this, but you could look at the before and after for ClhsdbPmap test to get an idea of if it is working. If you don't have an OSX machine to try, I can try out your changes for you.

BTW, I have no idea if Windows is getting the size right, but I guess we'll just have to assume it is:

    env->CallVoidMethod(obj, addLoadObject_ID, strName, (jlong) params[u].Size,
                        (jlong) params[u].Base);

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

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

From alanb at openjdk.java.net  Mon Feb 15 11:49:38 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 15 Feb 2021 11:49:38 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v8]
In-Reply-To: <emFkGJxXluWeFGg6QcYXtftGN-MGDOgEAcZu-mKF9Lk=.38224ed4-2847-4947-bed4-09d3e437d58b@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <KcO_olP0uhrkPxSvala6b0MN3zsFy0_Skl06Oq6Gla0=.398341c8-a9c6-4186-ab43-df19bec9d544@github.com>
 <cONOB0wrdWjjltXXAuaH_SYz_ay7AgllB3SN64c8K_I=.d711bc68-c800-45fd-9de5-5bd1c5621430@github.com>
 <SNPiblXpzCPdmntADzdMMqFCO6eSjKOltzwD5MWnipc=.814578a6-ea9b-40b1-bfd8-199324b7281e@github.com>
 <_uFXfNAzlG3COOLDN_bJBEH4n0xtk52RH4jgW0MYF_w=.358107f1-fa87-4b5a-8ded-08248080678f@github.com>
 <JzpZmZbaq1b-bBgth2Wq1YTVQKpP3DbToT4h8N7ofTE=.4490859d-21a1-4cc9-8e8c-a8d067c82989@github.com>
 <y0ZtJNDhwp3A2Jzsszmio6fg0sGSxvk49eZw2cR_kss=.16bf1d32-b7df-4b5b-a3cc-fd8b2d0bebbe@github.com>
 <9ueMq5ar7LfXsQ5hV2wMnVVethu_2kyzuelDPv_8tfk=.b40c37bb-604e-478f-bc01-428694f0d4c9@github.com>
 <KctKgE0hs5s-qmGmNe_tJwW5C-IrvK5i72mO06GZ3v4=.f48f8a2d-a4a9-4074-9350-7cd443f73373@github.com>
 <hGiSvYyNa6D0BuKfIh-3CkelapBMNrFaQ_prF3xzPQQ=.64336055-18e5-4428-bc5b-40d484ed18ba@github.com>
 <ADR73RPzLPNb5SY61wNVAQNB0JdNFrXgwms
 dteeicVU=.1c5f04db-c639-4028-b472-c56999c4746c@github.com>
 <h1cjvuqNbm9Chz7atbi8daeCmDWgzzAKdFoHdgngjR8=.543211a7-9513-4d5f-8f45-9b0d300cdf00@github.com>
 <emFkGJxXluWeFGg6QcYXtftGN-MGDOgEAcZu-mKF9Lk=.38224ed4-2847-4947-bed4-09d3e437d58b@github.com>
Message-ID: <xi_gLEAFRhno-QJ7-t9yN5roj4z8jgj8bSEqynItmMQ=.8dbd6668-ced8-461e-8bca-fb88db59aa6a@github.com>

On Sat, 13 Feb 2021 10:56:32 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> This fours tests pass without problems, when I run them separately.
>> 
>> ## sun/security/tools/jarsigner/TimestampCheck.java
>> ## sun/security/tools/keytool/DefaultOptions.java
>> ## sanity/client/SwingSet/src/ColorChooserDemoTest.java
>> ## sanity/client/SwingSet/src/SwingSet2DemoTest.java
>> 
>>     make test TEST="jtreg:sun/security/tools/jarsigner/TimestampCheck.java sun/security/tools/keytool/DefaultOptions.java sanity/client/SwingSet/src/SwingSet2DemoTest.java sanity/client/SwingSet/src/ColorChooserDemoTest.java"
>>     
>>     Building target 'test' in configuration 'windows-x86_64-server-release'
>>     Test selection 'jtreg:sun/security/tools/jarsigner/TimestampCheck.java sun/security/tools/keytool/DefaultOptions.java sanity/client/SwingSet/src/SwingSet2DemoTest.java sanity/client/SwingSet/src/ColorChooserDemoTest.java', will run:
>>     * jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java
>>     * jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java
>>     * jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java
>>     * jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java
>> 
>>     Running test 'jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java'
>>     Passed: sun/security/tools/jarsigner/TimestampCheck.java
>>     Test results: passed: 1
>>     Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sun_security_tools_jarsigner_TimestampCheck_java\html\report.html
>>     Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sun_security_tools_jarsigner_TimestampCheck_java
>>     Finished running test 'jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java'
>>     Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sun_security_tools_jarsigner_TimestampCheck_java
>> 
>>     Running test 'jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java'
>>     Passed: sun/security/tools/keytool/DefaultOptions.java
>>     Test results: passed: 1
>>     Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sun_security_tools_keytool_DefaultOptions_java\html\report.html
>>     Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sun_security_tools_keytool_DefaultOptions_java
>>     Finished running test 'jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java'
>>     Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sun_security_tools_keytool_DefaultOptions_java
>> 
>>     Running test 'jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java'
>>     Passed: sanity/client/SwingSet/src/SwingSet2DemoTest.java
>>     Test results: passed: 1
>>     Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sanity_client_SwingSet_src_SwingSet2DemoTest_java\html\report.html
>>     Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sanity_client_SwingSet_src_SwingSet2DemoTest_java
>>     Finished running test 'jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java'
>>     Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sanity_client_SwingSet_src_SwingSet2DemoTest_java
>> 
>>     Running test 'jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java'
>>     Passed: sanity/client/SwingSet/src/ColorChooserDemoTest.java
>>     Test results: passed: 1
>>     Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sanity_client_SwingSet_src_ColorChooserDemoTest_java\html\report.html
>>     Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sanity_client_SwingSet_src_ColorChooserDemoTest_java
>>     Finished running test 'jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java'
>>     Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sanity_client_SwingSet_src_ColorChooserDemoTest_java
>> 
>>     ==============================
>>     Test summary
>>     ==============================
>>        TEST                                              TOTAL  PASS  FAIL ERROR
>>        jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java
>>                                                              1     1     0     0
>>        jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java
>>                                                              1     1     0     0
>>        jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java
>>                                                              1     1     0     0
>>        jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java
>>                                                              1     1     0     0
>>     ==============================
>>     TEST SUCCESS
>> 
>>     Finished building target 'test' in configuration 'windows-x86_64-server-release'
>
> ## jdk/jshell/ToolBasicTest.java
>     
>     make test TEST="jtreg:jdk/jshell/ToolBasicTest.java"
> 
>     STDOUT:
>     [TestNG] Running:
>       jdk/jshell/ToolBasicTest.java
> 
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.elideStartUpFromList(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.elideStartUpFromSave(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.test8142447(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testAddExports(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testBadClasspath(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testBadModulePath(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testBadSourceJarClasspath(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testClasspathDirectory(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testClasspathJar(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testClasspathUserHomeExpansion(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testConstrainedUpdates(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testCtrlD(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testEnvInStartUp(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testFeedbackNegative(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testFeedbackNormal(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testFeedbackSilent(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testHistoryReference(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testIndent(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testInterrupt(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testLoadingFromArgs(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testModulePath(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testModulePathUserHomeExpansion(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testOpen(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testOpenFileOverHttp(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testOpenLocalFileUrl(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testOpenResource(): failure
>     java.lang.AssertionError: user output: printf("%4.2f", Math.PI).
>      expected [3.14] but found [3,14]
>             at org.testng.Assert.fail(Assert.java:94)
>             at org.testng.Assert.failNotEquals(Assert.java:496)
>             at org.testng.Assert.assertEquals(Assert.java:125)
>             at org.testng.Assert.assertEquals(Assert.java:178)
>             at ReplToolTesting.assertOutput(ReplToolTesting.java:529)
>             at ReplToolTesting.assertCommand(ReplToolTesting.java:513)
>             at ToolBasicTest.lambda$testOpenResource$118(ToolBasicTest.java:559)
>             at ReplToolTesting$PromptedCommandOutputStream.write(ReplToolTesting.java:824)
>             at java.base/java.io.PrintStream.write(PrintStream.java:536)
>             at jdk.internal.le/jdk.internal.org.jline.terminal.impl.LineDisciplineTerminal.processOutputByte(LineDisciplineTerminal.java:253)
>             at jdk.internal.le/jdk.internal.org.jline.terminal.impl.LineDisciplineTerminal$FilteringOutputStream.write(LineDisciplineTerminal.java:294)
>             at java.base/sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:242)
>             at java.base/sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:321)
>             at java.base/sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:325)
>             at java.base/sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:159)
>             at java.base/java.io.OutputStreamWriter.flush(OutputStreamWriter.java:248)
>             at java.base/java.io.PrintWriter.flush(PrintWriter.java:396)
>             at jdk.internal.le/jdk.internal.org.jline.terminal.impl.AbstractTerminal.flush(AbstractTerminal.java:174)
>             at jdk.internal.le/jdk.internal.org.jline.utils.Display.update(Display.java:336)
>             at jdk.internal.le/jdk.internal.org.jline.reader.impl.LineReaderImpl.redisplay(LineReaderImpl.java:3943)
>             at jdk.internal.le/jdk.internal.org.jline.reader.impl.LineReaderImpl.redisplay(LineReaderImpl.java:3803)
>             at jdk.internal.le/jdk.internal.org.jline.reader.impl.LineReaderImpl.readLine(LineReaderImpl.java:626)
>             at jdk.internal.le/jdk.internal.org.jline.reader.impl.LineReaderImpl.readLine(LineReaderImpl.java:454)
>             at jdk.jshell/jdk.internal.jshell.tool.ConsoleIOContext.readLine(ConsoleIOContext.java:233)
>             at jdk.jshell/jdk.internal.jshell.tool.JShellTool.getInput(JShellTool.java:1263)
>             at jdk.jshell/jdk.internal.jshell.tool.JShellTool.run(JShellTool.java:1199)
>             at jdk.jshell/jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:991)
>             at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder.run(JShellToolBuilder.java:240)
>             at ReplToolTesting.testRawRun(ReplToolTesting.java:313)
>             at ReplToolTesting.testRaw(ReplToolTesting.java:296)
>             at ReplToolTesting.test(ReplToolTesting.java:249)
>             at ReplToolTesting.test(ReplToolTesting.java:233)
>             at ReplToolTesting.test(ReplToolTesting.java:229)
>             at ReplToolTesting.test(ReplToolTesting.java:225)
>             at ToolBasicTest.testOpenResource(ToolBasicTest.java:555)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>             at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85)
>             at org.testng.internal.Invoker.invokeMethod(Invoker.java:639)
>             at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:821)
>             at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1131)
>             at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
>             at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108)
>             at org.testng.TestRunner.privateRun(TestRunner.java:773)
>             at org.testng.TestRunner.run(TestRunner.java:623)
>             at org.testng.SuiteRunner.runTest(SuiteRunner.java:357)
>             at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:352)
>             at org.testng.SuiteRunner.privateRun(SuiteRunner.java:310)
>             at org.testng.SuiteRunner.run(SuiteRunner.java:259)
>             at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
>             at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
>             at org.testng.TestNG.runSuitesSequentially(TestNG.java:1185)
>             at org.testng.TestNG.runSuitesLocally(TestNG.java:1110)
>             at org.testng.TestNG.run(TestNG.java:1018)
>             at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>             at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
>             at java.base/java.lang.Thread.run(Thread.java:831)
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testRedeclareVariableNoInit(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testRemoteExit(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testRerun(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testRerunIdRange(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testReset(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testSave(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testStartRetain(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testStartSave(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testStartupFileOption(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testStop(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testVarsWithNotActive(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testWarningUnchecked(): success
> 
>     ===============================================
>     jdk/jshell/ToolBasicTest.java
>     Total tests run: 38, Failures: 1, Skips: 0
>     ===============================================
> 
>     STDERR:
>     java.io.EOFException
>             at java.base/java.io.DataInputStream.readInt(DataInputStream.java:398)
>             at java.base/java.io.ObjectInputStream$BlockDataInputStream.readInt(ObjectInputStream.java:3381)
>             at java.base/java.io.ObjectInputStream.readInt(ObjectInputStream.java:1113)
>             at jdk.jshell/jdk.jshell.execution.StreamingExecutionControl.readAndReportExecutionResult(StreamingExecutionControl.java:277)
>             at jdk.jshell/jdk.jshell.execution.StreamingExecutionControl.invoke(StreamingExecutionControl.java:99)
>             at jdk.jshell/jdk.jshell.execution.JdiDefaultExecutionControl.invoke(JdiDefaultExecutionControl.java:160)
>             at jdk.jshell/jdk.jshell.Eval.declare(Eval.java:943)
>             at jdk.jshell/jdk.jshell.Eval.eval(Eval.java:139)
>             at jdk.jshell/jdk.jshell.JShell.eval(JShell.java:493)
>             at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processSource(JShellTool.java:3609)
>             at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processSourceCatchingReset(JShellTool.java:1330)
>             at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processInput(JShellTool.java:1228)
>             at jdk.jshell/jdk.internal.jshell.tool.JShellTool.run(JShellTool.java:1201)
>             at jdk.jshell/jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:991)
>             at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder.run(JShellToolBuilder.java:240)
>             at ReplToolTesting.testRawRun(ReplToolTesting.java:313)
>             at ReplToolTesting.testRaw(ReplToolTesting.java:296)
>             at ReplToolTesting.test(ReplToolTesting.java:249)
>             at ReplToolTesting.test(ReplToolTesting.java:233)
>             at ReplToolTesting.test(ReplToolTesting.java:229)
>             at ReplToolTesting.test(ReplToolTesting.java:225)
>             at ToolBasicTest.testRemoteExit(ToolBasicTest.java:680)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>             at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85)
>             at org.testng.internal.Invoker.invokeMethod(Invoker.java:639)
>             at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:821)
>             at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1131)
>             at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
>             at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108)
>             at org.testng.TestRunner.privateRun(TestRunner.java:773)
>             at org.testng.TestRunner.run(TestRunner.java:623)
>             at org.testng.SuiteRunner.runTest(SuiteRunner.java:357)
>             at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:352)
>             at org.testng.SuiteRunner.privateRun(SuiteRunner.java:310)
>             at org.testng.SuiteRunner.run(SuiteRunner.java:259)
>             at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
>             at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
>             at org.testng.TestNG.runSuitesSequentially(TestNG.java:1185)
>             at org.testng.TestNG.runSuitesLocally(TestNG.java:1110)
>             at org.testng.TestNG.run(TestNG.java:1018)
>             at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>             at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
>             at java.base/java.lang.Thread.run(Thread.java:831)
>     java.lang.Exception: failures: 1
>             at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:96)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>             at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
>             at java.base/java.lang.Thread.run(Thread.java:831)
> 
>     JavaTest Message: Test threw exception: java.lang.Exception
>     JavaTest Message: shutting down test
> 
> 
>     TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 1
> 
> https://bugs.openjdk.java.net/browse/JDK-8212234 looks like there is already known bug this test.

@turbanoff Can you run the tests in the en_US locale? I suspect some of these tests can't run in all locales. Also can you check your environment to ensure the file paths for F: are consistent (I suspect you have a mix of f: and F: in the environment).

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

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

From sgehwolf at openjdk.java.net  Mon Feb 15 13:27:41 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Mon, 15 Feb 2021 13:27:41 GMT
Subject: RFR: 8261607: SA attach is exceeding JNI Local Refs capacity
In-Reply-To: <RoYVASDz0Y5cNK3fwa8MhvCxcN1S4hQNYFdRD60H5lE=.892a258a-5bb2-40f4-ad42-24a7bf365463@github.com>
References: <RoYVASDz0Y5cNK3fwa8MhvCxcN1S4hQNYFdRD60H5lE=.892a258a-5bb2-40f4-ad42-24a7bf365463@github.com>
Message-ID: <10xLiGUOC8YGo24dJQFk8_oX84_BDhhqvjxvlgNsm6w=.dd17f959-c558-4980-b031-84a47a461ae2@github.com>

On Mon, 15 Feb 2021 06:00:29 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Delete some localrefs to avoid -Xcheck:jni warnings. See CR for details.

test/hotspot/jtreg/serviceability/sa/ClhsdbLauncher.java line 149:

> 147:         // Make sure no -Xcheck:jni failures. WARNING: JNI local refs
> 148:         oa.shouldNotMatch("^WARNING: JNI local refs:.*$");
> 149:         oa.shouldNotMatch("^WARNING in native method:.*$");

It's not clear to me why this matcher is being done without any tests using `-Xcheck:jni`. Is this intentional?

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

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

From burban at openjdk.java.net  Mon Feb 15 16:24:48 2021
From: burban at openjdk.java.net (Bernhard Urban-Forster)
Date: Mon, 15 Feb 2021 16:24:48 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
In-Reply-To: <quhwE-hqPgo6HXXf4D7o2FRIu48a_H9Fsd8TSqJrbE0=.e5ec4863-c3b4-4fd5-bf5d-f95cd1245770@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>
 <UnSWIprKrFiPt4vWX36CgseOH4-iJVexy8UBjsGUJ4k=.67e5231b-a1f0-4ded-9852-6ea7fcbff05a@github.com>
 <quhwE-hqPgo6HXXf4D7o2FRIu48a_H9Fsd8TSqJrbE0=.e5ec4863-c3b4-4fd5-bf5d-f95cd1245770@github.com>
Message-ID: <Po6Bn-jzngY9eRxVnQ4lBtRE5Y_NcTgFQUaRvvK58fs=.a8d42c1c-5403-4965-b3e0-006ba603abc0@github.com>

On Fri, 12 Feb 2021 12:22:09 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

>> Where did this come from - some snippet/example/tech note code? Maybe other people can help figure it out if we provide more info.
>
> This is the version of w^x on-demand switch implemented by microsoft guys. This is enabled only for debug builds.
> @lewurm could you comment here please

Those values can be observed in the debugger, but aren't documented or defined in header files.

This mode was useful for the initial bootstrap of the platform (it helped with missing W^X transitions), but shouldn't be required anymore today. I'm fine with removing it altogether.

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

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

From akozlov at openjdk.java.net  Mon Feb 15 17:34:14 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Mon, 15 Feb 2021 17:34:14 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v14]
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: <6SmGFRbH6_SgIW-aRpEIrRnfsv-BI2nmDUffhObbyu8=.e4979c82-2bfb-4932-b980-d261d7a55f74@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 73 commits:

 - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos
   
   Additional work for JDK-8253817: Support macOS Aarch64 ABI in
   Interpreter
 - JDK-8257882: oops, fixed 7fe50a996b6f436932452d220b351c73153ed945
 - Update signal handler part for debugger
 - Cleanup SA changes
 - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos
 - support macos_aarch64 in hsdis
 - Merge branch 'master' into jdk-macos
 - Update copyright year for BsdAARCH64ThreadContext.java
 - Fix inclusing of StubRoutines header
 - Redo buildsys fix
 - ... and 63 more: https://git.openjdk.java.net/jdk/compare/40ae9937...4094f351

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

Changes: https://git.openjdk.java.net/jdk/pull/2200/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=13
  Stats: 3066 lines in 84 files changed: 2954 ins; 47 del; 65 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  Mon Feb 15 17:45:07 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Mon, 15 Feb 2021 17:45:07 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v15]
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: <UzN3zGJ3ODTcQ4sCe1TDNgD6K8T38Das2Zk6OJD8UNg=.ec00d97b-25e1-475f-8877-d011b65ae449@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 75 commits:

 - Pull/2200 (#5)
   
   * bsd_aarch64 cleanup
   
   * remove the actual attribute too
   
   * Refactor bailing out on nativeWrapper generation
   
   * rename c_call_conv_priv function
 - Merge branch 'master' into jdk-macos
 - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos
   
   Additional work for JDK-8253817: Support macOS Aarch64 ABI in
   Interpreter
 - JDK-8257882: oops, fixed 7fe50a996b6f436932452d220b351c73153ed945
 - Update signal handler part for debugger
 - Cleanup SA changes
 - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos
 - support macos_aarch64 in hsdis
 - Merge branch 'master' into jdk-macos
 - Update copyright year for BsdAARCH64ThreadContext.java
 - ... and 65 more: https://git.openjdk.java.net/jdk/compare/849f4c0f...a9452a4c

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

Changes: https://git.openjdk.java.net/jdk/pull/2200/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=14
  Stats: 3032 lines in 83 files changed: 2919 ins; 47 del; 66 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  Mon Feb 15 17:48:48 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Mon, 15 Feb 2021 17:48:48 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v15]
In-Reply-To: <0-H97G4l5XqFtiEUbNAqrP_j143iny5kkF0tsiAqMvQ=.2396963b-db5d-469e-bc30-511f754a600a@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <W8UGeXzEc_BvnLqIZ7FZF6zks4U39dAZaXCzSGDS1qw=.1f3badd9-df84-4f00-9e1d-d959780fb997@github.com>
 <h9On7_RFadcLwhW15R4Jig9PZ0y9JoMI2diiqXv99eY=.9b814ff7-64cf-496f-a507-0a8f86070c2d@github.com>
 <GUQ9iV90tXzdUOtyjcIJygM7qBCcUtSHVOol8hOK2OE=.7b3ab947-f835-43d4-a852-cde094efbf62@github.com>
 <0-H97G4l5XqFtiEUbNAqrP_j143iny5kkF0tsiAqMvQ=.2396963b-db5d-469e-bc30-511f754a600a@github.com>
Message-ID: <ZzDf-j_FfFTasrbg9lcKPumX79r75Qq_na8CGzbrmEg=.35f0cf2c-4775-4388-a2c7-9bb65ca509be@github.com>

On Sun, 31 Jan 2021 20:08:01 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

>> I'm not sure it can wait. This change turns already-messy code into something significantly messier, to the extent that it's not really good enough to go into mainline.
>
> Hello
> Does this look like something in the right direction ? 
> 
> https://github.com/VladimirKempik/jdk/commit/c2820734f4b10148154085a70d380b8c5775fa49

The latest merge with JDK-8261071 should resolve the issue. Please take a look.

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

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

From cjplummer at openjdk.java.net  Mon Feb 15 17:53:58 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Mon, 15 Feb 2021 17:53:58 GMT
Subject: RFR: 8261607: SA attach is exceeding JNI Local Refs capacity [v2]
In-Reply-To: <RoYVASDz0Y5cNK3fwa8MhvCxcN1S4hQNYFdRD60H5lE=.892a258a-5bb2-40f4-ad42-24a7bf365463@github.com>
References: <RoYVASDz0Y5cNK3fwa8MhvCxcN1S4hQNYFdRD60H5lE=.892a258a-5bb2-40f4-ad42-24a7bf365463@github.com>
Message-ID: <LsTaNHOI0zMiyOJ1Cj9fcm_M3kAOCtbp3aTM0Ef2uYo=.cf36b828-37fa-4fec-81c9-a302d3b702ee@github.com>

> Delete some localrefs to avoid -Xcheck:jni warnings. See CR for details.

Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:

  Fix comment

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2568/files
  - new: https://git.openjdk.java.net/jdk/pull/2568/files/775374e4..21ff3296

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

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

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

From cjplummer at openjdk.java.net  Mon Feb 15 17:53:59 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Mon, 15 Feb 2021 17:53:59 GMT
Subject: RFR: 8261607: SA attach is exceeding JNI Local Refs capacity [v2]
In-Reply-To: <10xLiGUOC8YGo24dJQFk8_oX84_BDhhqvjxvlgNsm6w=.dd17f959-c558-4980-b031-84a47a461ae2@github.com>
References: <RoYVASDz0Y5cNK3fwa8MhvCxcN1S4hQNYFdRD60H5lE=.892a258a-5bb2-40f4-ad42-24a7bf365463@github.com>
 <10xLiGUOC8YGo24dJQFk8_oX84_BDhhqvjxvlgNsm6w=.dd17f959-c558-4980-b031-84a47a461ae2@github.com>
Message-ID: <CWfjZAfIUEFvE4zAWiUvFG7UETvghFl_bRfmPEB3Yag=.5f580a40-c956-4782-937b-29201a575beb@github.com>

On Mon, 15 Feb 2021 13:21:39 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix comment
>
> test/hotspot/jtreg/serviceability/sa/ClhsdbLauncher.java line 149:
> 
>> 147:         // Make sure no -Xcheck:jni failures. WARNING: JNI local refs
>> 148:         oa.shouldNotMatch("^WARNING: JNI local refs:.*$");
>> 149:         oa.shouldNotMatch("^WARNING in native method:.*$");
> 
> It's not clear to me why this matcher is being done without any tests using `-Xcheck:jni`. Is this intentional?

Although no Clhsdb test is explicitly always runs with `-Xcheck:jni`, the option can be added to any test run. For example:

`$ make test  TEST=open/test/hotspot/jtreg/serviceability/sa/ TEST_VM_OPTS="-Xcheck:jni"`

This matching is done to make sure there are no warnings when the test is run in this manner. The matching could be conditional on the test being run with  `-Xcheck:jni`, but I don't really see to point in cluttering up the logic with such a check since the warnings should never appear, whether or not you are using `-Xcheck:jni`.

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

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

From vkempik at openjdk.java.net  Mon Feb 15 18:03:55 2021
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Mon, 15 Feb 2021 18:03:55 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v8]
In-Reply-To: <cpf_Q2rM76sr9dlOexk27XKGxtOK41AJxugL6Le19Mo=.d77cc563-81b2-4d14-8ed4-f34d97a7b75a@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <ugV_PtxgaQkJQw3i1cwYiaKZ46--TZfgdVsuhQd5_3Y=.5b39eb44-1398-41b1-8bdf-2e6a3149e865@github.com>
 <cpf_Q2rM76sr9dlOexk27XKGxtOK41AJxugL6Le19Mo=.d77cc563-81b2-4d14-8ed4-f34d97a7b75a@github.com>
Message-ID: <M33x5HsjKpNTd34OwGfLGI3ACvCgb_oC4YnvKYF4TLA=.7d7d9112-a638-40bb-8309-0e8ab7743ee1@github.com>

On Mon, 1 Feb 2021 18:44:48 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 62 commits:
>> 
>>  - Merge branch 'master' into jdk-macos
>>  - Update copyright year for BsdAARCH64ThreadContext.java
>>  - Fix inclusing of StubRoutines header
>>  - Redo buildsys fix
>>  - Revert harfbuzz changes, disable warnings for it
>>  - Little adjustement of SlowSignatureHandler
>>  - Partially bring previous commit
>>  - Revert "Address feedback for signature generators"
>>    
>>    This reverts commit 50b55f6684cd21f8b532fa979b7b6fbb4613266d.
>>  - Refactor CDS disabling
>>  - Redo builsys support for aarch64-darwin
>>  - ... and 52 more: https://git.openjdk.java.net/jdk/compare/8a9004da...b421e0b4
>
> src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 839:
> 
>> 837:           // The code unable to handle this, bailout.
>> 838:           return -1;
>> 839: #endif
> 
> This looks like a bug to me. The caller doesn't necessarily check the return value. See CallRuntimeNode::calling_convention.

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

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

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

From vkempik at openjdk.java.net  Mon Feb 15 18:03:51 2021
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Mon, 15 Feb 2021 18:03: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: <MF1iA9imUPiz__P2Xgl06D6uqX6m3yi5_LkRtVy0yYA=.985a8d8e-d585-4ca1-8c27-3752dc4f297a@github.com>

On Tue, 2 Feb 2021 21:52:47 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/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

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

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

From akozlov at openjdk.java.net  Mon Feb 15 18:03:56 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Mon, 15 Feb 2021 18:03:56 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
In-Reply-To: <VRubHtUOaz3-yAHaC71ZiRvh_V1kkkbuviPPRBtuToo=.5ee2c5d2-7895-4967-9088-eb8d78fddf2e@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>
 <VRubHtUOaz3-yAHaC71ZiRvh_V1kkkbuviPPRBtuToo=.5ee2c5d2-7895-4967-9088-eb8d78fddf2e@github.com>
Message-ID: <TG8owPuYZRMTZ7VbF9ZBxDlazzsmbwemxnsWiiwFUrc=.ccaf94cf-ccb3-4cd3-b9be-f96095462e3e@github.com>

On Wed, 3 Feb 2021 20:08:41 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

> I'm going to do as much refactoring as needed before this patch under JDK-8261071

The recent merge resolves inconsitency between pass_byte/pass_short and other methods.

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

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

From lucy at openjdk.java.net  Mon Feb 15 18:05:59 2021
From: lucy at openjdk.java.net (Lutz Schmidt)
Date: Mon, 15 Feb 2021 18:05:59 GMT
Subject: RFR: 8261447: MethodInvocationCounters frequently run into
 overflow [v3]
In-Reply-To: <FsHAKG6KwqJeHLIhE6JroDUjiebdevi1asoLi-7pQ1s=.15d96719-36f2-4f9b-ae80-fcb17a3b6659@github.com>
References: <FsHAKG6KwqJeHLIhE6JroDUjiebdevi1asoLi-7pQ1s=.15d96719-36f2-4f9b-ae80-fcb17a3b6659@github.com>
Message-ID: <9fS9BEifmElhKXeBhN6anBBKCwaf3Rk4YeEA9ONBrQ4=.44725bb0-a3b5-456f-a43e-71d45fb69c73@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 (185 days 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 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 six additional commits since the last revision:

 - expand remaining counters to 64-bit, remove 64 suffix
 - 8261447: requested changes by TobiHartmann
 - JDK-8261447: MethodInvocationCounters frequently run into overflow
 - expand remaining counters to 64-bit, remove 64 duffix
 - 8261447: requested changes by TobiHartmann
 - JDK-8261447: MethodInvocationCounters frequently run into overflow

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2511/files
  - new: https://git.openjdk.java.net/jdk/pull/2511/files/bfd60a3c..67fb3f7d

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

  Stats: 8620 lines in 332 files changed: 4163 ins; 2472 del; 1985 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 akozlov at openjdk.java.net  Mon Feb 15 18:10:09 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Mon, 15 Feb 2021 18:10:09 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v16]
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: <TnvkF2Sys20zQJgZoLMkwa9Nif3YcqnPB7lh0Y96a8g=.8dc9535e-17e3-4511-868f-323f6dcba9c3@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 two additional commits since the last revision:

 - Merge pull request #6 from VladimirKempik/pull/2200
   
   Fix typo in comments
 - Fix typo in comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2200/files
  - new: https://git.openjdk.java.net/jdk/pull/2200/files/a9452a4c..419c2b1a

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

  Stats: 1 line in 1 file changed: 0 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 sgehwolf at openjdk.java.net  Mon Feb 15 18:12:39 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Mon, 15 Feb 2021 18:12:39 GMT
Subject: RFR: 8261607: SA attach is exceeding JNI Local Refs capacity [v2]
In-Reply-To: <CWfjZAfIUEFvE4zAWiUvFG7UETvghFl_bRfmPEB3Yag=.5f580a40-c956-4782-937b-29201a575beb@github.com>
References: <RoYVASDz0Y5cNK3fwa8MhvCxcN1S4hQNYFdRD60H5lE=.892a258a-5bb2-40f4-ad42-24a7bf365463@github.com>
 <10xLiGUOC8YGo24dJQFk8_oX84_BDhhqvjxvlgNsm6w=.dd17f959-c558-4980-b031-84a47a461ae2@github.com>
 <CWfjZAfIUEFvE4zAWiUvFG7UETvghFl_bRfmPEB3Yag=.5f580a40-c956-4782-937b-29201a575beb@github.com>
Message-ID: <TmtrKuBYcbsfREBLvR5hm-ry84euOhtTkqLjm8TzhsA=.47e895d8-c49f-48aa-b4dc-ecf8d8086ad6@github.com>

On Mon, 15 Feb 2021 17:47:47 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> test/hotspot/jtreg/serviceability/sa/ClhsdbLauncher.java line 149:
>> 
>>> 147:         // Make sure no -Xcheck:jni failures. WARNING: JNI local refs
>>> 148:         oa.shouldNotMatch("^WARNING: JNI local refs:.*$");
>>> 149:         oa.shouldNotMatch("^WARNING in native method:.*$");
>> 
>> It's not clear to me why this matcher is being done without any tests using `-Xcheck:jni`. Is this intentional?
>
> Although no Clhsdb test is explicitly always runs with `-Xcheck:jni`, the option can be added to any test run. For example:
> 
> `$ make test  TEST=open/test/hotspot/jtreg/serviceability/sa/ TEST_VM_OPTS="-Xcheck:jni"`
> 
> This matching is done to make sure there are no warnings when the test is run in this manner. The matching could be conditional on the test being run with  `-Xcheck:jni`, but I don't really see to point in cluttering up the logic with such a check since the warnings should never appear, whether or not you are using `-Xcheck:jni`.

OK, I thought so. Could you expand on the comment saying so, please? Suggestion: `Make sure there are no -Xcheck:jni warnings as -Xcheck:jni might be set via TEST_VM_OPTS on test runs`.

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

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

From jboes at openjdk.java.net  Mon Feb 15 18:18:39 2021
From: jboes at openjdk.java.net (Julia Boes)
Date: Mon, 15 Feb 2021 18:18:39 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v8]
In-Reply-To: <emFkGJxXluWeFGg6QcYXtftGN-MGDOgEAcZu-mKF9Lk=.38224ed4-2847-4947-bed4-09d3e437d58b@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <KcO_olP0uhrkPxSvala6b0MN3zsFy0_Skl06Oq6Gla0=.398341c8-a9c6-4186-ab43-df19bec9d544@github.com>
 <cONOB0wrdWjjltXXAuaH_SYz_ay7AgllB3SN64c8K_I=.d711bc68-c800-45fd-9de5-5bd1c5621430@github.com>
 <SNPiblXpzCPdmntADzdMMqFCO6eSjKOltzwD5MWnipc=.814578a6-ea9b-40b1-bfd8-199324b7281e@github.com>
 <_uFXfNAzlG3COOLDN_bJBEH4n0xtk52RH4jgW0MYF_w=.358107f1-fa87-4b5a-8ded-08248080678f@github.com>
 <JzpZmZbaq1b-bBgth2Wq1YTVQKpP3DbToT4h8N7ofTE=.4490859d-21a1-4cc9-8e8c-a8d067c82989@github.com>
 <y0ZtJNDhwp3A2Jzsszmio6fg0sGSxvk49eZw2cR_kss=.16bf1d32-b7df-4b5b-a3cc-fd8b2d0bebbe@github.com>
 <9ueMq5ar7LfXsQ5hV2wMnVVethu_2kyzuelDPv_8tfk=.b40c37bb-604e-478f-bc01-428694f0d4c9@github.com>
 <KctKgE0hs5s-qmGmNe_tJwW5C-IrvK5i72mO06GZ3v4=.f48f8a2d-a4a9-4074-9350-7cd443f73373@github.com>
 <hGiSvYyNa6D0BuKfIh-3CkelapBMNrFaQ_prF3xzPQQ=.64336055-18e5-4428-bc5b-40d484ed18ba@github.com>
 <ADR73RPzLPNb5SY61wNVAQNB0JdNFrXgwms
 dteeicVU=.1c5f04db-c639-4028-b472-c56999c4746c@github.com>
 <h1cjvuqNbm9Chz7atbi8daeCmDWgzzAKdFoHdgngjR8=.543211a7-9513-4d5f-8f45-9b0d300cdf00@github.com>
 <emFkGJxXluWeFGg6QcYXtftGN-MGDOgEAcZu-mKF9Lk=.38224ed4-2847-4947-bed4-09d3e437d58b@github.com>
Message-ID: <lR915nPeGioI4oTObfzDIcoVACkXvusnR7rF5R86k10=.739f8477-c380-4012-921e-335b937c2aea@github.com>

On Sat, 13 Feb 2021 10:56:32 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> This fours tests pass without problems, when I run them separately.
>> 
>> ## sun/security/tools/jarsigner/TimestampCheck.java
>> ## sun/security/tools/keytool/DefaultOptions.java
>> ## sanity/client/SwingSet/src/ColorChooserDemoTest.java
>> ## sanity/client/SwingSet/src/SwingSet2DemoTest.java
>> 
>>     make test TEST="jtreg:sun/security/tools/jarsigner/TimestampCheck.java sun/security/tools/keytool/DefaultOptions.java sanity/client/SwingSet/src/SwingSet2DemoTest.java sanity/client/SwingSet/src/ColorChooserDemoTest.java"
>>     
>>     Building target 'test' in configuration 'windows-x86_64-server-release'
>>     Test selection 'jtreg:sun/security/tools/jarsigner/TimestampCheck.java sun/security/tools/keytool/DefaultOptions.java sanity/client/SwingSet/src/SwingSet2DemoTest.java sanity/client/SwingSet/src/ColorChooserDemoTest.java', will run:
>>     * jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java
>>     * jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java
>>     * jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java
>>     * jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java
>> 
>>     Running test 'jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java'
>>     Passed: sun/security/tools/jarsigner/TimestampCheck.java
>>     Test results: passed: 1
>>     Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sun_security_tools_jarsigner_TimestampCheck_java\html\report.html
>>     Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sun_security_tools_jarsigner_TimestampCheck_java
>>     Finished running test 'jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java'
>>     Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sun_security_tools_jarsigner_TimestampCheck_java
>> 
>>     Running test 'jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java'
>>     Passed: sun/security/tools/keytool/DefaultOptions.java
>>     Test results: passed: 1
>>     Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sun_security_tools_keytool_DefaultOptions_java\html\report.html
>>     Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sun_security_tools_keytool_DefaultOptions_java
>>     Finished running test 'jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java'
>>     Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sun_security_tools_keytool_DefaultOptions_java
>> 
>>     Running test 'jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java'
>>     Passed: sanity/client/SwingSet/src/SwingSet2DemoTest.java
>>     Test results: passed: 1
>>     Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sanity_client_SwingSet_src_SwingSet2DemoTest_java\html\report.html
>>     Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sanity_client_SwingSet_src_SwingSet2DemoTest_java
>>     Finished running test 'jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java'
>>     Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sanity_client_SwingSet_src_SwingSet2DemoTest_java
>> 
>>     Running test 'jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java'
>>     Passed: sanity/client/SwingSet/src/ColorChooserDemoTest.java
>>     Test results: passed: 1
>>     Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sanity_client_SwingSet_src_ColorChooserDemoTest_java\html\report.html
>>     Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sanity_client_SwingSet_src_ColorChooserDemoTest_java
>>     Finished running test 'jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java'
>>     Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sanity_client_SwingSet_src_ColorChooserDemoTest_java
>> 
>>     ==============================
>>     Test summary
>>     ==============================
>>        TEST                                              TOTAL  PASS  FAIL ERROR
>>        jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java
>>                                                              1     1     0     0
>>        jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java
>>                                                              1     1     0     0
>>        jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java
>>                                                              1     1     0     0
>>        jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java
>>                                                              1     1     0     0
>>     ==============================
>>     TEST SUCCESS
>> 
>>     Finished building target 'test' in configuration 'windows-x86_64-server-release'
>
> ## jdk/jshell/ToolBasicTest.java
>     
>     make test TEST="jtreg:jdk/jshell/ToolBasicTest.java"
> 
>     STDOUT:
>     [TestNG] Running:
>       jdk/jshell/ToolBasicTest.java
> 
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.elideStartUpFromList(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.elideStartUpFromSave(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.test8142447(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testAddExports(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testBadClasspath(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testBadModulePath(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testBadSourceJarClasspath(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testClasspathDirectory(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testClasspathJar(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testClasspathUserHomeExpansion(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testConstrainedUpdates(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testCtrlD(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testEnvInStartUp(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testFeedbackNegative(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testFeedbackNormal(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testFeedbackSilent(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testHistoryReference(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testIndent(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testInterrupt(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testLoadingFromArgs(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testModulePath(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testModulePathUserHomeExpansion(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testOpen(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testOpenFileOverHttp(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testOpenLocalFileUrl(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testOpenResource(): failure
>     java.lang.AssertionError: user output: printf("%4.2f", Math.PI).
>      expected [3.14] but found [3,14]
>             at org.testng.Assert.fail(Assert.java:94)
>             at org.testng.Assert.failNotEquals(Assert.java:496)
>             at org.testng.Assert.assertEquals(Assert.java:125)
>             at org.testng.Assert.assertEquals(Assert.java:178)
>             at ReplToolTesting.assertOutput(ReplToolTesting.java:529)
>             at ReplToolTesting.assertCommand(ReplToolTesting.java:513)
>             at ToolBasicTest.lambda$testOpenResource$118(ToolBasicTest.java:559)
>             at ReplToolTesting$PromptedCommandOutputStream.write(ReplToolTesting.java:824)
>             at java.base/java.io.PrintStream.write(PrintStream.java:536)
>             at jdk.internal.le/jdk.internal.org.jline.terminal.impl.LineDisciplineTerminal.processOutputByte(LineDisciplineTerminal.java:253)
>             at jdk.internal.le/jdk.internal.org.jline.terminal.impl.LineDisciplineTerminal$FilteringOutputStream.write(LineDisciplineTerminal.java:294)
>             at java.base/sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:242)
>             at java.base/sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:321)
>             at java.base/sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:325)
>             at java.base/sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:159)
>             at java.base/java.io.OutputStreamWriter.flush(OutputStreamWriter.java:248)
>             at java.base/java.io.PrintWriter.flush(PrintWriter.java:396)
>             at jdk.internal.le/jdk.internal.org.jline.terminal.impl.AbstractTerminal.flush(AbstractTerminal.java:174)
>             at jdk.internal.le/jdk.internal.org.jline.utils.Display.update(Display.java:336)
>             at jdk.internal.le/jdk.internal.org.jline.reader.impl.LineReaderImpl.redisplay(LineReaderImpl.java:3943)
>             at jdk.internal.le/jdk.internal.org.jline.reader.impl.LineReaderImpl.redisplay(LineReaderImpl.java:3803)
>             at jdk.internal.le/jdk.internal.org.jline.reader.impl.LineReaderImpl.readLine(LineReaderImpl.java:626)
>             at jdk.internal.le/jdk.internal.org.jline.reader.impl.LineReaderImpl.readLine(LineReaderImpl.java:454)
>             at jdk.jshell/jdk.internal.jshell.tool.ConsoleIOContext.readLine(ConsoleIOContext.java:233)
>             at jdk.jshell/jdk.internal.jshell.tool.JShellTool.getInput(JShellTool.java:1263)
>             at jdk.jshell/jdk.internal.jshell.tool.JShellTool.run(JShellTool.java:1199)
>             at jdk.jshell/jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:991)
>             at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder.run(JShellToolBuilder.java:240)
>             at ReplToolTesting.testRawRun(ReplToolTesting.java:313)
>             at ReplToolTesting.testRaw(ReplToolTesting.java:296)
>             at ReplToolTesting.test(ReplToolTesting.java:249)
>             at ReplToolTesting.test(ReplToolTesting.java:233)
>             at ReplToolTesting.test(ReplToolTesting.java:229)
>             at ReplToolTesting.test(ReplToolTesting.java:225)
>             at ToolBasicTest.testOpenResource(ToolBasicTest.java:555)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>             at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85)
>             at org.testng.internal.Invoker.invokeMethod(Invoker.java:639)
>             at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:821)
>             at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1131)
>             at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
>             at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108)
>             at org.testng.TestRunner.privateRun(TestRunner.java:773)
>             at org.testng.TestRunner.run(TestRunner.java:623)
>             at org.testng.SuiteRunner.runTest(SuiteRunner.java:357)
>             at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:352)
>             at org.testng.SuiteRunner.privateRun(SuiteRunner.java:310)
>             at org.testng.SuiteRunner.run(SuiteRunner.java:259)
>             at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
>             at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
>             at org.testng.TestNG.runSuitesSequentially(TestNG.java:1185)
>             at org.testng.TestNG.runSuitesLocally(TestNG.java:1110)
>             at org.testng.TestNG.run(TestNG.java:1018)
>             at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>             at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
>             at java.base/java.lang.Thread.run(Thread.java:831)
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testRedeclareVariableNoInit(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testRemoteExit(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testRerun(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testRerunIdRange(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testReset(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testSave(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testStartRetain(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testStartSave(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testStartupFileOption(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testStop(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testVarsWithNotActive(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testWarningUnchecked(): success
> 
>     ===============================================
>     jdk/jshell/ToolBasicTest.java
>     Total tests run: 38, Failures: 1, Skips: 0
>     ===============================================
> 
>     STDERR:
>     java.io.EOFException
>             at java.base/java.io.DataInputStream.readInt(DataInputStream.java:398)
>             at java.base/java.io.ObjectInputStream$BlockDataInputStream.readInt(ObjectInputStream.java:3381)
>             at java.base/java.io.ObjectInputStream.readInt(ObjectInputStream.java:1113)
>             at jdk.jshell/jdk.jshell.execution.StreamingExecutionControl.readAndReportExecutionResult(StreamingExecutionControl.java:277)
>             at jdk.jshell/jdk.jshell.execution.StreamingExecutionControl.invoke(StreamingExecutionControl.java:99)
>             at jdk.jshell/jdk.jshell.execution.JdiDefaultExecutionControl.invoke(JdiDefaultExecutionControl.java:160)
>             at jdk.jshell/jdk.jshell.Eval.declare(Eval.java:943)
>             at jdk.jshell/jdk.jshell.Eval.eval(Eval.java:139)
>             at jdk.jshell/jdk.jshell.JShell.eval(JShell.java:493)
>             at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processSource(JShellTool.java:3609)
>             at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processSourceCatchingReset(JShellTool.java:1330)
>             at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processInput(JShellTool.java:1228)
>             at jdk.jshell/jdk.internal.jshell.tool.JShellTool.run(JShellTool.java:1201)
>             at jdk.jshell/jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:991)
>             at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder.run(JShellToolBuilder.java:240)
>             at ReplToolTesting.testRawRun(ReplToolTesting.java:313)
>             at ReplToolTesting.testRaw(ReplToolTesting.java:296)
>             at ReplToolTesting.test(ReplToolTesting.java:249)
>             at ReplToolTesting.test(ReplToolTesting.java:233)
>             at ReplToolTesting.test(ReplToolTesting.java:229)
>             at ReplToolTesting.test(ReplToolTesting.java:225)
>             at ToolBasicTest.testRemoteExit(ToolBasicTest.java:680)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>             at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85)
>             at org.testng.internal.Invoker.invokeMethod(Invoker.java:639)
>             at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:821)
>             at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1131)
>             at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
>             at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108)
>             at org.testng.TestRunner.privateRun(TestRunner.java:773)
>             at org.testng.TestRunner.run(TestRunner.java:623)
>             at org.testng.SuiteRunner.runTest(SuiteRunner.java:357)
>             at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:352)
>             at org.testng.SuiteRunner.privateRun(SuiteRunner.java:310)
>             at org.testng.SuiteRunner.run(SuiteRunner.java:259)
>             at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
>             at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
>             at org.testng.TestNG.runSuitesSequentially(TestNG.java:1185)
>             at org.testng.TestNG.runSuitesLocally(TestNG.java:1110)
>             at org.testng.TestNG.run(TestNG.java:1018)
>             at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>             at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
>             at java.base/java.lang.Thread.run(Thread.java:831)
>     java.lang.Exception: failures: 1
>             at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:96)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>             at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
>             at java.base/java.lang.Thread.run(Thread.java:831)
> 
>     JavaTest Message: Test threw exception: java.lang.Exception
>     JavaTest Message: shutting down test
> 
> 
>     TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 1
> 
> https://bugs.openjdk.java.net/browse/JDK-8212234 looks like there is already known bug this test.

Hi @turbanoff, I ran tier 1-3 in our build and test system and can't reproduce the errors, they seem to be specific to the environment, as Alan hinted at. I also ran the jdk_jfr tests, which came back all clear. 
On another note, let's drop the change in sun.net.www.MimeLauncher, it's a jdk-internal class that is no longer used and can likely be removed. I opened a separate issue for that: https://bugs.openjdk.java.net/browse/JDK-8261750.

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

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

From akozlov at openjdk.java.net  Mon Feb 15 18:24:08 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Mon, 15 Feb 2021 18:24:08 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v17]
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: <fTuSHaE65Q_xmXehGoDytUozrl7npPs3jHk5thgJK7Y=.ba0935db-c145-449d-9b51-99a7e1c286e9@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 two additional commits since the last revision:

 - Merge pull request #9 from VladimirKempik/pull/2200
   
   Removed unused variables
 - Removed unused variables

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2200/files
  - new: https://git.openjdk.java.net/jdk/pull/2200/files/419c2b1a..90e244e9

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

  Stats: 5 lines in 1 file changed: 0 ins; 5 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 lucy at openjdk.java.net  Mon Feb 15 18:24:40 2021
From: lucy at openjdk.java.net (Lutz Schmidt)
Date: Mon, 15 Feb 2021 18:24:40 GMT
Subject: RFR: 8261447: MethodInvocationCounters frequently run into
 overflow [v3]
In-Reply-To: <CYjuoGXt_uPG61kL7K3H_hn5_FhZOFJcRDoBqrdmA2E=.cead0f6d-f1e3-4684-a061-9c98e3ae38e9@github.com>
References: <FsHAKG6KwqJeHLIhE6JroDUjiebdevi1asoLi-7pQ1s=.15d96719-36f2-4f9b-ae80-fcb17a3b6659@github.com>
 <VGY2qZPofTF4kvhoh2eb-gEVskrAllfc2qUGniHve9w=.a1bbf3d0-a7d5-4362-8511-13e6ad3f5b6d@github.com>
 <uGFfe_CAI9XwHObEA-aFoqIK3Q5IjyyU7Zon9Kbwu9U=.fc24b09f-7cd6-4cba-84f4-2e265fe94e7c@github.com>
 <P43LJp7pLJb8s3r1UsNiCMDTkbp_sTKER_4rG_ng2n0=.f150cfaa-d21e-45da-ad4f-0e2943df4903@github.com>
 <vf7HwmzLTAIky5AgfmR3V8tkK4YNDalAuUrF_wTuLSo=.319ec36f-a143-470f-bf88-9398678818f2@github.com>
 <7S5jdlFpZ5m2xtFinD92jQEQm6hgbQXjHR5N-3XbXkc=.fe75978e-860a-4bcc-b5b4-3e4b4246d706@github.com>
 <CYjuoGXt_uPG61kL7K3H_hn5_FhZOFJcRDoBqrdmA2E=.cead0f6d-f1e3-4684-a061-9c98e3ae38e9@github.com>
Message-ID: <LHuyBhuR161oF-i_GQ2E5AbhuaoyhhMp-6whlBrXYNY=.3f376a03-2ef5-41db-b618-84cc3bd96917@github.com>

On Fri, 12 Feb 2021 11:58:47 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:

>> I introduced the *64 suffixes to not break anything that still uses the old calls. As old uses disappear step by step, I'm more than happy to remove the suffixes. I will have a look into SA and try to make it 64bit counter ready. There may be no new version before the weekend is over.
>
> This is a request for help. Could someone with SA knowledge please check if my assumption is correct?
> 
> In hotspot code, the field Method::_compiled_invocation_count is annotated with a comment that it is used by SA. The field is also exposed via vmStructs.cpp to enable such use. I have scanned SA code in OpenJDK11 and OpenJDK head but found no evidence that this particular field is accessed. Is this finding/assumption correct? 
> 
> If so, I could just stop exposing the field, making my life easier. Thanks!

Looks like I have completely messed up my pull request. Please disregard for now. I'm trying to find a way how to clean up. Maybe I'll just start over.

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

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

From github.com+741251+turbanoff at openjdk.java.net  Mon Feb 15 18:33:00 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 15 Feb 2021 18:33:00 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v10]
In-Reply-To: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
Message-ID: <9lTugXVNgsP2Iodc0ZjSw_22QYFfEULBQjWJpsAO538=.cfa40743-69f7-4880-8cae-712fb7343b0b@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 java.io.InputStream.transferTo
  revert changes from MimeLauncher

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1853/files
  - new: https://git.openjdk.java.net/jdk/pull/1853/files/6a8a3ae6..6614a10f

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

  Stats: 19 lines in 1 file changed: 11 ins; 0 del; 8 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 mcimadamore at openjdk.java.net  Mon Feb 15 18:53:42 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 15 Feb 2021 18:53:42 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v10]
In-Reply-To: <9lTugXVNgsP2Iodc0ZjSw_22QYFfEULBQjWJpsAO538=.cfa40743-69f7-4880-8cae-712fb7343b0b@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <9lTugXVNgsP2Iodc0ZjSw_22QYFfEULBQjWJpsAO538=.cfa40743-69f7-4880-8cae-712fb7343b0b@github.com>
Message-ID: <bGxQrdluW173rFjTwG5zYUl1cZwn8lvGizAGigtKVjY=.b3ddba92-d8f0-48d3-a99e-4a102c447832@github.com>

On Mon, 15 Feb 2021 18:33:00 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
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
>   revert changes from MimeLauncher

The changes to sjavac changes look good

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

Marked as reviewed by mcimadamore (Reviewer).

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

From aph at openjdk.java.net  Mon Feb 15 19:10:47 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Mon, 15 Feb 2021 19:10:47 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v8]
In-Reply-To: <M33x5HsjKpNTd34OwGfLGI3ACvCgb_oC4YnvKYF4TLA=.7d7d9112-a638-40bb-8309-0e8ab7743ee1@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <ugV_PtxgaQkJQw3i1cwYiaKZ46--TZfgdVsuhQd5_3Y=.5b39eb44-1398-41b1-8bdf-2e6a3149e865@github.com>
 <cpf_Q2rM76sr9dlOexk27XKGxtOK41AJxugL6Le19Mo=.d77cc563-81b2-4d14-8ed4-f34d97a7b75a@github.com>
 <M33x5HsjKpNTd34OwGfLGI3ACvCgb_oC4YnvKYF4TLA=.7d7d9112-a638-40bb-8309-0e8ab7743ee1@github.com>
Message-ID: <L1ugpaepjpPyipb5LZV3HBogQkyr_zp5Pfyk_iRskKU=.0583664a-0c58-4817-96eb-ffe96dae4fda@github.com>

On Mon, 15 Feb 2021 18:00:50 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 839:
>> 
>>> 837:           // The code unable to handle this, bailout.
>>> 838:           return -1;
>>> 839: #endif
>> 
>> This looks like a bug to me. The caller doesn't necessarily check the return value. See CallRuntimeNode::calling_convention.
>
> 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

This is when passing a float, yes? In the case where we have more float arguments than n_float_register_parameters_c.
I don't understand why you think it's acceptable to bail in this case. Can you explain, please?

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

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

From sgehwolf at openjdk.java.net  Mon Feb 15 19:24:40 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Mon, 15 Feb 2021 19:24:40 GMT
Subject: RFR: 8261607: SA attach is exceeding JNI Local Refs capacity [v2]
In-Reply-To: <LsTaNHOI0zMiyOJ1Cj9fcm_M3kAOCtbp3aTM0Ef2uYo=.cf36b828-37fa-4fec-81c9-a302d3b702ee@github.com>
References: <RoYVASDz0Y5cNK3fwa8MhvCxcN1S4hQNYFdRD60H5lE=.892a258a-5bb2-40f4-ad42-24a7bf365463@github.com>
 <LsTaNHOI0zMiyOJ1Cj9fcm_M3kAOCtbp3aTM0Ef2uYo=.cf36b828-37fa-4fec-81c9-a302d3b702ee@github.com>
Message-ID: <p8-nvuiIDjdoLZ-sFAsVVZN6MGTVgz1TseVsIaHffb0=.f93b0dd6-dd98-4d07-8bbd-d1c5c03ec16a@github.com>

On Mon, 15 Feb 2021 17:53:58 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Delete some localrefs to avoid -Xcheck:jni warnings. See CR for details.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment

Other than the comment suggestion this looks reasonable to me.

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

Marked as reviewed by sgehwolf (Reviewer).

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

From alanb at openjdk.java.net  Mon Feb 15 19:25:42 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 15 Feb 2021 19:25:42 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v10]
In-Reply-To: <9lTugXVNgsP2Iodc0ZjSw_22QYFfEULBQjWJpsAO538=.cfa40743-69f7-4880-8cae-712fb7343b0b@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <9lTugXVNgsP2Iodc0ZjSw_22QYFfEULBQjWJpsAO538=.cfa40743-69f7-4880-8cae-712fb7343b0b@github.com>
Message-ID: <bE94jmbj13PX9IS1rm73TwDkw1DghCm5yNNNuWkX4wY=.b182fc1e-076e-4951-adae-16834df72cfc@github.com>

On Mon, 15 Feb 2021 18:33:00 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
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
>   revert changes from MimeLauncher

src/java.management/share/classes/javax/management/loading/MLet.java line 1149:

> 1147:                      file.deleteOnExit();
> 1148:                      Files.copy(is, file.toPath(), StandardCopyOption.REPLACE_EXISTING);
> 1149:                      if (file.exists()) {

You might have missed the comment from a previous iteration. The files.exists() check goes away when Files.copy succeeds.

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

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

From amenkov at openjdk.java.net  Mon Feb 15 19:26:43 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Mon, 15 Feb 2021 19:26:43 GMT
Subject: RFR: 8261711: Clhsdb "versioncheck true" throws NPE every time
In-Reply-To: <No2GR3rp5bVBhvfB2ztAqX9KWhT7RygtyPfTYijSMTs=.cc1a7cb3-4b95-4a1c-abbb-63bf52459ab2@github.com>
References: <No2GR3rp5bVBhvfB2ztAqX9KWhT7RygtyPfTYijSMTs=.cc1a7cb3-4b95-4a1c-abbb-63bf52459ab2@github.com>
Message-ID: <9pta6M_V41_iStOTMnZe9u8okybod7L8vW3mmyoqbkE=.876f2644-3d00-44bb-bc0f-bc91a4529386@github.com>

On Sun, 14 Feb 2021 09:14:43 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> See CR for details. There's no test for `versioncheck`, and I don't think it's worth adding, especially for this trivial fix. Here's how I tested:
> hsdb> versioncheck
> versioncheck is true
> hsdb> versioncheck false
> hsdb> versioncheck
> versioncheck is false
> hsdb> versioncheck true
> hsdb> versioncheck
> versioncheck is true

Marked as reviewed by amenkov (Reviewer).

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

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

From amenkov at openjdk.java.net  Mon Feb 15 19:45:40 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Mon, 15 Feb 2021 19:45:40 GMT
Subject: RFR: 8261692:  Bugs in clhsdb history support
In-Reply-To: <3-9ngFZ9SzLX-MwIVN4fDjJAnbjqkt5Q0U8mah-tzHc=.ce625e90-080f-41b4-9227-771ea43b10b7@github.com>
References: <3-9ngFZ9SzLX-MwIVN4fDjJAnbjqkt5Q0U8mah-tzHc=.ce625e90-080f-41b4-9227-771ea43b10b7@github.com>
Message-ID: <NuIHjg6bpq7Z0vu7faFx8syuEYPE4oBXelIwNSpbpzs=.56f86636-09ee-4147-9a2b-7bcdede512ab@github.com>

On Sun, 14 Feb 2021 08:45:26 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> See the CR for a description of the 3 issues fixed. There's also a new test added. I'll explain the fix related to quoting the '!' here since it's not that obvious how it works.
> 
> There's a complex pattern called `historyPattern` that is used to find various uses of ! to do expansion of commands and arguments in the history
> 
>     static Pattern historyPattern = Pattern.compile("([\\\]?)((!\*)|(!\$)|(!!-?)|(!-?[0-9][0-9]*)|(![a-zA-Z][^ ]*))");
> 
> I added the `([\\\]?)` part to handle allowing a '!' to be quoted with a backslash so it will just be treated as a '!' instead of being used for history expansion. This part of the pattern basically says match 1 backslash if present. Yes, you need 4 backslashes to do this. javac will reduce it to two, and then the pattern compilation reduces it down to just one backslash (not to be used for quoting).
> 
> The above pattern for searching for the backslash before a '!' is in the first pattern grouping, and the part that matches on the '!' and what follows is in the 2nd pattern grouping. Thus the code I added checks if the first pattern grouping matches something (and at most it will match just one backslash), and if so then we eat it and don't treat the '!' that follows as a history expansion:
> 
>                     if (m.group(1).length() != 0) {
>                         // This means we matched a `` before the '!'. Don't do any history
>                         // expansion in this case. Just capture what matched after the ``.
>                         result.append(m.group(2));
>                         continue;
>                     }

Marked as reviewed by amenkov (Reviewer).

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

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

From github.com+741251+turbanoff at openjdk.java.net  Mon Feb 15 19:47:00 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 15 Feb 2021 19:47:00 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v11]
In-Reply-To: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
Message-ID: <djPl7TL8j0qwyuLjwnZI96g7UPmw3XamdbVltf8fbos=.36a5bbe7-1fd0-496b-999f-7c49d06fc0a8@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 java.io.InputStream.transferTo
  remove unnecessary file.exists() check

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1853/files
  - new: https://git.openjdk.java.net/jdk/pull/1853/files/6614a10f..6e71e961

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

  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 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 github.com+741251+turbanoff at openjdk.java.net  Mon Feb 15 19:47:01 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 15 Feb 2021 19:47:01 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v10]
In-Reply-To: <bE94jmbj13PX9IS1rm73TwDkw1DghCm5yNNNuWkX4wY=.b182fc1e-076e-4951-adae-16834df72cfc@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <9lTugXVNgsP2Iodc0ZjSw_22QYFfEULBQjWJpsAO538=.cfa40743-69f7-4880-8cae-712fb7343b0b@github.com>
 <bE94jmbj13PX9IS1rm73TwDkw1DghCm5yNNNuWkX4wY=.b182fc1e-076e-4951-adae-16834df72cfc@github.com>
Message-ID: <7bSIORe_urCOaP-rcSwcaRkhFU0rymCRLOk5s3t3PF4=.c340769a-e407-44c1-8704-fc7ea5eb7411@github.com>

On Mon, 15 Feb 2021 19:23:16 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
>>   revert changes from MimeLauncher
>
> src/java.management/share/classes/javax/management/loading/MLet.java line 1149:
> 
>> 1147:                      file.deleteOnExit();
>> 1148:                      Files.copy(is, file.toPath(), StandardCopyOption.REPLACE_EXISTING);
>> 1149:                      if (file.exists()) {
> 
> You might have missed the comment from a previous iteration. The files.exists() check goes away when Files.copy succeeds.

You are right. Fixed.

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

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

From cjplummer at openjdk.java.net  Mon Feb 15 20:10:02 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Mon, 15 Feb 2021 20:10:02 GMT
Subject: RFR: 8261607: SA attach is exceeding JNI Local Refs capacity [v3]
In-Reply-To: <RoYVASDz0Y5cNK3fwa8MhvCxcN1S4hQNYFdRD60H5lE=.892a258a-5bb2-40f4-ad42-24a7bf365463@github.com>
References: <RoYVASDz0Y5cNK3fwa8MhvCxcN1S4hQNYFdRD60H5lE=.892a258a-5bb2-40f4-ad42-24a7bf365463@github.com>
Message-ID: <DWmzxc9z4SzjaUEcjtc1SAvr4dqrenNEIhSnMIHZvYk=.399d57df-a0dd-40f5-8191-1d927bc65f74@github.com>

> Delete some localrefs to avoid -Xcheck:jni warnings. See CR for details.

Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:

  Fix comment

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2568/files
  - new: https://git.openjdk.java.net/jdk/pull/2568/files/21ff3296..e018e781

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

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

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

From cjplummer at openjdk.java.net  Mon Feb 15 20:10:02 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Mon, 15 Feb 2021 20:10:02 GMT
Subject: RFR: 8261607: SA attach is exceeding JNI Local Refs capacity [v3]
In-Reply-To: <TmtrKuBYcbsfREBLvR5hm-ry84euOhtTkqLjm8TzhsA=.47e895d8-c49f-48aa-b4dc-ecf8d8086ad6@github.com>
References: <RoYVASDz0Y5cNK3fwa8MhvCxcN1S4hQNYFdRD60H5lE=.892a258a-5bb2-40f4-ad42-24a7bf365463@github.com>
 <10xLiGUOC8YGo24dJQFk8_oX84_BDhhqvjxvlgNsm6w=.dd17f959-c558-4980-b031-84a47a461ae2@github.com>
 <CWfjZAfIUEFvE4zAWiUvFG7UETvghFl_bRfmPEB3Yag=.5f580a40-c956-4782-937b-29201a575beb@github.com>
 <TmtrKuBYcbsfREBLvR5hm-ry84euOhtTkqLjm8TzhsA=.47e895d8-c49f-48aa-b4dc-ecf8d8086ad6@github.com>
Message-ID: <pIXT5wwiXl36TPDmCJW8FWCw_PiEf4pNFMHRXryN7nE=.87471961-37dc-45ed-9240-98d22645dc47@github.com>

On Mon, 15 Feb 2021 18:09:45 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Although no Clhsdb test is explicitly always runs with `-Xcheck:jni`, the option can be added to any test run. For example:
>> 
>> `$ make test  TEST=open/test/hotspot/jtreg/serviceability/sa/ TEST_VM_OPTS="-Xcheck:jni"`
>> 
>> This matching is done to make sure there are no warnings when the test is run in this manner. The matching could be conditional on the test being run with  `-Xcheck:jni`, but I don't really see to point in cluttering up the logic with such a check since the warnings should never appear, whether or not you are using `-Xcheck:jni`.
>
> OK, I thought so. Could you expand on the comment saying so, please? Suggestion: `Make sure there are no -Xcheck:jni warnings as -Xcheck:jni might be set via TEST_VM_OPTS on test runs`.

Ok, the comment has been updated. Thanks!

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

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

From cjplummer at openjdk.java.net  Mon Feb 15 20:19:51 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Mon, 15 Feb 2021 20:19:51 GMT
Subject: RFR: 8261098: Add clhsdb "findsym" command [v2]
In-Reply-To: <EcsJkvo_wYh085Hc1uRmViYzUrsfMeNLFOEsn0YSyXs=.8243bb41-62d6-40a0-8942-650a9cd8a497@github.com>
References: <EcsJkvo_wYh085Hc1uRmViYzUrsfMeNLFOEsn0YSyXs=.8243bb41-62d6-40a0-8942-650a9cd8a497@github.com>
Message-ID: <XpoVBbUrUuf02j_bS6z7r0n8_kLJ5mr9pBqNHMyfDaA=.5123143d-94ff-46d1-99e4-5cde39521f94@github.com>

> Add "findsym" to clhsdb. See the CR and CSR for details. The [CSR](https://bugs.openjdk.java.net/browse/JDK-8261101) still needs a reviewer.
> 
> There is a fix in LinuxDebuggerLocal_lookupByName0() to allow passing in NULL for the dso name. This is allowed, and in fact even not null it gets ignored. It is needed by the new findsym support in order for the following to work, which passes in null for the dso name:
> 
> `    Address addr = VM.getVM().getDebugger().lookup(null, symbol);`
> 
> There is one other somewhat unrelated fix in the test:
> 
>  -            String value = parts[1];
>  +           String value = parts[1].split(linesep)[0];
> 
> This is suppose to capture just the value at the specified address, but it also captures the newline and some text after. The result if that when `findpc <value>` is executed, it also executes another command or two of garbage commands after that, which produce errors. They were not impacting the test, but were noticeable in the log. I first noticed it when similar code in the new part of the test had the same issue.

Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:

  Fix issue with findsym on windows build that doesn't have symbolic information.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2567/files
  - new: https://git.openjdk.java.net/jdk/pull/2567/files/8c6d9727..ba3464c4

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

  Stats: 29 lines in 1 file changed: 15 ins; 1 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2567.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2567/head:pull/2567

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

From amenkov at openjdk.java.net  Mon Feb 15 23:49:40 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Mon, 15 Feb 2021 23:49:40 GMT
Subject: RFR: 8261098: Add clhsdb "findsym" command [v2]
In-Reply-To: <XpoVBbUrUuf02j_bS6z7r0n8_kLJ5mr9pBqNHMyfDaA=.5123143d-94ff-46d1-99e4-5cde39521f94@github.com>
References: <EcsJkvo_wYh085Hc1uRmViYzUrsfMeNLFOEsn0YSyXs=.8243bb41-62d6-40a0-8942-650a9cd8a497@github.com>
 <XpoVBbUrUuf02j_bS6z7r0n8_kLJ5mr9pBqNHMyfDaA=.5123143d-94ff-46d1-99e4-5cde39521f94@github.com>
Message-ID: <lI7tcyHdEBpm9SzHKl8HINpyuKK88zX-XXDfn8gnJ7s=.f54d9d66-2d91-40ba-8feb-125e5155cb5f@github.com>

On Mon, 15 Feb 2021 20:19:51 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Add "findsym" to clhsdb. See the CR and CSR for details. The [CSR](https://bugs.openjdk.java.net/browse/JDK-8261101) still needs a reviewer.
>> 
>> There is a fix in LinuxDebuggerLocal_lookupByName0() to allow passing in NULL for the dso name. This is allowed, and in fact even not null it gets ignored. It is needed by the new findsym support in order for the following to work, which passes in null for the dso name:
>> 
>> `    Address addr = VM.getVM().getDebugger().lookup(null, symbol);`
>> 
>> There is one other somewhat unrelated fix in the test:
>> 
>>  -            String value = parts[1];
>>  +           String value = parts[1].split(linesep)[0];
>> 
>> This is suppose to capture just the value at the specified address, but it also captures the newline and some text after. The result if that when `findpc <value>` is executed, it also executes another command or two of garbage commands after that, which produce errors. They were not impacting the test, but were noticeable in the log. I first noticed it when similar code in the new part of the test had the same issue.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix issue with findsym on windows build that doesn't have symbolic information.

Changes requested by amenkov (Reviewer).

src/jdk.hotspot.agent/linux/native/libsaproc/LinuxDebuggerLocal.cpp line 350:

> 348:   // Note, objectName is ignored, and may in fact be NULL.
> 349:   // lookup_symbol will always search all objects/libs
> 350:   //AutoJavaString objectName_cstr(env, objectName);

I think it would be better to update AutoJavaString class to handle null strings:
`m_buf(str == NULL ? NULL : env->GetStringUTFChars(str, NULL)) `

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

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

From amenkov at openjdk.java.net  Tue Feb 16 00:17:40 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Tue, 16 Feb 2021 00:17:40 GMT
Subject: RFR: 8261607: SA attach is exceeding JNI Local Refs capacity [v3]
In-Reply-To: <DWmzxc9z4SzjaUEcjtc1SAvr4dqrenNEIhSnMIHZvYk=.399d57df-a0dd-40f5-8191-1d927bc65f74@github.com>
References: <RoYVASDz0Y5cNK3fwa8MhvCxcN1S4hQNYFdRD60H5lE=.892a258a-5bb2-40f4-ad42-24a7bf365463@github.com>
 <DWmzxc9z4SzjaUEcjtc1SAvr4dqrenNEIhSnMIHZvYk=.399d57df-a0dd-40f5-8191-1d927bc65f74@github.com>
Message-ID: <3Qx8G3xczRX76xbTgbVNwxLqwKkFJ6ZXwPVnbVea2N4=.1e0e263c-3f12-4dfd-963b-ae70e8630e98@github.com>

On Mon, 15 Feb 2021 20:10:02 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Delete some localrefs to avoid -Xcheck:jni warnings. See CR for details.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment

Marked as reviewed by amenkov (Reviewer).

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

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

From cjplummer at openjdk.java.net  Tue Feb 16 01:29:41 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 16 Feb 2021 01:29:41 GMT
Subject: RFR: 8261098: Add clhsdb "findsym" command [v2]
In-Reply-To: <lI7tcyHdEBpm9SzHKl8HINpyuKK88zX-XXDfn8gnJ7s=.f54d9d66-2d91-40ba-8feb-125e5155cb5f@github.com>
References: <EcsJkvo_wYh085Hc1uRmViYzUrsfMeNLFOEsn0YSyXs=.8243bb41-62d6-40a0-8942-650a9cd8a497@github.com>
 <XpoVBbUrUuf02j_bS6z7r0n8_kLJ5mr9pBqNHMyfDaA=.5123143d-94ff-46d1-99e4-5cde39521f94@github.com>
 <lI7tcyHdEBpm9SzHKl8HINpyuKK88zX-XXDfn8gnJ7s=.f54d9d66-2d91-40ba-8feb-125e5155cb5f@github.com>
Message-ID: <3_RpSFsQ7C7vUSRMdLyweUkxbKO23xTI_hkiT4NJOYs=.3eecb45b-0b09-4801-aba6-30226839ae40@github.com>

On Mon, 15 Feb 2021 23:15:46 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix issue with findsym on windows build that doesn't have symbolic information.
>
> src/jdk.hotspot.agent/linux/native/libsaproc/LinuxDebuggerLocal.cpp line 350:
> 
>> 348:   // Note, objectName is ignored, and may in fact be NULL.
>> 349:   // lookup_symbol will always search all objects/libs
>> 350:   //AutoJavaString objectName_cstr(env, objectName);
> 
> I think it would be better to update AutoJavaString class to handle null strings:
> `m_buf(str == NULL ? NULL : env->GetStringUTFChars(str, NULL)) `

The point is the argument is ignored, so it doesn't really matter if AutoJavaString can handle NULL. I  assume with your suggested fix that also want me to pass objectName_cstr to lookup_symbol() rather than an explicit NULL. I wanted the NULL to be explicit to help further convey that objectName is ignored.

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

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

From ysuenaga at openjdk.java.net  Tue Feb 16 01:39:38 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Tue, 16 Feb 2021 01:39:38 GMT
Subject: RFR: 8261710: SA DSO objects have sizes that are too large
In-Reply-To: <IlGty_H4BHMqmDRi0pWscIAKdyR_nKLI-Ceea9bcxTg=.e9a47c72-cfa8-41d1-8e05-ebde39ac1f24@github.com>
References: <rtxSvuvKLmHKrLtsnxf76vSK41b_HWPR_7Bn3wf9YuM=.cf1b54ae-f01d-48d5-9641-d7d9faa541f5@github.com>
 <IlGty_H4BHMqmDRi0pWscIAKdyR_nKLI-Ceea9bcxTg=.e9a47c72-cfa8-41d1-8e05-ebde39ac1f24@github.com>
Message-ID: <k6gxI6l5dgq2xN_8E9tplZqbml81gL1BpsQTd8kdE1s=.7b29334e-0f12-473b-b2f2-7b355cd5d90b@github.com>

On Mon, 15 Feb 2021 06:43:30 GMT, Chris Plummer <cjplummer 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.
>
> These changes look good, but it would be nice to fix OSX too. Fortunately it should be easier. As part of the fix for [JDK-8247515](https://bugs.openjdk.java.net/browse/JDK-8247515), I added a `lib_info->memsz` field. I think it is correct and is what you need. I needed it in order to properly scan .dylibs for symbols without scanning too far. It seems to be working. Unfortunately we don't really have a good tests for this, but you could look at the before and after for ClhsdbPmap test to get an idea of if it is working. If you don't have an OSX machine to try, I can try out your changes for you.
> 
> BTW, I have no idea if Windows is getting the size right, but I guess we'll just have to assume it is:
> 
>     env->CallVoidMethod(obj, addLoadObject_ID, strName, (jlong) params[u].Size,
>                         (jlong) params[u].Base);

@plummercj Thanks for the review!

> These changes look good, but it would be nice to fix OSX too. Fortunately it should be easier. As part of the fix for [JDK-8247515](https://bugs.openjdk.java.net/browse/JDK-8247515), I added a `lib_info->memsz` field. I think it is correct and is what you need.

AFAICS `lib_info->memsz` is not set to loaded size, it seems to relates to the offset of the symbol in the binary.

https://github.com/openjdk/jdk/blob/34ae7aeb64db90dcb4d2f3d4acb16c714a32824f/src/jdk.hotspot.agent/macosx/native/libsaproc/libproc_impl.c#L261
https://github.com/openjdk/jdk/blob/34ae7aeb64db90dcb4d2f3d4acb16c714a32824f/src/jdk.hotspot.agent/macosx/native/libsaproc/symtab.c#L185

Can I believe `lib_info->memsz` for this purpose?
I'm not familiar of Mach-O, and I don't have Mac, so I can't evaluate it.

> I needed it in order to properly scan .dylibs for symbols without scanning too far. It seems to be working. Unfortunately we don't really have a good tests for this, but you could look at the before and after for ClhsdbPmap test to get an idea of if it is working. If you don't have an OSX machine to try, I can try out your changes for you.

In process attach on Linux, we can test the change with /proc/<PID>/maps, but in other case, we might not test it.
In coredump on Linux, it is difficult because we cannot get memory map from other source (excepts the core).

> BTW, I have no idea if Windows is getting the size right, but I guess we'll just have to assume it is:
> 
> ```
>     env->CallVoidMethod(obj, addLoadObject_ID, strName, (jlong) params[u].Size,
>                         (jlong) params[u].Base);
> ```

According to [Microsoft Docs](https://docs.microsoft.com/ja-jp/windows-hardware/drivers/ddi/dbgeng/ns-dbgeng-_debug_module_parameters), it sounds good.

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

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

From cjplummer at openjdk.java.net  Tue Feb 16 02:48:38 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 16 Feb 2021 02:48:38 GMT
Subject: RFR: 8261710: SA DSO objects have sizes that are too large
In-Reply-To: <k6gxI6l5dgq2xN_8E9tplZqbml81gL1BpsQTd8kdE1s=.7b29334e-0f12-473b-b2f2-7b355cd5d90b@github.com>
References: <rtxSvuvKLmHKrLtsnxf76vSK41b_HWPR_7Bn3wf9YuM=.cf1b54ae-f01d-48d5-9641-d7d9faa541f5@github.com>
 <IlGty_H4BHMqmDRi0pWscIAKdyR_nKLI-Ceea9bcxTg=.e9a47c72-cfa8-41d1-8e05-ebde39ac1f24@github.com>
 <k6gxI6l5dgq2xN_8E9tplZqbml81gL1BpsQTd8kdE1s=.7b29334e-0f12-473b-b2f2-7b355cd5d90b@github.com>
Message-ID: <mUhWqJm-RdRly_sRdxywcm_04PQHZsOaLBf8zi-viqE=.13b1cf2d-990b-4ef9-99b5-f8186c120671@github.com>

On Tue, 16 Feb 2021 01:37:15 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> These changes look good, but it would be nice to fix OSX too. Fortunately it should be easier. As part of the fix for [JDK-8247515](https://bugs.openjdk.java.net/browse/JDK-8247515), I added a `lib_info->memsz` field. I think it is correct and is what you need. I needed it in order to properly scan .dylibs for symbols without scanning too far. It seems to be working. Unfortunately we don't really have a good tests for this, but you could look at the before and after for ClhsdbPmap test to get an idea of if it is working. If you don't have an OSX machine to try, I can try out your changes for you.
>> 
>> BTW, I have no idea if Windows is getting the size right, but I guess we'll just have to assume it is:
>> 
>>     env->CallVoidMethod(obj, addLoadObject_ID, strName, (jlong) params[u].Size,
>>                         (jlong) params[u].Base);
>
> @plummercj Thanks for the review!
> 
>> These changes look good, but it would be nice to fix OSX too. Fortunately it should be easier. As part of the fix for [JDK-8247515](https://bugs.openjdk.java.net/browse/JDK-8247515), I added a `lib_info->memsz` field. I think it is correct and is what you need.
> 
> AFAICS `lib_info->memsz` is not set to loaded size, it seems to relates to the offset of the symbol in the binary.
> 
> https://github.com/openjdk/jdk/blob/34ae7aeb64db90dcb4d2f3d4acb16c714a32824f/src/jdk.hotspot.agent/macosx/native/libsaproc/libproc_impl.c#L261
> https://github.com/openjdk/jdk/blob/34ae7aeb64db90dcb4d2f3d4acb16c714a32824f/src/jdk.hotspot.agent/macosx/native/libsaproc/symtab.c#L185
> 
> Can I believe `lib_info->memsz` for this purpose?
> I'm not familiar of Mach-O, and I don't have Mac, so I can't evaluate it.
> 
>> I needed it in order to properly scan .dylibs for symbols without scanning too far. It seems to be working. Unfortunately we don't really have a good tests for this, but you could look at the before and after for ClhsdbPmap test to get an idea of if it is working. If you don't have an OSX machine to try, I can try out your changes for you.
> 
> In process attach on Linux, we can test the change with /proc/<PID>/maps, but in other case, we might not test it.
> In coredump on Linux, it is difficult because we cannot get memory map from other source (excepts the core).
> 
>> BTW, I have no idea if Windows is getting the size right, but I guess we'll just have to assume it is:
>> 
>> ```
>>     env->CallVoidMethod(obj, addLoadObject_ID, strName, (jlong) params[u].Size,
>>                         (jlong) params[u].Base);
>> ```
> 
> According to [Microsoft Docs](https://docs.microsoft.com/ja-jp/windows-hardware/drivers/ddi/dbgeng/ns-dbgeng-_debug_module_parameters), it sounds good.

https://bugs.openjdk.java.net/browse/JDK-8250750 has some interesting details that I forgot about. Note this is referencing the state of the code before fixing JDK-8250750, which changed how `lib->memsz` is calculated.

> `lib->memsz` comes from the size of the `LC_SEGMENT_64` that the library was discovered in. However, the library can actually span multiple segments. In this case of the vtable address, the address was in the segment that follows the initial `LC_SEGMENT_64`. Because of this `lib->memsz` is too small, resulting in symbol lookups being restricted to addresses that are in the initial segment. 

>  The simplest approach to fixing this seems to be locating the largest offset found in the symbol table, round that up to a page boundary, and use it as `lib->memsz`. I've implemented this and it seems to be working. 

So it's not perfect, but I think it's good enough for our needs and better than using the file size and ending up with a size that is too big. I think the main way that this could fail is if you use `findpc` on an address that is beyond the last symbol (if it is even possible for there to be memory mapped at an address after the last symbol). In this case `findpc` will just say it doesn't know where the address is rather than saying it is in the dso + some very large offset. For symbols in the dso, they will always be found since lib`->memsz` now covers all symbols.

Also, since I never did figure out how to determine the size of a mach-o symbol, it's possible that the last symbol extends beyond the page boundary. If that is the case and you use `findpc` on and address that is part of the symbol but beyond the page boundary, `findpc` won't find it and say it doesn't know what the address is. So again, not perfect, but this issue can only happen with the last symbol in the dso, and only if the symbol crosses a page boundary, and only if the searched for address is after the page boundary. If you search for the start of the symbol, you'll still find it.

Having said all that, I think maybe we can get the correct size by taking the address of the highest symbol and then looking up the `map_info` that it is in. Then it's just a matter of adding `map->vaddr + map->memsz`. But this assumes that there are no more maps for the dso  after the one that has the last symbol, so maybe still not perfect. I'm not sure any of this extra work is worth it. When I dove into the mach-o support last year to fix some issues, it ended up being a huge rat hole that took way more of my time then I had expected. It was very badly broken, far worse then I first thought, and many things about mach-o core files were a mystery, and still remain so. For example, see https://bugs.openjdk.java.net/browse/JDK-8249779. We never did figure out how to create a link map.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2563

From vkempik at openjdk.java.net  Tue Feb 16 06:26:46 2021
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Tue, 16 Feb 2021 06:26:46 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v8]
In-Reply-To: <L1ugpaepjpPyipb5LZV3HBogQkyr_zp5Pfyk_iRskKU=.0583664a-0c58-4817-96eb-ffe96dae4fda@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <ugV_PtxgaQkJQw3i1cwYiaKZ46--TZfgdVsuhQd5_3Y=.5b39eb44-1398-41b1-8bdf-2e6a3149e865@github.com>
 <cpf_Q2rM76sr9dlOexk27XKGxtOK41AJxugL6Le19Mo=.d77cc563-81b2-4d14-8ed4-f34d97a7b75a@github.com>
 <M33x5HsjKpNTd34OwGfLGI3ACvCgb_oC4YnvKYF4TLA=.7d7d9112-a638-40bb-8309-0e8ab7743ee1@github.com>
 <L1ugpaepjpPyipb5LZV3HBogQkyr_zp5Pfyk_iRskKU=.0583664a-0c58-4817-96eb-ffe96dae4fda@github.com>
Message-ID: <ZUsF8QR6kEghT3bEUda2PuIvotR8sqMgfgkQG9dkHK0=.e9eee2a2-1953-43f8-8a7b-69b51f1dff96@github.com>

On Mon, 15 Feb 2021 19:07:40 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> 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
>
> This is when passing a float, yes? In the case where we have more float arguments than n_float_register_parameters_c.
> I don't understand why you think it's acceptable to bail in this case. Can you explain, please?

it's for everything that uses less than 8 bytes on a stack( ints ( 4), shorts(2), bytes(1), floats(4)).
currently native wrapper generation does not support such cases at all, it needs refactoring before this can be implemented.
So when a method has more argument than can be placed in registers, we may have issues. 

So we just bailing out to interpreter in case when a smaller (<=4 b) type is going to be passed thru the stack.

There was attempt to implement handling such cases but currently it requires some hacks (like using some vectors for non-specific task) - https://github.com/openjdk/aarch64-port/pull/3

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From cjplummer at openjdk.java.net  Tue Feb 16 07:33:47 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 16 Feb 2021 07:33:47 GMT
Subject: RFR: 8261269: When using clhsdb to "inspect" a java object,
 clhsdb prints "Oop for..." twice
Message-ID: <ZMXuV3A7BSpkJtmlUlvtMCL6beFGJNFWGxIbdMS9kYI=.b9e00805-9edc-4b29-b2e5-a8734791f4c0@github.com>

See CR for details. In brief, fixed the `inspect` command to remove duplicate output:

hsdb> inspect 0x00000007fef00770
instance of Oop for java/lang/Class @ 0x00000007fef00770 @ 0x00000007fef00770 (size = 160)
in: Oop for java/io/BufferedInputStream @ 0x0000000082005b08 Oop for java/io/BufferedInputStream @ 0x0000000082005b08
out: Oop for java/io/PrintStream @ 0x0000000082007b60 Oop for java/io/PrintStream @ 0x0000000082007b60
err: Oop for java/io/PrintStream @ 0x000000008200e0c8 Oop for java/io/PrintStream @ 0x000000008200e0c8 
It should be:

hsdb> inspect 0x00000007fef00770
instance of Oop for java/lang/Class @ 0x00000007fef00770 (size = 160)
in: Oop for java/io/BufferedInputStream @ 0x0000000082005b08
out: Oop for java/io/PrintStream @ 0x0000000082007b60
err: Oop for java/io/PrintStream @ 0x000000008200e0c8

-------------

Commit messages:
 - Fixed some comments.
 - Fixed some comments.
 - Fixed inspect command so it doesn't duplicate some output

Changes: https://git.openjdk.java.net/jdk/pull/2582/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2582&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8261269
  Stats: 116 lines in 2 files changed: 90 ins; 22 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2582.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2582/head:pull/2582

PR: https://git.openjdk.java.net/jdk/pull/2582

From alanb at openjdk.java.net  Tue Feb 16 07:42:40 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 16 Feb 2021 07:42:40 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v11]
In-Reply-To: <djPl7TL8j0qwyuLjwnZI96g7UPmw3XamdbVltf8fbos=.36a5bbe7-1fd0-496b-999f-7c49d06fc0a8@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <djPl7TL8j0qwyuLjwnZI96g7UPmw3XamdbVltf8fbos=.36a5bbe7-1fd0-496b-999f-7c49d06fc0a8@github.com>
Message-ID: <VUKHVu4XUJspWcev-cgNUDbKQWjIJZlg3pHgbn8u808=.e291d039-2af1-4d6e-ba17-bc38f8daee54@github.com>

On Mon, 15 Feb 2021 19:47:00 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
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
>   remove unnecessary file.exists() check

Thanks for perceiving with this one. I think you've addressed all issues in the latest revision.

-------------

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1853

From ysuenaga at openjdk.java.net  Tue Feb 16 08:06:02 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Tue, 16 Feb 2021 08:06:02 GMT
Subject: RFR: 8261710: SA DSO objects have sizes that are too large [v2]
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: <FvPH4sh8ILKRvrxsdKLyTPbIj7MCb-kg5KMhOFWwq-4=.57cb08f0-5386-4fbb-b5de-a33b3c41b8d3@github.com>

> 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 incrementally with one additional commit since the last revision:

  Fix for OS X

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2563/files
  - new: https://git.openjdk.java.net/jdk/pull/2563/files/9af4e232..b33398ea

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2563&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2563&range=00-01

  Stats: 35 lines in 7 files changed: 19 ins; 2 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2563.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2563/head:pull/2563

PR: https://git.openjdk.java.net/jdk/pull/2563

From ysuenaga at openjdk.java.net  Tue Feb 16 09:09:00 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Tue, 16 Feb 2021 09:09:00 GMT
Subject: RFR: 8261710: SA DSO objects have sizes that are too large [v3]
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: <qqu651YXc80Jo_Gwv9WoP0c8ekwtdWo-2Cl1BDRm_vQ=.66cf0138-ccf8-4adb-88be-6382464bf5a1@github.com>

> 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 incrementally with one additional commit since the last revision:

  Remove unnecessary code

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2563/files
  - new: https://git.openjdk.java.net/jdk/pull/2563/files/b33398ea..c9a34723

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2563&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2563&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2563.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2563/head:pull/2563

PR: https://git.openjdk.java.net/jdk/pull/2563

From kevinw at openjdk.java.net  Tue Feb 16 09:12:38 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Tue, 16 Feb 2021 09:12:38 GMT
Subject: RFR: 8261702: ClhsdbFindPC can fail due to PointerFinder
 incorrectly thinking an address is in a .so
In-Reply-To: <AFSFgu2cWGvCRDEq5jI67rk-Xwx1Xc3v2B3E81WjVJY=.3e2a4488-2e85-46b2-89f8-0da1bc349a99@github.com>
References: <AFSFgu2cWGvCRDEq5jI67rk-Xwx1Xc3v2B3E81WjVJY=.3e2a4488-2e85-46b2-89f8-0da1bc349a99@github.com>
Message-ID: <6uZb6UgPo33rhYiyaQyZLyxA099x1Y6GGGTDXp_cPjY=.7649d768-ab5c-4d72-951e-bf5020acd3d4@github.com>

On Sat, 13 Feb 2021 19:05:17 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> See bug description for details. The fix is simple and just a matter of moving some code to avoid incorrectly thinking an address is in a .so when it is in some other area of VM memory that occurs just after the last .so.

Looks good.

-------------

Marked as reviewed by kevinw (Committer).

PR: https://git.openjdk.java.net/jdk/pull/2562

From sspitsyn at openjdk.java.net  Tue Feb 16 10:07:40 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Tue, 16 Feb 2021 10:07:40 GMT
Subject: RFR: 8241403: JavaThread::get_thread_name() should be
 ThreadSMR-aware [v2]
In-Reply-To: <UY810XwxI_xwVSwdtX4pcnH__prubKLOXJB-2fMK0n4=.154fa1e0-560f-405e-ac62-e143c9a36536@github.com>
References: <wRdcRQurtpybntK9Qpji-6zVY-EcHKw3q87xpD0eoS4=.a6dc32f4-2919-42e9-80c3-5a264067f0e2@github.com>
 <UY810XwxI_xwVSwdtX4pcnH__prubKLOXJB-2fMK0n4=.154fa1e0-560f-405e-ac62-e143c9a36536@github.com>
Message-ID: <wwOYIKT3A8qbU7AlLuFOP-U6H3R07ViGt2EqylDAMA8=.e760903f-1b67-49fa-816d-48ef297baef8@github.com>

On Sat, 13 Feb 2021 21:53:51 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> A minor fix to add a new function:
>> 
>>     bool Thread::is_JavaThread_protected(const JavaThread* p)
>> 
>> that returns true when the target JavaThread* is protected and false
>> otherwise. Update JavaThread::get_thread_name() to create a
>> ThreadsListHandle and use the new is_JavaThread_protected(). Also
>> update JvmtiTrace::safe_get_thread_name() to use the new
>> is_JavaThread_protected().
>> 
>> This fix is tested via a Mach5 Tier[1-8] run.
>
> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address coleenp CR0 comments.

The update looks good.
Thanks,
Serguei

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2535

From sgehwolf at openjdk.java.net  Tue Feb 16 10:08:41 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Tue, 16 Feb 2021 10:08:41 GMT
Subject: RFR: 8261607: SA attach is exceeding JNI Local Refs capacity [v3]
In-Reply-To: <DWmzxc9z4SzjaUEcjtc1SAvr4dqrenNEIhSnMIHZvYk=.399d57df-a0dd-40f5-8191-1d927bc65f74@github.com>
References: <RoYVASDz0Y5cNK3fwa8MhvCxcN1S4hQNYFdRD60H5lE=.892a258a-5bb2-40f4-ad42-24a7bf365463@github.com>
 <DWmzxc9z4SzjaUEcjtc1SAvr4dqrenNEIhSnMIHZvYk=.399d57df-a0dd-40f5-8191-1d927bc65f74@github.com>
Message-ID: <e8W8tudOEO8JWXCwYkl8HmQBX2MLlnL15jZtXrHJz0E=.9968d54c-8bc8-46fd-abc9-f755867b58ee@github.com>

On Mon, 15 Feb 2021 20:10:02 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Delete some localrefs to avoid -Xcheck:jni warnings. See CR for details.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment

Marked as reviewed by sgehwolf (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2568

From ysuenaga at openjdk.java.net  Tue Feb 16 12:22:42 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Tue, 16 Feb 2021 12:22:42 GMT
Subject: RFR: 8261710: SA DSO objects have sizes that are too large
In-Reply-To: <mUhWqJm-RdRly_sRdxywcm_04PQHZsOaLBf8zi-viqE=.13b1cf2d-990b-4ef9-99b5-f8186c120671@github.com>
References: <rtxSvuvKLmHKrLtsnxf76vSK41b_HWPR_7Bn3wf9YuM=.cf1b54ae-f01d-48d5-9641-d7d9faa541f5@github.com>
 <IlGty_H4BHMqmDRi0pWscIAKdyR_nKLI-Ceea9bcxTg=.e9a47c72-cfa8-41d1-8e05-ebde39ac1f24@github.com>
 <k6gxI6l5dgq2xN_8E9tplZqbml81gL1BpsQTd8kdE1s=.7b29334e-0f12-473b-b2f2-7b355cd5d90b@github.com>
 <mUhWqJm-RdRly_sRdxywcm_04PQHZsOaLBf8zi-viqE=.13b1cf2d-990b-4ef9-99b5-f8186c120671@github.com>
Message-ID: <1em8Uu_1RP3ceaoHAzOwyyejR9jXJfu9Qy3mBRckXx0=.073c8889-9f12-4856-bd9b-78d02b1dd9eb@github.com>

On Tue, 16 Feb 2021 02:45:23 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> @plummercj Thanks for the review!
>> 
>>> These changes look good, but it would be nice to fix OSX too. Fortunately it should be easier. As part of the fix for [JDK-8247515](https://bugs.openjdk.java.net/browse/JDK-8247515), I added a `lib_info->memsz` field. I think it is correct and is what you need.
>> 
>> AFAICS `lib_info->memsz` is not set to loaded size, it seems to relates to the offset of the symbol in the binary.
>> 
>> https://github.com/openjdk/jdk/blob/34ae7aeb64db90dcb4d2f3d4acb16c714a32824f/src/jdk.hotspot.agent/macosx/native/libsaproc/libproc_impl.c#L261
>> https://github.com/openjdk/jdk/blob/34ae7aeb64db90dcb4d2f3d4acb16c714a32824f/src/jdk.hotspot.agent/macosx/native/libsaproc/symtab.c#L185
>> 
>> Can I believe `lib_info->memsz` for this purpose?
>> I'm not familiar of Mach-O, and I don't have Mac, so I can't evaluate it.
>> 
>>> I needed it in order to properly scan .dylibs for symbols without scanning too far. It seems to be working. Unfortunately we don't really have a good tests for this, but you could look at the before and after for ClhsdbPmap test to get an idea of if it is working. If you don't have an OSX machine to try, I can try out your changes for you.
>> 
>> In process attach on Linux, we can test the change with /proc/<PID>/maps, but in other case, we might not test it.
>> In coredump on Linux, it is difficult because we cannot get memory map from other source (excepts the core).
>> 
>>> BTW, I have no idea if Windows is getting the size right, but I guess we'll just have to assume it is:
>>> 
>>> ```
>>>     env->CallVoidMethod(obj, addLoadObject_ID, strName, (jlong) params[u].Size,
>>>                         (jlong) params[u].Base);
>>> ```
>> 
>> According to [Microsoft Docs](https://docs.microsoft.com/ja-jp/windows-hardware/drivers/ddi/dbgeng/ns-dbgeng-_debug_module_parameters), it sounds good.
>
> https://bugs.openjdk.java.net/browse/JDK-8250750 has some interesting details that I forgot about. Note this is referencing the state of the code before fixing JDK-8250750, which changed how `lib->memsz` is calculated.
> 
>> `lib->memsz` comes from the size of the `LC_SEGMENT_64` that the library was discovered in. However, the library can actually span multiple segments. In this case of the vtable address, the address was in the segment that follows the initial `LC_SEGMENT_64`. Because of this `lib->memsz` is too small, resulting in symbol lookups being restricted to addresses that are in the initial segment. 
> 
>>  The simplest approach to fixing this seems to be locating the largest offset found in the symbol table, round that up to a page boundary, and use it as `lib->memsz`. I've implemented this and it seems to be working. 
> 
> So it's not perfect, but I think it's good enough for our needs and better than using the file size and ending up with a size that is too big. I think the main way that this could fail is if you use `findpc` on an address that is beyond the last symbol (if it is even possible for there to be memory mapped at an address after the last symbol). In this case `findpc` will just say it doesn't know where the address is rather than saying it is in the dso + some very large offset. For symbols in the dso, they will always be found since lib`->memsz` now covers all symbols.
> 
> Also, since I never did figure out how to determine the size of a mach-o symbol, it's possible that the last symbol extends beyond the page boundary. If that is the case and you use `findpc` on and address that is part of the symbol but beyond the page boundary, `findpc` won't find it and say it doesn't know what the address is. So again, not perfect, but this issue can only happen with the last symbol in the dso, and only if the symbol crosses a page boundary, and only if the searched for address is after the page boundary. If you search for the start of the symbol, you'll still find it.
> 
> Having said all that, I think maybe we can get the correct size by taking the address of the highest symbol and then looking up the `map_info` that it is in. Then it's just a matter of adding `map->vaddr + map->memsz`. But this assumes that there are no more maps for the dso  after the one that has the last symbol, so maybe still not perfect. I'm not sure any of this extra work is worth it. When I dove into the mach-o support last year to fix some issues, it ended up being a huge rat hole that took way more of my time then I had expected. It was very badly broken, far worse then I first thought, and many things about mach-o core files were a mystery, and still remain so. For example, see https://bugs.openjdk.java.net/browse/JDK-8249779. We never did figure out how to create a link map.

Thanks for explanation!
I understood Marc-O is complex, and to use `lib->memsz` is reasonable as you said.

I updated patch for macOS. I cannot test it, but all of tier 1 servicerbility tests were passed on GitHub Actions. Could you review again?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2563

From coleenp at openjdk.java.net  Tue Feb 16 12:38:39 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 16 Feb 2021 12:38:39 GMT
Subject: RFR: 8241403: JavaThread::get_thread_name() should be
 ThreadSMR-aware [v2]
In-Reply-To: <KbdWt_86pRyMIKayliF7-NvoWufhF3FOw0RPLgMtPq0=.2e3f2904-06ca-4d15-ac87-0758db6d4f34@github.com>
References: <wRdcRQurtpybntK9Qpji-6zVY-EcHKw3q87xpD0eoS4=.a6dc32f4-2919-42e9-80c3-5a264067f0e2@github.com>
 <Uke4223ee6tPQRFdiMkUsIF7oRrz6bm4LMk1FpnmR-k=.190befb3-4d2b-44cf-81c7-2f2d147bd784@github.com>
 <AlPMnCZ8HBODRqVtHHXpUZKwO-yoAI724D0qNz3H4Qk=.ea8de8e2-dcfb-42c6-83a6-bc0626ed2fec@github.com>
 <JB_2ExyxLfCaR-W0ejdB6EMpSXORpKtIBE8PhkN_rGM=.7bd6fda1-6149-4f93-85a1-64e1981dd5c7@github.com>
 <u85rI973YRBpkQJWidXqQ3xk3MeZzSvotZvD594jUsI=.97a1db27-db13-4a44-a13f-f6cba026ff1b@github.com>
 <EUsIqjFQas0pSRZ5Bj6Pz-4ZUC-cqrKThA6pzc9YSRE=.eaded8c2-9ddd-4051-9c93-4e867b248e44@github.com>
 <hWZhAOgWF5S-e79V4Ekcujvq7qXXkfn7RoTf3R2Z-ic=.e52284db-30de-4087-971d-c5aed702b4ca@github.com>
 <brQU7T2_xzhayQLmemvJX9zjGNyS2fV8RdugpRSALlU=.6534ed80-a28f-4cd2-95fd-822954409e78@github.com>
 <KbdWt_86pRyMIKayliF7-NvoWufhF3FOw0RPLgMtPq0=.2e3f2904-06ca-4d15-ac87-0758db6d4f34@github.com>
Message-ID: <otx_Jx3c0U5F5NRD0lM6U0maavfUGepi8cOrBeuKVLs=.9e633949-3612-440c-a9e3-95d72bcfc8a5@github.com>

On Sat, 13 Feb 2021 15:42:32 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> And it looks like making is_JavaThread_protected() a protected function doesn't work either since `JavaThread::get_thread_name()` can't call it:
>> 
>> ./open/src/hotspot/share/runtime/thread.cpp:2857:15: error: 'is_JavaThread_protected' is a protected member of 'Thread'
>>   if (thread->is_JavaThread_protected(this)) {
>>               ^
>> ./open/src/hotspot/share/runtime/thread.cpp:488:14: note: can only access this member on an object of type 'JavaThread'
>> bool Thread::is_JavaThread_protected(const JavaThread* p) {
>>              ^
>> 1 error generated.
>
> `JavaThread::get_thread_name()` is calling `is_JavaThread_protected()` on the calling Thread and NOT on the `this` JavaThread so `protected` doesn't work.

ok.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2535

From coleenp at openjdk.java.net  Tue Feb 16 12:38:39 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 16 Feb 2021 12:38:39 GMT
Subject: RFR: 8241403: JavaThread::get_thread_name() should be
 ThreadSMR-aware [v2]
In-Reply-To: <UY810XwxI_xwVSwdtX4pcnH__prubKLOXJB-2fMK0n4=.154fa1e0-560f-405e-ac62-e143c9a36536@github.com>
References: <wRdcRQurtpybntK9Qpji-6zVY-EcHKw3q87xpD0eoS4=.a6dc32f4-2919-42e9-80c3-5a264067f0e2@github.com>
 <UY810XwxI_xwVSwdtX4pcnH__prubKLOXJB-2fMK0n4=.154fa1e0-560f-405e-ac62-e143c9a36536@github.com>
Message-ID: <d_HrdNGEX1dkcfjPWLu_84SzSX4I-jZm2kHYKbwAvZU=.a7e2382b-77cb-43ca-9473-78be2685c6ac@github.com>

On Sat, 13 Feb 2021 21:53:51 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> A minor fix to add a new function:
>> 
>>     bool Thread::is_JavaThread_protected(const JavaThread* p)
>> 
>> that returns true when the target JavaThread* is protected and false
>> otherwise. Update JavaThread::get_thread_name() to create a
>> ThreadsListHandle and use the new is_JavaThread_protected(). Also
>> update JvmtiTrace::safe_get_thread_name() to use the new
>> is_JavaThread_protected().
>> 
>> This fix is tested via a Mach5 Tier[1-8] run.
>
> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address coleenp CR0 comments.

Thanks!

-------------

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2535

From vkempik at openjdk.java.net  Tue Feb 16 14:09:54 2021
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Tue, 16 Feb 2021 14:09:54 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v10]
In-Reply-To: <i9UArB35vpHowW6HbtTkKLQX-wwfSx1dg1NKLHIRdGs=.5e08a151-8ad3-46cc-b006-34d750410c47@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>
Message-ID: <44L8Jccum5-J3RntkBsRZJ5daAJ-X1tYt_4xspIbP6U=.4dd53895-2fb7-4396-82e1-8387828bcdbf@github.com>

On Thu, 4 Feb 2021 22:49:23 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 297:
> 
>> 295:           stub = SharedRuntime::handle_unsafe_access(thread, next_pc);
>> 296:         }
>> 297:       } else if (sig == SIGILL && nativeInstruction_at(pc)->is_stop()) {
> 
> Can we add a comment here describing what this case means?

This was added as part of this commit ( to linux_aarch64) - https://github.com/openjdk/jdk/commit/339d52600b285eb3bc57d9ff107567d4424efeb1

@gerard-ziemski  do we really want to add anything new here ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From lucy at openjdk.java.net  Tue Feb 16 15:20:17 2021
From: lucy at openjdk.java.net (Lutz Schmidt)
Date: Tue, 16 Feb 2021 15:20:17 GMT
Subject: RFR: 8261447: MethodInvocationCounters frequently run into
 overflow [v4]
In-Reply-To: <FsHAKG6KwqJeHLIhE6JroDUjiebdevi1asoLi-7pQ1s=.15d96719-36f2-4f9b-ae80-fcb17a3b6659@github.com>
References: <FsHAKG6KwqJeHLIhE6JroDUjiebdevi1asoLi-7pQ1s=.15d96719-36f2-4f9b-ae80-fcb17a3b6659@github.com>
Message-ID: <_AP8N2ZJvjN2VbW_JhYes3vCgEGtmSVQYtSqLm6VsGI=.39897514-c44a-49b6-8e81-2f83b3bcde44@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 (185 days 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 with a new target base due to a merge or a rebase. The pull request now contains five commits:

 - 8261447: requested changes by TobiHartmann
 - JDK-8261447: MethodInvocationCounters frequently run into overflow
 - expand remaining counters to 64-bit, remove 64 duffix
 - 8261447: requested changes by TobiHartmann
 - JDK-8261447: MethodInvocationCounters frequently run into overflow

-------------

Changes: https://git.openjdk.java.net/jdk/pull/2511/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2511&range=03
  Stats: 5969 lines in 92 files changed: 5856 ins; 4 del; 109 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  Tue Feb 16 15:31:02 2021
From: lucy at openjdk.java.net (Lutz Schmidt)
Date: Tue, 16 Feb 2021 15:31:02 GMT
Subject: RFR: 8261447: MethodInvocationCounters frequently run into
 overflow [v5]
In-Reply-To: <FsHAKG6KwqJeHLIhE6JroDUjiebdevi1asoLi-7pQ1s=.15d96719-36f2-4f9b-ae80-fcb17a3b6659@github.com>
References: <FsHAKG6KwqJeHLIhE6JroDUjiebdevi1asoLi-7pQ1s=.15d96719-36f2-4f9b-ae80-fcb17a3b6659@github.com>
Message-ID: <xPFCe5hypP6eW_aIJgyMIg81_t9ategPg2gILlI-kgE=.8789bb51-df05-4caa-a61e-a42dad04158b@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 (185 days 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:
  - all: https://git.openjdk.java.net/jdk/pull/2511/files
  - new: https://git.openjdk.java.net/jdk/pull/2511/files/273d55c2..0a99ee4e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2511&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2511&range=03-04

  Stats: 5780 lines in 79 files changed: 0 ins; 5779 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 jboes at openjdk.java.net  Tue Feb 16 17:23:42 2021
From: jboes at openjdk.java.net (Julia Boes)
Date: Tue, 16 Feb 2021 17:23:42 GMT
Subject: RFR: 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: <5s4i5725zJd8QrefwYyc8sn2fQXad3hAGLVflkFttmY=.abe55236-e258-482b-b8be-be75e1eb086c@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

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

-------------

PR: https://git.openjdk.java.net/jdk/pull/1853

From github.com+741251+turbanoff at openjdk.java.net  Tue Feb 16 18:44:42 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Tue, 16 Feb 2021 18:44:42 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v9]
In-Reply-To: <WtXQ3xGo_psAegHONwjHWSSdAGsvsW9yN6eXAGL8Sbc=.c5c0ef89-24c9-428d-a86d-71db7437d6d3@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <oyAwqFESfH7q3wJicuQNF0Hds0Sp69dN5bzxYAIBaOQ=.df45bf24-3f70-457d-9df9-8a5b3022f1e1@github.com>
 <WtXQ3xGo_psAegHONwjHWSSdAGsvsW9yN6eXAGL8Sbc=.c5c0ef89-24c9-428d-a86d-71db7437d6d3@github.com>
Message-ID: <04LMLK3YO1cEPtchQl39EhAgeSN2mvEdQONQg_UzLKc=.7d1ce34f-04b6-4248-ba32-efec0c24b915@github.com>

On Mon, 8 Feb 2021 21:18:44 GMT, Philippe Marschall <github.com+471021+marschall at openjdk.org> wrote:

>> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
>>   fix review comments
>
> src/java.base/share/classes/sun/security/provider/certpath/X509CertPath.java line 230:
> 
>> 228:                 // Copy the entire input stream into an InputStream that does
>> 229:                 // support mark
>> 230:                 is = new ByteArrayInputStream(is.readAllBytes());
> 
> I don't understand why the check for #markSupported is done there. The InputStream constructor of PKCS7 creates a DataInputStream on the InputStream only to then call #readFully. I can't find a place where a call to #mark happens. Since the InputStream constructor reads all bytes anyway I wonder whether we could remove this if and unconditionally do:
> 
> PKCS7 pkcs7 = new PKCS7(is.readAllBytes());

Good idea. Will improve.
By the way, code in `sun.security.pkcs.PKCS7#PKCS7(java.io.InputStream)`  looks suspicious: it reads only `InputStream.available()` bytes, which doesn't make much sense to me.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1853

From github.com+741251+turbanoff at openjdk.java.net  Tue Feb 16 18:47:42 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Tue, 16 Feb 2021 18:47:42 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v9]
In-Reply-To: <4-2EVrWdbxsKykSlYd3bAuxS7iuzZbxKPEhrE-y_fMk=.986e5094-e940-4a89-a70e-5aad77dde26d@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <oyAwqFESfH7q3wJicuQNF0Hds0Sp69dN5bzxYAIBaOQ=.df45bf24-3f70-457d-9df9-8a5b3022f1e1@github.com>
 <4-2EVrWdbxsKykSlYd3bAuxS7iuzZbxKPEhrE-y_fMk=.986e5094-e940-4a89-a70e-5aad77dde26d@github.com>
Message-ID: <NsXuEr-MY1rbBYudsF_FG2EIDaJY-_QpzqgR4myHQ_g=.ee29d6c1-4eb8-414a-a722-67bb950c3894@github.com>

On Tue, 9 Feb 2021 11:40:09 GMT, Philippe Marschall <github.com+471021+marschall at openjdk.org> wrote:

>> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
>>   fix review comments
>
> src/java.base/share/classes/java/util/jar/JarInputStream.java line 93:
> 
>> 91:         if (e != null && JarFile.MANIFEST_NAME.equalsIgnoreCase(e.getName())) {
>> 92:             man = new Manifest();
>> 93:             byte[] bytes = new BufferedInputStream(this).readAllBytes();
> 
> I wonder if it makes sense to avoid reading the entire manifest into a byte[] when we don't need to verify the JAR. This may help avoiding some intermediate allocation and copying. This make be noticeable for some of the larger manifests (Java EE, OSGi, ...). A possible implementation may look like this https://github.com/marschall/jdk/commit/c50880ffb18607077c4da3456b27957d1df8edb7.
> 
> In either case since we're calling #readAllBytes I don't see why we are wrapping in a BufferedInputStream rather than calling #readAllBytes directly.

Usage of `BufferedInputStream` removed

-------------

PR: https://git.openjdk.java.net/jdk/pull/1853

From github.com+741251+turbanoff at openjdk.java.net  Tue Feb 16 18:58:57 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Tue, 16 Feb 2021 18:58:57 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v12]
In-Reply-To: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
Message-ID: <ZbjR8LxLcrLYtzwOCUh2PO9NtNI25iXTQwbpRJb3YKU=.bafdce7c-94ca-41b0-87df-5ab52f03e9c5@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 java.io.InputStream.transferTo
  cleanup

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1853/files
  - new: https://git.openjdk.java.net/jdk/pull/1853/files/6e71e961..1b30471d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=11
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=10-11

  Stats: 7 lines in 2 files changed: 0 ins; 5 del; 2 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 cjplummer at openjdk.java.net  Tue Feb 16 21:19:47 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 16 Feb 2021 21:19:47 GMT
Subject: Integrated: 8261607: SA attach is exceeding JNI Local Refs capacity
In-Reply-To: <RoYVASDz0Y5cNK3fwa8MhvCxcN1S4hQNYFdRD60H5lE=.892a258a-5bb2-40f4-ad42-24a7bf365463@github.com>
References: <RoYVASDz0Y5cNK3fwa8MhvCxcN1S4hQNYFdRD60H5lE=.892a258a-5bb2-40f4-ad42-24a7bf365463@github.com>
Message-ID: <3nXIl7D8Xwu7s6KGstt9svayFQwraX4e2jJy_0v1HJk=.99d39e28-d7b3-43b1-8f33-eb0a39351201@github.com>

On Mon, 15 Feb 2021 06:00:29 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Delete some localrefs to avoid -Xcheck:jni warnings. See CR for details.

This pull request has now been integrated.

Changeset: 55d7bbce
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/55d7bbce
Stats:     23 lines in 4 files changed: 16 ins; 3 del; 4 mod

8261607: SA attach is exceeding JNI Local Refs capacity

Reviewed-by: sgehwolf, amenkov

-------------

PR: https://git.openjdk.java.net/jdk/pull/2568

From dcubed at openjdk.java.net  Tue Feb 16 21:26:41 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 16 Feb 2021 21:26:41 GMT
Subject: RFR: 8241403: JavaThread::get_thread_name() should be
 ThreadSMR-aware [v2]
In-Reply-To: <d_HrdNGEX1dkcfjPWLu_84SzSX4I-jZm2kHYKbwAvZU=.a7e2382b-77cb-43ca-9473-78be2685c6ac@github.com>
References: <wRdcRQurtpybntK9Qpji-6zVY-EcHKw3q87xpD0eoS4=.a6dc32f4-2919-42e9-80c3-5a264067f0e2@github.com>
 <UY810XwxI_xwVSwdtX4pcnH__prubKLOXJB-2fMK0n4=.154fa1e0-560f-405e-ac62-e143c9a36536@github.com>
 <d_HrdNGEX1dkcfjPWLu_84SzSX4I-jZm2kHYKbwAvZU=.a7e2382b-77cb-43ca-9473-78be2685c6ac@github.com>
Message-ID: <xtCVgcK-lMTrnhaW135wk0yYqABXGzQl8kM2kXuhhR8=.871caaa3-aadc-4294-beaf-fe6d97d6fd8f@github.com>

On Tue, 16 Feb 2021 12:35:28 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address coleenp CR0 comments.
>
> Thanks!

@coleenp and @sspitsyn - Thanks for the re-reviews!

-------------

PR: https://git.openjdk.java.net/jdk/pull/2535

From dcubed at openjdk.java.net  Tue Feb 16 21:26:41 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 16 Feb 2021 21:26:41 GMT
Subject: RFR: 8241403: JavaThread::get_thread_name() should be
 ThreadSMR-aware [v2]
In-Reply-To: <xtCVgcK-lMTrnhaW135wk0yYqABXGzQl8kM2kXuhhR8=.871caaa3-aadc-4294-beaf-fe6d97d6fd8f@github.com>
References: <wRdcRQurtpybntK9Qpji-6zVY-EcHKw3q87xpD0eoS4=.a6dc32f4-2919-42e9-80c3-5a264067f0e2@github.com>
 <UY810XwxI_xwVSwdtX4pcnH__prubKLOXJB-2fMK0n4=.154fa1e0-560f-405e-ac62-e143c9a36536@github.com>
 <d_HrdNGEX1dkcfjPWLu_84SzSX4I-jZm2kHYKbwAvZU=.a7e2382b-77cb-43ca-9473-78be2685c6ac@github.com>
 <xtCVgcK-lMTrnhaW135wk0yYqABXGzQl8kM2kXuhhR8=.871caaa3-aadc-4294-beaf-fe6d97d6fd8f@github.com>
Message-ID: <D6G_iv5f7cVSgISF_UMAd3FYrEj-iXhNh5JC5Gm0Voo=.a91715fe-59ff-4640-ad07-97ff3a8cc1a3@github.com>

On Tue, 16 Feb 2021 21:23:48 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Thanks!
>
> @coleenp and @sspitsyn - Thanks for the re-reviews!

@dholmes and @fisk - did either or both of you plan to review this one?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2535

From dcubed at openjdk.java.net  Tue Feb 16 21:32:40 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 16 Feb 2021 21:32:40 GMT
Subject: RFR: 8261702: ClhsdbFindPC can fail due to PointerFinder
 incorrectly thinking an address is in a .so
In-Reply-To: <6uZb6UgPo33rhYiyaQyZLyxA099x1Y6GGGTDXp_cPjY=.7649d768-ab5c-4d72-951e-bf5020acd3d4@github.com>
References: <AFSFgu2cWGvCRDEq5jI67rk-Xwx1Xc3v2B3E81WjVJY=.3e2a4488-2e85-46b2-89f8-0da1bc349a99@github.com>
 <6uZb6UgPo33rhYiyaQyZLyxA099x1Y6GGGTDXp_cPjY=.7649d768-ab5c-4d72-951e-bf5020acd3d4@github.com>
Message-ID: <qOWKA-l4cR4QibO8uXJ3ZdpOFvYB628vOmqP8WezTvo=.6f159603-fb53-4c00-affe-3275f944ec52@github.com>

On Tue, 16 Feb 2021 09:10:17 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> See bug description for details. The fix is simple and just a matter of moving some code to avoid incorrectly thinking an address is in a .so when it is in some other area of VM memory that occurs just after the last .so.
>
> Looks good.

While I was characterizing:

    JDK-8261844 serviceability/sa/ClhsdbFindPC.java#id1 failed with "'In code in NMethod for LingeredAppWithTrivialMain.main' missing from stdout/stderr"

I determined that I could easily reproduce serviceability/sa/ClhsdbFindPC.java failures
on my Ubuntu 16.04 test machine. I've applied this version of this PR:

$ git log HEAD^!
commit fea1ed851ce6a93030169e7de0daac2c2ac12a31 (HEAD -> pull/2562)
Author: Chris Plummer <chris.plummer at oracle.com>
Date:   Sat Feb 13 19:02:24 2021 +0000

    Check if addr is in DSO last to avoid finding addr in DSO when it is not due to DSO.size() returning too large of a value.

and retested. I no longer see serviceability/sa/ClhsdbFindPC.java failures.
I did a total of 6 runs (X3 configs) and there were no failures.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2562

From cjplummer at openjdk.java.net  Tue Feb 16 21:46:43 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 16 Feb 2021 21:46:43 GMT
Subject: RFR: 8261702: ClhsdbFindPC can fail due to PointerFinder
 incorrectly thinking an address is in a .so
In-Reply-To: <qOWKA-l4cR4QibO8uXJ3ZdpOFvYB628vOmqP8WezTvo=.6f159603-fb53-4c00-affe-3275f944ec52@github.com>
References: <AFSFgu2cWGvCRDEq5jI67rk-Xwx1Xc3v2B3E81WjVJY=.3e2a4488-2e85-46b2-89f8-0da1bc349a99@github.com>
 <6uZb6UgPo33rhYiyaQyZLyxA099x1Y6GGGTDXp_cPjY=.7649d768-ab5c-4d72-951e-bf5020acd3d4@github.com>
 <qOWKA-l4cR4QibO8uXJ3ZdpOFvYB628vOmqP8WezTvo=.6f159603-fb53-4c00-affe-3275f944ec52@github.com>
Message-ID: <dj0c9Lx9S5MmY9nhgwhti12aCDGz4qWMjVlhRDLg03I=.db2d3f7f-23a3-46f8-a0e5-859518b71781@github.com>

On Tue, 16 Feb 2021 21:29:23 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Looks good.
>
> While I was characterizing:
> 
>     JDK-8261844 serviceability/sa/ClhsdbFindPC.java#id1 failed with "'In code in NMethod for LingeredAppWithTrivialMain.main' missing from stdout/stderr"
> 
> I determined that I could easily reproduce serviceability/sa/ClhsdbFindPC.java failures
> on my Ubuntu 16.04 test machine. I've applied this version of this PR:
> 
> $ git log HEAD^!
> commit fea1ed851ce6a93030169e7de0daac2c2ac12a31 (HEAD -> pull/2562)
> Author: Chris Plummer <chris.plummer at oracle.com>
> Date:   Sat Feb 13 19:02:24 2021 +0000
> 
>     Check if addr is in DSO last to avoid finding addr in DSO when it is not due to DSO.size() returning too large of a value.
> 
> and retested. I no longer see serviceability/sa/ClhsdbFindPC.java failures.
> I did a total of 6 runs (X3 configs) and there were no failures.

@dcubed-ojdk Can you also try pull/2563. It's for https://bugs.openjdk.java.net/browse/JDK-8261710, which is an attempt at a more proper fix for this bug (this PR is just avoiding the real issue, which is an incorrect DSO size calculation.)

-------------

PR: https://git.openjdk.java.net/jdk/pull/2562

From lucy at openjdk.java.net  Tue Feb 16 22:04:10 2021
From: lucy at openjdk.java.net (Lutz Schmidt)
Date: Tue, 16 Feb 2021 22:04:10 GMT
Subject: RFR: 8261447: MethodInvocationCounters frequently run into
 overflow [v6]
In-Reply-To: <FsHAKG6KwqJeHLIhE6JroDUjiebdevi1asoLi-7pQ1s=.15d96719-36f2-4f9b-ae80-fcb17a3b6659@github.com>
References: <FsHAKG6KwqJeHLIhE6JroDUjiebdevi1asoLi-7pQ1s=.15d96719-36f2-4f9b-ae80-fcb17a3b6659@github.com>
Message-ID: <tIC5jFu_NAQAGmcrEv9pbQ0OD53fXHIsF9ru8wJmcyY=.1db206df-1d3c-46d6-916d-a6b2e6150c6f@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 (185 days 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 two additional commits since the last revision:

 - no incrementq for x86_32
 - cleaning up the remaining mess

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2511/files
  - new: https://git.openjdk.java.net/jdk/pull/2511/files/0a99ee4e..faab64b0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2511&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2511&range=04-05

  Stats: 30 lines in 5 files changed: 0 ins; 15 del; 15 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 amenkov at openjdk.java.net  Tue Feb 16 22:09:39 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Tue, 16 Feb 2021 22:09:39 GMT
Subject: RFR: 8261098: Add clhsdb "findsym" command [v2]
In-Reply-To: <3_RpSFsQ7C7vUSRMdLyweUkxbKO23xTI_hkiT4NJOYs=.3eecb45b-0b09-4801-aba6-30226839ae40@github.com>
References: <EcsJkvo_wYh085Hc1uRmViYzUrsfMeNLFOEsn0YSyXs=.8243bb41-62d6-40a0-8942-650a9cd8a497@github.com>
 <XpoVBbUrUuf02j_bS6z7r0n8_kLJ5mr9pBqNHMyfDaA=.5123143d-94ff-46d1-99e4-5cde39521f94@github.com>
 <lI7tcyHdEBpm9SzHKl8HINpyuKK88zX-XXDfn8gnJ7s=.f54d9d66-2d91-40ba-8feb-125e5155cb5f@github.com>
 <3_RpSFsQ7C7vUSRMdLyweUkxbKO23xTI_hkiT4NJOYs=.3eecb45b-0b09-4801-aba6-30226839ae40@github.com>
Message-ID: <L8HWr_ODMFkZ0S5xPDGtUUFNzVoKE58Z6SHdjkgOaqM=.00fa3903-33ac-430c-992b-8c241eefda07@github.com>

On Tue, 16 Feb 2021 01:26:46 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> src/jdk.hotspot.agent/linux/native/libsaproc/LinuxDebuggerLocal.cpp line 350:
>> 
>>> 348:   // Note, objectName is ignored, and may in fact be NULL.
>>> 349:   // lookup_symbol will always search all objects/libs
>>> 350:   //AutoJavaString objectName_cstr(env, objectName);
>> 
>> I think it would be better to update AutoJavaString class to handle null strings:
>> `m_buf(str == NULL ? NULL : env->GetStringUTFChars(str, NULL)) `
>
> The point is the argument is ignored, so it doesn't really matter if AutoJavaString can handle NULL. I  assume with your suggested fix that also want me to pass objectName_cstr to lookup_symbol() rather than an explicit NULL. I wanted the NULL to be explicit to help further convey that objectName is ignored.

lookup_symbol implementation contains FIXME comment about object_name.
I suppose you want to make this argument ignorance permanent. Then I think this FIXME should be removed (or updated) and it would be nice to add comment about this to lookup_symbol declaration (or maybe it would be better to delete this argument)

-------------

PR: https://git.openjdk.java.net/jdk/pull/2567

From sspitsyn at openjdk.java.net  Tue Feb 16 22:13:52 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Tue, 16 Feb 2021 22:13:52 GMT
Subject: RFR: 8261711: Clhsdb "versioncheck true" throws NPE every time
In-Reply-To: <No2GR3rp5bVBhvfB2ztAqX9KWhT7RygtyPfTYijSMTs=.cc1a7cb3-4b95-4a1c-abbb-63bf52459ab2@github.com>
References: <No2GR3rp5bVBhvfB2ztAqX9KWhT7RygtyPfTYijSMTs=.cc1a7cb3-4b95-4a1c-abbb-63bf52459ab2@github.com>
Message-ID: <FU5it2GQYiFV8v9v56nid7UskaNrA0KN4fi6DJGxs3A=.87c0823e-68b0-4a4f-b264-454bb2a443e1@github.com>

On Sun, 14 Feb 2021 09:14:43 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> See CR for details. There's no test for `versioncheck`, and I don't think it's worth adding, especially for this trivial fix. Here's how I tested:
> hsdb> versioncheck
> versioncheck is true
> hsdb> versioncheck false
> hsdb> versioncheck
> versioncheck is false
> hsdb> versioncheck true
> hsdb> versioncheck
> versioncheck is true

Looks good.

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2566

From dcubed at openjdk.java.net  Tue Feb 16 22:17:40 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 16 Feb 2021 22:17:40 GMT
Subject: RFR: 8261710: SA DSO objects have sizes that are too large
In-Reply-To: <1em8Uu_1RP3ceaoHAzOwyyejR9jXJfu9Qy3mBRckXx0=.073c8889-9f12-4856-bd9b-78d02b1dd9eb@github.com>
References: <rtxSvuvKLmHKrLtsnxf76vSK41b_HWPR_7Bn3wf9YuM=.cf1b54ae-f01d-48d5-9641-d7d9faa541f5@github.com>
 <IlGty_H4BHMqmDRi0pWscIAKdyR_nKLI-Ceea9bcxTg=.e9a47c72-cfa8-41d1-8e05-ebde39ac1f24@github.com>
 <k6gxI6l5dgq2xN_8E9tplZqbml81gL1BpsQTd8kdE1s=.7b29334e-0f12-473b-b2f2-7b355cd5d90b@github.com>
 <mUhWqJm-RdRly_sRdxywcm_04PQHZsOaLBf8zi-viqE=.13b1cf2d-990b-4ef9-99b5-f8186c120671@github.com>
 <1em8Uu_1RP3ceaoHAzOwyyejR9jXJfu9Qy3mBRckXx0=.073c8889-9f12-4856-bd9b-78d02b1dd9eb@github.com>
Message-ID: <Jjr8hombQ3h4YNbErS4Py9pIUUVC0DjsskdQC0ia5yE=.7b342dff-dc1d-4891-8ea6-ac113abdb6e6@github.com>

On Tue, 16 Feb 2021 12:19:38 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> https://bugs.openjdk.java.net/browse/JDK-8250750 has some interesting details that I forgot about. Note this is referencing the state of the code before fixing JDK-8250750, which changed how `lib->memsz` is calculated.
>> 
>>> `lib->memsz` comes from the size of the `LC_SEGMENT_64` that the library was discovered in. However, the library can actually span multiple segments. In this case of the vtable address, the address was in the segment that follows the initial `LC_SEGMENT_64`. Because of this `lib->memsz` is too small, resulting in symbol lookups being restricted to addresses that are in the initial segment. 
>> 
>>>  The simplest approach to fixing this seems to be locating the largest offset found in the symbol table, round that up to a page boundary, and use it as `lib->memsz`. I've implemented this and it seems to be working. 
>> 
>> So it's not perfect, but I think it's good enough for our needs and better than using the file size and ending up with a size that is too big. I think the main way that this could fail is if you use `findpc` on an address that is beyond the last symbol (if it is even possible for there to be memory mapped at an address after the last symbol). In this case `findpc` will just say it doesn't know where the address is rather than saying it is in the dso + some very large offset. For symbols in the dso, they will always be found since lib`->memsz` now covers all symbols.
>> 
>> Also, since I never did figure out how to determine the size of a mach-o symbol, it's possible that the last symbol extends beyond the page boundary. If that is the case and you use `findpc` on and address that is part of the symbol but beyond the page boundary, `findpc` won't find it and say it doesn't know what the address is. So again, not perfect, but this issue can only happen with the last symbol in the dso, and only if the symbol crosses a page boundary, and only if the searched for address is after the page boundary. If you search for the start of the symbol, you'll still find it.
>> 
>> Having said all that, I think maybe we can get the correct size by taking the address of the highest symbol and then looking up the `map_info` that it is in. Then it's just a matter of adding `map->vaddr + map->memsz`. But this assumes that there are no more maps for the dso  after the one that has the last symbol, so maybe still not perfect. I'm not sure any of this extra work is worth it. When I dove into the mach-o support last year to fix some issues, it ended up being a huge rat hole that took way more of my time then I had expected. It was very badly broken, far worse then I first thought, and many things about mach-o core files were a mystery, and still remain so. For example, see https://bugs.openjdk.java.net/browse/JDK-8249779. We never did figure out how to create a link map.
>
> Thanks for explanation!
> I understood Marc-O is complex, and to use `lib->memsz` is reasonable as you said.
> 
> I updated patch for macOS. I cannot test it, but all of tier 1 servicerbility tests were passed on GitHub Actions. Could you review again?

While I was characterizing:

JDK-8261844 serviceability/sa/ClhsdbFindPC.java#id1 failed with "'In code in NMethod for LingeredAppWithTrivialMain.main' missing from stdout/stderr"

I determined that I could easily reproduce serviceability/sa/ClhsdbFindPC.java failures
on my Ubuntu 16.04 test machine. I've applied this version of this PR at @plummercj's
request:

$ git log HEAD^!
commit c9a34723e34550301e1b5fd06185e0b0977da78e (HEAD -> pull/2563)
Author: Yasumasa Suenaga <suenaga at oss.nttdata.com>
Date:   Tue Feb 16 18:05:43 2021 +0900

    Remove unnecessary code

and retested serviceability/sa/ClhsdbFindPC.java:

$ do_java_test serviceability/sa/ClhsdbFindPC.java 2>&1 | tee -a do_java_test.8261710.log
INFO: GNUMAKE=make
INFO: GNUMAKE version is: GNU Make 4.1

INFO: JTREG options:
INFO:   JOBS=16
INFO:   TEST_MODE=othervm
INFO:   EXTRA_PROBLEM_LISTS=ProblemList-extra.txt
INFO:   VM_OPTIONS=
INFO: test_val=serviceability/sa/ClhsdbFindPC.java
Test Config: linux-x86_64-normal-server-release
    INFO: TIMEOUT_FACTOR=4
    Done testing
    Test Run linux-x86_64-normal-server-release time: 0.55 minutes.

    TEST                                              TOTAL  PASS  FAIL ERROR
    jtreg:open/test/hotspot/jtreg/serviceability/sa/ClhsdbFindPC.java
    >>                                                       4     3     1     0 <<

    1 failure(s) found in log=do_java_test.linux-x86_64-normal-server-release.log

    TEST: serviceability/sa/ClhsdbFindPC.java#id3
    ERROR: Failed to instantiate timeout handler: jdk.test.failurehandler.jtreg.GatherProcessInfoTimeoutHandler: file does not exist


Test Config: linux-x86_64-normal-server-fastdebug
    INFO: TIMEOUT_FACTOR=6
    Done testing
    Test Run linux-x86_64-normal-server-fastdebug time: 0.87 minutes.

    TEST                                              TOTAL  PASS  FAIL ERROR
    jtreg:open/test/hotspot/jtreg/serviceability/sa/ClhsdbFindPC.java
                                                          4     4     0     0

Test Config: linux-x86_64-normal-server-slowdebug
    INFO: TIMEOUT_FACTOR=12
    Done testing
    Test Run linux-x86_64-normal-server-slowdebug time: 2.97 minutes.

    TEST                                              TOTAL  PASS  FAIL ERROR
    jtreg:open/test/hotspot/jtreg/serviceability/sa/ClhsdbFindPC.java
    >>                                                       4     3     1     0 <<

    1 failure(s) found in log=do_java_test.linux-x86_64-normal-server-slowdebug.log

    TEST: serviceability/sa/ClhsdbFindPC.java#id3
    LOG: build/linux-x86_64-normal-server-slowdebug/test-support/jtreg_open_test_hotspot_jtreg_serviceability_sa_ClhsdbFindPC_java/serviceability/sa/ClhsdbFindPC_id3.jtr
    Saving build/linux-x86_64-normal-server-slowdebug/test-support/jtreg_open_test_hotspot_jtreg_serviceability_sa_ClhsdbFindPC_java/serviceability/sa/ClhsdbFindPC_id3.jtr as /work/shared/bug_hunt/8261844_for_jdk17.git/test_failures.2021-02-16-171036/ClhsdbFindPC_id3.jtr.slowdebug
    Saving /work/shared/bug_hunt/8261844_for_jdk17.git/build/linux-x86_64-normal-server-slowdebug/test-support/jtreg_open_test_hotspot_jtreg_serviceability_sa_ClhsdbFindPC_java/serviceability/sa/ClhsdbFindPC_id3/hs_err_pid16470.log as /work/shared/bug_hunt/8261844_for_jdk17.git/test_failures.2021-02-16-171036/hs_err_pid16470.log
    Moving /work/shared/bug_hunt/8261844_for_jdk17.git/build/linux-x86_64-normal-server-slowdebug/test-support/jtreg_open_test_hotspot_jtreg_serviceability_sa_ClhsdbFindPC_java/serviceability/sa/ClhsdbFindPC_id3/core to /work/shared/bug_hunt/8261844_for_jdk17.git/test_failures.2021-02-16-171036/core.16470


Total test time: 4.40 minutes.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2563

From dcubed at openjdk.java.net  Tue Feb 16 22:18:47 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 16 Feb 2021 22:18:47 GMT
Subject: RFR: 8261702: ClhsdbFindPC can fail due to PointerFinder
 incorrectly thinking an address is in a .so
In-Reply-To: <dj0c9Lx9S5MmY9nhgwhti12aCDGz4qWMjVlhRDLg03I=.db2d3f7f-23a3-46f8-a0e5-859518b71781@github.com>
References: <AFSFgu2cWGvCRDEq5jI67rk-Xwx1Xc3v2B3E81WjVJY=.3e2a4488-2e85-46b2-89f8-0da1bc349a99@github.com>
 <6uZb6UgPo33rhYiyaQyZLyxA099x1Y6GGGTDXp_cPjY=.7649d768-ab5c-4d72-951e-bf5020acd3d4@github.com>
 <qOWKA-l4cR4QibO8uXJ3ZdpOFvYB628vOmqP8WezTvo=.6f159603-fb53-4c00-affe-3275f944ec52@github.com>
 <dj0c9Lx9S5MmY9nhgwhti12aCDGz4qWMjVlhRDLg03I=.db2d3f7f-23a3-46f8-a0e5-859518b71781@github.com>
Message-ID: <Fd12t_vwAd4qhLqgR_KcWWXF4N1nn4dh_LaI_LVFA2s=.8dc98c1b-0a4f-4c40-97a4-33ae8440af7e@github.com>

On Tue, 16 Feb 2021 21:43:53 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> While I was characterizing:
>> 
>>     JDK-8261844 serviceability/sa/ClhsdbFindPC.java#id1 failed with "'In code in NMethod for LingeredAppWithTrivialMain.main' missing from stdout/stderr"
>> 
>> I determined that I could easily reproduce serviceability/sa/ClhsdbFindPC.java failures
>> on my Ubuntu 16.04 test machine. I've applied this version of this PR:
>> 
>> $ git log HEAD^!
>> commit fea1ed851ce6a93030169e7de0daac2c2ac12a31 (HEAD -> pull/2562)
>> Author: Chris Plummer <chris.plummer at oracle.com>
>> Date:   Sat Feb 13 19:02:24 2021 +0000
>> 
>>     Check if addr is in DSO last to avoid finding addr in DSO when it is not due to DSO.size() returning too large of a value.
>> 
>> and retested. I no longer see serviceability/sa/ClhsdbFindPC.java failures.
>> I did a total of 6 runs (X3 configs) and there were no failures.
>
> @dcubed-ojdk Can you also try pull/2563. It's for https://bugs.openjdk.java.net/browse/JDK-8261710, which is an attempt at a more proper fix for this bug (this PR is just avoiding the real issue, which is an incorrect DSO size calculation.)

@plummercj - I tested pull/2563 and added a note over on that PR.
I see failures in 'release' and 'slowdebug' bits with pull/2563.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2562

From cjplummer at openjdk.java.net  Tue Feb 16 22:26:50 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 16 Feb 2021 22:26:50 GMT
Subject: RFR: 8261098: Add clhsdb "findsym" command [v2]
In-Reply-To: <L8HWr_ODMFkZ0S5xPDGtUUFNzVoKE58Z6SHdjkgOaqM=.00fa3903-33ac-430c-992b-8c241eefda07@github.com>
References: <EcsJkvo_wYh085Hc1uRmViYzUrsfMeNLFOEsn0YSyXs=.8243bb41-62d6-40a0-8942-650a9cd8a497@github.com>
 <XpoVBbUrUuf02j_bS6z7r0n8_kLJ5mr9pBqNHMyfDaA=.5123143d-94ff-46d1-99e4-5cde39521f94@github.com>
 <lI7tcyHdEBpm9SzHKl8HINpyuKK88zX-XXDfn8gnJ7s=.f54d9d66-2d91-40ba-8feb-125e5155cb5f@github.com>
 <3_RpSFsQ7C7vUSRMdLyweUkxbKO23xTI_hkiT4NJOYs=.3eecb45b-0b09-4801-aba6-30226839ae40@github.com>
 <L8HWr_ODMFkZ0S5xPDGtUUFNzVoKE58Z6SHdjkgOaqM=.00fa3903-33ac-430c-992b-8c241eefda07@github.com>
Message-ID: <B0btUCxMV5G7CQlK3QsY2q0hN6YgT1aspnWqm8wzreM=.59b82ce6-491c-4ecb-9110-e63466be0111@github.com>

On Tue, 16 Feb 2021 22:07:04 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The point is the argument is ignored, so it doesn't really matter if AutoJavaString can handle NULL. I  assume with your suggested fix that also want me to pass objectName_cstr to lookup_symbol() rather than an explicit NULL. I wanted the NULL to be explicit to help further convey that objectName is ignored.
>
> lookup_symbol implementation contains FIXME comment about object_name.
> I suppose you want to make this argument ignorance permanent. Then I think this FIXME should be removed (or updated) and it would be nice to add comment about this to lookup_symbol declaration (or maybe it would be better to delete this argument)

If the FIXME in `lookup_symbol` was ever addressed, then we would need for NULL to mean to search all libraries. I suppose in that case it would make sense for AutoJavaString to do as you suggested. It looks like Windows also has an AutoJavaString. I'll change it also, but it is never passed NULL. The Bsd version is, but it handles the GetStringUTFChars() inline without AutoJavaString, and it does support NULL already:

  objectName_cstr = NULL;
  if (objectName != NULL) {
    objectName_cstr = (*env)->GetStringUTFChars(env, objectName, &isCopy);
    CHECK_EXCEPTION_(0);
  }
...
  addr = (jlong) lookup_symbol(ph, objectName_cstr, symbolName_cstr);

-------------

PR: https://git.openjdk.java.net/jdk/pull/2567

From cjplummer at openjdk.java.net  Tue Feb 16 22:35:38 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 16 Feb 2021 22:35:38 GMT
Subject: Integrated: 8261711: Clhsdb "versioncheck true" throws NPE every time
In-Reply-To: <No2GR3rp5bVBhvfB2ztAqX9KWhT7RygtyPfTYijSMTs=.cc1a7cb3-4b95-4a1c-abbb-63bf52459ab2@github.com>
References: <No2GR3rp5bVBhvfB2ztAqX9KWhT7RygtyPfTYijSMTs=.cc1a7cb3-4b95-4a1c-abbb-63bf52459ab2@github.com>
Message-ID: <Qi2acP5V_hsz06kN6eURFSamoNvYeSfrkQ3CWJNEUqk=.b9814d92-0c65-4cb1-99ff-cfe4447989f7@github.com>

On Sun, 14 Feb 2021 09:14:43 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> See CR for details. There's no test for `versioncheck`, and I don't think it's worth adding, especially for this trivial fix. Here's how I tested:
> hsdb> versioncheck
> versioncheck is true
> hsdb> versioncheck false
> hsdb> versioncheck
> versioncheck is false
> hsdb> versioncheck true
> hsdb> versioncheck
> versioncheck is true

This pull request has now been integrated.

Changeset: e7e20d4e
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e7e20d4e
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8261711: Clhsdb "versioncheck true" throws NPE every time

Reviewed-by: amenkov, sspitsyn

-------------

PR: https://git.openjdk.java.net/jdk/pull/2566

From cjplummer at openjdk.java.net  Tue Feb 16 22:54:38 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 16 Feb 2021 22:54:38 GMT
Subject: RFR: 8261710: SA DSO objects have sizes that are too large
In-Reply-To: <1em8Uu_1RP3ceaoHAzOwyyejR9jXJfu9Qy3mBRckXx0=.073c8889-9f12-4856-bd9b-78d02b1dd9eb@github.com>
References: <rtxSvuvKLmHKrLtsnxf76vSK41b_HWPR_7Bn3wf9YuM=.cf1b54ae-f01d-48d5-9641-d7d9faa541f5@github.com>
 <IlGty_H4BHMqmDRi0pWscIAKdyR_nKLI-Ceea9bcxTg=.e9a47c72-cfa8-41d1-8e05-ebde39ac1f24@github.com>
 <k6gxI6l5dgq2xN_8E9tplZqbml81gL1BpsQTd8kdE1s=.7b29334e-0f12-473b-b2f2-7b355cd5d90b@github.com>
 <mUhWqJm-RdRly_sRdxywcm_04PQHZsOaLBf8zi-viqE=.13b1cf2d-990b-4ef9-99b5-f8186c120671@github.com>
 <1em8Uu_1RP3ceaoHAzOwyyejR9jXJfu9Qy3mBRckXx0=.073c8889-9f12-4856-bd9b-78d02b1dd9eb@github.com>
Message-ID: <FRUBBgqsAb017SxqmnJpfYgPJMHWwo4HrTAn4BNe7bE=.75a5c3b4-0272-42bb-9e52-709f64ee86f6@github.com>

On Tue, 16 Feb 2021 12:19:38 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> I updated patch for macOS. I cannot test it, but all of tier 1 servicerbility tests were passed on GitHub Actions. Could you review again?

The OSX changes look good and passed my testing. However as Dan indicated above, it seems with your changes in place the original problem is still being reproduced. Note the original problem never reproduced with the testing I've been doing, so my testing doesn't prove that you fixed the issue. However, Dan is running on a local host that does reproduce the issue pretty reliably, and seems to still reproduce it after your fixes.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2563

From cjplummer at openjdk.java.net  Tue Feb 16 22:54:39 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 16 Feb 2021 22:54:39 GMT
Subject: RFR: 8261710: SA DSO objects have sizes that are too large
In-Reply-To: <FRUBBgqsAb017SxqmnJpfYgPJMHWwo4HrTAn4BNe7bE=.75a5c3b4-0272-42bb-9e52-709f64ee86f6@github.com>
References: <rtxSvuvKLmHKrLtsnxf76vSK41b_HWPR_7Bn3wf9YuM=.cf1b54ae-f01d-48d5-9641-d7d9faa541f5@github.com>
 <IlGty_H4BHMqmDRi0pWscIAKdyR_nKLI-Ceea9bcxTg=.e9a47c72-cfa8-41d1-8e05-ebde39ac1f24@github.com>
 <k6gxI6l5dgq2xN_8E9tplZqbml81gL1BpsQTd8kdE1s=.7b29334e-0f12-473b-b2f2-7b355cd5d90b@github.com>
 <mUhWqJm-RdRly_sRdxywcm_04PQHZsOaLBf8zi-viqE=.13b1cf2d-990b-4ef9-99b5-f8186c120671@github.com>
 <1em8Uu_1RP3ceaoHAzOwyyejR9jXJfu9Qy3mBRckXx0=.073c8889-9f12-4856-bd9b-78d02b1dd9eb@github.com>
 <FRUBBgqsAb017SxqmnJpfYgPJMHWwo4HrTAn4BNe7bE=.75a5c3b4-0272-42bb-9e52-709f64ee86f6@github.com>
Message-ID: <Y592rdA_EQe2rQXQB9eyUk6-KrB5n-et7RwQkEDtmc8=.11a4f938-ff35-489b-987d-145ca692d910@github.com>

On Tue, 16 Feb 2021 22:50:58 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Thanks for explanation!
>> I understood Marc-O is complex, and to use `lib->memsz` is reasonable as you said.
>> 
>> I updated patch for macOS. I cannot test it, but all of tier 1 servicerbility tests were passed on GitHub Actions. Could you review again?
>
>> I updated patch for macOS. I cannot test it, but all of tier 1 servicerbility tests were passed on GitHub Actions. Could you review again?
> 
> The OSX changes look good and passed my testing. However as Dan indicated above, it seems with your changes in place the original problem is still being reproduced. Note the original problem never reproduced with the testing I've been doing, so my testing doesn't prove that you fixed the issue. However, Dan is running on a local host that does reproduce the issue pretty reliably, and seems to still reproduce it after your fixes.

Dan included the logs of the failures in the CR. This is what they show:

  + findpc 0x00002b77f084d116
Address 0x00002b77f084d116: /lib/x86_64-linux-gnu/libnss_files.so.2 + 0x21b116
...
java.lang.RuntimeException: Test ERROR java.lang.RuntimeException: 'In interpreter codelet' missing from stdout/stderr

-------------

PR: https://git.openjdk.java.net/jdk/pull/2563

From cjplummer at openjdk.java.net  Tue Feb 16 23:31:39 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 16 Feb 2021 23:31:39 GMT
Subject: RFR: 8261710: SA DSO objects have sizes that are too large
In-Reply-To: <Y592rdA_EQe2rQXQB9eyUk6-KrB5n-et7RwQkEDtmc8=.11a4f938-ff35-489b-987d-145ca692d910@github.com>
References: <rtxSvuvKLmHKrLtsnxf76vSK41b_HWPR_7Bn3wf9YuM=.cf1b54ae-f01d-48d5-9641-d7d9faa541f5@github.com>
 <IlGty_H4BHMqmDRi0pWscIAKdyR_nKLI-Ceea9bcxTg=.e9a47c72-cfa8-41d1-8e05-ebde39ac1f24@github.com>
 <k6gxI6l5dgq2xN_8E9tplZqbml81gL1BpsQTd8kdE1s=.7b29334e-0f12-473b-b2f2-7b355cd5d90b@github.com>
 <mUhWqJm-RdRly_sRdxywcm_04PQHZsOaLBf8zi-viqE=.13b1cf2d-990b-4ef9-99b5-f8186c120671@github.com>
 <1em8Uu_1RP3ceaoHAzOwyyejR9jXJfu9Qy3mBRckXx0=.073c8889-9f12-4856-bd9b-78d02b1dd9eb@github.com>
 <FRUBBgqsAb017SxqmnJpfYgPJMHWwo4HrTAn4BNe7bE=.75a5c3b4-0272-42bb-9e52-709f64ee86f6@github.com>
 <Y592rdA_EQe2rQXQB9eyUk6-KrB5n-et7RwQkEDtmc8=.11a4f938-ff35-489b-987d-145ca692d910@github.com>
Message-ID: <UWgN_HTc6kwGSqmzbEqn9bQYjiU35WDOEb2WzZMkgN8=.3aabfc54-fc64-4148-9464-9e74e20a8cc1@github.com>

On Tue, 16 Feb 2021 22:51:34 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>>> I updated patch for macOS. I cannot test it, but all of tier 1 servicerbility tests were passed on GitHub Actions. Could you review again?
>> 
>> The OSX changes look good and passed my testing. However as Dan indicated above, it seems with your changes in place the original problem is still being reproduced. Note the original problem never reproduced with the testing I've been doing, so my testing doesn't prove that you fixed the issue. However, Dan is running on a local host that does reproduce the issue pretty reliably, and seems to still reproduce it after your fixes.
>
> Dan included the logs of the failures in the CR. This is what they show:
> 
>   + findpc 0x00002b77f084d116
> Address 0x00002b77f084d116: /lib/x86_64-linux-gnu/libnss_files.so.2 + 0x21b116
> ...
> java.lang.RuntimeException: Test ERROR java.lang.RuntimeException: 'In interpreter codelet' missing from stdout/stderr

I should add that the failures Dan is seeing are with #id3, which is no -Xcomp, but with a core file instead of a live process. With -Xcomp this part of the test is not run, so possibly this is just an issue with the dso size calculation for core files, and works correctly with a live process.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2563

From cjplummer at openjdk.java.net  Wed Feb 17 00:15:38 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 17 Feb 2021 00:15:38 GMT
Subject: RFR: 8261710: SA DSO objects have sizes that are too large
In-Reply-To: <UWgN_HTc6kwGSqmzbEqn9bQYjiU35WDOEb2WzZMkgN8=.3aabfc54-fc64-4148-9464-9e74e20a8cc1@github.com>
References: <rtxSvuvKLmHKrLtsnxf76vSK41b_HWPR_7Bn3wf9YuM=.cf1b54ae-f01d-48d5-9641-d7d9faa541f5@github.com>
 <IlGty_H4BHMqmDRi0pWscIAKdyR_nKLI-Ceea9bcxTg=.e9a47c72-cfa8-41d1-8e05-ebde39ac1f24@github.com>
 <k6gxI6l5dgq2xN_8E9tplZqbml81gL1BpsQTd8kdE1s=.7b29334e-0f12-473b-b2f2-7b355cd5d90b@github.com>
 <mUhWqJm-RdRly_sRdxywcm_04PQHZsOaLBf8zi-viqE=.13b1cf2d-990b-4ef9-99b5-f8186c120671@github.com>
 <1em8Uu_1RP3ceaoHAzOwyyejR9jXJfu9Qy3mBRckXx0=.073c8889-9f12-4856-bd9b-78d02b1dd9eb@github.com>
 <FRUBBgqsAb017SxqmnJpfYgPJMHWwo4HrTAn4BNe7bE=.75a5c3b4-0272-42bb-9e52-709f64ee86f6@github.com>
 <Y592rdA_EQe2rQXQB9eyUk6-KrB5n-et7RwQkEDtmc8=.11a4f938-ff35-489b-987d-145ca692d910@github.com>
 <UWgN_HTc6kwGSqmzbEqn9bQYjiU35WDOEb2WzZMkgN8=.3aabfc54-fc64-4148-9464-9e74e20a8cc1@github.com>
Message-ID: <ENP5bQgjmSQ9NWXXiyDpJGtDed-2ySOstOHgLpG_8s0=.824f38bf-120b-43bd-9811-2cec1aa4dbc1@github.com>

On Tue, 16 Feb 2021 23:28:28 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Dan included the logs of the failures in the CR. This is what they show:
>> 
>>   + findpc 0x00002b77f084d116
>> Address 0x00002b77f084d116: /lib/x86_64-linux-gnu/libnss_files.so.2 + 0x21b116
>> ...
>> java.lang.RuntimeException: Test ERROR java.lang.RuntimeException: 'In interpreter codelet' missing from stdout/stderr
>
> I should add that the failures Dan is seeing are with #id3, which is no -Xcomp, but with a core file instead of a live process. With -Xcomp this part of the test is not run, so possibly this is just an issue with the dso size calculation for core files, and works correctly with a live process.

If you run ClhsdbPmap.java, you can see pmap output for both core and live processes. The sizes of the maps are very large for both of them, and actually a bit bigger with the live process. Here's the output for a live process:

0x000014755360c000	4048K	/usr/lib64/libnss_sss.so.2
0x0000147553815000	4012K	/usr/lib64/libnss_files-2.17.so
0x0000147560208000	4064K	/usr/lib64/libm-2.17.so
0x000014756050a000	3032K	/usr/lib64/librt-2.17.so
0x0000147560712000	32892K	/scratch/cplummer/ws/jdk/jdk.clean/build/linux-x64-debug/images/jdk/lib/server/libjvm.so
0x0000147562731000	4924K	/usr/lib64/libc-2.17.so
0x0000147562aff000	3076K	/usr/lib64/libdl-2.17.so
0x0000147562d03000	3060K	/usr/lib64/libpthread-2.17.so
0x0000147562f1f000	2948K	/usr/lib64/libz.so.1.2.7
0x0000147563135000	2860K	/usr/lib64/ld-2.17.so
0x0000147563164000	92K	/scratch/cplummer/ws/jdk/jdk.clean/build/linux-x64-debug/images/jdk/lib/libnet.so
0x000014756317b000	80K	/scratch/cplummer/ws/jdk/jdk.clean/build/linux-x64-debug/images/jdk/lib/libnio.so
0x00001475631e0000	156K	/scratch/cplummer/ws/jdk/jdk.clean/build/linux-x64-debug/images/jdk/lib/libjava.so
0x0000147563207000	128K	/scratch/cplummer/ws/jdk/jdk.clean/build/linux-x64-debug/images/jdk/lib/libjimage.so
0x000014756332c000	68K	/scratch/cplummer/ws/jdk/jdk.clean/build/linux-x64-debug/images/jdk/lib/libjli.so
0x0000563c950bf000	16K	/scratch/cplummer/ws/jdk/jdk.clean/build/linux-x64-debug/images/jdk/bin/java
`/usr/lib64/libnss_files-2.17.so` is the one that turned up in the test failure. It's only a 68k file but has a 4064k map. It's second in the list. I'm not sure if this is the order we would always see on linux systems. My assumption was it was the library at the highest address that was causing the problem, and that the inteprerter was located right after it, but that might not be the case.

The address in the interpreter that we are doing findpc on turned up at `libnss_files.so.2 + 0x21b116`, or at an offset of 2200k. I added a "pmap" command to ClhsdbFindPC, and from my test runs the interpreter seemed to alway be just before the first library. However, maybe on some systems it is intermixed with the libraries.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2563

From cjplummer at openjdk.java.net  Wed Feb 17 02:12:56 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 17 Feb 2021 02:12:56 GMT
Subject: RFR: 8261098: Add clhsdb "findsym" command [v3]
In-Reply-To: <EcsJkvo_wYh085Hc1uRmViYzUrsfMeNLFOEsn0YSyXs=.8243bb41-62d6-40a0-8942-650a9cd8a497@github.com>
References: <EcsJkvo_wYh085Hc1uRmViYzUrsfMeNLFOEsn0YSyXs=.8243bb41-62d6-40a0-8942-650a9cd8a497@github.com>
Message-ID: <BOLm1OyL1OX-VEExlhhHZ4W_9UMcTStsNtZFHKiRtS8=.ba1f9fb5-8122-4b29-b1ce-d4f192ca98fc@github.com>

> Add "findsym" to clhsdb. See the CR and CSR for details. The [CSR](https://bugs.openjdk.java.net/browse/JDK-8261101) still needs a reviewer.
> 
> There is a fix in LinuxDebuggerLocal_lookupByName0() to allow passing in NULL for the dso name. This is allowed, and in fact even not null it gets ignored. It is needed by the new findsym support in order for the following to work, which passes in null for the dso name:
> 
> `    Address addr = VM.getVM().getDebugger().lookup(null, symbol);`
> 
> There is one other somewhat unrelated fix in the test:
> 
>  -            String value = parts[1];
>  +           String value = parts[1].split(linesep)[0];
> 
> This is suppose to capture just the value at the specified address, but it also captures the newline and some text after. The result if that when `findpc <value>` is executed, it also executes another command or two of garbage commands after that, which produce errors. They were not impacting the test, but were noticeable in the log. I first noticed it when similar code in the new part of the test had the same issue.

Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:

  Improve handling of NULL objectName

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2567/files
  - new: https://git.openjdk.java.net/jdk/pull/2567/files/ba3464c4..1a772c3d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2567&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2567&range=01-02

  Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2567.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2567/head:pull/2567

PR: https://git.openjdk.java.net/jdk/pull/2567

From cjplummer at openjdk.java.net  Wed Feb 17 02:12:56 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 17 Feb 2021 02:12:56 GMT
Subject: RFR: 8261098: Add clhsdb "findsym" command [v2]
In-Reply-To: <B0btUCxMV5G7CQlK3QsY2q0hN6YgT1aspnWqm8wzreM=.59b82ce6-491c-4ecb-9110-e63466be0111@github.com>
References: <EcsJkvo_wYh085Hc1uRmViYzUrsfMeNLFOEsn0YSyXs=.8243bb41-62d6-40a0-8942-650a9cd8a497@github.com>
 <XpoVBbUrUuf02j_bS6z7r0n8_kLJ5mr9pBqNHMyfDaA=.5123143d-94ff-46d1-99e4-5cde39521f94@github.com>
 <lI7tcyHdEBpm9SzHKl8HINpyuKK88zX-XXDfn8gnJ7s=.f54d9d66-2d91-40ba-8feb-125e5155cb5f@github.com>
 <3_RpSFsQ7C7vUSRMdLyweUkxbKO23xTI_hkiT4NJOYs=.3eecb45b-0b09-4801-aba6-30226839ae40@github.com>
 <L8HWr_ODMFkZ0S5xPDGtUUFNzVoKE58Z6SHdjkgOaqM=.00fa3903-33ac-430c-992b-8c241eefda07@github.com>
 <B0btUCxMV5G7CQlK3QsY2q0hN6YgT1aspnWqm8wzreM=.59b82ce6-491c-4ecb-9110-e63466be0111@github.com>
Message-ID: <6WJkqnOjqDttAWaNcajmT7PMzLtX4MCTnETnkmYqO1M=.8aa6b9f7-2cc9-48f6-8454-20e56f6b934a@github.com>

On Tue, 16 Feb 2021 22:24:19 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> lookup_symbol implementation contains FIXME comment about object_name.
>> I suppose you want to make this argument ignorance permanent. Then I think this FIXME should be removed (or updated) and it would be nice to add comment about this to lookup_symbol declaration (or maybe it would be better to delete this argument)
>
> If the FIXME in `lookup_symbol` was ever addressed, then we would need for NULL to mean to search all libraries. I suppose in that case it would make sense for AutoJavaString to do as you suggested. It looks like Windows also has an AutoJavaString. I'll change it also, but it is never passed NULL. The Bsd version is, but it handles the GetStringUTFChars() inline without AutoJavaString, and it does support NULL already:
> 
>   objectName_cstr = NULL;
>   if (objectName != NULL) {
>     objectName_cstr = (*env)->GetStringUTFChars(env, objectName, &isCopy);
>     CHECK_EXCEPTION_(0);
>   }
> ...
>   addr = (jlong) lookup_symbol(ph, objectName_cstr, symbolName_cstr);

I've pushed the AutoJavaString change.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2567

From lzang at openjdk.java.net  Wed Feb 17 03:17:57 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Wed, 17 Feb 2021 03:17:57 GMT
Subject: RFR: JDK-8261034: improve jcmd GC.class_histogram to support
 parallel
In-Reply-To: <FIfmotGSNufKVt5sEnmE2UlvdnokbdJbIbxmVlWa868=.623032fb-1a5e-40e4-8f92-e965a1cd381a@github.com>
References: <VKzVY-01CEXUbQdlKMhDWjtjxUgpxs_6487x232VsAI=.3b9c5d8a-972b-4997-9f75-1951f98e1751@github.com>
 <X_7cTwpI8cxsVTCMi6oe6f1Fy6yPcw7b0-Pa-Ayou2Y=.69cba9c8-f6e4-40b4-a180-3eb79428692b@github.com>
 <EQm4vRIvMgIFwt3dwYO3YTdbCLyQEKjISTt-QudCNbE=.f2366e5b-b9fa-456d-bafa-6531293b2cc2@github.com>
 <gBKEb-EMtCvqvSZiS1ImsYpQg63tg6R8KaizkL-BrlE=.f51a4335-251c-4041-bd71-75ec13f0591d@github.com>
 <v4SsYZMv2DVW2v8KDDDrCMa-JlyDX6Nsa20ue9JZKqs=.2617d216-b696-48c9-b34e-b0a97bb3bf12@github.com>
 <C47zxVTOUeIMyATz4LgWhTZsmZ6Nk5ncQRbgNKSvTxg=.7570353c-862e-428d-b6bf-aed24b461ea9@github.com>
 <oNo87kApGGMUT6MJYpvDAlyjBzza1-GmLNZSwAGrmEc=.d8669c88-6882-4744-8a05-5cadaa48404f@github.com>
 <A-u0xkGoB54J-q4yyOu-fXBqvXkTRLnmje8qh1KUTTE=.75f97621-8e70-4ab4-b54f-f45b37bd84f5@github.com>
 <hZpMlhWW1rB89tC-Wj_DH9R05YcOFOaqkFprf9MwBD4=.755ccfc2-b743-4037-8f0c-69c078937c5e@github.com>
 <-mAEJ8TjIlhEHKFP0ybmVgqjhCIr8YoAz4Q-GilpZgs=.d1b01b4c-3c14-43ad-8203-b1cd4d2f7ad4@github.com>
 <6APNXM7Ih9TxHMNEPD-uOla7-w08UxJeP4e
 f3-f3joA=.77a8b309-1973-471d-87d7-f682b3ebdb32@github.com>
 <L8t5llrzyxpof_frsgyaf8jznTCckZF-h0t7rM8eAX8=.bb67bcc3-d8db-45a5-a365-7cc05faf27da@github.com>
 <BX2O5NH7WOa57DlDNDgWefirxYUBT7nsCnPhqjchfs0=.6df0ae15-a16b-4cbe-ba5c-02c10d4c332f@github.com>
 <uIKLse-ugmKBUDcOM37UbZkziorlrzcMFJAZa25eqTE=.9ad0afaa-37e6-4ee1-885a-936c60bfad7f@github.com>
 <Ze8CKZ6Auw1oW4J-XKuMpO7n7NTedBBmj0O2UKrOH6o=.a16e8ebb-1a0b-499b-a913-92375c486d76@github.com>
 <ZXHKiFA6-hVma_2MXvCzHMLUFspOl3coMjZ5-u2LBA4=.adbb69ca-f7e0-4189-8951-8619403cf835@github.com>
 <uYzejCgfjq5-bRCKx7RaZWH1zUPsDjBMFeBVIaM4B7o=.5a71658f-9431-4bcb-bde9-37970fbf6823@github.com>
 <LXv3U99qPkiJQxlV7UHbRMC9cDYwacPbF6pCVsA2jwg=.dd0dce40-490d-438e-905c-f6fc35c040b7@github.com>
 <mA-4bFE2CPUhPK00SY8G9DC9hjU3y_aJsxdMoy5Z9bA=.ab46dfe9-49c9-4bf2-bf42-d3e6ff81a712@github.com>
 <HFeNprAvlRyaSkwWJO7U8n4u9w8YwZpOCs-8ONl1a3o=.cd41fd5c-d90d-4931-a029-7a2156364eda@github.com>
 <jiD1W4vuwLTeiiZZvCYgiEl-w5XPErcvUeYUxZ1G5QA=.a4b665af-f973-4ec2-befb-e40ff332dee8@
 github.com>
 <BdD2NhK4j3NDO6MEPdgBqrjeqoMkLnLNdpY8Msbmt70=.bb352cad-388a-4d65-b672-dc9c3e2133ac@github.com>
 <FIfmotGSNufKVt5sEnmE2UlvdnokbdJbIbxmVlWa868=.623032fb-1a5e-40e4-8f92-e965a1cd381a@github.com>
Message-ID: <1u3g8qfry7iEGQcvP6fiYy-vaulzJ9rQK1rWVAlR7LU=.4972c8f2-44a7-49b7-83cf-2771c0b16bfb@github.com>

On Sat, 13 Feb 2021 07:10:03 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>>> > Yes, It is not known at present, but the heapInspect and heapDumper accept an outputStream, and the actual parallel thread number can be got by gang->active_workers() after WithUpdatedActiveWorkers. Then maybe some code can be added there to record the actual number and finally print to outputStream at the end.
>>> 
>>> So you are proposing having the attach "heapdumpext" and "inspectheap" commands always print the number of threads used? I'm not so sure that is a good idea since there are probably existing tools and tests that parse the output, and changing its format could break them.
>> 
>> Correct? if there is parsing tools (which I think there alreay are.), they will be broken.
>> So I am afraid user can only tuning the thread number by expriments and some common sense such as the core number of their server or the multi-processing scenario.
>
>> Correct? if there is parsing tools (which I think there alreay are.), they will be broken.
>> So I am afraid user can only tuning the thread number by expriments and some common sense such as the core number of their server or the multi-processing scenario.
> 
> I'm ok with that. I think the other options we've explored are more trouble than they are worth.

Dear All, 
    May I say that we all agreed that "noparallel" is not necessary at present? I think the PR 2519 and related CSR and issue could be all closed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2379

From dcubed at openjdk.java.net  Wed Feb 17 03:47:04 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 17 Feb 2021 03:47:04 GMT
Subject: RFR: 8241403: JavaThread::get_thread_name() should be
 ThreadSMR-aware [v3]
In-Reply-To: <wRdcRQurtpybntK9Qpji-6zVY-EcHKw3q87xpD0eoS4=.a6dc32f4-2919-42e9-80c3-5a264067f0e2@github.com>
References: <wRdcRQurtpybntK9Qpji-6zVY-EcHKw3q87xpD0eoS4=.a6dc32f4-2919-42e9-80c3-5a264067f0e2@github.com>
Message-ID: <yER6SKX-lfZsdJmls-clFnBnZd-SWbJkCF4kO_OZg-o=.64d2e6af-47ea-4f82-9a9a-fec6395a2ad5@github.com>

> A minor fix to add a new function:
> 
>     bool Thread::is_JavaThread_protected(const JavaThread* p)
> 
> that returns true when the target JavaThread* is protected and false
> otherwise. Update JavaThread::get_thread_name() to create a
> ThreadsListHandle and use the new is_JavaThread_protected(). Also
> update JvmtiTrace::safe_get_thread_name() to use the new
> is_JavaThread_protected().
> 
> This fix is tested via a Mach5 Tier[1-8] run.

Daniel D. Daugherty has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Merge branch 'master' into JDK-8241403
 - Address coleenp CR0 comments.
 - 8241403: JavaThread::get_thread_name() should be ThreadSMR-aware

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2535/files
  - new: https://git.openjdk.java.net/jdk/pull/2535/files/00e38868..1401c327

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2535&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2535&range=01-02

  Stats: 32041 lines in 979 files changed: 18959 ins; 8673 del; 4409 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2535.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2535/head:pull/2535

PR: https://git.openjdk.java.net/jdk/pull/2535

From dcubed at openjdk.java.net  Wed Feb 17 03:47:05 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 17 Feb 2021 03:47:05 GMT
Subject: RFR: 8241403: JavaThread::get_thread_name() should be
 ThreadSMR-aware [v2]
In-Reply-To: <D6G_iv5f7cVSgISF_UMAd3FYrEj-iXhNh5JC5Gm0Voo=.a91715fe-59ff-4640-ad07-97ff3a8cc1a3@github.com>
References: <wRdcRQurtpybntK9Qpji-6zVY-EcHKw3q87xpD0eoS4=.a6dc32f4-2919-42e9-80c3-5a264067f0e2@github.com>
 <UY810XwxI_xwVSwdtX4pcnH__prubKLOXJB-2fMK0n4=.154fa1e0-560f-405e-ac62-e143c9a36536@github.com>
 <d_HrdNGEX1dkcfjPWLu_84SzSX4I-jZm2kHYKbwAvZU=.a7e2382b-77cb-43ca-9473-78be2685c6ac@github.com>
 <xtCVgcK-lMTrnhaW135wk0yYqABXGzQl8kM2kXuhhR8=.871caaa3-aadc-4294-beaf-fe6d97d6fd8f@github.com>
 <D6G_iv5f7cVSgISF_UMAd3FYrEj-iXhNh5JC5Gm0Voo=.a91715fe-59ff-4640-ad07-97ff3a8cc1a3@github.com>
Message-ID: <KbJARI_PVcm_DnpqHDrxH9mh2Yk2_Vx47xkSH4wgM3Q=.ad83d4ed-f011-40fd-81ad-0cb2293b9110@github.com>

On Tue, 16 Feb 2021 21:24:32 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> @coleenp and @sspitsyn - Thanks for the re-reviews!
>
> @dholmes and @fisk - did either or both of you plan to review this one?

Merged with master and retested with Mach5 Tier1.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2535

From cjplummer at openjdk.java.net  Wed Feb 17 04:33:38 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 17 Feb 2021 04:33:38 GMT
Subject: RFR: JDK-8261034: improve jcmd GC.class_histogram to support
 parallel
In-Reply-To: <1u3g8qfry7iEGQcvP6fiYy-vaulzJ9rQK1rWVAlR7LU=.4972c8f2-44a7-49b7-83cf-2771c0b16bfb@github.com>
References: <VKzVY-01CEXUbQdlKMhDWjtjxUgpxs_6487x232VsAI=.3b9c5d8a-972b-4997-9f75-1951f98e1751@github.com>
 <X_7cTwpI8cxsVTCMi6oe6f1Fy6yPcw7b0-Pa-Ayou2Y=.69cba9c8-f6e4-40b4-a180-3eb79428692b@github.com>
 <EQm4vRIvMgIFwt3dwYO3YTdbCLyQEKjISTt-QudCNbE=.f2366e5b-b9fa-456d-bafa-6531293b2cc2@github.com>
 <gBKEb-EMtCvqvSZiS1ImsYpQg63tg6R8KaizkL-BrlE=.f51a4335-251c-4041-bd71-75ec13f0591d@github.com>
 <v4SsYZMv2DVW2v8KDDDrCMa-JlyDX6Nsa20ue9JZKqs=.2617d216-b696-48c9-b34e-b0a97bb3bf12@github.com>
 <C47zxVTOUeIMyATz4LgWhTZsmZ6Nk5ncQRbgNKSvTxg=.7570353c-862e-428d-b6bf-aed24b461ea9@github.com>
 <oNo87kApGGMUT6MJYpvDAlyjBzza1-GmLNZSwAGrmEc=.d8669c88-6882-4744-8a05-5cadaa48404f@github.com>
 <A-u0xkGoB54J-q4yyOu-fXBqvXkTRLnmje8qh1KUTTE=.75f97621-8e70-4ab4-b54f-f45b37bd84f5@github.com>
 <hZpMlhWW1rB89tC-Wj_DH9R05YcOFOaqkFprf9MwBD4=.755ccfc2-b743-4037-8f0c-69c078937c5e@github.com>
 <-mAEJ8TjIlhEHKFP0ybmVgqjhCIr8YoAz4Q-GilpZgs=.d1b01b4c-3c14-43ad-8203-b1cd4d2f7ad4@github.com>
 <6APNXM7Ih9TxHMNEPD-uOla7-w08UxJeP4e
 f3-f3joA=.77a8b309-1973-471d-87d7-f682b3ebdb32@github.com>
 <L8t5llrzyxpof_frsgyaf8jznTCckZF-h0t7rM8eAX8=.bb67bcc3-d8db-45a5-a365-7cc05faf27da@github.com>
 <BX2O5NH7WOa57DlDNDgWefirxYUBT7nsCnPhqjchfs0=.6df0ae15-a16b-4cbe-ba5c-02c10d4c332f@github.com>
 <uIKLse-ugmKBUDcOM37UbZkziorlrzcMFJAZa25eqTE=.9ad0afaa-37e6-4ee1-885a-936c60bfad7f@github.com>
 <Ze8CKZ6Auw1oW4J-XKuMpO7n7NTedBBmj0O2UKrOH6o=.a16e8ebb-1a0b-499b-a913-92375c486d76@github.com>
 <ZXHKiFA6-hVma_2MXvCzHMLUFspOl3coMjZ5-u2LBA4=.adbb69ca-f7e0-4189-8951-8619403cf835@github.com>
 <uYzejCgfjq5-bRCKx7RaZWH1zUPsDjBMFeBVIaM4B7o=.5a71658f-9431-4bcb-bde9-37970fbf6823@github.com>
 <LXv3U99qPkiJQxlV7UHbRMC9cDYwacPbF6pCVsA2jwg=.dd0dce40-490d-438e-905c-f6fc35c040b7@github.com>
 <mA-4bFE2CPUhPK00SY8G9DC9hjU3y_aJsxdMoy5Z9bA=.ab46dfe9-49c9-4bf2-bf42-d3e6ff81a712@github.com>
 <HFeNprAvlRyaSkwWJO7U8n4u9w8YwZpOCs-8ONl1a3o=.cd41fd5c-d90d-4931-a029-7a2156364eda@github.com>
 <jiD1W4vuwLTeiiZZvCYgiEl-w5XPErcvUeYUxZ1G5QA=.a4b665af-f973-4ec2-befb-e40ff332dee8@
 github.com>
 <BdD2NhK4j3NDO6MEPdgBqrjeqoMkLnLNdpY8Msbmt70=.bb352cad-388a-4d65-b672-dc9c3e2133ac@github.com>
 <FIfmotGSNufKVt5sEnmE2UlvdnokbdJbIbxmVlWa868=.623032fb-1a5e-40e4-8f92-e965a1cd381a@github.com>
 <1u3g8qfry7iEGQcvP6fiYy-vaulzJ9rQK1rWVAlR7LU=.4972c8f2-44a7-49b7-83cf-2771c0b16bfb@github.com>
Message-ID: <vPaS5x8Dsl5iyfwApmU1cMEuzjSbP_l-I60NOd1X9VE=.718c4d1c-6871-4fb6-aa15-306c842e152d@github.com>

On Wed, 17 Feb 2021 03:14:51 GMT, Lin Zang <lzang at openjdk.org> wrote:

>  May I say that we all agreed that "noparallel" is not necessary at present? I think the PR #2519 and related CSR and issue could be all closed.

Yes, assuming we get approval for `dumpheapext`. Unfortunately the email that went out did not get any feedback. Maybe we should just create a CSR for that and see what the CSR committee says.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2379

From lzang at openjdk.java.net  Wed Feb 17 04:47:39 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Wed, 17 Feb 2021 04:47:39 GMT
Subject: RFR: 8261482: Adjust jmap histo command to accept noparallel
 option to inspect heap serially
In-Reply-To: <Tw5mfybEuzyGsoqGNDMD3ZAVc4m-m3Pq2aJIshAphZc=.a904f0ce-a8f8-4a03-80fb-29e3b33dcd6d@github.com>
References: <friAzRs8vnY7hHEUc-fiL0KSGmEiAnZ9Lckg76-t8cM=.9bf22703-d312-4bad-bd28-2571170637af@github.com>
 <Tw5mfybEuzyGsoqGNDMD3ZAVc4m-m3Pq2aJIshAphZc=.a904f0ce-a8f8-4a03-80fb-29e3b33dcd6d@github.com>
Message-ID: <s0X8Cww6Uj3BoGzRW6ULCsbWEYhpeH06eOtp9G18dUM=.25dcb4c4-5d59-4d54-8ed9-67db5bce1b28@github.com>

On Thu, 11 Feb 2021 02:43:46 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> 8261482: Adjust jmap histo command to accept noparallel option to inspect heap serially
>
> Dear All,
>      Stories and discussions related with this PR could be found at #2379 and #2261.  Just FYI.
> BRs,
> Lin

>From the discussion of #2379, it is prefered to keep "parallel=n" option. 
so close this PR.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2519

From lzang at openjdk.java.net  Wed Feb 17 04:47:39 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Wed, 17 Feb 2021 04:47:39 GMT
Subject: Withdrawn: 8261482: Adjust jmap histo command to accept noparallel
 option to inspect heap serially
In-Reply-To: <friAzRs8vnY7hHEUc-fiL0KSGmEiAnZ9Lckg76-t8cM=.9bf22703-d312-4bad-bd28-2571170637af@github.com>
References: <friAzRs8vnY7hHEUc-fiL0KSGmEiAnZ9Lckg76-t8cM=.9bf22703-d312-4bad-bd28-2571170637af@github.com>
Message-ID: <8dpkus_KykBCnQqBJ3flQWFg6mNJfnLqoEkwPFEZTHA=.0326e13d-22ec-4072-bc8f-2f17819d3cef@github.com>

On Thu, 11 Feb 2021 02:36:01 GMT, Lin Zang <lzang at openjdk.org> wrote:

> 8261482: Adjust jmap histo command to accept noparallel option to inspect heap serially

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2519

From lzang at openjdk.java.net  Wed Feb 17 04:48:47 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Wed, 17 Feb 2021 04:48:47 GMT
Subject: RFR: JDK-8261034: improve jcmd GC.class_histogram to support
 parallel
In-Reply-To: <vPaS5x8Dsl5iyfwApmU1cMEuzjSbP_l-I60NOd1X9VE=.718c4d1c-6871-4fb6-aa15-306c842e152d@github.com>
References: <VKzVY-01CEXUbQdlKMhDWjtjxUgpxs_6487x232VsAI=.3b9c5d8a-972b-4997-9f75-1951f98e1751@github.com>
 <X_7cTwpI8cxsVTCMi6oe6f1Fy6yPcw7b0-Pa-Ayou2Y=.69cba9c8-f6e4-40b4-a180-3eb79428692b@github.com>
 <EQm4vRIvMgIFwt3dwYO3YTdbCLyQEKjISTt-QudCNbE=.f2366e5b-b9fa-456d-bafa-6531293b2cc2@github.com>
 <gBKEb-EMtCvqvSZiS1ImsYpQg63tg6R8KaizkL-BrlE=.f51a4335-251c-4041-bd71-75ec13f0591d@github.com>
 <v4SsYZMv2DVW2v8KDDDrCMa-JlyDX6Nsa20ue9JZKqs=.2617d216-b696-48c9-b34e-b0a97bb3bf12@github.com>
 <C47zxVTOUeIMyATz4LgWhTZsmZ6Nk5ncQRbgNKSvTxg=.7570353c-862e-428d-b6bf-aed24b461ea9@github.com>
 <oNo87kApGGMUT6MJYpvDAlyjBzza1-GmLNZSwAGrmEc=.d8669c88-6882-4744-8a05-5cadaa48404f@github.com>
 <A-u0xkGoB54J-q4yyOu-fXBqvXkTRLnmje8qh1KUTTE=.75f97621-8e70-4ab4-b54f-f45b37bd84f5@github.com>
 <hZpMlhWW1rB89tC-Wj_DH9R05YcOFOaqkFprf9MwBD4=.755ccfc2-b743-4037-8f0c-69c078937c5e@github.com>
 <-mAEJ8TjIlhEHKFP0ybmVgqjhCIr8YoAz4Q-GilpZgs=.d1b01b4c-3c14-43ad-8203-b1cd4d2f7ad4@github.com>
 <6APNXM7Ih9TxHMNEPD-uOla7-w08UxJeP4e
 f3-f3joA=.77a8b309-1973-471d-87d7-f682b3ebdb32@github.com>
 <L8t5llrzyxpof_frsgyaf8jznTCckZF-h0t7rM8eAX8=.bb67bcc3-d8db-45a5-a365-7cc05faf27da@github.com>
 <BX2O5NH7WOa57DlDNDgWefirxYUBT7nsCnPhqjchfs0=.6df0ae15-a16b-4cbe-ba5c-02c10d4c332f@github.com>
 <uIKLse-ugmKBUDcOM37UbZkziorlrzcMFJAZa25eqTE=.9ad0afaa-37e6-4ee1-885a-936c60bfad7f@github.com>
 <Ze8CKZ6Auw1oW4J-XKuMpO7n7NTedBBmj0O2UKrOH6o=.a16e8ebb-1a0b-499b-a913-92375c486d76@github.com>
 <ZXHKiFA6-hVma_2MXvCzHMLUFspOl3coMjZ5-u2LBA4=.adbb69ca-f7e0-4189-8951-8619403cf835@github.com>
 <uYzejCgfjq5-bRCKx7RaZWH1zUPsDjBMFeBVIaM4B7o=.5a71658f-9431-4bcb-bde9-37970fbf6823@github.com>
 <LXv3U99qPkiJQxlV7UHbRMC9cDYwacPbF6pCVsA2jwg=.dd0dce40-490d-438e-905c-f6fc35c040b7@github.com>
 <mA-4bFE2CPUhPK00SY8G9DC9hjU3y_aJsxdMoy5Z9bA=.ab46dfe9-49c9-4bf2-bf42-d3e6ff81a712@github.com>
 <HFeNprAvlRyaSkwWJO7U8n4u9w8YwZpOCs-8ONl1a3o=.cd41fd5c-d90d-4931-a029-7a2156364eda@github.com>
 <jiD1W4vuwLTeiiZZvCYgiEl-w5XPErcvUeYUxZ1G5QA=.a4b665af-f973-4ec2-befb-e40ff332dee8@
 github.com>
 <BdD2NhK4j3NDO6MEPdgBqrjeqoMkLnLNdpY8Msbmt70=.bb352cad-388a-4d65-b672-dc9c3e2133ac@github.com>
 <FIfmotGSNufKVt5sEnmE2UlvdnokbdJbIbxmVlWa868=.623032fb-1a5e-40e4-8f92-e965a1cd381a@github.com>
 <1u3g8qfry7iEGQcvP6fiYy-vaulzJ9rQK1rWVAlR7LU=.4972c8f2-44a7-49b7-83cf-2771c0b16bfb@github.com>
 <vPaS5x8Dsl5iyfwApmU1cMEuzjSbP_l-I60NOd1X9VE=.718c4d1c-6871-4fb6-aa15-306c842e152d@github.com>
Message-ID: <1vw2tGbuOk2bOwU1LT__6OwHJOU0eaTvfAtSntFDLFs=.bde13965-583b-424a-a05b-66e7b1e5c7c7@github.com>

On Wed, 17 Feb 2021 04:30:45 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> > May I say that we all agreed that "noparallel" is not necessary at present? I think the PR #2519 and related CSR and issue could be all closed.
> 
> Yes, assuming we get approval for `dumpheapext`. Unfortunately the email that went out did not get any feedback. Maybe we should just create a CSR for that and see what the CSR committee says.

OK, I will create the CSR and update it in the email thread also.
Thanks!

-------------

PR: https://git.openjdk.java.net/jdk/pull/2379

From ysuenaga at openjdk.java.net  Wed Feb 17 06:28:09 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Wed, 17 Feb 2021 06:28:09 GMT
Subject: RFR: 8261710: SA DSO objects have sizes that are too large [v4]
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: <-tUjqHsXhVl31QRbblNj5TjV6BVOOLtl6dmXjzVFheo=.498514c8-d0f8-4081-a036-1f9114a6a9c3@github.com>

> 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 incrementally with one additional commit since the last revision:

  Use p_filesz instead of p_memsz

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2563/files
  - new: https://git.openjdk.java.net/jdk/pull/2563/files/c9a34723..033e096e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2563&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2563&range=02-03

  Stats: 28 lines in 1 file changed: 10 ins; 10 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2563.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2563/head:pull/2563

PR: https://git.openjdk.java.net/jdk/pull/2563

From ysuenaga at openjdk.java.net  Wed Feb 17 06:48:43 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Wed, 17 Feb 2021 06:48:43 GMT
Subject: RFR: 8261710: SA DSO objects have sizes that are too large
In-Reply-To: <ENP5bQgjmSQ9NWXXiyDpJGtDed-2ySOstOHgLpG_8s0=.824f38bf-120b-43bd-9811-2cec1aa4dbc1@github.com>
References: <rtxSvuvKLmHKrLtsnxf76vSK41b_HWPR_7Bn3wf9YuM=.cf1b54ae-f01d-48d5-9641-d7d9faa541f5@github.com>
 <IlGty_H4BHMqmDRi0pWscIAKdyR_nKLI-Ceea9bcxTg=.e9a47c72-cfa8-41d1-8e05-ebde39ac1f24@github.com>
 <k6gxI6l5dgq2xN_8E9tplZqbml81gL1BpsQTd8kdE1s=.7b29334e-0f12-473b-b2f2-7b355cd5d90b@github.com>
 <mUhWqJm-RdRly_sRdxywcm_04PQHZsOaLBf8zi-viqE=.13b1cf2d-990b-4ef9-99b5-f8186c120671@github.com>
 <1em8Uu_1RP3ceaoHAzOwyyejR9jXJfu9Qy3mBRckXx0=.073c8889-9f12-4856-bd9b-78d02b1dd9eb@github.com>
 <FRUBBgqsAb017SxqmnJpfYgPJMHWwo4HrTAn4BNe7bE=.75a5c3b4-0272-42bb-9e52-709f64ee86f6@github.com>
 <Y592rdA_EQe2rQXQB9eyUk6-KrB5n-et7RwQkEDtmc8=.11a4f938-ff35-489b-987d-145ca692d910@github.com>
 <UWgN_HTc6kwGSqmzbEqn9bQYjiU35WDOEb2WzZMkgN8=.3aabfc54-fc64-4148-9464-9e74e20a8cc1@github.com>
 <ENP5bQgjmSQ9NWXXiyDpJGtDed-2ySOstOHgLpG_8s0=.824f38bf-120b-43bd-9811-2cec1aa4dbc1@github.com>
Message-ID: <2SkS8QygsIwmN6nMlOEzn7aUDOFQ1BHbSAB_TsPB8zM=.05317643-1e0c-4047-a326-2fb18a4086d6@github.com>

On Wed, 17 Feb 2021 00:13:02 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> I should add that the failures Dan is seeing are with #id3, which is no -Xcomp, but with a core file instead of a live process. With -Xcomp this part of the test is not run, so possibly this is just an issue with the dso size calculation for core files, and works correctly with a live process.
>
> If you run ClhsdbPmap.java, you can see pmap output for both core and live processes. The sizes of the maps are very large for both of them, and actually a bit bigger with the live process. Here's the output for a live process:
> 
> 0x000014755360c000	4048K	/usr/lib64/libnss_sss.so.2
> 0x0000147553815000	4012K	/usr/lib64/libnss_files-2.17.so
> 0x0000147560208000	4064K	/usr/lib64/libm-2.17.so
> 0x000014756050a000	3032K	/usr/lib64/librt-2.17.so
> 0x0000147560712000	32892K	/scratch/cplummer/ws/jdk/jdk.clean/build/linux-x64-debug/images/jdk/lib/server/libjvm.so
> 0x0000147562731000	4924K	/usr/lib64/libc-2.17.so
> 0x0000147562aff000	3076K	/usr/lib64/libdl-2.17.so
> 0x0000147562d03000	3060K	/usr/lib64/libpthread-2.17.so
> 0x0000147562f1f000	2948K	/usr/lib64/libz.so.1.2.7
> 0x0000147563135000	2860K	/usr/lib64/ld-2.17.so
> 0x0000147563164000	92K	/scratch/cplummer/ws/jdk/jdk.clean/build/linux-x64-debug/images/jdk/lib/libnet.so
> 0x000014756317b000	80K	/scratch/cplummer/ws/jdk/jdk.clean/build/linux-x64-debug/images/jdk/lib/libnio.so
> 0x00001475631e0000	156K	/scratch/cplummer/ws/jdk/jdk.clean/build/linux-x64-debug/images/jdk/lib/libjava.so
> 0x0000147563207000	128K	/scratch/cplummer/ws/jdk/jdk.clean/build/linux-x64-debug/images/jdk/lib/libjimage.so
> 0x000014756332c000	68K	/scratch/cplummer/ws/jdk/jdk.clean/build/linux-x64-debug/images/jdk/lib/libjli.so
> 0x0000563c950bf000	16K	/scratch/cplummer/ws/jdk/jdk.clean/build/linux-x64-debug/images/jdk/bin/java
> `/usr/lib64/libnss_files-2.17.so` is the one that turned up in the test failure. It's only a 68k file but has a 4064k map. It's second in the list. I'm not sure if this is the order we would always see on linux systems. My assumption was it was the library at the highest address that was causing the problem, and that the inteprerter was located right after it, but that might not be the case.
> 
> The address in the interpreter that we are doing findpc on turned up at `libnss_files.so.2 + 0x21b116`, or at an offset of 2200k. I added a "pmap" command to ClhsdbFindPC, and from my test runs the interpreter seemed to alway be just before the first library. However, maybe on some systems it is intermixed with the libraries.

I pushed new change to use `ELF_PHDR.p_filesz` instead of `p_memsz`. It almost works fine, but it is not perfect solution.
For example, let's consider for libnss_sss (provided by Fedora 33) - `/proc/<PID>/maps` shows libnss as following. There are 5 segments.

7f0ba6ec5000-7f0ba6ec7000 r--p 00000000 08:03 340133                     /usr/lib64/libnss_sss.so.2
7f0ba6ec7000-7f0ba6ece000 r-xp 00002000 08:03 340133                     /usr/lib64/libnss_sss.so.2
7f0ba6ece000-7f0ba6ed0000 r--p 00009000 08:03 340133                     /usr/lib64/libnss_sss.so.2
7f0ba6ed0000-7f0ba6ed1000 r--p 0000a000 08:03 340133                     /usr/lib64/libnss_sss.so.2
7f0ba6ed1000-7f0ba6ed2000 rw-p 0000b000 08:03 340133                     /usr/lib64/libnss_sss.so.2

However I could see only 4 segments in libnss_sss.so when I ran `readelf -l /usr/lib64/libnss_sss.so.2`:

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  LOAD           0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000001468 0x0000000000001468  R      0x1000
  LOAD           0x0000000000002000 0x0000000000002000 0x0000000000002000
                 0x0000000000006931 0x0000000000006931  R E    0x1000
  LOAD           0x0000000000009000 0x0000000000009000 0x0000000000009000
                 0x0000000000001110 0x0000000000001110  R      0x1000
  LOAD           0x000000000000ac78 0x000000000000bc78 0x000000000000bc78
                 0x000000000000044c 0x0000000000000658  RW     0x1000

Linux kernel seems to separate final segment (0xbc78) into RO and RW segments when it attempts to load shared library. (but I'm not sure)

I think we need to refactor handling shared libraries in other ways.

For live process, we can use `/proc/<PID>/maps`.
For coredump, we can use `NT_FILE` in note section in corefile, It has valid segments as below.

$ readelf -n core
  :
    0x00007f0ba6ec5000  0x00007f0ba6ec7000  0x0000000000000000

    0x00007f0ba6ec7000  0x00007f0ba6ece000  0x0000000000000002

    0x00007f0ba6ece000  0x00007f0ba6ed0000  0x0000000000000009

    0x00007f0ba6ed0000  0x00007f0ba6ed1000  0x000000000000000a

    0x00007f0ba6ed1000  0x00007f0ba6ed2000  0x000000000000000b


But they makes big change to SA.
As an option, we can integrate this change at first, then we will refactor them.
What do you think?
(I want to resolve this problem with smaller fix if I can of course, so another solutions are welcome)

-------------

PR: https://git.openjdk.java.net/jdk/pull/2563

From cjplummer at openjdk.java.net  Wed Feb 17 07:35:41 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 17 Feb 2021 07:35:41 GMT
Subject: RFR: 8261710: SA DSO objects have sizes that are too large
In-Reply-To: <2SkS8QygsIwmN6nMlOEzn7aUDOFQ1BHbSAB_TsPB8zM=.05317643-1e0c-4047-a326-2fb18a4086d6@github.com>
References: <rtxSvuvKLmHKrLtsnxf76vSK41b_HWPR_7Bn3wf9YuM=.cf1b54ae-f01d-48d5-9641-d7d9faa541f5@github.com>
 <IlGty_H4BHMqmDRi0pWscIAKdyR_nKLI-Ceea9bcxTg=.e9a47c72-cfa8-41d1-8e05-ebde39ac1f24@github.com>
 <k6gxI6l5dgq2xN_8E9tplZqbml81gL1BpsQTd8kdE1s=.7b29334e-0f12-473b-b2f2-7b355cd5d90b@github.com>
 <mUhWqJm-RdRly_sRdxywcm_04PQHZsOaLBf8zi-viqE=.13b1cf2d-990b-4ef9-99b5-f8186c120671@github.com>
 <1em8Uu_1RP3ceaoHAzOwyyejR9jXJfu9Qy3mBRckXx0=.073c8889-9f12-4856-bd9b-78d02b1dd9eb@github.com>
 <FRUBBgqsAb017SxqmnJpfYgPJMHWwo4HrTAn4BNe7bE=.75a5c3b4-0272-42bb-9e52-709f64ee86f6@github.com>
 <Y592rdA_EQe2rQXQB9eyUk6-KrB5n-et7RwQkEDtmc8=.11a4f938-ff35-489b-987d-145ca692d910@github.com>
 <UWgN_HTc6kwGSqmzbEqn9bQYjiU35WDOEb2WzZMkgN8=.3aabfc54-fc64-4148-9464-9e74e20a8cc1@github.com>
 <ENP5bQgjmSQ9NWXXiyDpJGtDed-2ySOstOHgLpG_8s0=.824f38bf-120b-43bd-9811-2cec1aa4dbc1@github.com>
 <2SkS8QygsIwmN6nMlOEzn7aUDOFQ1BHbSAB_TsPB8zM=.05317643-1e0c-4047-a326-2fb18a4086d6@github.com>
Message-ID: <Y3c2FMjumdBjhOo1gLSUl9ZeOoEJ3G7kO5Nv4WPbR9o=.3e15a176-d245-4f75-9fa7-5ae37ab82cd2@github.com>

On Wed, 17 Feb 2021 06:46:27 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> Linux kernel seems to separate final segment (0xbc78) into RO and RW segments when it attempts to load shared library. (but I'm not sure)

I know I've seen this brought up before, if not with SA then with hotspot itself. Maybe it was CDS or NMT. Or maybe it has something to do with how hotspot generates core dumps (I seem to recall there are some bits you can set somewhere that determine what does or does not get dumped to the core).

In any case, I think the main issue it causes for you is that your rounding up the size of the last (4th) segment may not enough. I think in most cases you would need to round it up to a page boundary, and then add another page to it. Consider a page as 4k and let's say the segment size is 2k, but it is split into two 1k segments. Each of those segment would take one page, so a total of 8k. But if you round 2k up to a page boundary you only get to 4k. You need to add another page to that. I think the only time you don't want to add an extra page to the size is if one of the segment's size was already page aligned. However, you have know way of knowing if that will be the case, unless you can determine the RO and RW sizes of the segment.

> But they makes big change to SA.
As an option, we can integrate this change at first, then we will refactor them.
What do you think?

Whatever works for you. I'm actually not too concerned about getting this right, because with my PointerFinder workaround I don't think this issue with the map sizes has much impact on SA. Probably the only place it will show up is with SA pmap output.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2563

From dholmes at openjdk.java.net  Wed Feb 17 07:35:46 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 17 Feb 2021 07:35:46 GMT
Subject: RFR: 8241403: JavaThread::get_thread_name() should be
 ThreadSMR-aware [v3]
In-Reply-To: <yER6SKX-lfZsdJmls-clFnBnZd-SWbJkCF4kO_OZg-o=.64d2e6af-47ea-4f82-9a9a-fec6395a2ad5@github.com>
References: <wRdcRQurtpybntK9Qpji-6zVY-EcHKw3q87xpD0eoS4=.a6dc32f4-2919-42e9-80c3-5a264067f0e2@github.com>
 <yER6SKX-lfZsdJmls-clFnBnZd-SWbJkCF4kO_OZg-o=.64d2e6af-47ea-4f82-9a9a-fec6395a2ad5@github.com>
Message-ID: <LwyuPftEZnuGNnUAjr3ar5upnTHEBRZF9JRtdciVc1s=.64695cc9-0139-4efd-aa4d-e5c57eddca9f@github.com>

On Wed, 17 Feb 2021 03:47:04 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> A minor fix to add a new function:
>> 
>>     bool Thread::is_JavaThread_protected(const JavaThread* p)
>> 
>> that returns true when the target JavaThread* is protected and false
>> otherwise. Update JavaThread::get_thread_name() to create a
>> ThreadsListHandle and use the new is_JavaThread_protected(). Also
>> update JvmtiTrace::safe_get_thread_name() to use the new
>> is_JavaThread_protected().
>> 
>> This fix is tested via a Mach5 Tier[1-8] run.
>
> Daniel D. Daugherty has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8241403
>  - Address coleenp CR0 comments.
>  - 8241403: JavaThread::get_thread_name() should be ThreadSMR-aware

Hi Dan,

Sorry but I have a lot of issues with this. After thinking about it a lot I don't think the current approach is what is needed. To repeat what I wrote in one of the comments I think the simple fix here is to replace the use of Threads_lock in the caller with suitable use of a TLH, and then replace the assert_locked_or_safepoint(Threads_lock) with assert(is_JavaThread_protected(t)) where is_JavaThread_protected checks the target for either being the current thread or included in a TLH of the current thread. I don't think get_thread_name() should try to protect the target as that is the responsibility of the caller.

Thanks,
David

src/hotspot/share/runtime/thread.cpp line 486:

> 484: 
> 485: // Is the target JavaThread protected by this Thread:
> 486: bool Thread::is_JavaThread_protected(const JavaThread* p) {

Why is this a function on Thread instead of JavaThread??

src/hotspot/share/prims/jvmtiTrace.cpp line 283:

> 281:   // If the target JavaThread is not protected, then we return the
> 282:   // specified non-NULL string:
> 283:   return thread->as_Java_thread()->get_thread_name("<NOT FILLED IN>");

That's not what the original logic is doing. We only return "NOT FILLED IN" if we find that the java.lang.Thread oop does not have a name set. That's not normally possible but this code is intended to be 100% safe, hence the check. (And it may be possible to see null during the attach process ...)

I would expect the target thread to already be protected when this method is called in any case. So while this code partially duplicates JavaThread::get_thread_name() I'm not convinced we need to change this code to use JavaThread::get_thread_name() instead.

src/hotspot/share/runtime/thread.cpp line 490:

> 488:     // Current thread is always protected:
> 489:     return true;
> 490:   }

This is true but it is awkward that we are going to manifest Thread::current multiple times when using this - see below.

src/hotspot/share/runtime/thread.cpp line 2547:

> 2545: // for such that this method never returns NULL.
> 2546: const char* JavaThread::get_thread_name(const char* default_name) const {
> 2547:   Thread* thread = Thread::current();

So you manifest Thread::current() and then is_JavaThread_protected will manifest it again.

src/hotspot/share/runtime/thread.cpp line 2548:

> 2546: const char* JavaThread::get_thread_name(const char* default_name) const {
> 2547:   Thread* thread = Thread::current();
> 2548:   ThreadsListHandle tlh(thread);

I would only expect this code to create a TLH if the target is not protected, otherwise why do we need to search through the existing thread-lists as it would suffice to see if the target is within the newly created TLH ??
I expected the basic logic here to be:
`if (thread is protected) return name;
else { protect the thread; return name; }`

though if it is cheaper to create a TLH than to search the existing ones, then we may as well just create the TLH, check that the target has been captured and then return its name.

That said we need to carefully examine where the taking of the Threads_lock would occur in the thread termination sequence, to understand what observable states are possible with respect to the target having a threadObj. (Though this may have already changed with the introduction of Thread-SMR.)

That all said I'm not so sure the only thing we actually need to do for this issue is to replace the use of Threads_lock, in the caller, with suitable TLH usage, and then in get_thread_name() assert that the target is in fact protected.

-------------

Changes requested by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2535

From dholmes at openjdk.java.net  Wed Feb 17 07:35:47 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 17 Feb 2021 07:35:47 GMT
Subject: RFR: 8241403: JavaThread::get_thread_name() should be
 ThreadSMR-aware [v2]
In-Reply-To: <UY810XwxI_xwVSwdtX4pcnH__prubKLOXJB-2fMK0n4=.154fa1e0-560f-405e-ac62-e143c9a36536@github.com>
References: <wRdcRQurtpybntK9Qpji-6zVY-EcHKw3q87xpD0eoS4=.a6dc32f4-2919-42e9-80c3-5a264067f0e2@github.com>
 <UY810XwxI_xwVSwdtX4pcnH__prubKLOXJB-2fMK0n4=.154fa1e0-560f-405e-ac62-e143c9a36536@github.com>
Message-ID: <NnM7MtJfxNa66wBIrc7to1gg5lMMAETonQa06KnCfCo=.c0513f4a-2567-409b-ab65-4ac3025f006b@github.com>

On Sat, 13 Feb 2021 21:53:51 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> A minor fix to add a new function:
>> 
>>     bool Thread::is_JavaThread_protected(const JavaThread* p)
>> 
>> that returns true when the target JavaThread* is protected and false
>> otherwise. Update JavaThread::get_thread_name() to create a
>> ThreadsListHandle and use the new is_JavaThread_protected(). Also
>> update JvmtiTrace::safe_get_thread_name() to use the new
>> is_JavaThread_protected().
>> 
>> This fix is tested via a Mach5 Tier[1-8] run.
>
> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address coleenp CR0 comments.

src/hotspot/share/compiler/compileBroker.cpp line 1008:

> 1006:       if (TraceCompilerThreads) {
> 1007:         ResourceMark rm;
> 1008:         tty->print_cr("Added initial compiler thread %s", ct->get_thread_name());

This code seems potentially broken both before and after this change. If the ct thread is protected already (by current call chain) you don't need the lock, if it isn't protected then you can't safely call get_thread_name() on it without first ensuring it is still a valid reference.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2535

From cjplummer at openjdk.java.net  Wed Feb 17 09:55:51 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 17 Feb 2021 09:55:51 GMT
Subject: RFR: 8261710: SA DSO objects have sizes that are too large
In-Reply-To: <2SkS8QygsIwmN6nMlOEzn7aUDOFQ1BHbSAB_TsPB8zM=.05317643-1e0c-4047-a326-2fb18a4086d6@github.com>
References: <rtxSvuvKLmHKrLtsnxf76vSK41b_HWPR_7Bn3wf9YuM=.cf1b54ae-f01d-48d5-9641-d7d9faa541f5@github.com>
 <IlGty_H4BHMqmDRi0pWscIAKdyR_nKLI-Ceea9bcxTg=.e9a47c72-cfa8-41d1-8e05-ebde39ac1f24@github.com>
 <k6gxI6l5dgq2xN_8E9tplZqbml81gL1BpsQTd8kdE1s=.7b29334e-0f12-473b-b2f2-7b355cd5d90b@github.com>
 <mUhWqJm-RdRly_sRdxywcm_04PQHZsOaLBf8zi-viqE=.13b1cf2d-990b-4ef9-99b5-f8186c120671@github.com>
 <1em8Uu_1RP3ceaoHAzOwyyejR9jXJfu9Qy3mBRckXx0=.073c8889-9f12-4856-bd9b-78d02b1dd9eb@github.com>
 <FRUBBgqsAb017SxqmnJpfYgPJMHWwo4HrTAn4BNe7bE=.75a5c3b4-0272-42bb-9e52-709f64ee86f6@github.com>
 <Y592rdA_EQe2rQXQB9eyUk6-KrB5n-et7RwQkEDtmc8=.11a4f938-ff35-489b-987d-145ca692d910@github.com>
 <UWgN_HTc6kwGSqmzbEqn9bQYjiU35WDOEb2WzZMkgN8=.3aabfc54-fc64-4148-9464-9e74e20a8cc1@github.com>
 <ENP5bQgjmSQ9NWXXiyDpJGtDed-2ySOstOHgLpG_8s0=.824f38bf-120b-43bd-9811-2cec1aa4dbc1@github.com>
 <2SkS8QygsIwmN6nMlOEzn7aUDOFQ1BHbSAB_TsPB8zM=.05317643-1e0c-4047-a326-2fb18a4086d6@github.com>
Message-ID: <Zhax9I3IuPohxh4hlYL_09a9hVMARC9K0gM6Yh8R_ug=.ed0c9b2d-0889-49f3-9824-f2a99df083d6@github.com>

On Wed, 17 Feb 2021 06:46:27 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> If you run ClhsdbPmap.java, you can see pmap output for both core and live processes. The sizes of the maps are very large for both of them, and actually a bit bigger with the live process. Here's the output for a live process:
>> 
>> 0x000014755360c000	4048K	/usr/lib64/libnss_sss.so.2
>> 0x0000147553815000	4012K	/usr/lib64/libnss_files-2.17.so
>> 0x0000147560208000	4064K	/usr/lib64/libm-2.17.so
>> 0x000014756050a000	3032K	/usr/lib64/librt-2.17.so
>> 0x0000147560712000	32892K	/scratch/cplummer/ws/jdk/jdk.clean/build/linux-x64-debug/images/jdk/lib/server/libjvm.so
>> 0x0000147562731000	4924K	/usr/lib64/libc-2.17.so
>> 0x0000147562aff000	3076K	/usr/lib64/libdl-2.17.so
>> 0x0000147562d03000	3060K	/usr/lib64/libpthread-2.17.so
>> 0x0000147562f1f000	2948K	/usr/lib64/libz.so.1.2.7
>> 0x0000147563135000	2860K	/usr/lib64/ld-2.17.so
>> 0x0000147563164000	92K	/scratch/cplummer/ws/jdk/jdk.clean/build/linux-x64-debug/images/jdk/lib/libnet.so
>> 0x000014756317b000	80K	/scratch/cplummer/ws/jdk/jdk.clean/build/linux-x64-debug/images/jdk/lib/libnio.so
>> 0x00001475631e0000	156K	/scratch/cplummer/ws/jdk/jdk.clean/build/linux-x64-debug/images/jdk/lib/libjava.so
>> 0x0000147563207000	128K	/scratch/cplummer/ws/jdk/jdk.clean/build/linux-x64-debug/images/jdk/lib/libjimage.so
>> 0x000014756332c000	68K	/scratch/cplummer/ws/jdk/jdk.clean/build/linux-x64-debug/images/jdk/lib/libjli.so
>> 0x0000563c950bf000	16K	/scratch/cplummer/ws/jdk/jdk.clean/build/linux-x64-debug/images/jdk/bin/java
>> `/usr/lib64/libnss_files-2.17.so` is the one that turned up in the test failure. It's only a 68k file but has a 4064k map. It's second in the list. I'm not sure if this is the order we would always see on linux systems. My assumption was it was the library at the highest address that was causing the problem, and that the inteprerter was located right after it, but that might not be the case.
>> 
>> The address in the interpreter that we are doing findpc on turned up at `libnss_files.so.2 + 0x21b116`, or at an offset of 2200k. I added a "pmap" command to ClhsdbFindPC, and from my test runs the interpreter seemed to alway be just before the first library. However, maybe on some systems it is intermixed with the libraries.
>
> I pushed new change to use `ELF_PHDR.p_filesz` instead of `p_memsz`. It almost works fine, but it is not perfect solution.
> For example, let's consider for libnss_sss (provided by Fedora 33) - `/proc/<PID>/maps` shows libnss as following. There are 5 segments.
> 
> 7f0ba6ec5000-7f0ba6ec7000 r--p 00000000 08:03 340133                     /usr/lib64/libnss_sss.so.2
> 7f0ba6ec7000-7f0ba6ece000 r-xp 00002000 08:03 340133                     /usr/lib64/libnss_sss.so.2
> 7f0ba6ece000-7f0ba6ed0000 r--p 00009000 08:03 340133                     /usr/lib64/libnss_sss.so.2
> 7f0ba6ed0000-7f0ba6ed1000 r--p 0000a000 08:03 340133                     /usr/lib64/libnss_sss.so.2
> 7f0ba6ed1000-7f0ba6ed2000 rw-p 0000b000 08:03 340133                     /usr/lib64/libnss_sss.so.2
> 
> However I could see only 4 segments in libnss_sss.so when I ran `readelf -l /usr/lib64/libnss_sss.so.2`:
> 
> Program Headers:
>   Type           Offset             VirtAddr           PhysAddr
>                  FileSiz            MemSiz              Flags  Align
>   LOAD           0x0000000000000000 0x0000000000000000 0x0000000000000000
>                  0x0000000000001468 0x0000000000001468  R      0x1000
>   LOAD           0x0000000000002000 0x0000000000002000 0x0000000000002000
>                  0x0000000000006931 0x0000000000006931  R E    0x1000
>   LOAD           0x0000000000009000 0x0000000000009000 0x0000000000009000
>                  0x0000000000001110 0x0000000000001110  R      0x1000
>   LOAD           0x000000000000ac78 0x000000000000bc78 0x000000000000bc78
>                  0x000000000000044c 0x0000000000000658  RW     0x1000
> 
> Linux kernel seems to separate final segment (0xbc78) into RO and RW segments when it attempts to load shared library. (but I'm not sure)
> 
> I think we need to refactor handling shared libraries in other ways.
> 
> For live process, we can use `/proc/<PID>/maps`.
> For coredump, we can use `NT_FILE` in note section in corefile, It has valid segments as below.
> 
> $ readelf -n core
>   :
>     0x00007f0ba6ec5000  0x00007f0ba6ec7000  0x0000000000000000
> 
>     0x00007f0ba6ec7000  0x00007f0ba6ece000  0x0000000000000002
> 
>     0x00007f0ba6ece000  0x00007f0ba6ed0000  0x0000000000000009
> 
>     0x00007f0ba6ed0000  0x00007f0ba6ed1000  0x000000000000000a
> 
>     0x00007f0ba6ed1000  0x00007f0ba6ed2000  0x000000000000000b
> 
> 
> But they makes big change to SA.
> As an option, we can integrate this change at first, then we will refactor them.
> What do you think?
> (I want to resolve this problem with smaller fix if I can of course, so another solutions are welcome)

@YaSuenag https://bugs.openjdk.java.net/browse/JDK-8250826 is the bug I was thinking of that sounds like the RO/RW issue you were talking about.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2563

From akozlov at openjdk.java.net  Wed Feb 17 12:36:10 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Wed, 17 Feb 2021 12:36:10 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v18]
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: <ix6gQkIFb_3zkw3EwW6PbnsHBPwjoai9kux5-O3SM7E=.a36d66e9-97cc-4240-8512-4850a0daa02c@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 88 commits:

 - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos
 - Re-do safefetch.hpp
 - Merge remote-tracking branch 'origin/jdk/8261075-stubroutines-inline' into jdk-macos
 - stubRoutines.inline.hpp -> safefetch.hpp
 - Update copyrights
 - Merge remote-tracking branch 'upstream/jdk/master' into 8261075-stubroutines-inline
 - Merge remote-tracking branch 'upstream/jdk/master' into 8261075-stubroutines-inline
 - Extract SafeFetch32/N to stubRoutines.inline.hpp
 - Revert "Extract SafeFetch32/N to stubRoutines.inline.hpp"
   
   This reverts commit b873c25f31dd21349d140b790713cc9ccb5f2dc0.
 - Merge pull request #9 from VladimirKempik/pull/2200
   
   Removed unused variables
 - ... and 78 more: https://git.openjdk.java.net/jdk/compare/b955f85e...ab72613c

-------------

Changes: https://git.openjdk.java.net/jdk/pull/2200/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=17
  Stats: 2946 lines in 74 files changed: 2861 ins; 27 del; 58 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  Wed Feb 17 12:36:11 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Wed, 17 Feb 2021 12:36:11 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: <uTRSjjXjpGoVKZVZbMAOZsgbpeUqKbH4T562LCOXVB4=.842f2a69-b18f-4065-b62d-0714203ea5a1@github.com>

On Tue, 2 Feb 2021 21:51:56 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/cpu/aarch64/macroAssembler_aarch64.hpp line 31:
> 
>> 29: #include "asm/assembler.inline.hpp"
>> 30: #include "oops/compressedOops.hpp"
>> 31: #include "runtime/vm_version.hpp"
> 
> It's not clear why this include needed to be added.

Line 448 calls `VM_Version::features()`. It seems the declaration is included indirectly somehow on the rest of the platforms, through OS specific headers.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From akozlov at openjdk.java.net  Wed Feb 17 13:09:14 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Wed, 17 Feb 2021 13:09:14 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
In-Reply-To: <Po6Bn-jzngY9eRxVnQ4lBtRE5Y_NcTgFQUaRvvK58fs=.a8d42c1c-5403-4965-b3e0-006ba603abc0@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>
 <UnSWIprKrFiPt4vWX36CgseOH4-iJVexy8UBjsGUJ4k=.67e5231b-a1f0-4ded-9852-6ea7fcbff05a@github.com>
 <quhwE-hqPgo6HXXf4D7o2FRIu48a_H9Fsd8TSqJrbE0=.e5ec4863-c3b4-4fd5-bf5d-f95cd1245770@github.com>
 <Po6Bn-jzngY9eRxVnQ4lBtRE5Y_NcTgFQUaRvvK58fs=.a8d42c1c-5403-4965-b3e0-006ba603abc0@github.com>
Message-ID: <bbAiX8_uDNs3KcPng9Ax4GGBIiJe_VRT_qSOyVykGBk=.691e3273-4f8a-407c-8770-69f44d1a606b@github.com>

On Mon, 15 Feb 2021 16:21:53 GMT, Bernhard Urban-Forster <burban at openjdk.org> wrote:

>> This is the version of w^x on-demand switch implemented by microsoft guys. This is enabled only for debug builds.
>> @lewurm could you comment here please
>
> Those values can be observed in the debugger, but aren't documented or defined in header files.
> 
> This mode was useful for the initial bootstrap of the platform (it helped with missing W^X transitions), but shouldn't be required anymore today. I'm fine with removing it altogether.

OK, I'm going to remove this block. So we'll be able to revert changes in globals.hpp https://github.com/openjdk/jdk/pull/2200/files#r568986339

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From akozlov at openjdk.java.net  Wed Feb 17 13:11:48 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Wed, 17 Feb 2021 13:11:48 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: <2DZXzH1_KDoevOmbbR0ipW0LWSo16BCilHOP1geU3_0=.201276ca-ddb3-49eb-a488-122b54467c49@github.com>

On Tue, 2 Feb 2021 22:42:22 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/logging/logStream.hpp line 35:
> 
>> 33: class LogStream : public outputStream {
>> 34:   // see test/hotspot/gtest/logging/test_logStream.cpp
>> 35:   friend class LogStreamTest;
> 
> It's not clear why this change is made for this port.

This was done for previous implementation of W^X, for gtests be able to access this test. This not required anymore, this hunk was reverted.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From aph at openjdk.java.net  Wed Feb 17 15:55:51 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Wed, 17 Feb 2021 15:55:51 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v8]
In-Reply-To: <ZUsF8QR6kEghT3bEUda2PuIvotR8sqMgfgkQG9dkHK0=.e9eee2a2-1953-43f8-8a7b-69b51f1dff96@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <ugV_PtxgaQkJQw3i1cwYiaKZ46--TZfgdVsuhQd5_3Y=.5b39eb44-1398-41b1-8bdf-2e6a3149e865@github.com>
 <cpf_Q2rM76sr9dlOexk27XKGxtOK41AJxugL6Le19Mo=.d77cc563-81b2-4d14-8ed4-f34d97a7b75a@github.com>
 <M33x5HsjKpNTd34OwGfLGI3ACvCgb_oC4YnvKYF4TLA=.7d7d9112-a638-40bb-8309-0e8ab7743ee1@github.com>
 <L1ugpaepjpPyipb5LZV3HBogQkyr_zp5Pfyk_iRskKU=.0583664a-0c58-4817-96eb-ffe96dae4fda@github.com>
 <ZUsF8QR6kEghT3bEUda2PuIvotR8sqMgfgkQG9dkHK0=.e9eee2a2-1953-43f8-8a7b-69b51f1dff96@github.com>
Message-ID: <l7NCFwAQa6BHneMFK2MHtSvl_HlTWR1N5FI18DmK6cA=.fe347ec4-91c7-4731-addd-a84607b4f304@github.com>

On Tue, 16 Feb 2021 06:24:05 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

>> This is when passing a float, yes? In the case where we have more float arguments than n_float_register_parameters_c.
>> I don't understand why you think it's acceptable to bail in this case. Can you explain, please?
>
> it's for everything that uses less than 8 bytes on a stack( ints ( 4), shorts(2), bytes(1), floats(4)).
> currently native wrapper generation does not support such cases at all, it needs refactoring before this can be implemented.
> So when a method has more argument than can be placed in registers, we may have issues. 
> 
> So we just bailing out to interpreter in case when a smaller (<=4 b) type is going to be passed thru the stack.
> 
> There was attempt to implement handling such cases but currently it requires some hacks (like using some vectors for non-specific task) - https://github.com/openjdk/aarch64-port/pull/3

OK. I checked and the Panama preview doesn't support direct native calls for stack arguments, so we're good for now.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From aph at openjdk.java.net  Wed Feb 17 15:55:50 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Wed, 17 Feb 2021 15:55:50 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v18]
In-Reply-To: <ZzDf-j_FfFTasrbg9lcKPumX79r75Qq_na8CGzbrmEg=.35f0cf2c-4775-4388-a2c7-9bb65ca509be@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <W8UGeXzEc_BvnLqIZ7FZF6zks4U39dAZaXCzSGDS1qw=.1f3badd9-df84-4f00-9e1d-d959780fb997@github.com>
 <h9On7_RFadcLwhW15R4Jig9PZ0y9JoMI2diiqXv99eY=.9b814ff7-64cf-496f-a507-0a8f86070c2d@github.com>
 <GUQ9iV90tXzdUOtyjcIJygM7qBCcUtSHVOol8hOK2OE=.7b3ab947-f835-43d4-a852-cde094efbf62@github.com>
 <0-H97G4l5XqFtiEUbNAqrP_j143iny5kkF0tsiAqMvQ=.2396963b-db5d-469e-bc30-511f754a600a@github.com>
 <ZzDf-j_FfFTasrbg9lcKPumX79r75Qq_na8CGzbrmEg=.35f0cf2c-4775-4388-a2c7-9bb65ca509be@github.com>
Message-ID: <2D2djDl7sFFBYlKWrD1t7aXikT8r5iVAibMR4HI6bfw=.1465f633-0045-4917-b4dd-883f04e5e41e@github.com>

On Mon, 15 Feb 2021 17:45:32 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> I'm not sure it can wait. This change turns already-messy code into something significantly messier, to the extent that it's not really good enough to go into mainline.
>
> The latest merge with JDK-8261071 should resolve the issue. Please take a look.

Looks much better, thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From dcubed at openjdk.java.net  Wed Feb 17 17:36:48 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 17 Feb 2021 17:36:48 GMT
Subject: RFR: 8241403: JavaThread::get_thread_name() should be
 ThreadSMR-aware [v3]
In-Reply-To: <LwyuPftEZnuGNnUAjr3ar5upnTHEBRZF9JRtdciVc1s=.64695cc9-0139-4efd-aa4d-e5c57eddca9f@github.com>
References: <wRdcRQurtpybntK9Qpji-6zVY-EcHKw3q87xpD0eoS4=.a6dc32f4-2919-42e9-80c3-5a264067f0e2@github.com>
 <yER6SKX-lfZsdJmls-clFnBnZd-SWbJkCF4kO_OZg-o=.64d2e6af-47ea-4f82-9a9a-fec6395a2ad5@github.com>
 <LwyuPftEZnuGNnUAjr3ar5upnTHEBRZF9JRtdciVc1s=.64695cc9-0139-4efd-aa4d-e5c57eddca9f@github.com>
Message-ID: <xVPLwLdUNsPogD1lTYOn6EQPsCxzX5xEz_Ywk83SsYE=.f7604702-37e0-43b8-942f-3eed91ab4080@github.com>

On Wed, 17 Feb 2021 07:32:46 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Daniel D. Daugherty has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8241403
>>  - Address coleenp CR0 comments.
>>  - 8241403: JavaThread::get_thread_name() should be ThreadSMR-aware
>
> Hi Dan,
> 
> Sorry but I have a lot of issues with this. After thinking about it a lot I don't think the current approach is what is needed. To repeat what I wrote in one of the comments I think the simple fix here is to replace the use of Threads_lock in the caller with suitable use of a TLH, and then replace the assert_locked_or_safepoint(Threads_lock) with assert(is_JavaThread_protected(t)) where is_JavaThread_protected checks the target for either being the current thread or included in a TLH of the current thread. I don't think get_thread_name() should try to protect the target as that is the responsibility of the caller.
> 
> Thanks,
> David

@dholmes-ora - I'm really glad that I waited for your review! Thanks for taking the time.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2535

From dcubed at openjdk.java.net  Wed Feb 17 17:44:49 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 17 Feb 2021 17:44:49 GMT
Subject: RFR: 8241403: JavaThread::get_thread_name() should be
 ThreadSMR-aware [v3]
In-Reply-To: <LwyuPftEZnuGNnUAjr3ar5upnTHEBRZF9JRtdciVc1s=.64695cc9-0139-4efd-aa4d-e5c57eddca9f@github.com>
References: <wRdcRQurtpybntK9Qpji-6zVY-EcHKw3q87xpD0eoS4=.a6dc32f4-2919-42e9-80c3-5a264067f0e2@github.com>
 <yER6SKX-lfZsdJmls-clFnBnZd-SWbJkCF4kO_OZg-o=.64d2e6af-47ea-4f82-9a9a-fec6395a2ad5@github.com>
 <LwyuPftEZnuGNnUAjr3ar5upnTHEBRZF9JRtdciVc1s=.64695cc9-0139-4efd-aa4d-e5c57eddca9f@github.com>
Message-ID: <-VeCo9c6QIcG7PaUSaYDtCUC9AM-LNbtdCuMNRqZoyQ=.dc5b1890-defa-4795-866c-009a560d1160@github.com>

On Wed, 17 Feb 2021 06:56:26 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Daniel D. Daugherty has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8241403
>>  - Address coleenp CR0 comments.
>>  - 8241403: JavaThread::get_thread_name() should be ThreadSMR-aware
>
> src/hotspot/share/runtime/thread.cpp line 486:
> 
>> 484: 
>> 485: // Is the target JavaThread protected by this Thread:
>> 486: bool Thread::is_JavaThread_protected(const JavaThread* p) {
> 
> Why is this a function on Thread instead of JavaThread??

I made it a function on Thread because a Thread can use a ThreadsListHandle
to protect access to JavaThreads and we're checking the ThreadsList(s) that
are associated with the calling Thread.

It dawns on me that the comment could have been more clear:

`// Is the target JavaThread protected by the calling Thread:`

If I had written the comment that way, then I would have realized that the
function should be static in Thread and then it could call Thread::current()
itself and then make its checks of the ThreadsList(s).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2535

From lucy at openjdk.java.net  Wed Feb 17 18:22:01 2021
From: lucy at openjdk.java.net (Lutz Schmidt)
Date: Wed, 17 Feb 2021 18:22:01 GMT
Subject: RFR: 8261447: MethodInvocationCounters frequently run into
 overflow [v7]
In-Reply-To: <FsHAKG6KwqJeHLIhE6JroDUjiebdevi1asoLi-7pQ1s=.15d96719-36f2-4f9b-ae80-fcb17a3b6659@github.com>
References: <FsHAKG6KwqJeHLIhE6JroDUjiebdevi1asoLi-7pQ1s=.15d96719-36f2-4f9b-ae80-fcb17a3b6659@github.com>
Message-ID: <Aj0149Vh2JIXvEwJ3Vxj7ThRz93rAmZv8hcJtkFdNLo=.bf8765cf-6c33-4bd9-85bc-c18f41eb62b5@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 (185 days 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:

  update copyright year

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2511/files
  - new: https://git.openjdk.java.net/jdk/pull/2511/files/faab64b0..0f220ee3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2511&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2511&range=05-06

  Stats: 8 lines in 6 files changed: 0 ins; 0 del; 8 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 Feb 17 18:27:43 2021
From: lucy at openjdk.java.net (Lutz Schmidt)
Date: Wed, 17 Feb 2021 18:27:43 GMT
Subject: RFR: 8261447: MethodInvocationCounters frequently run into
 overflow [v7]
In-Reply-To: <LHuyBhuR161oF-i_GQ2E5AbhuaoyhhMp-6whlBrXYNY=.3f376a03-2ef5-41db-b618-84cc3bd96917@github.com>
References: <FsHAKG6KwqJeHLIhE6JroDUjiebdevi1asoLi-7pQ1s=.15d96719-36f2-4f9b-ae80-fcb17a3b6659@github.com>
 <VGY2qZPofTF4kvhoh2eb-gEVskrAllfc2qUGniHve9w=.a1bbf3d0-a7d5-4362-8511-13e6ad3f5b6d@github.com>
 <uGFfe_CAI9XwHObEA-aFoqIK3Q5IjyyU7Zon9Kbwu9U=.fc24b09f-7cd6-4cba-84f4-2e265fe94e7c@github.com>
 <P43LJp7pLJb8s3r1UsNiCMDTkbp_sTKER_4rG_ng2n0=.f150cfaa-d21e-45da-ad4f-0e2943df4903@github.com>
 <vf7HwmzLTAIky5AgfmR3V8tkK4YNDalAuUrF_wTuLSo=.319ec36f-a143-470f-bf88-9398678818f2@github.com>
 <7S5jdlFpZ5m2xtFinD92jQEQm6hgbQXjHR5N-3XbXkc=.fe75978e-860a-4bcc-b5b4-3e4b4246d706@github.com>
 <CYjuoGXt_uPG61kL7K3H_hn5_FhZOFJcRDoBqrdmA2E=.cead0f6d-f1e3-4684-a061-9c98e3ae38e9@github.com>
 <LHuyBhuR161oF-i_GQ2E5AbhuaoyhhMp-6whlBrXYNY=.3f376a03-2ef5-41db-b618-84cc3bd96917@github.com>
Message-ID: <kZm8Ip9Uu0dTwrZ7KX2Tih4sNCWqT5AreWHcuj2753k=.3f7697e1-1677-4005-9722-47924f3bed52@github.com>

On Mon, 15 Feb 2021 18:21:53 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:

>> This is a request for help. Could someone with SA knowledge please check if my assumption is correct?
>> 
>> In hotspot code, the field Method::_compiled_invocation_count is annotated with a comment that it is used by SA. The field is also exposed via vmStructs.cpp to enable such use. I have scanned SA code in OpenJDK11 and OpenJDK head but found no evidence that this particular field is accessed. Is this finding/assumption correct? 
>> 
>> If so, I could just stop exposing the field, making my life easier. Thanks!
>
> Looks like I have completely messed up my pull request. Please disregard for now. I'm trying to find a way how to clean up. Maybe I'll just start over.

OK, my pull request is back in a reviewable state. Here is what changed: 

1) Honouring review comments from @TobiHartmann and @veresov 
Trusting my own code research, I removed _compiled_invocation_count from vmStructs.cpp. Builds are ok and all tests we run in-house (including the jtreg suite) did not show any issue. The updated pull request has _compiled_invocation_count widened to 64-bit and all those *64 suffixes are removed. 

2) Dealing with counter updates in {v|i}table stubs
While waiting for a response from SA experts, I took the time and had a closer look at the last remaining 32-bit counter (_nof_megamorphic_calls). It turned out the required changes to code generation were trivial. So I took the opportunity and made it a 64-bit counter. Call stats look even nicer now!

In summary: All global invocation counters are 64-bit now. From those counters that register method-individual calls, only _compiled_invocation_count and _nof_megamorphic_calls were widened to 64-bit. The three remaining method-individual counters (invocation_count, interpreter_invocation_count. and backedge_count) remain untouched.

I appreciate your feedback!

Here is how stats look like now:

Invocations summary for 28214 methods:
         41055191904 (100%)  total
          4818528940 (11.7%) |- interpreted
         36236662964 (88.3%) |- compiled
          9065026571 (22.1%) |- special methods (interpreted and compiled)
           607128840 ( 1.5%)    |- synchronized
          2107652419 ( 5.1%)    |- final
          6347934023 (15.5%)    |- static
             1122857 ( 0.0%)    |- native
             1188432 ( 0.0%)    |- accessor

Calls from compiled code:
         27011733837 (100%)  total non-inlined
         14500960686 (53.7%) |- virtual calls
        124325246564 ( 857%) |  |- inlined
                   0 (   0%) |  |- optimized
          8890453008 (  61%) |  |- monomorphic
          5610507678 (  39%) |  |- megamorphic
          4529160753 (16.8%) |- interface calls
          8905052200 ( 197%) |  |- inlined
                   0 (   0%) |  |- optimized
          4529160753 ( 100%) |  |- monomorphic
                   0 (   0%) |  |- megamorphic
          7981612398 (29.5%) |- static/special calls
         73886243527 ( 926%) |  |- inlined

-------------

PR: https://git.openjdk.java.net/jdk/pull/2511

From shade at openjdk.java.net  Wed Feb 17 18:58:51 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 17 Feb 2021 18:58:51 GMT
Subject: RFR: 8261925: ProblemList com/sun/jdi/AfterThreadDeathTest.java on
 Linux
Message-ID: <FgXvDZyKjY0f9HnlLDIYoD5t4zdkuUUJeRrFQH8lr7s=.b26d5bd2-946a-46fd-af36-11c0a395d8b8@github.com>

I am seeing exactly the same error in GitHub Actions on x86_32, as in [JDK-8232839](https://bugs.openjdk.java.net/browse/JDK-8232839). [JDK-8258832](JDK-8258832) put it on problemlist for linux-x64, let's elevate that to linux-all.

Additional testing:
 - [x] Test on Linux x86_64 (still skipped)
 - [x] Test on Linux x86_32 (now skipped)

-------------

Commit messages:
 - Problemlist

Changes: https://git.openjdk.java.net/jdk/pull/2614/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2614&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8261925
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2614.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2614/head:pull/2614

PR: https://git.openjdk.java.net/jdk/pull/2614

From cjplummer at openjdk.java.net  Wed Feb 17 19:28:39 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 17 Feb 2021 19:28:39 GMT
Subject: RFR: 8261710: SA DSO objects have sizes that are too large
In-Reply-To: <2SkS8QygsIwmN6nMlOEzn7aUDOFQ1BHbSAB_TsPB8zM=.05317643-1e0c-4047-a326-2fb18a4086d6@github.com>
References: <rtxSvuvKLmHKrLtsnxf76vSK41b_HWPR_7Bn3wf9YuM=.cf1b54ae-f01d-48d5-9641-d7d9faa541f5@github.com>
 <IlGty_H4BHMqmDRi0pWscIAKdyR_nKLI-Ceea9bcxTg=.e9a47c72-cfa8-41d1-8e05-ebde39ac1f24@github.com>
 <k6gxI6l5dgq2xN_8E9tplZqbml81gL1BpsQTd8kdE1s=.7b29334e-0f12-473b-b2f2-7b355cd5d90b@github.com>
 <mUhWqJm-RdRly_sRdxywcm_04PQHZsOaLBf8zi-viqE=.13b1cf2d-990b-4ef9-99b5-f8186c120671@github.com>
 <1em8Uu_1RP3ceaoHAzOwyyejR9jXJfu9Qy3mBRckXx0=.073c8889-9f12-4856-bd9b-78d02b1dd9eb@github.com>
 <FRUBBgqsAb017SxqmnJpfYgPJMHWwo4HrTAn4BNe7bE=.75a5c3b4-0272-42bb-9e52-709f64ee86f6@github.com>
 <Y592rdA_EQe2rQXQB9eyUk6-KrB5n-et7RwQkEDtmc8=.11a4f938-ff35-489b-987d-145ca692d910@github.com>
 <UWgN_HTc6kwGSqmzbEqn9bQYjiU35WDOEb2WzZMkgN8=.3aabfc54-fc64-4148-9464-9e74e20a8cc1@github.com>
 <ENP5bQgjmSQ9NWXXiyDpJGtDed-2ySOstOHgLpG_8s0=.824f38bf-120b-43bd-9811-2cec1aa4dbc1@github.com>
 <2SkS8QygsIwmN6nMlOEzn7aUDOFQ1BHbSAB_TsPB8zM=.05317643-1e0c-4047-a326-2fb18a4086d6@github.com>
Message-ID: <_n9G1Pez1YjmWZqxJt3OWEfBzImoLyTy7oSYDidhKx8=.094bc1df-b120-485b-aac8-92a47cc32e83@github.com>

On Wed, 17 Feb 2021 06:46:27 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> If you run ClhsdbPmap.java, you can see pmap output for both core and live processes. The sizes of the maps are very large for both of them, and actually a bit bigger with the live process. Here's the output for a live process:
>> 
>> 0x000014755360c000	4048K	/usr/lib64/libnss_sss.so.2
>> 0x0000147553815000	4012K	/usr/lib64/libnss_files-2.17.so
>> 0x0000147560208000	4064K	/usr/lib64/libm-2.17.so
>> 0x000014756050a000	3032K	/usr/lib64/librt-2.17.so
>> 0x0000147560712000	32892K	/scratch/cplummer/ws/jdk/jdk.clean/build/linux-x64-debug/images/jdk/lib/server/libjvm.so
>> 0x0000147562731000	4924K	/usr/lib64/libc-2.17.so
>> 0x0000147562aff000	3076K	/usr/lib64/libdl-2.17.so
>> 0x0000147562d03000	3060K	/usr/lib64/libpthread-2.17.so
>> 0x0000147562f1f000	2948K	/usr/lib64/libz.so.1.2.7
>> 0x0000147563135000	2860K	/usr/lib64/ld-2.17.so
>> 0x0000147563164000	92K	/scratch/cplummer/ws/jdk/jdk.clean/build/linux-x64-debug/images/jdk/lib/libnet.so
>> 0x000014756317b000	80K	/scratch/cplummer/ws/jdk/jdk.clean/build/linux-x64-debug/images/jdk/lib/libnio.so
>> 0x00001475631e0000	156K	/scratch/cplummer/ws/jdk/jdk.clean/build/linux-x64-debug/images/jdk/lib/libjava.so
>> 0x0000147563207000	128K	/scratch/cplummer/ws/jdk/jdk.clean/build/linux-x64-debug/images/jdk/lib/libjimage.so
>> 0x000014756332c000	68K	/scratch/cplummer/ws/jdk/jdk.clean/build/linux-x64-debug/images/jdk/lib/libjli.so
>> 0x0000563c950bf000	16K	/scratch/cplummer/ws/jdk/jdk.clean/build/linux-x64-debug/images/jdk/bin/java
>> `/usr/lib64/libnss_files-2.17.so` is the one that turned up in the test failure. It's only a 68k file but has a 4064k map. It's second in the list. I'm not sure if this is the order we would always see on linux systems. My assumption was it was the library at the highest address that was causing the problem, and that the inteprerter was located right after it, but that might not be the case.
>> 
>> The address in the interpreter that we are doing findpc on turned up at `libnss_files.so.2 + 0x21b116`, or at an offset of 2200k. I added a "pmap" command to ClhsdbFindPC, and from my test runs the interpreter seemed to alway be just before the first library. However, maybe on some systems it is intermixed with the libraries.
>
> I pushed new change to use `ELF_PHDR.p_filesz` instead of `p_memsz`. It almost works fine, but it is not perfect solution.
> For example, let's consider for libnss_sss (provided by Fedora 33) - `/proc/<PID>/maps` shows libnss as following. There are 5 segments.
> 
> 7f0ba6ec5000-7f0ba6ec7000 r--p 00000000 08:03 340133                     /usr/lib64/libnss_sss.so.2
> 7f0ba6ec7000-7f0ba6ece000 r-xp 00002000 08:03 340133                     /usr/lib64/libnss_sss.so.2
> 7f0ba6ece000-7f0ba6ed0000 r--p 00009000 08:03 340133                     /usr/lib64/libnss_sss.so.2
> 7f0ba6ed0000-7f0ba6ed1000 r--p 0000a000 08:03 340133                     /usr/lib64/libnss_sss.so.2
> 7f0ba6ed1000-7f0ba6ed2000 rw-p 0000b000 08:03 340133                     /usr/lib64/libnss_sss.so.2
> 
> However I could see only 4 segments in libnss_sss.so when I ran `readelf -l /usr/lib64/libnss_sss.so.2`:
> 
> Program Headers:
>   Type           Offset             VirtAddr           PhysAddr
>                  FileSiz            MemSiz              Flags  Align
>   LOAD           0x0000000000000000 0x0000000000000000 0x0000000000000000
>                  0x0000000000001468 0x0000000000001468  R      0x1000
>   LOAD           0x0000000000002000 0x0000000000002000 0x0000000000002000
>                  0x0000000000006931 0x0000000000006931  R E    0x1000
>   LOAD           0x0000000000009000 0x0000000000009000 0x0000000000009000
>                  0x0000000000001110 0x0000000000001110  R      0x1000
>   LOAD           0x000000000000ac78 0x000000000000bc78 0x000000000000bc78
>                  0x000000000000044c 0x0000000000000658  RW     0x1000
> 
> Linux kernel seems to separate final segment (0xbc78) into RO and RW segments when it attempts to load shared library. (but I'm not sure)
> 
> I think we need to refactor handling shared libraries in other ways.
> 
> For live process, we can use `/proc/<PID>/maps`.
> For coredump, we can use `NT_FILE` in note section in corefile, It has valid segments as below.
> 
> $ readelf -n core
>   :
>     0x00007f0ba6ec5000  0x00007f0ba6ec7000  0x0000000000000000
> 
>     0x00007f0ba6ec7000  0x00007f0ba6ece000  0x0000000000000002
> 
>     0x00007f0ba6ece000  0x00007f0ba6ed0000  0x0000000000000009
> 
>     0x00007f0ba6ed0000  0x00007f0ba6ed1000  0x000000000000000a
> 
>     0x00007f0ba6ed1000  0x00007f0ba6ed2000  0x000000000000000b
> 
> 
> But they makes big change to SA.
> As an option, we can integrate this change at first, then we will refactor them.
> What do you think?
> (I want to resolve this problem with smaller fix if I can of course, so another solutions are welcome)

@YaSuenag I asked Dan to run a modified `ClhsdbFindPC` that also issues a `clhsdb pmap` command so we can see what the maps look like, and compare them to the address being looked up. This is before your latest fix, so the the sizes are still too big, but that's ok for this analysis. First, this is the `findpc` command that was suppose to show the address in the interpreter:

hsdb> + findpc 0x00002ab36ca942b6
Address 0x00002ab36ca942b6: /lib/x86_64-linux-gnu/libnss_files.so.2 + 0x21b2b6

And here's the pmap output . I had to manually sort by address, and I also added the location of the interpreter address being looked up.

0x00005652c8fd0000	16K	<jdkdir>/jdk/bin/java
0x00002ab3692ae000	3400K	/lib64/ld-linux-x86-64.so.2
0x00002ab3692e0000	12K	<jdkdir>/test/hotspot/jtreg/native/libLingeredApp.so
0x00002ab3692ed000	84K	<jdkdir>/jdk/bin/../lib/libjli.so
0x00002ab369406000	144K	<jdkdir>/jdk/lib/libjimage.so
0x00002ab36942a000	200K	<jdkdir>/jdk/lib/libjava.so
0x00002ab3694bc000	88K	<jdkdir>/jdk/lib/libnio.so
0x00002ab3694d6000	3240K	/lib/x86_64-linux-gnu/libz.so.1
0x00002ab3696f0000	3136K	/lib/x86_64-linux-gnu/libpthread.so.0
0x00002ab36990d000	3020K	/lib/x86_64-linux-gnu/libdl.so.2
0x00002ab369b11000	5052K	/lib/x86_64-linux-gnu/libc.so.6
0x00002ab369edb000	31100K	<jdkdir>/jdk/lib/server/libjvm.so
0x00002ab36bd3a000	2840K	/lib/x86_64-linux-gnu/librt.so.1
0x00002ab36bf42000	4856K	/lib/x86_64-linux-gnu/libm.so.6
0x00002ab36c24b000	3796K	/lib/x86_64-linux-gnu/libnss_compat.so.2
0x00002ab36c454000	3760K	/lib/x86_64-linux-gnu/libnsl.so.1
0x00002ab36c66d000	3660K	/lib/x86_64-linux-gnu/libnss_nis.so.2
0x00002ab36c879000	3612K	/lib/x86_64-linux-gnu/libnss_files.so.2
0x00002ab36ca942b6: /lib/x86_64-linux-gnu/libnss_files.so.2 + 0x21b2b6
0x00002ab38fc08000	112K	<jdkdir>/jdk/lib/libnet.so
0x00002ab38fc55000	3756K	/usr/lib/x86_64-linux-gnu/libstdc++.so.6
0x00002ab3bc000000	4096K	/lib/x86_64-linux-gnu/libgcc_s.so.1

There appears to be a very large gap between `libnss_files.so.2` and `libnet.so` (about 590mb) so I assume a lot of hotspot memory allocations are located in this area, including the interpreter.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2563

From dcubed at openjdk.java.net  Wed Feb 17 19:34:40 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 17 Feb 2021 19:34:40 GMT
Subject: RFR: 8261925: ProblemList com/sun/jdi/AfterThreadDeathTest.java
 on Linux
In-Reply-To: <FgXvDZyKjY0f9HnlLDIYoD5t4zdkuUUJeRrFQH8lr7s=.b26d5bd2-946a-46fd-af36-11c0a395d8b8@github.com>
References: <FgXvDZyKjY0f9HnlLDIYoD5t4zdkuUUJeRrFQH8lr7s=.b26d5bd2-946a-46fd-af36-11c0a395d8b8@github.com>
Message-ID: <kz1D3dsM4ohtVqa0XZAi0EjX_NRZ5KqhuyVHLDkjZdE=.0b0cff14-814c-497e-9d25-afed89134a19@github.com>

On Wed, 17 Feb 2021 18:46:51 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I am seeing exactly the same error in GitHub Actions on x86_32, as in [JDK-8232839](https://bugs.openjdk.java.net/browse/JDK-8232839). [JDK-8258832](JDK-8258832) put it on problemlist for linux-x64, let's elevate that to linux-all.
> 
> Additional testing:
>  - [x] Test on Linux x86_64 (still skipped)
>  - [x] Test on Linux x86_32 (now skipped)

Thumbs up. This is a trivial fix and does not need to wait for 24 hours.

-------------

Marked as reviewed by dcubed (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2614

From amenkov at openjdk.java.net  Wed Feb 17 19:51:38 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Wed, 17 Feb 2021 19:51:38 GMT
Subject: RFR: 8261098: Add clhsdb "findsym" command [v3]
In-Reply-To: <BOLm1OyL1OX-VEExlhhHZ4W_9UMcTStsNtZFHKiRtS8=.ba1f9fb5-8122-4b29-b1ce-d4f192ca98fc@github.com>
References: <EcsJkvo_wYh085Hc1uRmViYzUrsfMeNLFOEsn0YSyXs=.8243bb41-62d6-40a0-8942-650a9cd8a497@github.com>
 <BOLm1OyL1OX-VEExlhhHZ4W_9UMcTStsNtZFHKiRtS8=.ba1f9fb5-8122-4b29-b1ce-d4f192ca98fc@github.com>
Message-ID: <XSPBnOCmOPLAKWpLtEu32Sk24wdAwwRSI6JaFXLsURA=.04455449-ee09-49ca-ae54-a804f843594d@github.com>

On Wed, 17 Feb 2021 02:12:56 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Add "findsym" to clhsdb. See the CR and CSR for details. The [CSR](https://bugs.openjdk.java.net/browse/JDK-8261101) still needs a reviewer.
>> 
>> There is a fix in LinuxDebuggerLocal_lookupByName0() to allow passing in NULL for the dso name. This is allowed, and in fact even not null it gets ignored. It is needed by the new findsym support in order for the following to work, which passes in null for the dso name:
>> 
>> `    Address addr = VM.getVM().getDebugger().lookup(null, symbol);`
>> 
>> There is one other somewhat unrelated fix in the test:
>> 
>>  -            String value = parts[1];
>>  +           String value = parts[1].split(linesep)[0];
>> 
>> This is suppose to capture just the value at the specified address, but it also captures the newline and some text after. The result if that when `findpc <value>` is executed, it also executes another command or two of garbage commands after that, which produce errors. They were not impacting the test, but were noticeable in the log. I first noticed it when similar code in the new part of the test had the same issue.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve handling of NULL objectName

Marked as reviewed by amenkov (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2567

From dcubed at openjdk.java.net  Wed Feb 17 21:49:48 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 17 Feb 2021 21:49:48 GMT
Subject: RFR: 8241403: JavaThread::get_thread_name() should be
 ThreadSMR-aware [v3]
In-Reply-To: <LwyuPftEZnuGNnUAjr3ar5upnTHEBRZF9JRtdciVc1s=.64695cc9-0139-4efd-aa4d-e5c57eddca9f@github.com>
References: <wRdcRQurtpybntK9Qpji-6zVY-EcHKw3q87xpD0eoS4=.a6dc32f4-2919-42e9-80c3-5a264067f0e2@github.com>
 <yER6SKX-lfZsdJmls-clFnBnZd-SWbJkCF4kO_OZg-o=.64d2e6af-47ea-4f82-9a9a-fec6395a2ad5@github.com>
 <LwyuPftEZnuGNnUAjr3ar5upnTHEBRZF9JRtdciVc1s=.64695cc9-0139-4efd-aa4d-e5c57eddca9f@github.com>
Message-ID: <_krD1qdX0gdkJw7qbtzHiesqrbik62m2aiAGUW28XI0=.6c3ce69c-8153-45bf-bed9-8f1b06b0c93b@github.com>

On Wed, 17 Feb 2021 07:07:44 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Daniel D. Daugherty has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8241403
>>  - Address coleenp CR0 comments.
>>  - 8241403: JavaThread::get_thread_name() should be ThreadSMR-aware
>
> src/hotspot/share/runtime/thread.cpp line 490:
> 
>> 488:     // Current thread is always protected:
>> 489:     return true;
>> 490:   }
> 
> This is true but it is awkward that we are going to manifest Thread::current multiple times when using this - see below.

The static Thread::is_JavaThread_protected() now calls:

 bool Thread::is_JavaThread_protected(const JavaThread* p) {
  Thread* thread = Thread::current();
  if (thread == p) {

and because the function is now static, the caller doesn't have to call
Thread::current() and just calls Thread::is_JavaThread_protected(target).

> src/hotspot/share/runtime/thread.cpp line 2547:
> 
>> 2545: // for such that this method never returns NULL.
>> 2546: const char* JavaThread::get_thread_name(const char* default_name) const {
>> 2547:   Thread* thread = Thread::current();
> 
> So you manifest Thread::current() and then is_JavaThread_protected will manifest it again.

I'm dropping the call to Thread::current() in JavaThread::get_thread_name().

> src/hotspot/share/runtime/thread.cpp line 2548:
> 
>> 2546: const char* JavaThread::get_thread_name(const char* default_name) const {
>> 2547:   Thread* thread = Thread::current();
>> 2548:   ThreadsListHandle tlh(thread);
> 
> I would only expect this code to create a TLH if the target is not protected, otherwise why do we need to search through the existing thread-lists as it would suffice to see if the target is within the newly created TLH ??
> I expected the basic logic here to be:
> `if (thread is protected) return name;
> else { protect the thread; return name; }`
> 
> though if it is cheaper to create a TLH than to search the existing ones, then we may as well just create the TLH, check that the target has been captured and then return its name.
> 
> That said we need to carefully examine where the taking of the Threads_lock would occur in the thread termination sequence, to understand what observable states are possible with respect to the target having a threadObj. (Though this may have already changed with the introduction of Thread-SMR.)
> 
> That all said I'm not so sure the only thing we actually need to do for this issue is to replace the use of Threads_lock, in the caller, with suitable TLH usage, and then in get_thread_name() assert that the target is in fact protected.

I dropped the TLH into JavaThread::get_thread_name() because I was focused
on protecting the fetching of the name from the JavaThread. In reality that
doesn't happen in a vacuum so a TLH should really exist in the caller or some
where higher in the call stack.

There is a subtle point here: Creating a TLH in JavaThread::get_thread_name()
may not actually protect "this" JavaThread. "this" JavaThread would only be
protected by a newly created TLH, if it is on the current ThreadsList. If we
happen to call java_thread->get_thread_name() too early in the lifecycle or
too late in the lifecycle, then that newly created TLH doesn't help.

The original code's assertion check was a little complicated, but still was
a good idea:

    if we're not at a safepoint and if we're not calling the function on our self
       then assert_locked_or_safepoint_or_handshake(Threads_lock)

I'm going to add back a simpler assertion that takes advantage of the
fact that Thread::is_JavaThread_protected() returns true when the
target is the current thread.

> src/hotspot/share/prims/jvmtiTrace.cpp line 283:
> 
>> 281:   // If the target JavaThread is not protected, then we return the
>> 282:   // specified non-NULL string:
>> 283:   return thread->as_Java_thread()->get_thread_name("<NOT FILLED IN>");
> 
> That's not what the original logic is doing. We only return "NOT FILLED IN" if we find that the java.lang.Thread oop does not have a name set. That's not normally possible but this code is intended to be 100% safe, hence the check. (And it may be possible to see null during the attach process ...)
> 
> I would expect the target thread to already be protected when this method is called in any case. So while this code partially duplicates JavaThread::get_thread_name() I'm not convinced we need to change this code to use JavaThread::get_thread_name() instead.

My intent was to have safe_get_thread_name() take advantage of
JavaThread::get_thread_name() when we know that we're dealing
with a JavaThread. Shared code means less maintenance, but it
does look like I didn't achieve equivalence so I'm going to back
out my changes for JvmtiTrace::safe_get_thread_name().

-------------

PR: https://git.openjdk.java.net/jdk/pull/2535

From dcubed at openjdk.java.net  Wed Feb 17 21:49:49 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 17 Feb 2021 21:49:49 GMT
Subject: RFR: 8241403: JavaThread::get_thread_name() should be
 ThreadSMR-aware [v2]
In-Reply-To: <NnM7MtJfxNa66wBIrc7to1gg5lMMAETonQa06KnCfCo=.c0513f4a-2567-409b-ab65-4ac3025f006b@github.com>
References: <wRdcRQurtpybntK9Qpji-6zVY-EcHKw3q87xpD0eoS4=.a6dc32f4-2919-42e9-80c3-5a264067f0e2@github.com>
 <UY810XwxI_xwVSwdtX4pcnH__prubKLOXJB-2fMK0n4=.154fa1e0-560f-405e-ac62-e143c9a36536@github.com>
 <NnM7MtJfxNa66wBIrc7to1gg5lMMAETonQa06KnCfCo=.c0513f4a-2567-409b-ab65-4ac3025f006b@github.com>
Message-ID: <DClqYPcy1rOY7ON23EBRFa76_Fjo3ni0GpQgLAkAcws=.b7968f08-d3d7-4914-9516-53e5cb379519@github.com>

On Wed, 17 Feb 2021 06:53:20 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address coleenp CR0 comments.
>
> src/hotspot/share/compiler/compileBroker.cpp line 1008:
> 
>> 1006:       if (TraceCompilerThreads) {
>> 1007:         ResourceMark rm;
>> 1008:         tty->print_cr("Added initial compiler thread %s", ct->get_thread_name());
> 
> This code seems potentially broken both before and after this change. If the ct thread is protected already (by current call chain) you don't need the lock, if it isn't protected then you can't safely call get_thread_name() on it without first ensuring it is still a valid reference.

Ouch! You are correct that any time after the make_thread() call,
the newly created JavaThread could run and exit quickly. In the
baseline code, the Threads_lock grab only keeps 'ct' from exiting
while the lock is held. It doesn't help if 'ct' exited before the lock
was grabbed.

I'm not sure why you would think that 'ct' could be protected by
the current call chain. Of course, I could be missing something.

I'm going to see if I can do something here with a TLH.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2535

From sspitsyn at openjdk.java.net  Wed Feb 17 21:58:40 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Wed, 17 Feb 2021 21:58:40 GMT
Subject: RFR: 8261710: SA DSO objects have sizes that are too large [v4]
In-Reply-To: <-tUjqHsXhVl31QRbblNj5TjV6BVOOLtl6dmXjzVFheo=.498514c8-d0f8-4081-a036-1f9114a6a9c3@github.com>
References: <rtxSvuvKLmHKrLtsnxf76vSK41b_HWPR_7Bn3wf9YuM=.cf1b54ae-f01d-48d5-9641-d7d9faa541f5@github.com>
 <-tUjqHsXhVl31QRbblNj5TjV6BVOOLtl6dmXjzVFheo=.498514c8-d0f8-4081-a036-1f9114a6a9c3@github.com>
Message-ID: <ZpQrDMQXuzEUbe5qhXvKPi1fKgmWnz1n_gCpYxPib-M=.b365c936-b8d2-4115-92dd-4e117248f14c@github.com>

On Wed, 17 Feb 2021 06:28:09 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 incrementally with one additional commit since the last revision:
> 
>   Use p_filesz instead of p_memsz

Hi Yasumasa,

Just some comments.

src/jdk.hotspot.agent/linux/native/libsaproc/libproc_impl.c
+static inline uintptr_t align_down(uintptr_t ptr, size_t size) {
+  return (ptr & ~(size - 1));
+}
+
+static inline uintptr_t align_up(uintptr_t ptr, size_t size) {
+  return ((ptr + size - 1) & ~(size - 1));
+}

The name of 'size' parameter is confusing. Should it be renamed to something like page_size of psize?

+  lib->end = (uintptr_t)-1L;
. . .
+      if ((lib->end == (uintptr_t)-1L) || (lib->end < aligned_end)) {
+        lib->end = aligned_end;
       }
 
The condition  `(lib->end == (uintptr_t)-1L)` is a subset of `(lib->end < aligned_end)`, and so, can be removed. The same is true for the condition:
+        if ((lib->exec_end == (uintptr_t)-1L) || (lib->exec_end < aligned_end)) {
+          lib->exec_end = aligned_end;
+        }

`+      print_debug("%s [%d] 0x%lx-0x%lx: base = 0x%lx, vaddr = 0x%lx, memsz = 0x%lx, filesz = 0x%lx\n", lib->name, cnt, aligned_start, aligned_end, lib->base, ph->p_vaddr, ph->p_memsz, ph->p_filesz);`

It is better to split this long line.

Thanks,
Serguei

-------------

PR: https://git.openjdk.java.net/jdk/pull/2563

From sspitsyn at openjdk.java.net  Wed Feb 17 22:47:39 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Wed, 17 Feb 2021 22:47:39 GMT
Subject: RFR: 8261098: Add clhsdb "findsym" command [v3]
In-Reply-To: <BOLm1OyL1OX-VEExlhhHZ4W_9UMcTStsNtZFHKiRtS8=.ba1f9fb5-8122-4b29-b1ce-d4f192ca98fc@github.com>
References: <EcsJkvo_wYh085Hc1uRmViYzUrsfMeNLFOEsn0YSyXs=.8243bb41-62d6-40a0-8942-650a9cd8a497@github.com>
 <BOLm1OyL1OX-VEExlhhHZ4W_9UMcTStsNtZFHKiRtS8=.ba1f9fb5-8122-4b29-b1ce-d4f192ca98fc@github.com>
Message-ID: <4NgUojnNaUGdFOQ_Lnp4e1NpI4y2TXCi8PRUD6OXcI4=.31c04051-43e3-4023-89c3-b3c3ad0bce6c@github.com>

On Wed, 17 Feb 2021 02:12:56 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Add "findsym" to clhsdb. See the CR and CSR for details. The [CSR](https://bugs.openjdk.java.net/browse/JDK-8261101) still needs a reviewer.
>> 
>> There is a fix in LinuxDebuggerLocal_lookupByName0() to allow passing in NULL for the dso name. This is allowed, and in fact even not null it gets ignored. It is needed by the new findsym support in order for the following to work, which passes in null for the dso name:
>> 
>> `    Address addr = VM.getVM().getDebugger().lookup(null, symbol);`
>> 
>> There is one other somewhat unrelated fix in the test:
>> 
>>  -            String value = parts[1];
>>  +           String value = parts[1].split(linesep)[0];
>> 
>> This is suppose to capture just the value at the specified address, but it also captures the newline and some text after. The result if that when `findpc <value>` is executed, it also executes another command or two of garbage commands after that, which produce errors. They were not impacting the test, but were noticeable in the log. I first noticed it when similar code in the new part of the test had the same issue.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve handling of NULL objectName

It looks good to me.

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2567

From sspitsyn at openjdk.java.net  Wed Feb 17 23:32:38 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Wed, 17 Feb 2021 23:32:38 GMT
Subject: RFR: 8261269: When using clhsdb to "inspect" a java object,
 clhsdb prints "Oop for..." twice
In-Reply-To: <ZMXuV3A7BSpkJtmlUlvtMCL6beFGJNFWGxIbdMS9kYI=.b9e00805-9edc-4b29-b2e5-a8734791f4c0@github.com>
References: <ZMXuV3A7BSpkJtmlUlvtMCL6beFGJNFWGxIbdMS9kYI=.b9e00805-9edc-4b29-b2e5-a8734791f4c0@github.com>
Message-ID: <XnpJKuLybz4Fcghw6bdu6cq34SapMCzpP0gLnwWKZUM=.57283da1-91d0-4d5f-a64a-fff049f8391d@github.com>

On Tue, 16 Feb 2021 07:28:45 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> See CR for details. In brief, fixed the `inspect` command to remove duplicate output:
> 
> hsdb> inspect 0x00000007fef00770
> instance of Oop for java/lang/Class @ 0x00000007fef00770 @ 0x00000007fef00770 (size = 160)
> in: Oop for java/io/BufferedInputStream @ 0x0000000082005b08 Oop for java/io/BufferedInputStream @ 0x0000000082005b08
> out: Oop for java/io/PrintStream @ 0x0000000082007b60 Oop for java/io/PrintStream @ 0x0000000082007b60
> err: Oop for java/io/PrintStream @ 0x000000008200e0c8 Oop for java/io/PrintStream @ 0x000000008200e0c8 
> It should be:
> 
> hsdb> inspect 0x00000007fef00770
> instance of Oop for java/lang/Class @ 0x00000007fef00770 (size = 160)
> in: Oop for java/io/BufferedInputStream @ 0x0000000082005b08
> out: Oop for java/io/PrintStream @ 0x0000000082007b60
> err: Oop for java/io/PrintStream @ 0x000000008200e0c8

It looks good to me.
One side comment about the test. It is not easy to read the code with the same pattern (e.g. "Oop for java/io/BufferedInputStream") repeated several times. I understand, you prefer to make it more explicit but it'd be more readable if a predefined pattern is used like below:
    String pattern = "Oop for java/io/BufferedInputStream";
+            expStrMap.put(cmd, List.of("instance of Oop for java/lang/Class @ " + examineResult,
+                                       "in: " + pattern + @"));
. . .
+            unexpStrMap.put(cmd, List.of(
+                    "instance of Oop for java/lang/Class @ "  + examineResult + " @ " + examineResult,
+                    "in: " + pattern + " .* " + pattern));

Just an opinion with no pressure. It is up to you.

Thanks,
Serguei

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2582

From sspitsyn at openjdk.java.net  Wed Feb 17 23:43:39 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Wed, 17 Feb 2021 23:43:39 GMT
Subject: RFR: 8261702: ClhsdbFindPC can fail due to PointerFinder
 incorrectly thinking an address is in a .so
In-Reply-To: <AFSFgu2cWGvCRDEq5jI67rk-Xwx1Xc3v2B3E81WjVJY=.3e2a4488-2e85-46b2-89f8-0da1bc349a99@github.com>
References: <AFSFgu2cWGvCRDEq5jI67rk-Xwx1Xc3v2B3E81WjVJY=.3e2a4488-2e85-46b2-89f8-0da1bc349a99@github.com>
Message-ID: <BITamwRgCsTVZCJF9yaL3fsEFKmpzhUN4qD0L4HHylw=.72219a1a-0dca-4751-a9b1-a64e54c4ca83@github.com>

On Sat, 13 Feb 2021 19:05:17 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> See bug description for details. The fix is simple and just a matter of moving some code to avoid incorrectly thinking an address is in a .so when it is in some other area of VM memory that occurs just after the last .so.

Looks good.

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2562

From david.holmes at oracle.com  Wed Feb 17 23:48:22 2021
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 18 Feb 2021 09:48:22 +1000
Subject: RFR: 8241403: JavaThread::get_thread_name() should be
 ThreadSMR-aware [v3]
In-Reply-To: <xVPLwLdUNsPogD1lTYOn6EQPsCxzX5xEz_Ywk83SsYE=.f7604702-37e0-43b8-942f-3eed91ab4080@github.com>
References: <wRdcRQurtpybntK9Qpji-6zVY-EcHKw3q87xpD0eoS4=.a6dc32f4-2919-42e9-80c3-5a264067f0e2@github.com>
 <yER6SKX-lfZsdJmls-clFnBnZd-SWbJkCF4kO_OZg-o=.64d2e6af-47ea-4f82-9a9a-fec6395a2ad5@github.com>
 <LwyuPftEZnuGNnUAjr3ar5upnTHEBRZF9JRtdciVc1s=.64695cc9-0139-4efd-aa4d-e5c57eddca9f@github.com>
 <xVPLwLdUNsPogD1lTYOn6EQPsCxzX5xEz_Ywk83SsYE=.f7604702-37e0-43b8-942f-3eed91ab4080@github.com>
Message-ID: <7093f109-2869-8b44-5174-aded34467847@oracle.com>

Hi Dan,

On 18/02/2021 3:36 am, Daniel D.Daugherty wrote:
> On Wed, 17 Feb 2021 07:32:46 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>>> Daniel D. Daugherty has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>>>
>>>   - Merge branch 'master' into JDK-8241403
>>>   - Address coleenp CR0 comments.
>>>   - 8241403: JavaThread::get_thread_name() should be ThreadSMR-aware
>>
>> Hi Dan,
>>
>> Sorry but I have a lot of issues with this. After thinking about it a lot I don't think the current approach is what is needed. To repeat what I wrote in one of the comments I think the simple fix here is to replace the use of Threads_lock in the caller with suitable use of a TLH, and then replace the assert_locked_or_safepoint(Threads_lock) with assert(is_JavaThread_protected(t)) where is_JavaThread_protected checks the target for either being the current thread or included in a TLH of the current thread. I don't think get_thread_name() should try to protect the target as that is the responsibility of the caller.
>>
>> Thanks,
>> David
> 
> @dholmes-ora - I'm really glad that I waited for your review! Thanks for taking the time.

I think there are more issues with the existing code that then impact 
any changes.

The general rule to operate on a target thread is that it must not be 
able to terminate (or more strongly be deallocated) whilst you may 
operate on it, but there are many ways this can be true:

- current thread
- at a safepoint
- in a handshake
- captured in a TLH
- target thread is immortal
- current thread holds a resource that the target needs before it exits

This last category is very general and can't really be captured by an 
assertion. Holding the Threads_lock was one old example (and could be 
asserted), but there are other possibilities including:

- current thread holds the ObjectMonitor of the target's j.l.Thread instance
- current thread is "synchronizing" with the target and the target can't 
proceed until after the current thread releases it

So I think the current assertion in get_thread_name is more restrictive 
than is actually necessary (imagine adding a logging statement in the OM 
code that prints the name of the thread it has selected to unpark - 
perfectly safe but no safepoint active and no Threads_lock held). 
Changing that assertion is also more involved than just checking for an 
active TLH as there are many safety conditions, not all of which can be 
checked explicitly.

I think the CompileBroker code was a case of dealing with immortal 
threads (before UseDynamicNumberOfCompilerThreads was introduced) and 
the acquisition of the Threads_lock was simply done to placate the 
assertion. With dynamic compiler threads it is I guess theoretically 
possible that a newly created thread might terminate again before the 
creating thread reaches the get_thread_name() call - but exceedingly 
unlikely. Not sure how to fix that one without splitting apart the 
thread creation and start processes.

Cheers,
David
-----


> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/2535
> 

From ysuenaga at openjdk.java.net  Thu Feb 18 02:48:38 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Thu, 18 Feb 2021 02:48:38 GMT
Subject: RFR: 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: <uKd6dxjSqGW3bkP5k-ZIXSDQcx9lG5NRtGFClVH79qQ=.d486d108-1a9d-46b6-9571-b5fb1aaa6b2b@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.

> @YaSuenag https://bugs.openjdk.java.net/browse/JDK-8250826 is the bug I was thinking of that sounds like the RO/RW issue you were talking about.

It is similar, but it's different from this issue because JDK-8250826 is caused by `mprotect()` call against memory segment in ELF binary.

> In any case, I think the main issue it causes for you is that your rounding up the size of the last (4th) segment may not enough. I think in most cases you would need to round it up to a page boundary, and then add another page to it.

Hmm... it might be page-boundary problem as you said, but I don't have any ideas where we can collect the information about that excepting note section in the core.
My latest patch shows following debug message on the console. It shows all PT_LOAD segments have been handled correctly.

libsaproc DEBUG: /lib64/libnss_sss.so.2 [0] 0x7f0ba6ec5000-0x7f0ba6ec7000: base = 0x7f0ba6ec5000, vaddr = 0x0, memsz = 0x1468, filesz = 0x1468
libsaproc DEBUG: /lib64/libnss_sss.so.2 [1] 0x7f0ba6ec7000-0x7f0ba6ece000: base = 0x7f0ba6ec5000, vaddr = 0x2000, memsz = 0x6931, filesz = 0x6931
libsaproc DEBUG: /lib64/libnss_sss.so.2 [2] 0x7f0ba6ece000-0x7f0ba6ed0000: base = 0x7f0ba6ec5000, vaddr = 0x9000, memsz = 0x1110, filesz = 0x1110
libsaproc DEBUG: /lib64/libnss_sss.so.2 [3] 0x7f0ba6ed0000-0x7f0ba6ed1000: base = 0x7f0ba6ec5000, vaddr = 0xbc78, memsz = 0x658, filesz = 0x44c

> I'm actually not too concerned about getting this right, because with my PointerFinder workaround I don't think this issue with the map sizes has much impact on SA. Probably the only place it will show up is with SA pmap output.

Ok, I will move forward this fix.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2563

From ysuenaga at openjdk.java.net  Thu Feb 18 02:56:55 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Thu, 18 Feb 2021 02:56:55 GMT
Subject: RFR: 8261710: SA DSO objects have sizes that are too large [v5]
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: <C1ZuBo_zuSpQ9EMMFRvm_-NWAuU4MseXMdTgkgV2tUE=.486349a5-8178-498e-952d-ca04ed484a29@github.com>

> 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

-------------

Changes: https://git.openjdk.java.net/jdk/pull/2563/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2563&range=04
  Stats: 95 lines in 9 files changed: 56 ins; 13 del; 26 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2563.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2563/head:pull/2563

PR: https://git.openjdk.java.net/jdk/pull/2563

From ysuenaga at openjdk.java.net  Thu Feb 18 03:01:39 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Thu, 18 Feb 2021 03:01:39 GMT
Subject: RFR: 8261710: SA DSO objects have sizes that are too large [v4]
In-Reply-To: <ZpQrDMQXuzEUbe5qhXvKPi1fKgmWnz1n_gCpYxPib-M=.b365c936-b8d2-4115-92dd-4e117248f14c@github.com>
References: <rtxSvuvKLmHKrLtsnxf76vSK41b_HWPR_7Bn3wf9YuM=.cf1b54ae-f01d-48d5-9641-d7d9faa541f5@github.com>
 <-tUjqHsXhVl31QRbblNj5TjV6BVOOLtl6dmXjzVFheo=.498514c8-d0f8-4081-a036-1f9114a6a9c3@github.com>
 <ZpQrDMQXuzEUbe5qhXvKPi1fKgmWnz1n_gCpYxPib-M=.b365c936-b8d2-4115-92dd-4e117248f14c@github.com>
Message-ID: <KtbKpVu273Kz9u1RpRPvwOH6DBgXIJyJXIlHPqHsi2U=.84f275e4-0123-4dd2-97ba-c2021faeccac@github.com>

On Wed, 17 Feb 2021 21:55:57 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use p_filesz instead of p_memsz
>
> Hi Yasumasa,
> 
> Just some comments.
> 
> src/jdk.hotspot.agent/linux/native/libsaproc/libproc_impl.c
> +static inline uintptr_t align_down(uintptr_t ptr, size_t size) {
> +  return (ptr & ~(size - 1));
> +}
> +
> +static inline uintptr_t align_up(uintptr_t ptr, size_t size) {
> +  return ((ptr + size - 1) & ~(size - 1));
> +}
> 
> The name of 'size' parameter is confusing. Should it be renamed to something like page_size of psize?
> 
> +  lib->end = (uintptr_t)-1L;
> . . .
> +      if ((lib->end == (uintptr_t)-1L) || (lib->end < aligned_end)) {
> +        lib->end = aligned_end;
>        }
>  
> The condition  `(lib->end == (uintptr_t)-1L)` is a subset of `(lib->end < aligned_end)`, and so, can be removed. The same is true for the condition:
> +        if ((lib->exec_end == (uintptr_t)-1L) || (lib->exec_end < aligned_end)) {
> +          lib->exec_end = aligned_end;
> +        }
> 
> `+      print_debug("%s [%d] 0x%lx-0x%lx: base = 0x%lx, vaddr = 0x%lx, memsz = 0x%lx, filesz = 0x%lx\n", lib->name, cnt, aligned_start, aligned_end, lib->base, ph->p_vaddr, ph->p_memsz, ph->p_filesz);`
> 
> It is better to split this long line.
> 
> Thanks,
> Serguei

Thanks @sspitsyn for the comment!
I fixed almost of your comment in new commit.

> The condition `(lib->end == (uintptr_t)-1L)` is a subset of `(lib->end < aligned_end)`, and so, can be removed. The same is true for the condition:

`lib->end` is declared as unsigned (`uintptr_t`), so we can't use `(lib->end < aligned_end)` when `lib->end` is set to -1.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2563

From dholmes at openjdk.java.net  Thu Feb 18 05:14:40 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 18 Feb 2021 05:14:40 GMT
Subject: RFR: 8261447: MethodInvocationCounters frequently run into
 overflow [v7]
In-Reply-To: <Aj0149Vh2JIXvEwJ3Vxj7ThRz93rAmZv8hcJtkFdNLo=.bf8765cf-6c33-4bd9-85bc-c18f41eb62b5@github.com>
References: <FsHAKG6KwqJeHLIhE6JroDUjiebdevi1asoLi-7pQ1s=.15d96719-36f2-4f9b-ae80-fcb17a3b6659@github.com>
 <Aj0149Vh2JIXvEwJ3Vxj7ThRz93rAmZv8hcJtkFdNLo=.bf8765cf-6c33-4bd9-85bc-c18f41eb62b5@github.com>
Message-ID: <dFGw9vzL7mixav5czdcAlDty2VpAYyM3tBXNVLeM5Cw=.f1a89cfe-af03-4155-8340-244b3f9127aa@github.com>

On Wed, 17 Feb 2021 18:22:01 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 (185 days 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:
> 
>   update copyright year

src/hotspot/share/oops/method.cpp line 511:

> 509:   tty->cr();
> 510: 
> 511:   // Internal counting is based on signed int counters. They tend to

Is there a good reason to not simply make them unsigned int?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2511

From cjplummer at openjdk.java.net  Thu Feb 18 06:18:55 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 18 Feb 2021 06:18:55 GMT
Subject: RFR: 8261857: serviceability/sa/ClhsdbPrintAll.java failed with "Test
 ERROR java.lang.RuntimeException: 'cannot be cast to' found in stdout"
Message-ID: <Hb_DUhlaogiehEC-bhiW11Y4R0Y76X_KXJ7NYNJLmwY=.d2815725-6b32-4750-bbd0-ae90a88eb3e9@github.com>

The test is checking for "cannot be cast to" because at one point there was a bug in `printall` that was causing a `ClassCastException`. See [JDK-8175384](https://bugs.openjdk.java.net/browse/JDK-8175384). However, there is also a "cannot be cast to" message in the `printall` output when disassembling since the java source actually has it in a string literal:

 3203 302 ldc #214(6) <String " cannot be cast to ResourceBundle"> [fast_aldc]

Which comes from the following in the ResourceBundle.java source:

                        throw new ClassCastException(c.getName()
                                + " cannot be cast to ResourceBundle"); 

So this occurrence of "cannot be cast" is fine. The one we don't want comes from `SharedRuntime::generate_class_cast_message()` in `sharedRuntime.cpp`:

`                 "class %s cannot be cast to class %s (%s%s%s)",`

So we can avoid this bug by changing the check to be a bit more explicit and check for "cannot be cast to class" instead.

-------------

Commit messages:
 - Be more specific about the "cannot be cast" message the test looks for

Changes: https://git.openjdk.java.net/jdk/pull/2624/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2624&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8261857
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2624.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2624/head:pull/2624

PR: https://git.openjdk.java.net/jdk/pull/2624

From cjplummer at openjdk.java.net  Thu Feb 18 06:43:01 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 18 Feb 2021 06:43:01 GMT
Subject: RFR: 8261269: When using clhsdb to "inspect" a java object,
 clhsdb prints "Oop for..." twice [v2]
In-Reply-To: <ZMXuV3A7BSpkJtmlUlvtMCL6beFGJNFWGxIbdMS9kYI=.b9e00805-9edc-4b29-b2e5-a8734791f4c0@github.com>
References: <ZMXuV3A7BSpkJtmlUlvtMCL6beFGJNFWGxIbdMS9kYI=.b9e00805-9edc-4b29-b2e5-a8734791f4c0@github.com>
Message-ID: <IA04M2nZaQKP4T8SFUy1u66aJAbVgM5pouh7iNBoXYg=.f9c0559d-d75d-44ca-8b19-434b59fe865d@github.com>

> See CR for details. In brief, fixed the `inspect` command to remove duplicate output:
> 
> hsdb> inspect 0x00000007fef00770
> instance of Oop for java/lang/Class @ 0x00000007fef00770 @ 0x00000007fef00770 (size = 160)
> in: Oop for java/io/BufferedInputStream @ 0x0000000082005b08 Oop for java/io/BufferedInputStream @ 0x0000000082005b08
> out: Oop for java/io/PrintStream @ 0x0000000082007b60 Oop for java/io/PrintStream @ 0x0000000082007b60
> err: Oop for java/io/PrintStream @ 0x000000008200e0c8 Oop for java/io/PrintStream @ 0x000000008200e0c8 
> It should be:
> 
> hsdb> inspect 0x00000007fef00770
> instance of Oop for java/lang/Class @ 0x00000007fef00770 (size = 160)
> in: Oop for java/io/BufferedInputStream @ 0x0000000082005b08
> out: Oop for java/io/PrintStream @ 0x0000000082007b60
> err: Oop for java/io/PrintStream @ 0x000000008200e0c8

Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:

  Put replicated strings into a local variable.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2582/files
  - new: https://git.openjdk.java.net/jdk/pull/2582/files/d5a300c3..1304bd78

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2582&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2582&range=00-01

  Stats: 8 lines in 1 file changed: 2 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2582.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2582/head:pull/2582

PR: https://git.openjdk.java.net/jdk/pull/2582

From cjplummer at openjdk.java.net  Thu Feb 18 06:45:39 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 18 Feb 2021 06:45:39 GMT
Subject: RFR: 8261269: When using clhsdb to "inspect" a java object,
 clhsdb prints "Oop for..." twice [v2]
In-Reply-To: <XnpJKuLybz4Fcghw6bdu6cq34SapMCzpP0gLnwWKZUM=.57283da1-91d0-4d5f-a64a-fff049f8391d@github.com>
References: <ZMXuV3A7BSpkJtmlUlvtMCL6beFGJNFWGxIbdMS9kYI=.b9e00805-9edc-4b29-b2e5-a8734791f4c0@github.com>
 <XnpJKuLybz4Fcghw6bdu6cq34SapMCzpP0gLnwWKZUM=.57283da1-91d0-4d5f-a64a-fff049f8391d@github.com>
Message-ID: <3V_U0CgI3sW7LE1O6el65AkykEx3-Y6kwBcDp7GUPr4=.aa17426a-f31b-4f6f-a35f-f3f692d15181@github.com>

On Wed, 17 Feb 2021 23:30:04 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Put replicated strings into a local variable.
>
> It looks good to me.
> One side comment about the test. It is not easy to read the code with the same pattern (e.g. "Oop for java/io/BufferedInputStream") repeated several times. I understand, you prefer to make it more explicit but it'd be more readable if a predefined pattern is used like below:
>     String pattern = "Oop for java/io/BufferedInputStream";
> +            expStrMap.put(cmd, List.of("instance of Oop for java/lang/Class @ " + examineResult,
> +                                       "in: " + pattern + @"));
> . . .
> +            unexpStrMap.put(cmd, List.of(
> +                    "instance of Oop for java/lang/Class @ "  + examineResult + " @ " + examineResult,
> +                    "in: " + pattern + " .* " + pattern));
> 
> Just an opinion with no pressure. It is up to you.
> 
> Thanks,
> Serguei

Good idea. I've added the pattern strings. Thanks!

-------------

PR: https://git.openjdk.java.net/jdk/pull/2582

From shade at openjdk.java.net  Thu Feb 18 06:55:40 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 18 Feb 2021 06:55:40 GMT
Subject: Integrated: 8261925: ProblemList
 com/sun/jdi/AfterThreadDeathTest.java on Linux
In-Reply-To: <FgXvDZyKjY0f9HnlLDIYoD5t4zdkuUUJeRrFQH8lr7s=.b26d5bd2-946a-46fd-af36-11c0a395d8b8@github.com>
References: <FgXvDZyKjY0f9HnlLDIYoD5t4zdkuUUJeRrFQH8lr7s=.b26d5bd2-946a-46fd-af36-11c0a395d8b8@github.com>
Message-ID: <Tp0SehV4m2xsDdXqBQYZLdjCpicUk2yqgttZ668g0DY=.a65e2ac8-5807-4a93-9855-4c284d53ca3e@github.com>

On Wed, 17 Feb 2021 18:46:51 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I am seeing exactly the same error in GitHub Actions on x86_32, as in [JDK-8232839](https://bugs.openjdk.java.net/browse/JDK-8232839). [JDK-8258832](JDK-8258832) put it on problemlist for linux-x64, let's elevate that to linux-all.
> 
> Additional testing:
>  - [x] Test on Linux x86_64 (still skipped)
>  - [x] Test on Linux x86_32 (now skipped)

This pull request has now been integrated.

Changeset: b695c7ee
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b695c7ee
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8261925: ProblemList com/sun/jdi/AfterThreadDeathTest.java on Linux

Reviewed-by: dcubed

-------------

PR: https://git.openjdk.java.net/jdk/pull/2614

From github.com+741251+turbanoff at openjdk.java.net  Thu Feb 18 07:15:40 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Thu, 18 Feb 2021 07:15:40 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy
In-Reply-To: <5s4i5725zJd8QrefwYyc8sn2fQXad3hAGLVflkFttmY=.abe55236-e258-482b-b8be-be75e1eb086c@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <5s4i5725zJd8QrefwYyc8sn2fQXad3hAGLVflkFttmY=.abe55236-e258-482b-b8be-be75e1eb086c@github.com>
Message-ID: <klPrlAvPsVYcAtWjox3cWGgbEIjbHXoaFtYu7iBPCxc=.22a22c0a-7d04-4abf-b9ff-0e2a423a6b18@github.com>

On Tue, 16 Feb 2021 17:20:37 GMT, Julia Boes <jboes at openjdk.org> wrote:

>> 8080272  Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy
>
> 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)?

-------------

PR: https://git.openjdk.java.net/jdk/pull/1853

From lzang at openjdk.java.net  Thu Feb 18 09:00:46 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Thu, 18 Feb 2021 09:00:46 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump
In-Reply-To: <uNnW324l-gBNDcYd0aLLxQRF3G3vZfFeO71Da3oWkTo=.e0b9fa86-c6b5-4c18-8abb-2c69a66dfbf7@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
 <crJcuaqSgYZQCEw2lqGaLpRmCVOXr99P1i5bcnSFpQc=.cb824923-e649-4ecd-ba5b-8d26cb93b265@github.com>
 <esex_demB2ZT0CsAp2WrzNGC_gieM9USGg_fYgmFCAE=.1911dd08-7dcc-4d88-9532-5d670399dd62@github.com>
 <ztN32xTk5joNRB7MhfYMl9zHCfGA1j8bQNu-ke975qc=.4c7ff2a9-2af8-495d-8f22-83e98c2e3221@github.com>
 <oQe3_j7vewkS8wlIuYXRCa_86pI215cFIceztTf5jX0=.d6d6201b-ec15-418e-a73b-e907d9d02607@github.com>
 <oPJ9OfKdD8CTbihLREww1QM2hc3Ckiai0-1OSpkq830=.87c4f119-07c9-471f-8c25-99dcfaad8d11@github.com>
 <ngMsS8jp0GTuqLVGD5k2ZL5AckbFwh8CBj5ec_GaBes=.0c51dacf-b158-4e62-874d-5e9c5a7b5f8e@github.com>
 <JDsbDqJRQ0V_s1SvGBhr3FLu98T2-X51kpkCs8s8vxQ=.fdb2242c-8706-4057-b4aa-084cfcb24166@github.com>
 <cHsGHKQrSqSUKJJ2OIRVUYuKUVOJGH-Pch-aDmoPj64=.88025b63-b0bb-401a-a749-57089ebea3aa@github.com>
 <gnDO9moDHlyHgJCEdcILr-MauRQgQP7I6QE38XZHus0=.4e488aca-8206-4db5-acec-5c029a6328ca@github.com>
 <vN4ZxgYOLsOQLqwyX4fXMJsQ-LM-S5JqeZo
 WdMXzmqc=.dfdc97a5-4838-4f09-9082-e5562c4691e0@github.com>
 <hLyibl3_enSszfZLKP74PE3i_ranX51N3nNiX0F9KoA=.8f2fea52-c394-4612-9c74-d9d975a3c42a@github.com>
 <Gs7-OplIQn5Vtq9vmQ6QXnB3l_XGSwfsagD044OQ2RM=.564b8980-fd3b-4555-864c-33c1b55a9fbd@github.com>
 <ONgCbmqprWaFkq_OtsFB5KBW1KjPIQu7QRaHXFEHOB8=.e1af696f-9e30-4b94-9524-682a14226c74@github.com>
 <sQsnkEh6czmuyAbsFV8pm0HRBc4iR21hMXj0o5Za8VA=.c455e261-03b5-4bd7-8b88-0fff84c20e85@github.com>
 <yWtKl2uvn5MZTKXzjBrZBhXf-slKdGI1DjBZxBJaTws=.01b30893-7395-4e00-aa50-e2c25fd33ba1@github.com>
 <uNnW324l-gBNDcYd0aLLxQRF3G3vZfFeO71Da3oWkTo=.e0b9fa86-c6b5-4c18-8abb-2c69a66dfbf7@github.com>
Message-ID: <PvQWprLL5osQE6QKlj1lV0-kybWhy4b_oFKk_e34XOg=.8d06d1d6-a006-40cb-923c-5e288310fc3c@github.com>

On Fri, 12 Feb 2021 00:56:47 GMT, Lin Zang <lzang at openjdk.org> wrote:

>>> BTW, one thing to keep in mind that whatever we do with `dumpheap`, the jcmd version will support fine control over parallelism. So for that reason it wouldn't be so bad to just have `dumpheap` and `inspectheap` always use some default parallelism, and allow tuning it with the jcmd versions. But since the `inspectheap` parallel support already went into 16, that might be hard to undo.
>> 
>> Hi Chris, Lin,
>> IMHO, 16 is not an LTS, maybe it's better for us to adjust the behavior of jmap -histo in 17 which is LTS? I just filed https://bugs.openjdk.java.net/browse/JDK-8261482 to address the issue if you both think it's OK to undo it.
>> Thanks.
>
> Hi Chris, 
> I have update the PR to add a new dumpheapext command that could handle more arguments passed from JMap.java. 
> And I have tested with "jmap -dump:file=dump.bin,noparallel [pid]", with this change, new jmap targeting on old hotspot would print: 
> 
> Exception in thread "main" com.sun.tools.attach.AttachOperationFailedException: Operation dumpheapext not recognized!
> 	at jdk.attach/sun.tools.attach.VirtualMachineImpl.execute(VirtualMachineImpl.java:227)
> 	at jdk.attach/sun.tools.attach.HotSpotVirtualMachine.executeCommand(HotSpotVirtualMachine.java:309)
> 	at jdk.jcmd/sun.tools.jmap.JMap.executeCommandForPid(JMap.java:133)
> 	at jdk.jcmd/sun.tools.jmap.JMap.dump(JMap.java:262)
> 	at jdk.jcmd/sun.tools.jmap.JMap.main(JMap.java:114)
> 
> IMH, one problem is that it doesn't give out the reason clearly that "dumpheapext" is actually caused by new option "noparallel". But I think having this kind of error message is acceptable. Otherwise it seems the choice we left is remove the "parallel/noparallel" for Jmap. What do you think?

Dear All, 
     I am going to create a CSR for the new internal command "dumpheapext", one problem is that seem if a new CSR is created, this PR will depends on 2 CSRs, I am not sure is this reasonable?  Thanks!

-------------

PR: https://git.openjdk.java.net/jdk/pull/2261

From lzang at openjdk.java.net  Thu Feb 18 09:00:45 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Thu, 18 Feb 2021 09:00:45 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump
In-Reply-To: <yWtKl2uvn5MZTKXzjBrZBhXf-slKdGI1DjBZxBJaTws=.01b30893-7395-4e00-aa50-e2c25fd33ba1@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
 <crJcuaqSgYZQCEw2lqGaLpRmCVOXr99P1i5bcnSFpQc=.cb824923-e649-4ecd-ba5b-8d26cb93b265@github.com>
 <esex_demB2ZT0CsAp2WrzNGC_gieM9USGg_fYgmFCAE=.1911dd08-7dcc-4d88-9532-5d670399dd62@github.com>
 <ztN32xTk5joNRB7MhfYMl9zHCfGA1j8bQNu-ke975qc=.4c7ff2a9-2af8-495d-8f22-83e98c2e3221@github.com>
 <oQe3_j7vewkS8wlIuYXRCa_86pI215cFIceztTf5jX0=.d6d6201b-ec15-418e-a73b-e907d9d02607@github.com>
 <oPJ9OfKdD8CTbihLREww1QM2hc3Ckiai0-1OSpkq830=.87c4f119-07c9-471f-8c25-99dcfaad8d11@github.com>
 <ngMsS8jp0GTuqLVGD5k2ZL5AckbFwh8CBj5ec_GaBes=.0c51dacf-b158-4e62-874d-5e9c5a7b5f8e@github.com>
 <JDsbDqJRQ0V_s1SvGBhr3FLu98T2-X51kpkCs8s8vxQ=.fdb2242c-8706-4057-b4aa-084cfcb24166@github.com>
 <cHsGHKQrSqSUKJJ2OIRVUYuKUVOJGH-Pch-aDmoPj64=.88025b63-b0bb-401a-a749-57089ebea3aa@github.com>
 <gnDO9moDHlyHgJCEdcILr-MauRQgQP7I6QE38XZHus0=.4e488aca-8206-4db5-acec-5c029a6328ca@github.com>
 <vN4ZxgYOLsOQLqwyX4fXMJsQ-LM-S5JqeZo
 WdMXzmqc=.dfdc97a5-4838-4f09-9082-e5562c4691e0@github.com>
 <hLyibl3_enSszfZLKP74PE3i_ranX51N3nNiX0F9KoA=.8f2fea52-c394-4612-9c74-d9d975a3c42a@github.com>
 <Gs7-OplIQn5Vtq9vmQ6QXnB3l_XGSwfsagD044OQ2RM=.564b8980-fd3b-4555-864c-33c1b55a9fbd@github.com>
 <ONgCbmqprWaFkq_OtsFB5KBW1KjPIQu7QRaHXFEHOB8=.e1af696f-9e30-4b94-9524-682a14226c74@github.com>
 <sQsnkEh6czmuyAbsFV8pm0HRBc4iR21hMXj0o5Za8VA=.c455e261-03b5-4bd7-8b88-0fff84c20e85@github.com>
 <yWtKl2uvn5MZTKXzjBrZBhXf-slKdGI1DjBZxBJaTws=.01b30893-7395-4e00-aa50-e2c25fd33ba1@github.com>
Message-ID: <uNnW324l-gBNDcYd0aLLxQRF3G3vZfFeO71Da3oWkTo=.e0b9fa86-c6b5-4c18-8abb-2c69a66dfbf7@github.com>

On Wed, 10 Feb 2021 02:00:11 GMT, Hamlin Li <mli at openjdk.org> wrote:

>>>  IMO, there can be two ways which may help solve the compatibility issue of introducing "parallel" option:
>>> 
>>>     * unblock socket with timeout. In this way, old Jmap could work with new JDK, but it maybe complicated because of different implementation for different OS.
>>> 
>>>     * Two times communication as you mentioned,  it sounds a reasonable solution, I will work out a prototype and then discuss with you .
>>> 
>> A 3rd would be to create a new `dumpheap` command for the Attach API, maybe `dumpheap_parallel`. If you try using it with an old JVM, it should immediately return an error:
>> 
>>         st.print("Operation %s not recognized!", op->name());
>>         res = JNI_ERR;
>> If it does, you can fallback to the regular `dumpheap` command. If an old JVM attaches and uses `dumpheap`, you can choose to make it parallel by default if you wish. A slightly different variant of this idea is have something like `dumpheap_extraargs` or `dumpheap_ext`, leaving room to add even more args in the future (possibly a single argument with a list of args as you suggested before)
>> 
>> BTW, one thing to keep in mind that whatever we do with `dumpheap`, the jcmd version will support fine control over parallelism. So for that reason it wouldn't be so bad to just have `dumpheap` and `inspectheap` always use some default parallelism, and allow tuning it with the jcmd versions. But since the `inspectheap` parallel support already went into 16, that might be hard to undo.
>
>> BTW, one thing to keep in mind that whatever we do with `dumpheap`, the jcmd version will support fine control over parallelism. So for that reason it wouldn't be so bad to just have `dumpheap` and `inspectheap` always use some default parallelism, and allow tuning it with the jcmd versions. But since the `inspectheap` parallel support already went into 16, that might be hard to undo.
> 
> Hi Chris, Lin,
> IMHO, 16 is not an LTS, maybe it's better for us to adjust the behavior of jmap -histo in 17 which is LTS? I just filed https://bugs.openjdk.java.net/browse/JDK-8261482 to address the issue if you both think it's OK to undo it.
> Thanks.

Hi Chris, 
I have update the PR to add a new dumpheapext command that could handle more arguments passed from JMap.java. 
And I have tested with "jmap -dump:file=dump.bin,noparallel [pid]", with this change, new jmap targeting on old hotspot would print: 

Exception in thread "main" com.sun.tools.attach.AttachOperationFailedException: Operation dumpheapext not recognized!
	at jdk.attach/sun.tools.attach.VirtualMachineImpl.execute(VirtualMachineImpl.java:227)
	at jdk.attach/sun.tools.attach.HotSpotVirtualMachine.executeCommand(HotSpotVirtualMachine.java:309)
	at jdk.jcmd/sun.tools.jmap.JMap.executeCommandForPid(JMap.java:133)
	at jdk.jcmd/sun.tools.jmap.JMap.dump(JMap.java:262)
	at jdk.jcmd/sun.tools.jmap.JMap.main(JMap.java:114)

IMH, one problem is that it doesn't give out the reason clearly that "dumpheapext" is actually caused by new option "noparallel". But I think having this kind of error message is acceptable. Otherwise it seems the choice we left is remove the "parallel/noparallel" for Jmap. What do you think?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2261

From lzang at openjdk.java.net  Thu Feb 18 09:28:05 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Thu, 18 Feb 2021 09:28:05 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v7]
In-Reply-To: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
Message-ID: <Wo03LBq0IxKwKe6lHHqh2EqCXsYqDAggySEjj3xD41Q=.21e442fe-048d-4a7e-a3a4-9961951b4201@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:

  use parallel= option instead of noparallel

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2261/files
  - new: https://git.openjdk.java.net/jdk/pull/2261/files/b4776658..44ea7927

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2261&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2261&range=05-06

  Stats: 26 lines in 2 files changed: 14 ins; 1 del; 11 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  Thu Feb 18 09:32:14 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Thu, 18 Feb 2021 09:32:14 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v8]
In-Reply-To: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
Message-ID: <2YV-EzcOxFjq7rIw-rRES6RGqv8ObBI14RaDHYmeTtg=.d50997a9-2983-4c23-a9c5-cdd2550fa0ae@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 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 pd
 - use parallel= option instead of noparallel
 - Add dumpheapext command for extra argument passing
 - Fix logic in thread number calculation and code refine
 - Merge branch 'master' into par-dump
 - fix buffer queue issue
 - code refine
 - Do not expose parallel thread number to user
 - fix white space trailing issue
 - 8252842: Extend jmap to support parallel heap dump

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2261/files
  - new: https://git.openjdk.java.net/jdk/pull/2261/files/44ea7927..375e6732

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2261&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2261&range=06-07

  Stats: 40119 lines in 1084 files changed: 24892 ins; 10354 del; 4873 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 jboes at openjdk.java.net  Thu Feb 18 10:38:41 2021
From: jboes at openjdk.java.net (Julia Boes)
Date: Thu, 18 Feb 2021 10:38:41 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: <8pRy5JBdXXoJzu35O6aFHAUALWZ__OBbdganHZKu1FE=.f5fcf42b-eab5-49a6-9450-4942c933f39d@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)?

To re-integrate, just run the /integrate command again. 

Before doing that, could someone from security libs acknowledge the changes in their area?

-------------

PR: https://git.openjdk.java.net/jdk/pull/1853

From lucy at openjdk.java.net  Thu Feb 18 11:25:40 2021
From: lucy at openjdk.java.net (Lutz Schmidt)
Date: Thu, 18 Feb 2021 11:25:40 GMT
Subject: RFR: 8261447: MethodInvocationCounters frequently run into
 overflow [v7]
In-Reply-To: <dFGw9vzL7mixav5czdcAlDty2VpAYyM3tBXNVLeM5Cw=.f1a89cfe-af03-4155-8340-244b3f9127aa@github.com>
References: <FsHAKG6KwqJeHLIhE6JroDUjiebdevi1asoLi-7pQ1s=.15d96719-36f2-4f9b-ae80-fcb17a3b6659@github.com>
 <Aj0149Vh2JIXvEwJ3Vxj7ThRz93rAmZv8hcJtkFdNLo=.bf8765cf-6c33-4bd9-85bc-c18f41eb62b5@github.com>
 <dFGw9vzL7mixav5czdcAlDty2VpAYyM3tBXNVLeM5Cw=.f1a89cfe-af03-4155-8340-244b3f9127aa@github.com>
Message-ID: <5KNOS1zweuPypTt0JZTNCzmHaBPj4NhiwCsmNwbDr8c=.a32b1c8b-1eb2-40bc-877a-44cbfebbb0fd@github.com>

On Thu, 18 Feb 2021 05:12:08 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Lutz Schmidt has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update copyright year
>
> src/hotspot/share/oops/method.cpp line 511:
> 
>> 509:   tty->cr();
>> 510: 
>> 511:   // Internal counting is based on signed int counters. They tend to
> 
> Is there a good reason to not simply make them unsigned int?

Well, depends on what you accept as a good reason. :-)

I decided to keep the counters as they are to limit the scope of the change. A grep for backedge_counter returns 94 lines, for example. Deep down, these counters are InvocationCounters, declared as uint. On their way up to the surface, they are treated signed or unsigned. Pretty inconsistent, yes. But a huge task to get it all straight, including checking/fixing assembly code. 

Is that reason enough?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2511

From david.holmes at oracle.com  Thu Feb 18 12:56:15 2021
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 18 Feb 2021 22:56:15 +1000
Subject: RFR: 8261447: MethodInvocationCounters frequently run into
 overflow [v7]
In-Reply-To: <5KNOS1zweuPypTt0JZTNCzmHaBPj4NhiwCsmNwbDr8c=.a32b1c8b-1eb2-40bc-877a-44cbfebbb0fd@github.com>
References: <FsHAKG6KwqJeHLIhE6JroDUjiebdevi1asoLi-7pQ1s=.15d96719-36f2-4f9b-ae80-fcb17a3b6659@github.com>
 <Aj0149Vh2JIXvEwJ3Vxj7ThRz93rAmZv8hcJtkFdNLo=.bf8765cf-6c33-4bd9-85bc-c18f41eb62b5@github.com>
 <dFGw9vzL7mixav5czdcAlDty2VpAYyM3tBXNVLeM5Cw=.f1a89cfe-af03-4155-8340-244b3f9127aa@github.com>
 <5KNOS1zweuPypTt0JZTNCzmHaBPj4NhiwCsmNwbDr8c=.a32b1c8b-1eb2-40bc-877a-44cbfebbb0fd@github.com>
Message-ID: <0d1f637c-0330-3362-99d6-5c310fd3f98d@oracle.com>

On 18/02/2021 9:25 pm, Lutz Schmidt wrote:
> On Thu, 18 Feb 2021 05:12:08 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>>> Lutz Schmidt has updated the pull request incrementally with one additional commit since the last revision:
>>>
>>>    update copyright year
>>
>> src/hotspot/share/oops/method.cpp line 511:
>>
>>> 509:   tty->cr();
>>> 510:
>>> 511:   // Internal counting is based on signed int counters. They tend to
>>
>> Is there a good reason to not simply make them unsigned int?
> 
> Well, depends on what you accept as a good reason. :-)
> 
> I decided to keep the counters as they are to limit the scope of the change. A grep for backedge_counter returns 94 lines, for example. Deep down, these counters are InvocationCounters, declared as uint. On their way up to the surface, they are treated signed or unsigned. Pretty inconsistent, yes. But a huge task to get it all straight, including checking/fixing assembly code.
> 
> Is that reason enough?

I guess so :) It sounds terribly messy and confused.

Thanks,
David

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/2511
> 

From cjplummer at openjdk.java.net  Thu Feb 18 16:42:44 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 18 Feb 2021 16:42:44 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump
In-Reply-To: <PvQWprLL5osQE6QKlj1lV0-kybWhy4b_oFKk_e34XOg=.8d06d1d6-a006-40cb-923c-5e288310fc3c@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
 <crJcuaqSgYZQCEw2lqGaLpRmCVOXr99P1i5bcnSFpQc=.cb824923-e649-4ecd-ba5b-8d26cb93b265@github.com>
 <esex_demB2ZT0CsAp2WrzNGC_gieM9USGg_fYgmFCAE=.1911dd08-7dcc-4d88-9532-5d670399dd62@github.com>
 <ztN32xTk5joNRB7MhfYMl9zHCfGA1j8bQNu-ke975qc=.4c7ff2a9-2af8-495d-8f22-83e98c2e3221@github.com>
 <oQe3_j7vewkS8wlIuYXRCa_86pI215cFIceztTf5jX0=.d6d6201b-ec15-418e-a73b-e907d9d02607@github.com>
 <oPJ9OfKdD8CTbihLREww1QM2hc3Ckiai0-1OSpkq830=.87c4f119-07c9-471f-8c25-99dcfaad8d11@github.com>
 <ngMsS8jp0GTuqLVGD5k2ZL5AckbFwh8CBj5ec_GaBes=.0c51dacf-b158-4e62-874d-5e9c5a7b5f8e@github.com>
 <JDsbDqJRQ0V_s1SvGBhr3FLu98T2-X51kpkCs8s8vxQ=.fdb2242c-8706-4057-b4aa-084cfcb24166@github.com>
 <cHsGHKQrSqSUKJJ2OIRVUYuKUVOJGH-Pch-aDmoPj64=.88025b63-b0bb-401a-a749-57089ebea3aa@github.com>
 <gnDO9moDHlyHgJCEdcILr-MauRQgQP7I6QE38XZHus0=.4e488aca-8206-4db5-acec-5c029a6328ca@github.com>
 <vN4ZxgYOLsOQLqwyX4fXMJsQ-LM-S5JqeZo
 WdMXzmqc=.dfdc97a5-4838-4f09-9082-e5562c4691e0@github.com>
 <hLyibl3_enSszfZLKP74PE3i_ranX51N3nNiX0F9KoA=.8f2fea52-c394-4612-9c74-d9d975a3c42a@github.com>
 <Gs7-OplIQn5Vtq9vmQ6QXnB3l_XGSwfsagD044OQ2RM=.564b8980-fd3b-4555-864c-33c1b55a9fbd@github.com>
 <ONgCbmqprWaFkq_OtsFB5KBW1KjPIQu7QRaHXFEHOB8=.e1af696f-9e30-4b94-9524-682a14226c74@github.com>
 <sQsnkEh6czmuyAbsFV8pm0HRBc4iR21hMXj0o5Za8VA=.c455e261-03b5-4bd7-8b88-0fff84c20e85@github.com>
 <yWtKl2uvn5MZTKXzjBrZBhXf-slKdGI1DjBZxBJaTws=.01b30893-7395-4e00-aa50-e2c25fd33ba1@github.com>
 <uNnW324l-gBNDcYd0aLLxQRF3G3vZfFeO71Da3oWkTo=.e0b9fa86-c6b5-4c18-8abb-2c69a66dfbf7@github.com>
 <PvQWprLL5osQE6QKlj1lV0-kybWhy4b_oFKk_e34XOg=.8d06d1d6-a006-40cb-923c-5e288310fc3c@github.com>
Message-ID: <j2NdBB317FgfZGi1tyIpmIlgfYbjWQv_IruuElr2Md0=.cfcc0d39-8ea5-452f-93a2-5a9dffc6e52e@github.com>

On Thu, 18 Feb 2021 08:58:25 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> Hi Chris, 
>> I have update the PR to add a new dumpheapext command that could handle more arguments passed from JMap.java. 
>> And I have tested with "jmap -dump:file=dump.bin,noparallel [pid]", with this change, new jmap targeting on old hotspot would print: 
>> 
>> Exception in thread "main" com.sun.tools.attach.AttachOperationFailedException: Operation dumpheapext not recognized!
>> 	at jdk.attach/sun.tools.attach.VirtualMachineImpl.execute(VirtualMachineImpl.java:227)
>> 	at jdk.attach/sun.tools.attach.HotSpotVirtualMachine.executeCommand(HotSpotVirtualMachine.java:309)
>> 	at jdk.jcmd/sun.tools.jmap.JMap.executeCommandForPid(JMap.java:133)
>> 	at jdk.jcmd/sun.tools.jmap.JMap.dump(JMap.java:262)
>> 	at jdk.jcmd/sun.tools.jmap.JMap.main(JMap.java:114)
>> 
>> IMH, one problem is that it doesn't give out the reason clearly that "dumpheapext" is actually caused by new option "noparallel". But I think having this kind of error message is acceptable. Otherwise it seems the choice we left is remove the "parallel/noparallel" for Jmap. What do you think?
>
> Dear All, 
>      I am going to create a CSR for the new internal command "dumpheapext", one problem is that seem if a new CSR is created, this PR will depends on 2 CSRs, I am not sure is this reasonable?  Thanks!

I was thought the plan was for new the `jmap` to detect the error, eat the exception, and retry with the `dumpheap` command (without any `parallel` related option). Or the other option would be to eat the exception and produce an error message saying that the `parallel` option is not supported by the target VM. I don't think the user should be exposed to the "Operation dumpheapext not recognized" message.

>  I am going to create a CSR for the new internal command "dumpheapext", one problem is that seem if a new CSR is created, this PR will depends on 2 CSRs, I am not sure is this reasonable? Thanks!

I have no idea if you can add two CSRs to a PR and a CR. If you can, then I see no issue with doing that. If not, we might need to talk to the CSR committee to see how best to handle it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2261

From mullan at openjdk.java.net  Thu Feb 18 19:24:43 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Thu, 18 Feb 2021 19:24:43 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v11]
In-Reply-To: <djPl7TL8j0qwyuLjwnZI96g7UPmw3XamdbVltf8fbos=.36a5bbe7-1fd0-496b-999f-7c49d06fc0a8@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <djPl7TL8j0qwyuLjwnZI96g7UPmw3XamdbVltf8fbos=.36a5bbe7-1fd0-496b-999f-7c49d06fc0a8@github.com>
Message-ID: <6zhT8ySP8rFE4wV5vva0oKRDSxDnSYYZ-sXAQJ6F_DM=.b83a0f88-7231-4796-a0b5-d51b5950d316@github.com>

On Mon, 15 Feb 2021 19:47:00 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
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
>   remove unnecessary file.exists() check

src/java.base/share/classes/sun/security/provider/certpath/X509CertPath.java line 228:

> 226:         try {
> 227:             if (is.markSupported() == false) {
> 228:                 // Copy the entire input stream into an InputStream that does

I don't think you should remove lines 228-232. These methods are called by methods of CertificateFactory that take InputStream (which may contain a stream of security data) and they are designed such that they try to read one Certificate, CRL, or CertPath from the InputStream and leave the InputStream ready to parse the next structure instead of consuming all of the bytes. Thus they check if the InputStream supports mark in order to try to preserve that behavior. If mark is not supported, then it's ok to use InputStream.readAllBytes, otherwise, leave the stream as-is.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1853

From amenkov at openjdk.java.net  Thu Feb 18 21:51:54 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Thu, 18 Feb 2021 21:51:54 GMT
Subject: RFR: 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: <XNtryNIqeNjw469aK_pYJo5RF8po0h1swVsMbpV0orQ=.e96eac15-403f-47f7-9254-e4a1331a1040@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)

Added serviceability and net as this is JDI tests, but the issue is networking-related

-------------

PR: https://git.openjdk.java.net/jdk/pull/2633

From amenkov at openjdk.java.net  Thu Feb 18 21:51:53 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Thu, 18 Feb 2021 21:51:53 GMT
Subject: RFR: 8224775: test/jdk/com/sun/jdi/JdwpListenTest.java failed to
 attach
Message-ID: <pRiX1N1rR7NYrKg4y4BmHmB4vtRpCO0fVEZH0NMgkaM=.219d5434-25b9-4d5d-945a-27aaedefb6d2@github.com>

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)

-------------

Commit messages:
 - test only IPv6 link-local addresses

Changes: https://git.openjdk.java.net/jdk/pull/2633/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2633&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8224775
  Stats: 14 lines in 1 file changed: 3 ins; 0 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2633.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2633/head:pull/2633

PR: https://git.openjdk.java.net/jdk/pull/2633

From cjplummer at openjdk.java.net  Fri Feb 19 01:01:40 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Fri, 19 Feb 2021 01:01:40 GMT
Subject: Integrated: 8261098: Add clhsdb "findsym" command
In-Reply-To: <EcsJkvo_wYh085Hc1uRmViYzUrsfMeNLFOEsn0YSyXs=.8243bb41-62d6-40a0-8942-650a9cd8a497@github.com>
References: <EcsJkvo_wYh085Hc1uRmViYzUrsfMeNLFOEsn0YSyXs=.8243bb41-62d6-40a0-8942-650a9cd8a497@github.com>
Message-ID: <XIp9vxhgns1Ffudh5qjy6f5yt1go8Of4MQW1DuSWQ_k=.6bd2d21c-2dc1-4fdf-b76a-d1f7fe7fb0fa@github.com>

On Mon, 15 Feb 2021 05:51:07 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Add "findsym" to clhsdb. See the CR and CSR for details. The [CSR](https://bugs.openjdk.java.net/browse/JDK-8261101) still needs a reviewer.
> 
> There is a fix in LinuxDebuggerLocal_lookupByName0() to allow passing in NULL for the dso name. This is allowed, and in fact even not null it gets ignored. It is needed by the new findsym support in order for the following to work, which passes in null for the dso name:
> 
> `    Address addr = VM.getVM().getDebugger().lookup(null, symbol);`
> 
> There is one other somewhat unrelated fix in the test:
> 
>  -            String value = parts[1];
>  +           String value = parts[1].split(linesep)[0];
> 
> This is suppose to capture just the value at the specified address, but it also captures the newline and some text after. The result if that when `findpc <value>` is executed, it also executes another command or two of garbage commands after that, which produce errors. They were not impacting the test, but were noticeable in the log. I first noticed it when similar code in the new part of the test had the same issue.

This pull request has now been integrated.

Changeset: c158413e
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c158413e
Stats:     83 lines in 4 files changed: 75 ins; 0 del; 8 mod

8261098: Add clhsdb "findsym" command

Reviewed-by: amenkov, sspitsyn

-------------

PR: https://git.openjdk.java.net/jdk/pull/2567

From cjplummer at openjdk.java.net  Fri Feb 19 01:08:52 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Fri, 19 Feb 2021 01:08:52 GMT
Subject: RFR: 8261929: ClhsdbFindPC fails with java.lang.RuntimeException: 'In
 java stack' missing from stdout/stderr
Message-ID: <yNakPYlp6Q6YF6NB6db7IyAhAqMvgUc9dq6p6CAJJYU=.41bdf544-1b81-4a90-a3a7-e3207fb1fc9d@github.com>

Sometimes due to the state of the java thread, jstack does cannot determine the address of the java frame and instead it is 0x. We need to special case this so the test does not fail.

-------------

Commit messages:
 - Special case when we can't get the address of the java stack.

Changes: https://git.openjdk.java.net/jdk/pull/2637/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2637&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8261929
  Stats: 9 lines in 1 file changed: 4 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2637.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2637/head:pull/2637

PR: https://git.openjdk.java.net/jdk/pull/2637

From kbarrett at openjdk.java.net  Fri Feb 19 02:45:04 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Fri, 19 Feb 2021 02:45:04 GMT
Subject: RFR: 8261998: Remove unused shared entry support from
 utilities/hashtable
Message-ID: <49wKLf3cdp0YDVDbUsbRIyV6576RzmT4fqFlIC3BDLU=.301faf2d-ad9b-4c84-8c15-dec7df375bb9@github.com>

Please review this small cleanup in the utilities/hashtable facility.  The
support for "shared" entries is no longer needed or used, so is being deleted.

Testing:
mach5 tier1-4 (some CDS tests are in tier4)

-------------

Commit messages:
 - remove shared entry support

Changes: https://git.openjdk.java.net/jdk/pull/2638/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2638&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8261998
  Stats: 28 lines in 3 files changed: 0 ins; 23 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2638.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2638/head:pull/2638

PR: https://git.openjdk.java.net/jdk/pull/2638

From coleenp at openjdk.java.net  Fri Feb 19 02:58:42 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Fri, 19 Feb 2021 02:58:42 GMT
Subject: RFR: 8261998: Remove unused shared entry support from
 utilities/hashtable
In-Reply-To: <49wKLf3cdp0YDVDbUsbRIyV6576RzmT4fqFlIC3BDLU=.301faf2d-ad9b-4c84-8c15-dec7df375bb9@github.com>
References: <49wKLf3cdp0YDVDbUsbRIyV6576RzmT4fqFlIC3BDLU=.301faf2d-ad9b-4c84-8c15-dec7df375bb9@github.com>
Message-ID: <71z-SnDx5bGZgGxNyQVcKz79eA_Vsg6XEZ_RGNVP1K4=.dd905031-8f45-43ed-9d66-4753d41f34b4@github.com>

On Fri, 19 Feb 2021 02:39:20 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this small cleanup in the utilities/hashtable facility.  The
> support for "shared" entries is no longer needed or used, so is being deleted.
> 
> Testing:
> mach5 tier1-4 (some CDS tests are in tier4)

We might want to share other hashtables like this, like the loader constraint table, but I don't think this will be needed.

src/hotspot/share/prims/jvmtiTagMapTable.cpp line 255:

> 253:       }
> 254:       // get next entry
> 255:       entry = (JvmtiTagMapEntry*)HashtableEntry<WeakHandle, mtServiceability>::make_ptr(*p);

Nice to get rid of this.  It would be nice if the hashtables didn't need to declare bucket() and bucket_addr() with all these casts but some template nonsense makes it not compile.

-------------

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2638

From david.holmes at oracle.com  Fri Feb 19 03:58:40 2021
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 19 Feb 2021 13:58:40 +1000
Subject: RFR: 8252842: Extend jmap to support parallel heap dump
In-Reply-To: <j2NdBB317FgfZGi1tyIpmIlgfYbjWQv_IruuElr2Md0=.cfcc0d39-8ea5-452f-93a2-5a9dffc6e52e@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
 <vN4ZxgYOLsOQLqwyX4fXMJsQ-LM-S5JqeZo
 WdMXzmqc=.dfdc97a5-4838-4f09-9082-e5562c4691e0@github.com>
 <hLyibl3_enSszfZLKP74PE3i_ranX51N3nNiX0F9KoA=.8f2fea52-c394-4612-9c74-d9d975a3c42a@github.com>
 <Gs7-OplIQn5Vtq9vmQ6QXnB3l_XGSwfsagD044OQ2RM=.564b8980-fd3b-4555-864c-33c1b55a9fbd@github.com>
 <ONgCbmqprWaFkq_OtsFB5KBW1KjPIQu7QRaHXFEHOB8=.e1af696f-9e30-4b94-9524-682a14226c74@github.com>
 <sQsnkEh6czmuyAbsFV8pm0HRBc4iR21hMXj0o5Za8VA=.c455e261-03b5-4bd7-8b88-0fff84c20e85@github.com>
 <yWtKl2uvn5MZTKXzjBrZBhXf-slKdGI1DjBZxBJaTws=.01b30893-7395-4e00-aa50-e2c25fd33ba1@github.com>
 <uNnW324l-gBNDcYd0aLLxQRF3G3vZfFeO71Da3oWkTo=.e0b9fa86-c6b5-4c18-8abb-2c69a66dfbf7@github.com>
 <PvQWprLL5osQE6QKlj1lV0-kybWhy4b_oFKk_e34XOg=.8d06d1d6-a006-40cb-923c-5e288310fc3c@github.com>
 <j2NdBB317FgfZGi1tyIpmIlgfYbjWQv_IruuElr2Md0=.cfcc0d39-8ea5-452f-93a2-5a9dffc6e52e@github.com>
Message-ID: <a697625d-6627-a044-c600-c1b6128b0f4c@oracle.com>

On 19/02/2021 2:42 am, Chris Plummer wrote:
> On Thu, 18 Feb 2021 08:58:25 GMT, Lin Zang <lzang at openjdk.org> wrote:
> 
>>> Hi Chris,
>>> I have update the PR to add a new dumpheapext command that could handle more arguments passed from JMap.java.
>>> And I have tested with "jmap -dump:file=dump.bin,noparallel [pid]", with this change, new jmap targeting on old hotspot would print:
>>>
>>> Exception in thread "main" com.sun.tools.attach.AttachOperationFailedException: Operation dumpheapext not recognized!
>>> 	at jdk.attach/sun.tools.attach.VirtualMachineImpl.execute(VirtualMachineImpl.java:227)
>>> 	at jdk.attach/sun.tools.attach.HotSpotVirtualMachine.executeCommand(HotSpotVirtualMachine.java:309)
>>> 	at jdk.jcmd/sun.tools.jmap.JMap.executeCommandForPid(JMap.java:133)
>>> 	at jdk.jcmd/sun.tools.jmap.JMap.dump(JMap.java:262)
>>> 	at jdk.jcmd/sun.tools.jmap.JMap.main(JMap.java:114)
>>>
>>> IMH, one problem is that it doesn't give out the reason clearly that "dumpheapext" is actually caused by new option "noparallel". But I think having this kind of error message is acceptable. Otherwise it seems the choice we left is remove the "parallel/noparallel" for Jmap. What do you think?
>>
>> Dear All,
>>       I am going to create a CSR for the new internal command "dumpheapext", one problem is that seem if a new CSR is created, this PR will depends on 2 CSRs, I am not sure is this reasonable?  Thanks!
> 
> I was thought the plan was for new the `jmap` to detect the error, eat the exception, and retry with the `dumpheap` command (without any `parallel` related option). Or the other option would be to eat the exception and produce an error message saying that the `parallel` option is not supported by the target VM. I don't think the user should be exposed to the "Operation dumpheapext not recognized" message.
> 
>>   I am going to create a CSR for the new internal command "dumpheapext", one problem is that seem if a new CSR is created, this PR will depends on 2 CSRs, I am not sure is this reasonable? Thanks!
> 
> I have no idea if you can add two CSRs to a PR and a CR. If you can, then I see no issue with doing that. If not, we might need to talk to the CSR committee to see how best to handle it.

CSR requests are associated with a JBS issue not a PR. If there exists a 
CSR request for this JBS issue and you are making further changes then 
move the CSR back to draft and update it and re-submit it.

Thanks,
David

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/2261
> 

From cjplummer at openjdk.java.net  Fri Feb 19 04:22:43 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Fri, 19 Feb 2021 04:22:43 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump
In-Reply-To: <j2NdBB317FgfZGi1tyIpmIlgfYbjWQv_IruuElr2Md0=.cfcc0d39-8ea5-452f-93a2-5a9dffc6e52e@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
 <crJcuaqSgYZQCEw2lqGaLpRmCVOXr99P1i5bcnSFpQc=.cb824923-e649-4ecd-ba5b-8d26cb93b265@github.com>
 <esex_demB2ZT0CsAp2WrzNGC_gieM9USGg_fYgmFCAE=.1911dd08-7dcc-4d88-9532-5d670399dd62@github.com>
 <ztN32xTk5joNRB7MhfYMl9zHCfGA1j8bQNu-ke975qc=.4c7ff2a9-2af8-495d-8f22-83e98c2e3221@github.com>
 <oQe3_j7vewkS8wlIuYXRCa_86pI215cFIceztTf5jX0=.d6d6201b-ec15-418e-a73b-e907d9d02607@github.com>
 <oPJ9OfKdD8CTbihLREww1QM2hc3Ckiai0-1OSpkq830=.87c4f119-07c9-471f-8c25-99dcfaad8d11@github.com>
 <ngMsS8jp0GTuqLVGD5k2ZL5AckbFwh8CBj5ec_GaBes=.0c51dacf-b158-4e62-874d-5e9c5a7b5f8e@github.com>
 <JDsbDqJRQ0V_s1SvGBhr3FLu98T2-X51kpkCs8s8vxQ=.fdb2242c-8706-4057-b4aa-084cfcb24166@github.com>
 <cHsGHKQrSqSUKJJ2OIRVUYuKUVOJGH-Pch-aDmoPj64=.88025b63-b0bb-401a-a749-57089ebea3aa@github.com>
 <gnDO9moDHlyHgJCEdcILr-MauRQgQP7I6QE38XZHus0=.4e488aca-8206-4db5-acec-5c029a6328ca@github.com>
 <vN4ZxgYOLsOQLqwyX4fXMJsQ-LM-S5JqeZo
 WdMXzmqc=.dfdc97a5-4838-4f09-9082-e5562c4691e0@github.com>
 <hLyibl3_enSszfZLKP74PE3i_ranX51N3nNiX0F9KoA=.8f2fea52-c394-4612-9c74-d9d975a3c42a@github.com>
 <Gs7-OplIQn5Vtq9vmQ6QXnB3l_XGSwfsagD044OQ2RM=.564b8980-fd3b-4555-864c-33c1b55a9fbd@github.com>
 <ONgCbmqprWaFkq_OtsFB5KBW1KjPIQu7QRaHXFEHOB8=.e1af696f-9e30-4b94-9524-682a14226c74@github.com>
 <sQsnkEh6czmuyAbsFV8pm0HRBc4iR21hMXj0o5Za8VA=.c455e261-03b5-4bd7-8b88-0fff84c20e85@github.com>
 <yWtKl2uvn5MZTKXzjBrZBhXf-slKdGI1DjBZxBJaTws=.01b30893-7395-4e00-aa50-e2c25fd33ba1@github.com>
 <uNnW324l-gBNDcYd0aLLxQRF3G3vZfFeO71Da3oWkTo=.e0b9fa86-c6b5-4c18-8abb-2c69a66dfbf7@github.com>
 <PvQWprLL5osQE6QKlj1lV0-kybWhy4b_oFKk_e34XOg=.8d06d1d6-a006-40cb-923c-5e288310fc3c@github.com>
 <j2NdBB317FgfZGi1tyIpmIlgfYbjWQv_IruuElr2Md0=.cfcc0d39-8ea5-452f-93a2-5a9dffc6e52e@github.com>
Message-ID: <oYxIOURyOxHh1U9LV7YFIeh-J-vj9IbF5jhR1IUMvVQ=.7f54ac95-eea2-441f-8c4b-1fd87011da30@github.com>

On Thu, 18 Feb 2021 16:39:46 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Dear All, 
>>      I am going to create a CSR for the new internal command "dumpheapext", one problem is that seem if a new CSR is created, this PR will depends on 2 CSRs, I am not sure is this reasonable?  Thanks!
>
>>  I am going to create a CSR for the new internal command "dumpheapext", one problem is that seem if a new CSR is created, this PR will depends on 2 CSRs, I am not sure is this reasonable? Thanks!
> 
> I have no idea if you can add two CSRs to a PR and a CR. If you can, then I see no issue with doing that. If not, we might need to talk to the CSR committee to see how best to handle it.

> CSR requests are associated with a JBS issue not a PR. If there exists a CSR request for this JBS issue and you are making further changes then move the CSR back to draft and update it and re-submit it.
>
>Thanks,
>David 

The complexity comes from the fact there there are really two separate features to call out. One is adding the `parallel=<n>` option to `jmap -dump`, and the other is adding the `dumpheapext` command to the attach api. However, they are not really separable since `dumpheapext` is needed in order to support `parallel=<n>`.  We could lump them into one CR and CSR, but it seems this is overloading them a bit. I guess the other option is to try to separate the `dumpeheapext` part and do that first, although it really would serve no purpose until `parallel=<n>` is added.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2261

From mli at openjdk.java.net  Fri Feb 19 05:20:38 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Fri, 19 Feb 2021 05:20:38 GMT
Subject: RFR: JDK-8261034: improve jcmd GC.class_histogram to support
 parallel
In-Reply-To: <vPaS5x8Dsl5iyfwApmU1cMEuzjSbP_l-I60NOd1X9VE=.718c4d1c-6871-4fb6-aa15-306c842e152d@github.com>
References: <VKzVY-01CEXUbQdlKMhDWjtjxUgpxs_6487x232VsAI=.3b9c5d8a-972b-4997-9f75-1951f98e1751@github.com>
 <X_7cTwpI8cxsVTCMi6oe6f1Fy6yPcw7b0-Pa-Ayou2Y=.69cba9c8-f6e4-40b4-a180-3eb79428692b@github.com>
 <EQm4vRIvMgIFwt3dwYO3YTdbCLyQEKjISTt-QudCNbE=.f2366e5b-b9fa-456d-bafa-6531293b2cc2@github.com>
 <gBKEb-EMtCvqvSZiS1ImsYpQg63tg6R8KaizkL-BrlE=.f51a4335-251c-4041-bd71-75ec13f0591d@github.com>
 <v4SsYZMv2DVW2v8KDDDrCMa-JlyDX6Nsa20ue9JZKqs=.2617d216-b696-48c9-b34e-b0a97bb3bf12@github.com>
 <C47zxVTOUeIMyATz4LgWhTZsmZ6Nk5ncQRbgNKSvTxg=.7570353c-862e-428d-b6bf-aed24b461ea9@github.com>
 <oNo87kApGGMUT6MJYpvDAlyjBzza1-GmLNZSwAGrmEc=.d8669c88-6882-4744-8a05-5cadaa48404f@github.com>
 <A-u0xkGoB54J-q4yyOu-fXBqvXkTRLnmje8qh1KUTTE=.75f97621-8e70-4ab4-b54f-f45b37bd84f5@github.com>
 <hZpMlhWW1rB89tC-Wj_DH9R05YcOFOaqkFprf9MwBD4=.755ccfc2-b743-4037-8f0c-69c078937c5e@github.com>
 <-mAEJ8TjIlhEHKFP0ybmVgqjhCIr8YoAz4Q-GilpZgs=.d1b01b4c-3c14-43ad-8203-b1cd4d2f7ad4@github.com>
 <6APNXM7Ih9TxHMNEPD-uOla7-w08UxJeP4e
 f3-f3joA=.77a8b309-1973-471d-87d7-f682b3ebdb32@github.com>
 <L8t5llrzyxpof_frsgyaf8jznTCckZF-h0t7rM8eAX8=.bb67bcc3-d8db-45a5-a365-7cc05faf27da@github.com>
 <BX2O5NH7WOa57DlDNDgWefirxYUBT7nsCnPhqjchfs0=.6df0ae15-a16b-4cbe-ba5c-02c10d4c332f@github.com>
 <uIKLse-ugmKBUDcOM37UbZkziorlrzcMFJAZa25eqTE=.9ad0afaa-37e6-4ee1-885a-936c60bfad7f@github.com>
 <Ze8CKZ6Auw1oW4J-XKuMpO7n7NTedBBmj0O2UKrOH6o=.a16e8ebb-1a0b-499b-a913-92375c486d76@github.com>
 <ZXHKiFA6-hVma_2MXvCzHMLUFspOl3coMjZ5-u2LBA4=.adbb69ca-f7e0-4189-8951-8619403cf835@github.com>
 <uYzejCgfjq5-bRCKx7RaZWH1zUPsDjBMFeBVIaM4B7o=.5a71658f-9431-4bcb-bde9-37970fbf6823@github.com>
 <LXv3U99qPkiJQxlV7UHbRMC9cDYwacPbF6pCVsA2jwg=.dd0dce40-490d-438e-905c-f6fc35c040b7@github.com>
 <mA-4bFE2CPUhPK00SY8G9DC9hjU3y_aJsxdMoy5Z9bA=.ab46dfe9-49c9-4bf2-bf42-d3e6ff81a712@github.com>
 <HFeNprAvlRyaSkwWJO7U8n4u9w8YwZpOCs-8ONl1a3o=.cd41fd5c-d90d-4931-a029-7a2156364eda@github.com>
 <jiD1W4vuwLTeiiZZvCYgiEl-w5XPErcvUeYUxZ1G5QA=.a4b665af-f973-4ec2-befb-e40ff332dee8@
 github.com>
 <BdD2NhK4j3NDO6MEPdgBqrjeqoMkLnLNdpY8Msbmt70=.bb352cad-388a-4d65-b672-dc9c3e2133ac@github.com>
 <FIfmotGSNufKVt5sEnmE2UlvdnokbdJbIbxmVlWa868=.623032fb-1a5e-40e4-8f92-e965a1cd381a@github.com>
 <1u3g8qfry7iEGQcvP6fiYy-vaulzJ9rQK1rWVAlR7LU=.4972c8f2-44a7-49b7-83cf-2771c0b16bfb@github.com>
 <vPaS5x8Dsl5iyfwApmU1cMEuzjSbP_l-I60NOd1X9VE=.718c4d1c-6871-4fb6-aa15-306c842e152d@github.com>
Message-ID: <MxbDdxDbM5BzJejZYAEVFQ05T69o1rgML849zugREZY=.a3da781b-9b30-4331-b176-0d455fdd5123@github.com>

On Wed, 17 Feb 2021 04:30:45 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Dear All, 
>>     May I say that we all agreed that "noparallel" is not necessary at present? I think the PR #2519 and related CSR and issue could be all closed.
>
>>  May I say that we all agreed that "noparallel" is not necessary at present? I think the PR #2519 and related CSR and issue could be all closed.
> 
> Yes, assuming we get approval for `dumpheapext`. Unfortunately the email that went out did not get any feedback. Maybe we should just create a CSR for that and see what the CSR committee says.

Hi @plummercj @sspitsyn @linzang 
Thanks for discussion. I understood that currently the final decision is to still use "parallel=<N>" and do not introduce new option "noparallel".
Based on this decision, for jcmd GC.class_historgram, would you mind to double confirm whether currently implementation is fine? I think we only need to refine the words in help doc or CSR, am I right? please kindly correct me if I misunderstand it. :-)
If I'm understanding correctly, would you mind to suggest how should we describe <N>? IMHO, I don't think it's a good idea to expose to much details about the implementation, and it's hard to make its meaning precise. Following is my version:

"Degree of parallelism for heap iteration. "
"0 means let the VM determine the parallelism. "
"1 means use one thread, i.e. disable parallelism. "
"n means ask the VM try best to use n threads, but it's not guaranteed and dependant on the specific implementation and runtime environment. n must be positive."

How do you think about it?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2379

From david.holmes at oracle.com  Fri Feb 19 07:30:31 2021
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 19 Feb 2021 17:30:31 +1000
Subject: RFR: 8252842: Extend jmap to support parallel heap dump
In-Reply-To: <oYxIOURyOxHh1U9LV7YFIeh-J-vj9IbF5jhR1IUMvVQ=.7f54ac95-eea2-441f-8c4b-1fd87011da30@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
 <hLyibl3_enSszfZLKP74PE3i_ranX51N3nNiX0F9KoA=.8f2fea52-c394-4612-9c74-d9d975a3c42a@github.com>
 <Gs7-OplIQn5Vtq9vmQ6QXnB3l_XGSwfsagD044OQ2RM=.564b8980-fd3b-4555-864c-33c1b55a9fbd@github.com>
 <ONgCbmqprWaFkq_OtsFB5KBW1KjPIQu7QRaHXFEHOB8=.e1af696f-9e30-4b94-9524-682a14226c74@github.com>
 <sQsnkEh6czmuyAbsFV8pm0HRBc4iR21hMXj0o5Za8VA=.c455e261-03b5-4bd7-8b88-0fff84c20e85@github.com>
 <yWtKl2uvn5MZTKXzjBrZBhXf-slKdGI1DjBZxBJaTws=.01b30893-7395-4e00-aa50-e2c25fd33ba1@github.com>
 <uNnW324l-gBNDcYd0aLLxQRF3G3vZfFeO71Da3oWkTo=.e0b9fa86-c6b5-4c18-8abb-2c69a66dfbf7@github.com>
 <PvQWprLL5osQE6QKlj1lV0-kybWhy4b_oFKk_e34XOg=.8d06d1d6-a006-40cb-923c-5e288310fc3c@github.com>
 <j2NdBB317FgfZGi1tyIpmIlgfYbjWQv_IruuElr2Md0=.cfcc0d39-8ea5-452f-93a2-5a9dffc6e52e@github.com>
 <oYxIOURyOxHh1U9LV7YFIeh-J-vj9IbF5jhR1IUMvVQ=.7f54ac95-eea2-441f-8c4b-1fd87011da30@github.com>
Message-ID: <fe1db2dd-80ea-fc16-9012-bb3c93c46611@oracle.com>

On 19/02/2021 2:22 pm, Chris Plummer wrote:
> On Thu, 18 Feb 2021 16:39:46 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:
> 
>>> Dear All,
>>>       I am going to create a CSR for the new internal command "dumpheapext", one problem is that seem if a new CSR is created, this PR will depends on 2 CSRs, I am not sure is this reasonable?  Thanks!
>>
>>>   I am going to create a CSR for the new internal command "dumpheapext", one problem is that seem if a new CSR is created, this PR will depends on 2 CSRs, I am not sure is this reasonable? Thanks!
>>
>> I have no idea if you can add two CSRs to a PR and a CR. If you can, then I see no issue with doing that. If not, we might need to talk to the CSR committee to see how best to handle it.
> 
>> CSR requests are associated with a JBS issue not a PR. If there exists a CSR request for this JBS issue and you are making further changes then move the CSR back to draft and update it and re-submit it.
>>
>> Thanks,
>> David
> 
> The complexity comes from the fact there there are really two separate features to call out. One is adding the `parallel=<n>` option to `jmap -dump`, and the other is adding the `dumpheapext` command to the attach api. However, they are not really separable since `dumpheapext` is needed in order to support `parallel=<n>`.  We could lump them into one CR and CSR, but it seems this is overloading them a bit. I guess the other option is to try to separate the `dumpeheapext` part and do that first, although it really would serve no purpose until `parallel=<n>` is added.

A CSR request can cover multiple related changes. Otherwise distinct 
issues and CSR requests is of course fine.

David

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/2261
> 

From lzang at openjdk.java.net  Fri Feb 19 08:00:39 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Fri, 19 Feb 2021 08:00:39 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump
In-Reply-To: <oYxIOURyOxHh1U9LV7YFIeh-J-vj9IbF5jhR1IUMvVQ=.7f54ac95-eea2-441f-8c4b-1fd87011da30@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
 <crJcuaqSgYZQCEw2lqGaLpRmCVOXr99P1i5bcnSFpQc=.cb824923-e649-4ecd-ba5b-8d26cb93b265@github.com>
 <esex_demB2ZT0CsAp2WrzNGC_gieM9USGg_fYgmFCAE=.1911dd08-7dcc-4d88-9532-5d670399dd62@github.com>
 <ztN32xTk5joNRB7MhfYMl9zHCfGA1j8bQNu-ke975qc=.4c7ff2a9-2af8-495d-8f22-83e98c2e3221@github.com>
 <oQe3_j7vewkS8wlIuYXRCa_86pI215cFIceztTf5jX0=.d6d6201b-ec15-418e-a73b-e907d9d02607@github.com>
 <oPJ9OfKdD8CTbihLREww1QM2hc3Ckiai0-1OSpkq830=.87c4f119-07c9-471f-8c25-99dcfaad8d11@github.com>
 <ngMsS8jp0GTuqLVGD5k2ZL5AckbFwh8CBj5ec_GaBes=.0c51dacf-b158-4e62-874d-5e9c5a7b5f8e@github.com>
 <JDsbDqJRQ0V_s1SvGBhr3FLu98T2-X51kpkCs8s8vxQ=.fdb2242c-8706-4057-b4aa-084cfcb24166@github.com>
 <cHsGHKQrSqSUKJJ2OIRVUYuKUVOJGH-Pch-aDmoPj64=.88025b63-b0bb-401a-a749-57089ebea3aa@github.com>
 <gnDO9moDHlyHgJCEdcILr-MauRQgQP7I6QE38XZHus0=.4e488aca-8206-4db5-acec-5c029a6328ca@github.com>
 <vN4ZxgYOLsOQLqwyX4fXMJsQ-LM-S5JqeZo
 WdMXzmqc=.dfdc97a5-4838-4f09-9082-e5562c4691e0@github.com>
 <hLyibl3_enSszfZLKP74PE3i_ranX51N3nNiX0F9KoA=.8f2fea52-c394-4612-9c74-d9d975a3c42a@github.com>
 <Gs7-OplIQn5Vtq9vmQ6QXnB3l_XGSwfsagD044OQ2RM=.564b8980-fd3b-4555-864c-33c1b55a9fbd@github.com>
 <ONgCbmqprWaFkq_OtsFB5KBW1KjPIQu7QRaHXFEHOB8=.e1af696f-9e30-4b94-9524-682a14226c74@github.com>
 <sQsnkEh6czmuyAbsFV8pm0HRBc4iR21hMXj0o5Za8VA=.c455e261-03b5-4bd7-8b88-0fff84c20e85@github.com>
 <yWtKl2uvn5MZTKXzjBrZBhXf-slKdGI1DjBZxBJaTws=.01b30893-7395-4e00-aa50-e2c25fd33ba1@github.com>
 <uNnW324l-gBNDcYd0aLLxQRF3G3vZfFeO71Da3oWkTo=.e0b9fa86-c6b5-4c18-8abb-2c69a66dfbf7@github.com>
 <PvQWprLL5osQE6QKlj1lV0-kybWhy4b_oFKk_e34XOg=.8d06d1d6-a006-40cb-923c-5e288310fc3c@github.com>
 <j2NdBB317FgfZGi1tyIpmIlgfYbjWQv_IruuElr2Md0=.cfcc0d39-8ea5-452f-93a2-5a9dffc6e52e@github.com>
 <oYxIOURyOxHh1U9LV7YFIeh-J-vj9IbF5jhR1IUMvVQ=.7f54ac95-eea2-441f-8c4b-1fd87011da30@github.com>
Message-ID: <jyIyPxSco1SXKnPt7evwvLtjAiM0aiSxo9RDdUlE_ck=.ca13dd99-df82-490d-bfa2-958162aaa3fe@github.com>

On Fri, 19 Feb 2021 04:20:14 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> > CSR requests are associated with a JBS issue not a PR. If there exists a CSR request for this JBS issue and you are making further changes then move the CSR back to draft and update it and re-submit it.
> > Thanks,
> > David
> 
> The complexity comes from the fact there there are really two separate features to call out. One is adding the `parallel=<n>` option to `jmap -dump`, and the other is adding the `dumpheapext` command to the attach api. However, they are not really separable since `dumpheapext` is needed in order to support `parallel=<n>`. We could lump them into one CR and CSR, but it seems this is overloading them a bit. I guess the other option is to try to separate the `dumpeheapext` part and do that first, although it really would serve no purpose until `parallel=<n>` is added.

Hi Chris and David, 

I guess we can create a sub-task of dumpheapext, I have created one(https://bugs.openjdk.java.net/browse/JDK-8261943) and then create a CSR related with it. 
Then we have two CSRs, one for introducing "parallel=" option and one for "dumpheapext" command. And both are fixed in this PR. 
What do you think?

Thanks, 
Lin

-------------

PR: https://git.openjdk.java.net/jdk/pull/2261

From github.com+741251+turbanoff at openjdk.java.net  Fri Feb 19 08:07:42 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Fri, 19 Feb 2021 08:07:42 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v11]
In-Reply-To: <6zhT8ySP8rFE4wV5vva0oKRDSxDnSYYZ-sXAQJ6F_DM=.b83a0f88-7231-4796-a0b5-d51b5950d316@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>
Message-ID: <KKuuOtcyAwZLESU78ZnNaF5LmeoQeWzxj-yO-xCj5ZM=.ea9ff05f-ffea-477f-b7eb-b94df1f186f3@github.com>

On Thu, 18 Feb 2021 19:21:45 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
>>   remove unnecessary file.exists() check
>
> src/java.base/share/classes/sun/security/provider/certpath/X509CertPath.java line 228:
> 
>> 226:         try {
>> 227:             if (is.markSupported() == false) {
>> 228:                 // Copy the entire input stream into an InputStream that does
> 
> I don't think you should remove lines 228-232. These methods are called by methods of CertificateFactory that take InputStream (which may contain a stream of security data) and they are designed such that they try to read one Certificate, CRL, or CertPath from the InputStream and leave the InputStream ready to parse the next structure instead of consuming all of the bytes. Thus they check if the InputStream supports mark in order to try to preserve that behavior. If mark is not supported, then it's ok to use InputStream.readAllBytes, otherwise, leave the stream as-is.

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?

-------------

PR: https://git.openjdk.java.net/jdk/pull/1853

From iklam at openjdk.java.net  Fri Feb 19 08:49:47 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Fri, 19 Feb 2021 08:49:47 GMT
Subject: RFR: 8261998: Remove unused shared entry support from
 utilities/hashtable
In-Reply-To: <49wKLf3cdp0YDVDbUsbRIyV6576RzmT4fqFlIC3BDLU=.301faf2d-ad9b-4c84-8c15-dec7df375bb9@github.com>
References: <49wKLf3cdp0YDVDbUsbRIyV6576RzmT4fqFlIC3BDLU=.301faf2d-ad9b-4c84-8c15-dec7df375bb9@github.com>
Message-ID: <IZc0KBigguT-piU77oVKCnBmu9Zp8bzd8CiFeCS1GXk=.58b42bd3-fec2-4c3d-8c11-082b8dba01f4@github.com>

On Fri, 19 Feb 2021 02:39:20 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this small cleanup in the utilities/hashtable facility.  The
> support for "shared" entries is no longer needed or used, so is being deleted.
> 
> Testing:
> mach5 tier1-4 (some CDS tests are in tier4)

Marked as reviewed by iklam (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2638

From iklam at openjdk.java.net  Fri Feb 19 08:49:47 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Fri, 19 Feb 2021 08:49:47 GMT
Subject: RFR: 8261998: Remove unused shared entry support from
 utilities/hashtable
In-Reply-To: <71z-SnDx5bGZgGxNyQVcKz79eA_Vsg6XEZ_RGNVP1K4=.dd905031-8f45-43ed-9d66-4753d41f34b4@github.com>
References: <49wKLf3cdp0YDVDbUsbRIyV6576RzmT4fqFlIC3BDLU=.301faf2d-ad9b-4c84-8c15-dec7df375bb9@github.com>
 <71z-SnDx5bGZgGxNyQVcKz79eA_Vsg6XEZ_RGNVP1K4=.dd905031-8f45-43ed-9d66-4753d41f34b4@github.com>
Message-ID: <kCQTHFHzOifPacH0yIF6E-Mj0A2qiJj1ExtqvjqV5eU=.314cc87b-5722-4829-ba48-9434a3c97a59@github.com>

On Fri, 19 Feb 2021 02:56:14 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> We might want to share other hashtables like this, like the loader constraint table, but I don't think this will be needed.

CDS used to use Hashtable to store stuff into the archive. It doesn't do that anymore, and has switched to CompactHashtable. So the "shared entry" support in Hashtable can be safely deleted.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2638

From lzang at openjdk.java.net  Fri Feb 19 10:11:14 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Fri, 19 Feb 2021 10:11:14 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump
In-Reply-To: <j2NdBB317FgfZGi1tyIpmIlgfYbjWQv_IruuElr2Md0=.cfcc0d39-8ea5-452f-93a2-5a9dffc6e52e@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
 <crJcuaqSgYZQCEw2lqGaLpRmCVOXr99P1i5bcnSFpQc=.cb824923-e649-4ecd-ba5b-8d26cb93b265@github.com>
 <esex_demB2ZT0CsAp2WrzNGC_gieM9USGg_fYgmFCAE=.1911dd08-7dcc-4d88-9532-5d670399dd62@github.com>
 <ztN32xTk5joNRB7MhfYMl9zHCfGA1j8bQNu-ke975qc=.4c7ff2a9-2af8-495d-8f22-83e98c2e3221@github.com>
 <oQe3_j7vewkS8wlIuYXRCa_86pI215cFIceztTf5jX0=.d6d6201b-ec15-418e-a73b-e907d9d02607@github.com>
 <oPJ9OfKdD8CTbihLREww1QM2hc3Ckiai0-1OSpkq830=.87c4f119-07c9-471f-8c25-99dcfaad8d11@github.com>
 <ngMsS8jp0GTuqLVGD5k2ZL5AckbFwh8CBj5ec_GaBes=.0c51dacf-b158-4e62-874d-5e9c5a7b5f8e@github.com>
 <JDsbDqJRQ0V_s1SvGBhr3FLu98T2-X51kpkCs8s8vxQ=.fdb2242c-8706-4057-b4aa-084cfcb24166@github.com>
 <cHsGHKQrSqSUKJJ2OIRVUYuKUVOJGH-Pch-aDmoPj64=.88025b63-b0bb-401a-a749-57089ebea3aa@github.com>
 <gnDO9moDHlyHgJCEdcILr-MauRQgQP7I6QE38XZHus0=.4e488aca-8206-4db5-acec-5c029a6328ca@github.com>
 <vN4ZxgYOLsOQLqwyX4fXMJsQ-LM-S5JqeZo
 WdMXzmqc=.dfdc97a5-4838-4f09-9082-e5562c4691e0@github.com>
 <hLyibl3_enSszfZLKP74PE3i_ranX51N3nNiX0F9KoA=.8f2fea52-c394-4612-9c74-d9d975a3c42a@github.com>
 <Gs7-OplIQn5Vtq9vmQ6QXnB3l_XGSwfsagD044OQ2RM=.564b8980-fd3b-4555-864c-33c1b55a9fbd@github.com>
 <ONgCbmqprWaFkq_OtsFB5KBW1KjPIQu7QRaHXFEHOB8=.e1af696f-9e30-4b94-9524-682a14226c74@github.com>
 <sQsnkEh6czmuyAbsFV8pm0HRBc4iR21hMXj0o5Za8VA=.c455e261-03b5-4bd7-8b88-0fff84c20e85@github.com>
 <yWtKl2uvn5MZTKXzjBrZBhXf-slKdGI1DjBZxBJaTws=.01b30893-7395-4e00-aa50-e2c25fd33ba1@github.com>
 <uNnW324l-gBNDcYd0aLLxQRF3G3vZfFeO71Da3oWkTo=.e0b9fa86-c6b5-4c18-8abb-2c69a66dfbf7@github.com>
 <PvQWprLL5osQE6QKlj1lV0-kybWhy4b_oFKk_e34XOg=.8d06d1d6-a006-40cb-923c-5e288310fc3c@github.com>
 <j2NdBB317FgfZGi1tyIpmIlgfYbjWQv_IruuElr2Md0=.cfcc0d39-8ea5-452f-93a2-5a9dffc6e52e@github.com>
Message-ID: <WKnoIfU8HeVKc2fx6kbe_jGgPJcvCZcsvUOgtD7B8V4=.b4d33981-1d0b-497e-b3c3-d672a5af18f2@github.com>

On Thu, 18 Feb 2021 16:38:04 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Or the other option would be to eat the exception and produce an error message saying that the `parallel` option is not supported by the target VM. I don't think the user should be exposed to the "Operation dumpheapext not recognized" message.

Hi Chris,
   I prefer this one as it keep consistent with the old version of jmap -dump command when processing "parallel=" option.
   I have updated the PR with the change. 
   Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2261

From lzang at openjdk.java.net  Fri Feb 19 10:11:14 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Fri, 19 Feb 2021 10:11:14 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v9]
In-Reply-To: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
Message-ID: <dXi6t5uSBupnKQKXJkRMnnMvN4ovL0vDzhNTisAYG2k=.4e9ac5da-8608-45ed-b8f6-85b7513583bf@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:

  hide the dumpheapext error message

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2261/files
  - new: https://git.openjdk.java.net/jdk/pull/2261/files/375e6732..1af0e1e2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2261&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2261&range=07-08

  Stats: 10 lines in 1 file changed: 9 ins; 0 del; 1 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  Fri Feb 19 11:25:55 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Fri, 19 Feb 2021 11:25:55 GMT
Subject: RFR: 8257234 : Add gz option to SA jmap to write a gzipped heap
 dump [v20]
In-Reply-To: <oGY-ppesG-r0OhxPxXkiK5TIz9flvHj5LB-7DnielCc=.eb6b75b6-5799-4d54-9e38-c72e2aa009b8@github.com>
References: <oTMRc7LWvx9_Uov01HPX9UgyEqFmXt_nMG920HUQBIM=.3651754b-e1f1-46f8-9f44-c118a5c56dbe@github.com>
 <G_Lbe4FPO42wiU-W7Y_UkV53JzqVCql2sUWJAFObFm0=.74a3d2a7-fb24-4dc7-bac4-da347b61d98f@github.com>
 <oGY-ppesG-r0OhxPxXkiK5TIz9flvHj5LB-7DnielCc=.eb6b75b6-5799-4d54-9e38-c72e2aa009b8@github.com>
Message-ID: <DrMr1ov79WErpNS4JpDh2Xxv4dAzLw9mY40IrNdiOTE=.04b6b05f-561b-4782-9aa2-63f3c7fbcc27@github.com>

On Wed, 10 Feb 2021 04:23:43 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> Lin Zang has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - fix indentation isue
>>  - fix help message issue and Use ByteBuffer for integer writing
>
> Marked as reviewed by ysuenaga (Reviewer).

Dear @sspitsyn, 
    May I ask your help to approve when it is ok to you and there is no more issues? No hurry, and please surly take your time, I just want to check the status :)  
    Thanks!
Lin

-------------

PR: https://git.openjdk.java.net/jdk/pull/1712

From lzang at openjdk.java.net  Fri Feb 19 14:36:00 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Fri, 19 Feb 2021 14:36:00 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v10]
In-Reply-To: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
Message-ID: <6l7TqqEmupdBa2J8b_NlWif5oVY2SGpu7iKeJMM97ic=.bf63c6e2-878d-4c2a-9a1e-336419c88b58@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 build fail issue on windows

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2261/files
  - new: https://git.openjdk.java.net/jdk/pull/2261/files/1af0e1e2..0301a74d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2261&range=09
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2261&range=08-09

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 mullan at openjdk.java.net  Fri Feb 19 15:05:42 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Fri, 19 Feb 2021 15:05:42 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v11]
In-Reply-To: <KKuuOtcyAwZLESU78ZnNaF5LmeoQeWzxj-yO-xCj5ZM=.ea9ff05f-ffea-477f-b7eb-b94df1f186f3@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>
Message-ID: <fPIf2TG2r9A2gJKfY2q8ifG4fHP7Ed1lHJ1KyExwI-U=.59c5f061-4e65-4db1-8a86-64a97a323b24@github.com>

On Fri, 19 Feb 2021 08:05:06 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/provider/certpath/X509CertPath.java line 228:
>> 
>>> 226:         try {
>>> 227:             if (is.markSupported() == false) {
>>> 228:                 // Copy the entire input stream into an InputStream that does
>> 
>> I don't think you should remove lines 228-232. These methods are called by methods of CertificateFactory that take InputStream (which may contain a stream of security data) and they are designed such that they try to read one Certificate, CRL, or CertPath from the InputStream and leave the InputStream ready to parse the next structure instead of consuming all of the bytes. Thus they check if the InputStream supports mark in order to try to preserve that behavior. If mark is not supported, then it's ok to use InputStream.readAllBytes, otherwise, leave the stream as-is.
>
> 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

-------------

PR: https://git.openjdk.java.net/jdk/pull/1853

From cjplummer at openjdk.java.net  Fri Feb 19 20:03:43 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Fri, 19 Feb 2021 20:03:43 GMT
Subject: RFR: 8257234 : Add gz option to SA jmap to write a gzipped heap
 dump [v20]
In-Reply-To: <G_Lbe4FPO42wiU-W7Y_UkV53JzqVCql2sUWJAFObFm0=.74a3d2a7-fb24-4dc7-bac4-da347b61d98f@github.com>
References: <oTMRc7LWvx9_Uov01HPX9UgyEqFmXt_nMG920HUQBIM=.3651754b-e1f1-46f8-9f44-c118a5c56dbe@github.com>
 <G_Lbe4FPO42wiU-W7Y_UkV53JzqVCql2sUWJAFObFm0=.74a3d2a7-fb24-4dc7-bac4-da347b61d98f@github.com>
Message-ID: <h-29LR29psutzoUwDZpIB96GNtd8BR1q4Vyt3IDbbKA=.534ce2d5-821a-41e2-94eb-9ea409c7fb9f@github.com>

On Wed, 10 Feb 2021 04:04:56 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> 8257234 : Add gz option to SA jmap to write a gzipped heap dump
>
> Lin Zang has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - fix indentation isue
>  - fix help message issue and Use ByteBuffer for integer writing

Marked as reviewed by cjplummer (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1712

From amenkov at openjdk.java.net  Fri Feb 19 20:15:47 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Fri, 19 Feb 2021 20:15:47 GMT
Subject: RFR: 8253940: com/sun/jdi/JdwpAttachTest.java failed with
 "RuntimeException: ERROR: LingeredApp.startApp was able to attach"
Message-ID: <HBuZ978kLXLgllYPgBTv7q9_L9MWcAxkh3oqzw-EC2Y=.03e5f605-978b-472b-a56d-b280c4645242@github.com>

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)

-------------

Commit messages:
 - JDK-8253940

Changes: https://git.openjdk.java.net/jdk/pull/2654/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2654&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8253940
  Stats: 18 lines in 1 file changed: 14 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2654.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2654/head:pull/2654

PR: https://git.openjdk.java.net/jdk/pull/2654

From cjplummer at openjdk.java.net  Fri Feb 19 20:22:40 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Fri, 19 Feb 2021 20:22:40 GMT
Subject: RFR: JDK-8261034: improve jcmd GC.class_histogram to support
 parallel
In-Reply-To: <MxbDdxDbM5BzJejZYAEVFQ05T69o1rgML849zugREZY=.a3da781b-9b30-4331-b176-0d455fdd5123@github.com>
References: <VKzVY-01CEXUbQdlKMhDWjtjxUgpxs_6487x232VsAI=.3b9c5d8a-972b-4997-9f75-1951f98e1751@github.com>
 <X_7cTwpI8cxsVTCMi6oe6f1Fy6yPcw7b0-Pa-Ayou2Y=.69cba9c8-f6e4-40b4-a180-3eb79428692b@github.com>
 <EQm4vRIvMgIFwt3dwYO3YTdbCLyQEKjISTt-QudCNbE=.f2366e5b-b9fa-456d-bafa-6531293b2cc2@github.com>
 <gBKEb-EMtCvqvSZiS1ImsYpQg63tg6R8KaizkL-BrlE=.f51a4335-251c-4041-bd71-75ec13f0591d@github.com>
 <v4SsYZMv2DVW2v8KDDDrCMa-JlyDX6Nsa20ue9JZKqs=.2617d216-b696-48c9-b34e-b0a97bb3bf12@github.com>
 <C47zxVTOUeIMyATz4LgWhTZsmZ6Nk5ncQRbgNKSvTxg=.7570353c-862e-428d-b6bf-aed24b461ea9@github.com>
 <oNo87kApGGMUT6MJYpvDAlyjBzza1-GmLNZSwAGrmEc=.d8669c88-6882-4744-8a05-5cadaa48404f@github.com>
 <A-u0xkGoB54J-q4yyOu-fXBqvXkTRLnmje8qh1KUTTE=.75f97621-8e70-4ab4-b54f-f45b37bd84f5@github.com>
 <hZpMlhWW1rB89tC-Wj_DH9R05YcOFOaqkFprf9MwBD4=.755ccfc2-b743-4037-8f0c-69c078937c5e@github.com>
 <-mAEJ8TjIlhEHKFP0ybmVgqjhCIr8YoAz4Q-GilpZgs=.d1b01b4c-3c14-43ad-8203-b1cd4d2f7ad4@github.com>
 <6APNXM7Ih9TxHMNEPD-uOla7-w08UxJeP4e
 f3-f3joA=.77a8b309-1973-471d-87d7-f682b3ebdb32@github.com>
 <L8t5llrzyxpof_frsgyaf8jznTCckZF-h0t7rM8eAX8=.bb67bcc3-d8db-45a5-a365-7cc05faf27da@github.com>
 <BX2O5NH7WOa57DlDNDgWefirxYUBT7nsCnPhqjchfs0=.6df0ae15-a16b-4cbe-ba5c-02c10d4c332f@github.com>
 <uIKLse-ugmKBUDcOM37UbZkziorlrzcMFJAZa25eqTE=.9ad0afaa-37e6-4ee1-885a-936c60bfad7f@github.com>
 <Ze8CKZ6Auw1oW4J-XKuMpO7n7NTedBBmj0O2UKrOH6o=.a16e8ebb-1a0b-499b-a913-92375c486d76@github.com>
 <ZXHKiFA6-hVma_2MXvCzHMLUFspOl3coMjZ5-u2LBA4=.adbb69ca-f7e0-4189-8951-8619403cf835@github.com>
 <uYzejCgfjq5-bRCKx7RaZWH1zUPsDjBMFeBVIaM4B7o=.5a71658f-9431-4bcb-bde9-37970fbf6823@github.com>
 <LXv3U99qPkiJQxlV7UHbRMC9cDYwacPbF6pCVsA2jwg=.dd0dce40-490d-438e-905c-f6fc35c040b7@github.com>
 <mA-4bFE2CPUhPK00SY8G9DC9hjU3y_aJsxdMoy5Z9bA=.ab46dfe9-49c9-4bf2-bf42-d3e6ff81a712@github.com>
 <HFeNprAvlRyaSkwWJO7U8n4u9w8YwZpOCs-8ONl1a3o=.cd41fd5c-d90d-4931-a029-7a2156364eda@github.com>
 <jiD1W4vuwLTeiiZZvCYgiEl-w5XPErcvUeYUxZ1G5QA=.a4b665af-f973-4ec2-befb-e40ff332dee8@
 github.com>
 <BdD2NhK4j3NDO6MEPdgBqrjeqoMkLnLNdpY8Msbmt70=.bb352cad-388a-4d65-b672-dc9c3e2133ac@github.com>
 <FIfmotGSNufKVt5sEnmE2UlvdnokbdJbIbxmVlWa868=.623032fb-1a5e-40e4-8f92-e965a1cd381a@github.com>
 <1u3g8qfry7iEGQcvP6fiYy-vaulzJ9rQK1rWVAlR7LU=.4972c8f2-44a7-49b7-83cf-2771c0b16bfb@github.com>
 <vPaS5x8Dsl5iyfwApmU1cMEuzjSbP_l-I60NOd1X9VE=.718c4d1c-6871-4fb6-aa15-306c842e152d@github.com>
 <MxbDdxDbM5BzJejZYAEVFQ05T69o1rgML849zugREZY=.a3da781b-9b30-4331-b176-0d455fdd5123@github.com>
Message-ID: <MMfaRF7ay6_yVGOxC6SvO7-b7GwYkMG7r2uIkzfhSJ4=.f8d0457e-bc40-4025-8555-f3921fe9b6d3@github.com>

On Fri, 19 Feb 2021 05:17:43 GMT, Hamlin Li <mli at openjdk.org> wrote:

>"Degree of parallelism for heap iteration. "

How about "Number of parallel threads to use for heap inspection". I've noticed the term "heap iteration" in a few places, but I think "heap inspection" would be better. That would be inline with terminology used in the source:

 130   VM_GC_HeapInspection(outputStream* out, bool request_full_gc,
 131                        uint parallel_thread_num = 1) :

For the rest of the help:

"0: let the VM determine the number of threads to use. "
"1: use one thread, i.e. disable parallelism. "
"<n>: Request that <n> threads be used. <n> must be positive. The VM will try to use <n> threads, but might use fewer threads than <n>."

-------------

PR: https://git.openjdk.java.net/jdk/pull/2379

From cjplummer at openjdk.java.net  Fri Feb 19 20:25:41 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Fri, 19 Feb 2021 20:25:41 GMT
Subject: RFR: JDK-8261034: improve jcmd GC.class_histogram to support
 parallel
In-Reply-To: <MMfaRF7ay6_yVGOxC6SvO7-b7GwYkMG7r2uIkzfhSJ4=.f8d0457e-bc40-4025-8555-f3921fe9b6d3@github.com>
References: <VKzVY-01CEXUbQdlKMhDWjtjxUgpxs_6487x232VsAI=.3b9c5d8a-972b-4997-9f75-1951f98e1751@github.com>
 <X_7cTwpI8cxsVTCMi6oe6f1Fy6yPcw7b0-Pa-Ayou2Y=.69cba9c8-f6e4-40b4-a180-3eb79428692b@github.com>
 <EQm4vRIvMgIFwt3dwYO3YTdbCLyQEKjISTt-QudCNbE=.f2366e5b-b9fa-456d-bafa-6531293b2cc2@github.com>
 <gBKEb-EMtCvqvSZiS1ImsYpQg63tg6R8KaizkL-BrlE=.f51a4335-251c-4041-bd71-75ec13f0591d@github.com>
 <v4SsYZMv2DVW2v8KDDDrCMa-JlyDX6Nsa20ue9JZKqs=.2617d216-b696-48c9-b34e-b0a97bb3bf12@github.com>
 <C47zxVTOUeIMyATz4LgWhTZsmZ6Nk5ncQRbgNKSvTxg=.7570353c-862e-428d-b6bf-aed24b461ea9@github.com>
 <oNo87kApGGMUT6MJYpvDAlyjBzza1-GmLNZSwAGrmEc=.d8669c88-6882-4744-8a05-5cadaa48404f@github.com>
 <A-u0xkGoB54J-q4yyOu-fXBqvXkTRLnmje8qh1KUTTE=.75f97621-8e70-4ab4-b54f-f45b37bd84f5@github.com>
 <hZpMlhWW1rB89tC-Wj_DH9R05YcOFOaqkFprf9MwBD4=.755ccfc2-b743-4037-8f0c-69c078937c5e@github.com>
 <-mAEJ8TjIlhEHKFP0ybmVgqjhCIr8YoAz4Q-GilpZgs=.d1b01b4c-3c14-43ad-8203-b1cd4d2f7ad4@github.com>
 <6APNXM7Ih9TxHMNEPD-uOla7-w08UxJeP4e
 f3-f3joA=.77a8b309-1973-471d-87d7-f682b3ebdb32@github.com>
 <L8t5llrzyxpof_frsgyaf8jznTCckZF-h0t7rM8eAX8=.bb67bcc3-d8db-45a5-a365-7cc05faf27da@github.com>
 <BX2O5NH7WOa57DlDNDgWefirxYUBT7nsCnPhqjchfs0=.6df0ae15-a16b-4cbe-ba5c-02c10d4c332f@github.com>
 <uIKLse-ugmKBUDcOM37UbZkziorlrzcMFJAZa25eqTE=.9ad0afaa-37e6-4ee1-885a-936c60bfad7f@github.com>
 <Ze8CKZ6Auw1oW4J-XKuMpO7n7NTedBBmj0O2UKrOH6o=.a16e8ebb-1a0b-499b-a913-92375c486d76@github.com>
 <ZXHKiFA6-hVma_2MXvCzHMLUFspOl3coMjZ5-u2LBA4=.adbb69ca-f7e0-4189-8951-8619403cf835@github.com>
 <uYzejCgfjq5-bRCKx7RaZWH1zUPsDjBMFeBVIaM4B7o=.5a71658f-9431-4bcb-bde9-37970fbf6823@github.com>
 <LXv3U99qPkiJQxlV7UHbRMC9cDYwacPbF6pCVsA2jwg=.dd0dce40-490d-438e-905c-f6fc35c040b7@github.com>
 <mA-4bFE2CPUhPK00SY8G9DC9hjU3y_aJsxdMoy5Z9bA=.ab46dfe9-49c9-4bf2-bf42-d3e6ff81a712@github.com>
 <HFeNprAvlRyaSkwWJO7U8n4u9w8YwZpOCs-8ONl1a3o=.cd41fd5c-d90d-4931-a029-7a2156364eda@github.com>
 <jiD1W4vuwLTeiiZZvCYgiEl-w5XPErcvUeYUxZ1G5QA=.a4b665af-f973-4ec2-befb-e40ff332dee8@
 github.com>
 <BdD2NhK4j3NDO6MEPdgBqrjeqoMkLnLNdpY8Msbmt70=.bb352cad-388a-4d65-b672-dc9c3e2133ac@github.com>
 <FIfmotGSNufKVt5sEnmE2UlvdnokbdJbIbxmVlWa868=.623032fb-1a5e-40e4-8f92-e965a1cd381a@github.com>
 <1u3g8qfry7iEGQcvP6fiYy-vaulzJ9rQK1rWVAlR7LU=.4972c8f2-44a7-49b7-83cf-2771c0b16bfb@github.com>
 <vPaS5x8Dsl5iyfwApmU1cMEuzjSbP_l-I60NOd1X9VE=.718c4d1c-6871-4fb6-aa15-306c842e152d@github.com>
 <MxbDdxDbM5BzJejZYAEVFQ05T69o1rgML849zugREZY=.a3da781b-9b30-4331-b176-0d455fdd5123@github.com>
 <MMfaRF7ay6_yVGOxC6SvO7-b7GwYkMG7r2uIkzfhSJ4=.f8d0457e-bc40-4025-8555-f3921fe9b6d3@github.com>
Message-ID: <bNl-kdwPZVRfceE1bR2Lt3nYencF6XHmIJdDUAsjdL8=.da92bc6f-41df-486b-8e8d-f90d764c64aa@github.com>

On Fri, 19 Feb 2021 20:20:19 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Hi @plummercj @sspitsyn @linzang 
>> Thanks for discussion. I understood that currently the final decision is to still use "parallel=<N>" and do not introduce new option "noparallel".
>> Based on this decision, for jcmd GC.class_historgram, would you mind to double confirm whether currently implementation is fine? I think we only need to refine the words in help doc or CSR, am I right? please kindly correct me if I misunderstand it. :-)
>> If I'm understanding correctly, would you mind to suggest how should we describe <N>? IMHO, I don't think it's a good idea to expose to much details about the implementation, and it's hard to make its meaning precise. Following is my version:
>> 
>> "Degree of parallelism for heap iteration. "
>> "0 means let the VM determine the parallelism. "
>> "1 means use one thread, i.e. disable parallelism. "
>> "n means ask the VM try best to use n threads, but it's not guaranteed and dependant on the specific implementation and runtime environment. n must be positive."
>> 
>> How do you think about it?
>
>>"Degree of parallelism for heap iteration. "
> 
> How about "Number of parallel threads to use for heap inspection". I've noticed the term "heap iteration" in a few places, but I think "heap inspection" would be better. That would be inline with terminology used in the source:
> 
>  130   VM_GC_HeapInspection(outputStream* out, bool request_full_gc,
>  131                        uint parallel_thread_num = 1) :
> 
> For the rest of the help:
> 
> "0: let the VM determine the number of threads to use. "
> "1: use one thread, i.e. disable parallelism. "
> "<n>: Request that <n> threads be used. <n> must be positive. The VM will try to use <n> threads, but might use fewer threads than <n>."

BTW, we have three PRs related to `parallel=<n>`. I think it would be best to hold off pushing any of them until they have all been reviewed and approved. One reason is because the `parallel=<n>` output should be consistent for all of them, and if there is a minor suggestion for a change in one, it should be applied to all 3.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2379

From cjplummer at openjdk.java.net  Fri Feb 19 20:53:40 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Fri, 19 Feb 2021 20:53:40 GMT
Subject: RFR: 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: <AC46OpIxGuIORecs2S67penPE6gLlg1u5KoD5x9Ahjs=.dd6d351c-1d96-43a6-8353-264229ef383c@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)

test/jdk/com/sun/jdi/JdwpAttachTest.java line 88:

> 86: 
> 87:         // by using "localhost" or empty hostname
> 88:         // we should be able to attach to both IPv4 and IPv6 addresses (127.0.0.1 & ::1).

As long as you're touching this comment, start it with "By" and put more of the comment on the first line.

Also, the comment is a bit misleading now. You can attach to both, but you only try the one that is preferred.

test/jdk/com/sun/jdi/JdwpAttachTest.java line 180:

> 178:     // loopback address.
> 179:     // The method checks if the address is safe to test with current network config.
> 180:     private static boolean addressIfSafeToConnectToLocalhost(InetAddress addr) {

Do you really mean to name it "addressIfSafe..." rather than "addressIsSafe..."?

test/jdk/com/sun/jdi/JdwpAttachTest.java line 178:

> 176:     // Attach to localhost tries to connect to both IPv4 and IPv6 loopback addresses.
> 177:     // But sometimes it causes interference with other processes which can listen on the same port but different
> 178:     // loopback address.

Move a few words from the end of the 2nd line of the comment down to the 3rd.

test/jdk/com/sun/jdi/JdwpAttachTest.java line 183:

> 181:         boolean ipv6 = Boolean.parseBoolean(System.getProperty("java.net.preferIPv6Addresses"));
> 182:         return ipv6 == (addr instanceof Inet6Address);
> 183:     }

In the CR you said:

> But JDI framework respects "java.net.preferIPv6Addresses" system property (which by default is false), so connecting to empty host tries IPv4 addresses 1st and tries IPv6 addresses only if connect to IPv4 failed. 

Are you referring to the JDI implementation, or the JDI test framework. In any case, I had trouble locating this anywhere in the source.

Also, "preferv6" doesn't mean that's what it ends up using. It just tries v6 first before deferring to v4 if v6 fails (or the opposite if it doesn't prefer v6). I don't think you are capturing that part of the logic. What happens if preferv6 is true but the connect to a v6 port fails. Should the test try to connect to the v4 in that case?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2654

From cjplummer at openjdk.java.net  Fri Feb 19 21:02:45 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Fri, 19 Feb 2021 21:02:45 GMT
Subject: RFR: 8261710: SA DSO objects have sizes that are too large [v4]
In-Reply-To: <KtbKpVu273Kz9u1RpRPvwOH6DBgXIJyJXIlHPqHsi2U=.84f275e4-0123-4dd2-97ba-c2021faeccac@github.com>
References: <rtxSvuvKLmHKrLtsnxf76vSK41b_HWPR_7Bn3wf9YuM=.cf1b54ae-f01d-48d5-9641-d7d9faa541f5@github.com>
 <-tUjqHsXhVl31QRbblNj5TjV6BVOOLtl6dmXjzVFheo=.498514c8-d0f8-4081-a036-1f9114a6a9c3@github.com>
 <ZpQrDMQXuzEUbe5qhXvKPi1fKgmWnz1n_gCpYxPib-M=.b365c936-b8d2-4115-92dd-4e117248f14c@github.com>
 <KtbKpVu273Kz9u1RpRPvwOH6DBgXIJyJXIlHPqHsi2U=.84f275e4-0123-4dd2-97ba-c2021faeccac@github.com>
Message-ID: <RA4wgKJxRelMOnsGQN8APbj0c5Ldc7j_mCq0ypE50cg=.3e5fd8e8-6ae6-4f09-a6f0-3e1d06c3f2f9@github.com>

On Thu, 18 Feb 2021 02:58:55 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> Hi Yasumasa,
>> 
>> Just some comments.
>> 
>> src/jdk.hotspot.agent/linux/native/libsaproc/libproc_impl.c
>> +static inline uintptr_t align_down(uintptr_t ptr, size_t size) {
>> +  return (ptr & ~(size - 1));
>> +}
>> +
>> +static inline uintptr_t align_up(uintptr_t ptr, size_t size) {
>> +  return ((ptr + size - 1) & ~(size - 1));
>> +}
>> 
>> The name of 'size' parameter is confusing. Should it be renamed to something like page_size of psize?
>> 
>> +  lib->end = (uintptr_t)-1L;
>> . . .
>> +      if ((lib->end == (uintptr_t)-1L) || (lib->end < aligned_end)) {
>> +        lib->end = aligned_end;
>>        }
>>  
>> The condition  `(lib->end == (uintptr_t)-1L)` is a subset of `(lib->end < aligned_end)`, and so, can be removed. The same is true for the condition:
>> +        if ((lib->exec_end == (uintptr_t)-1L) || (lib->exec_end < aligned_end)) {
>> +          lib->exec_end = aligned_end;
>> +        }
>> 
>> `+      print_debug("%s [%d] 0x%lx-0x%lx: base = 0x%lx, vaddr = 0x%lx, memsz = 0x%lx, filesz = 0x%lx\n", lib->name, cnt, aligned_start, aligned_end, lib->base, ph->p_vaddr, ph->p_memsz, ph->p_filesz);`
>> 
>> It is better to split this long line.
>> 
>> Thanks,
>> Serguei
>
> Thanks @sspitsyn for the comment!
> I fixed almost of your comment in new commit.
> 
>> The condition `(lib->end == (uintptr_t)-1L)` is a subset of `(lib->end < aligned_end)`, and so, can be removed. The same is true for the condition:
> 
> `lib->end` is declared as unsigned (`uintptr_t`), so we can't use `(lib->end < aligned_end)` when `lib->end` is set to -1.

BTW, one way to test these changes might be to do a `clhsdb pmap` and then do a `findpc` on the last address of each library's map (should find a symbol) and the first address after the map (should not find a symbol unless that happens to be the start of the next mapped library). I'm not sure if this will always work. It's possible that no symbol covers the very end of the map, especially due to page alignment. Maybe try the first address of the last page then. I'm not necessarily suggesting you write a test that does this, but maybe just do a bit of experimenting as a sanity check.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2563

From chris.plummer at oracle.com  Fri Feb 19 21:18:48 2021
From: chris.plummer at oracle.com (Chris Plummer)
Date: Fri, 19 Feb 2021 13:18:48 -0800
Subject: Ping! for a few PRs
Message-ID: <429c76b5-6ea9-8775-04ae-210934ae38c5@oracle.com>

Hi All,

I have 4 PRs that need reviewing. For the most part they are pretty 
simple and some already have one review. Can I get some volunteers 
please? I would especially like to get the first two pushed since they 
are causing frequent failures in our CI testing.

https://github.com/openjdk/jdk/pull/2637
8261929: ClhsdbFindPC fails with java.lang.RuntimeException: 'In java 
stack' missing from stdout/stderr

https://github.com/openjdk/jdk/pull/2624
8261857: serviceability/sa/ClhsdbPrintAll.java failed with "Test ERROR 
java.lang.RuntimeException: 'cannot be cast to' found in stdout"

https://github.com/openjdk/jdk/pull/2582
8261269: When using clhsdb to "inspect" a java object, clhsdb prints 
"Oop for..." twice

https://github.com/openjdk/jdk/pull/2565
8261692: Bugs in clhsdb history support

thanks!

Chris

From amenkov at openjdk.java.net  Fri Feb 19 23:05:00 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Fri, 19 Feb 2021 23:05:00 GMT
Subject: RFR: 8253940: com/sun/jdi/JdwpAttachTest.java failed with
 "RuntimeException: ERROR: LingeredApp.startApp was able to attach" [v2]
In-Reply-To: <AC46OpIxGuIORecs2S67penPE6gLlg1u5KoD5x9Ahjs=.dd6d351c-1d96-43a6-8353-264229ef383c@github.com>
References: <HBuZ978kLXLgllYPgBTv7q9_L9MWcAxkh3oqzw-EC2Y=.03e5f605-978b-472b-a56d-b280c4645242@github.com>
 <AC46OpIxGuIORecs2S67penPE6gLlg1u5KoD5x9Ahjs=.dd6d351c-1d96-43a6-8353-264229ef383c@github.com>
Message-ID: <mxutG2D2Ukm-PvhfSGgeX_VhgOy3EXU_M4kB1NCVo8o=.748067b1-4aac-4b6c-a2ce-5172c273d91e@github.com>

On Fri, 19 Feb 2021 20:30:19 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
>
> test/jdk/com/sun/jdi/JdwpAttachTest.java line 180:
> 
>> 178:     // loopback address.
>> 179:     // The method checks if the address is safe to test with current network config.
>> 180:     private static boolean addressIfSafeToConnectToLocalhost(InetAddress addr) {
> 
> Do you really mean to name it "addressIfSafe..." rather than "addressIsSafe..."?

Correct. Fixed.

> test/jdk/com/sun/jdi/JdwpAttachTest.java line 178:
> 
>> 176:     // Attach to localhost tries to connect to both IPv4 and IPv6 loopback addresses.
>> 177:     // But sometimes it causes interference with other processes which can listen on the same port but different
>> 178:     // loopback address.
> 
> Move a few words from the end of the 2nd line of the comment down to the 3rd.

Done.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2654

From amenkov at openjdk.java.net  Fri Feb 19 23:04:59 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Fri, 19 Feb 2021 23:04:59 GMT
Subject: RFR: 8253940: com/sun/jdi/JdwpAttachTest.java failed with
 "RuntimeException: ERROR: LingeredApp.startApp was able to attach" [v2]
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: <hxbQJ5saY9Matb6No5O-nBHXYiLGj6Ius17Yt4fABhc=.92ee0ccd-01b7-4010-82c3-6308cf043b59@github.com>

> 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

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2654/files
  - new: https://git.openjdk.java.net/jdk/pull/2654/files/fe12d328..2cf7031a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2654&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2654&range=00-01

  Stats: 8 lines in 1 file changed: 2 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2654.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2654/head:pull/2654

PR: https://git.openjdk.java.net/jdk/pull/2654

From amenkov at openjdk.java.net  Fri Feb 19 23:56:39 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Fri, 19 Feb 2021 23:56:39 GMT
Subject: RFR: 8253940: com/sun/jdi/JdwpAttachTest.java failed with
 "RuntimeException: ERROR: LingeredApp.startApp was able to attach" [v2]
In-Reply-To: <AC46OpIxGuIORecs2S67penPE6gLlg1u5KoD5x9Ahjs=.dd6d351c-1d96-43a6-8353-264229ef383c@github.com>
References: <HBuZ978kLXLgllYPgBTv7q9_L9MWcAxkh3oqzw-EC2Y=.03e5f605-978b-472b-a56d-b280c4645242@github.com>
 <AC46OpIxGuIORecs2S67penPE6gLlg1u5KoD5x9Ahjs=.dd6d351c-1d96-43a6-8353-264229ef383c@github.com>
Message-ID: <6hdDjQwkBSQvhHi4nd-cBZGz0CbJMYqspF1WrF3PXks=.ef7700cd-69a6-48af-b947-8729eb3e010a@github.com>

On Fri, 19 Feb 2021 20:50:58 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> In the CR you said:
> 
> > But JDI framework respects "java.net.preferIPv6Addresses" system property (which by default is false), so connecting to empty host tries IPv4 addresses 1st and tries IPv6 addresses only if connect to IPv4 failed.
> 
> Are you referring to the JDI implementation, or the JDI test framework. In any case, I had trouble locating this anywhere in the source.

This is about JDI implementation (the test uses JDWP agent to attach - corresponding code is at src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c)

> Also, "preferv6" doesn't mean that's what it ends up using. It just tries v6 first before deferring to v4 if v6 fails (or the opposite if it doesn't prefer v6). I don't think you are capturing that part of the logic. What happens if preferv6 is true but the connect to a v6 port fails. Should the test try to connect to the v4 in that case?

Well. Lets consider the case when we have both IPv4 and IPv6 loopback addresses and "preferv6" is true (for "preferv6" == false it works opposite).
The test does:
1. - listen on IPv6 loopback ("::1")
   - tries to attach to localhost
     JDI 1st tries IPv6, which is expected to succeed. If it fails, that means the test should fail too. Theoretically in the case test can successfully attach to some other process which listens on the same port IPv4 loopback, but we expect the test to pass :)
2. - listen on IPv4 loopback (127.0.0.1)
   - tries to attach to localhost.
      JDI 1st tries IPv6, which is expected to fail, but if there is some other process which listens on the same port on IPv6 loopback, we get the error like described in the issue (handshake failure)

So the logic is to test 1 and skip 2

-------------

PR: https://git.openjdk.java.net/jdk/pull/2654

From amenkov at openjdk.java.net  Sat Feb 20 00:22:39 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Sat, 20 Feb 2021 00:22:39 GMT
Subject: RFR: 8261929: ClhsdbFindPC fails with java.lang.RuntimeException:
 'In java stack' missing from stdout/stderr
In-Reply-To: <yNakPYlp6Q6YF6NB6db7IyAhAqMvgUc9dq6p6CAJJYU=.41bdf544-1b81-4a90-a3a7-e3207fb1fc9d@github.com>
References: <yNakPYlp6Q6YF6NB6db7IyAhAqMvgUc9dq6p6CAJJYU=.41bdf544-1b81-4a90-a3a7-e3207fb1fc9d@github.com>
Message-ID: <gPQ0k7qEtiXI_FaiibNjdlKfXZ4v4aNEAZuh1Uy5e-U=.b2e2b7a9-b978-4772-9f30-faa3e084d732@github.com>

On Fri, 19 Feb 2021 01:04:20 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Sometimes due to the state of the java thread, jstack does cannot determine the address of the java frame and instead it is 0x. We need to special case this so the test does not fail.

Marked as reviewed by amenkov (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2637

From mli at openjdk.java.net  Sat Feb 20 00:50:39 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Sat, 20 Feb 2021 00:50:39 GMT
Subject: RFR: JDK-8261034: improve jcmd GC.class_histogram to support
 parallel
In-Reply-To: <bNl-kdwPZVRfceE1bR2Lt3nYencF6XHmIJdDUAsjdL8=.da92bc6f-41df-486b-8e8d-f90d764c64aa@github.com>
References: <VKzVY-01CEXUbQdlKMhDWjtjxUgpxs_6487x232VsAI=.3b9c5d8a-972b-4997-9f75-1951f98e1751@github.com>
 <X_7cTwpI8cxsVTCMi6oe6f1Fy6yPcw7b0-Pa-Ayou2Y=.69cba9c8-f6e4-40b4-a180-3eb79428692b@github.com>
 <EQm4vRIvMgIFwt3dwYO3YTdbCLyQEKjISTt-QudCNbE=.f2366e5b-b9fa-456d-bafa-6531293b2cc2@github.com>
 <gBKEb-EMtCvqvSZiS1ImsYpQg63tg6R8KaizkL-BrlE=.f51a4335-251c-4041-bd71-75ec13f0591d@github.com>
 <v4SsYZMv2DVW2v8KDDDrCMa-JlyDX6Nsa20ue9JZKqs=.2617d216-b696-48c9-b34e-b0a97bb3bf12@github.com>
 <C47zxVTOUeIMyATz4LgWhTZsmZ6Nk5ncQRbgNKSvTxg=.7570353c-862e-428d-b6bf-aed24b461ea9@github.com>
 <oNo87kApGGMUT6MJYpvDAlyjBzza1-GmLNZSwAGrmEc=.d8669c88-6882-4744-8a05-5cadaa48404f@github.com>
 <A-u0xkGoB54J-q4yyOu-fXBqvXkTRLnmje8qh1KUTTE=.75f97621-8e70-4ab4-b54f-f45b37bd84f5@github.com>
 <hZpMlhWW1rB89tC-Wj_DH9R05YcOFOaqkFprf9MwBD4=.755ccfc2-b743-4037-8f0c-69c078937c5e@github.com>
 <-mAEJ8TjIlhEHKFP0ybmVgqjhCIr8YoAz4Q-GilpZgs=.d1b01b4c-3c14-43ad-8203-b1cd4d2f7ad4@github.com>
 <6APNXM7Ih9TxHMNEPD-uOla7-w08UxJeP4e
 f3-f3joA=.77a8b309-1973-471d-87d7-f682b3ebdb32@github.com>
 <L8t5llrzyxpof_frsgyaf8jznTCckZF-h0t7rM8eAX8=.bb67bcc3-d8db-45a5-a365-7cc05faf27da@github.com>
 <BX2O5NH7WOa57DlDNDgWefirxYUBT7nsCnPhqjchfs0=.6df0ae15-a16b-4cbe-ba5c-02c10d4c332f@github.com>
 <uIKLse-ugmKBUDcOM37UbZkziorlrzcMFJAZa25eqTE=.9ad0afaa-37e6-4ee1-885a-936c60bfad7f@github.com>
 <Ze8CKZ6Auw1oW4J-XKuMpO7n7NTedBBmj0O2UKrOH6o=.a16e8ebb-1a0b-499b-a913-92375c486d76@github.com>
 <ZXHKiFA6-hVma_2MXvCzHMLUFspOl3coMjZ5-u2LBA4=.adbb69ca-f7e0-4189-8951-8619403cf835@github.com>
 <uYzejCgfjq5-bRCKx7RaZWH1zUPsDjBMFeBVIaM4B7o=.5a71658f-9431-4bcb-bde9-37970fbf6823@github.com>
 <LXv3U99qPkiJQxlV7UHbRMC9cDYwacPbF6pCVsA2jwg=.dd0dce40-490d-438e-905c-f6fc35c040b7@github.com>
 <mA-4bFE2CPUhPK00SY8G9DC9hjU3y_aJsxdMoy5Z9bA=.ab46dfe9-49c9-4bf2-bf42-d3e6ff81a712@github.com>
 <HFeNprAvlRyaSkwWJO7U8n4u9w8YwZpOCs-8ONl1a3o=.cd41fd5c-d90d-4931-a029-7a2156364eda@github.com>
 <jiD1W4vuwLTeiiZZvCYgiEl-w5XPErcvUeYUxZ1G5QA=.a4b665af-f973-4ec2-befb-e40ff332dee8@
 github.com>
 <BdD2NhK4j3NDO6MEPdgBqrjeqoMkLnLNdpY8Msbmt70=.bb352cad-388a-4d65-b672-dc9c3e2133ac@github.com>
 <FIfmotGSNufKVt5sEnmE2UlvdnokbdJbIbxmVlWa868=.623032fb-1a5e-40e4-8f92-e965a1cd381a@github.com>
 <1u3g8qfry7iEGQcvP6fiYy-vaulzJ9rQK1rWVAlR7LU=.4972c8f2-44a7-49b7-83cf-2771c0b16bfb@github.com>
 <vPaS5x8Dsl5iyfwApmU1cMEuzjSbP_l-I60NOd1X9VE=.718c4d1c-6871-4fb6-aa15-306c842e152d@github.com>
 <MxbDdxDbM5BzJejZYAEVFQ05T69o1rgML849zugREZY=.a3da781b-9b30-4331-b176-0d455fdd5123@github.com>
 <MMfaRF7ay6_yVGOxC6SvO7-b7GwYkMG7r2uIkzfhSJ4=.f8d0457e-bc40-4025-8555-f3921fe9b6d3@github.com>
 <bNl-kdwPZVRfceE1bR2Lt3nYencF6XHmIJdDUAsjdL8=.da92bc6f-41df-486b-8e8d-f90d764c64aa@github.com>
Message-ID: <lcOubi8bD8nfjs6CyZ_VVq__wlq1md0-kgKam76Ibwo=.6c10a867-9b3a-4c7b-b460-cdfd278a23f1@github.com>

On Fri, 19 Feb 2021 20:23:01 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> BTW, we have three PRs related to `parallel=<n>`. I think it would be best to hold off pushing any of them until they have all been reviewed and approved. One reason is because the `parallel=<n>` output should be consistent for all of them, and if there is a minor suggestion for a change in one, it should be applied to all 3.

Sure, will hold off.
Summarize the help messages as below:
"Number of parallel threads to use for heap inspection. "
"0: let the VM determine the number of threads to use. "
"1: use one thread, i.e. disable parallelism. "
"n: Request that threads be used. n must be positive. The VM will try to use n threads, but might use fewer threads than n."

-------------

PR: https://git.openjdk.java.net/jdk/pull/2379

From kbarrett at openjdk.java.net  Sat Feb 20 02:57:40 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Sat, 20 Feb 2021 02:57:40 GMT
Subject: RFR: 8261998: Remove unused shared entry support from
 utilities/hashtable
In-Reply-To: <71z-SnDx5bGZgGxNyQVcKz79eA_Vsg6XEZ_RGNVP1K4=.dd905031-8f45-43ed-9d66-4753d41f34b4@github.com>
References: <49wKLf3cdp0YDVDbUsbRIyV6576RzmT4fqFlIC3BDLU=.301faf2d-ad9b-4c84-8c15-dec7df375bb9@github.com>
 <71z-SnDx5bGZgGxNyQVcKz79eA_Vsg6XEZ_RGNVP1K4=.dd905031-8f45-43ed-9d66-4753d41f34b4@github.com>
Message-ID: <K0-I7cZo1l53YzsDX8rTGANDlY89zqLcqY3LAoisozQ=.077c0678-1714-4666-b274-3cdd4f339274@github.com>

On Fri, 19 Feb 2021 02:56:14 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this small cleanup in the utilities/hashtable facility.  The
>> support for "shared" entries is no longer needed or used, so is being deleted.
>> 
>> Testing:
>> mach5 tier1-4 (some CDS tests are in tier4)
>
> We might want to share other hashtables like this, like the loader constraint table, but I don't think this will be needed.

Thanks @coleenp and @iklam for reviews.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2638

From kbarrett at openjdk.java.net  Sat Feb 20 03:05:59 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Sat, 20 Feb 2021 03:05:59 GMT
Subject: Integrated: 8261998: Remove unused shared entry support from
 utilities/hashtable
In-Reply-To: <49wKLf3cdp0YDVDbUsbRIyV6576RzmT4fqFlIC3BDLU=.301faf2d-ad9b-4c84-8c15-dec7df375bb9@github.com>
References: <49wKLf3cdp0YDVDbUsbRIyV6576RzmT4fqFlIC3BDLU=.301faf2d-ad9b-4c84-8c15-dec7df375bb9@github.com>
Message-ID: <flYG4nUYHpSNgSRKHNCL_lNcV8BdIboz_zgRY_O31hc=.9b1d86a6-9786-448a-9603-e13694709c31@github.com>

On Fri, 19 Feb 2021 02:39:20 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this small cleanup in the utilities/hashtable facility.  The
> support for "shared" entries is no longer needed or used, so is being deleted.
> 
> Testing:
> mach5 tier1-4 (some CDS tests are in tier4)

This pull request has now been integrated.

Changeset: 5a25cea5
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5a25cea5
Stats:     28 lines in 3 files changed: 0 ins; 23 del; 5 mod

8261998: Remove unused shared entry support from utilities/hashtable

Reviewed-by: coleenp, iklam

-------------

PR: https://git.openjdk.java.net/jdk/pull/2638

From kbarrett at openjdk.java.net  Sat Feb 20 03:05:58 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Sat, 20 Feb 2021 03:05:58 GMT
Subject: RFR: 8261998: Remove unused shared entry support from
 utilities/hashtable [v2]
In-Reply-To: <49wKLf3cdp0YDVDbUsbRIyV6576RzmT4fqFlIC3BDLU=.301faf2d-ad9b-4c84-8c15-dec7df375bb9@github.com>
References: <49wKLf3cdp0YDVDbUsbRIyV6576RzmT4fqFlIC3BDLU=.301faf2d-ad9b-4c84-8c15-dec7df375bb9@github.com>
Message-ID: <iBuBnzr0G8FJGpKFCQuED3ODsTN_0dsZp_MvvPNpOHY=.1811d1f7-3ef5-4415-953c-67f895791632@github.com>

> Please review this small cleanup in the utilities/hashtable facility.  The
> support for "shared" entries is no longer needed or used, so is being deleted.
> 
> Testing:
> mach5 tier1-4 (some CDS tests are in tier4)

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 two additional commits since the last revision:

 - Merge branch 'master' into ht_shared
 - remove shared entry support

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2638/files
  - new: https://git.openjdk.java.net/jdk/pull/2638/files/4ebdd71a..bf811b54

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2638&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2638&range=00-01

  Stats: 3323 lines in 88 files changed: 2061 ins; 627 del; 635 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2638.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2638/head:pull/2638

PR: https://git.openjdk.java.net/jdk/pull/2638

From cjplummer at openjdk.java.net  Sat Feb 20 03:08:39 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Sat, 20 Feb 2021 03:08:39 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: <HbKTNw-y04gUU47FKLdMn_EapfXk_pF1ova7pzt4JiY=.c91bd739-3b40-4681-a93b-a2bb15f971da@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 cjplummer (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2654

From cjplummer at openjdk.java.net  Sat Feb 20 03:08:40 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Sat, 20 Feb 2021 03:08:40 GMT
Subject: RFR: 8253940: com/sun/jdi/JdwpAttachTest.java failed with
 "RuntimeException: ERROR: LingeredApp.startApp was able to attach" [v2]
In-Reply-To: <6hdDjQwkBSQvhHi4nd-cBZGz0CbJMYqspF1WrF3PXks=.ef7700cd-69a6-48af-b947-8729eb3e010a@github.com>
References: <HBuZ978kLXLgllYPgBTv7q9_L9MWcAxkh3oqzw-EC2Y=.03e5f605-978b-472b-a56d-b280c4645242@github.com>
 <AC46OpIxGuIORecs2S67penPE6gLlg1u5KoD5x9Ahjs=.dd6d351c-1d96-43a6-8353-264229ef383c@github.com>
 <6hdDjQwkBSQvhHi4nd-cBZGz0CbJMYqspF1WrF3PXks=.ef7700cd-69a6-48af-b947-8729eb3e010a@github.com>
Message-ID: <nzie9k2igMhGtAWDlawrT3n6yXidKEC6AnBkZSO-PIA=.bf858128-30d5-4849-966c-5943586fcf28@github.com>

On Fri, 19 Feb 2021 23:54:11 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> test/jdk/com/sun/jdi/JdwpAttachTest.java line 183:
>> 
>>> 181:         boolean ipv6 = Boolean.parseBoolean(System.getProperty("java.net.preferIPv6Addresses"));
>>> 182:         return ipv6 == (addr instanceof Inet6Address);
>>> 183:     }
>> 
>> In the CR you said:
>> 
>>> But JDI framework respects "java.net.preferIPv6Addresses" system property (which by default is false), so connecting to empty host tries IPv4 addresses 1st and tries IPv6 addresses only if connect to IPv4 failed. 
>> 
>> Are you referring to the JDI implementation, or the JDI test framework. In any case, I had trouble locating this anywhere in the source.
>> 
>> Also, "preferv6" doesn't mean that's what it ends up using. It just tries v6 first before deferring to v4 if v6 fails (or the opposite if it doesn't prefer v6). I don't think you are capturing that part of the logic. What happens if preferv6 is true but the connect to a v6 port fails. Should the test try to connect to the v4 in that case?
>
>> In the CR you said:
>> 
>> > But JDI framework respects "java.net.preferIPv6Addresses" system property (which by default is false), so connecting to empty host tries IPv4 addresses 1st and tries IPv6 addresses only if connect to IPv4 failed.
>> 
>> Are you referring to the JDI implementation, or the JDI test framework. In any case, I had trouble locating this anywhere in the source.
> 
> This is about JDI implementation (the test uses JDWP agent to attach - corresponding code is at src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c)
> 
>> Also, "preferv6" doesn't mean that's what it ends up using. It just tries v6 first before deferring to v4 if v6 fails (or the opposite if it doesn't prefer v6). I don't think you are capturing that part of the logic. What happens if preferv6 is true but the connect to a v6 port fails. Should the test try to connect to the v4 in that case?
> 
> Well. Lets consider the case when we have both IPv4 and IPv6 loopback addresses and "preferv6" is true (for "preferv6" == false it works opposite).
> The test does:
> 1. - listen on IPv6 loopback ("::1")
>    - tries to attach to localhost
>      JDI 1st tries IPv6, which is expected to succeed. If it fails, that means the test should fail too. Theoretically in the case test can successfully attach to some other process which listens on the same port IPv4 loopback, but we expect the test to pass :)
> 2. - listen on IPv4 loopback (127.0.0.1)
>    - tries to attach to localhost.
>       JDI 1st tries IPv6, which is expected to fail, but if there is some other process which listens on the same port on IPv6 loopback, we get the error like described in the issue (handshake failure)
> 
> So the logic is to test 1 and skip 2

Ok, that makes sense. Thanks

-------------

PR: https://git.openjdk.java.net/jdk/pull/2654

From cjplummer at openjdk.java.net  Sat Feb 20 03:29:41 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Sat, 20 Feb 2021 03:29:41 GMT
Subject: RFR: JDK-8261034: improve jcmd GC.class_histogram to support
 parallel
In-Reply-To: <lcOubi8bD8nfjs6CyZ_VVq__wlq1md0-kgKam76Ibwo=.6c10a867-9b3a-4c7b-b460-cdfd278a23f1@github.com>
References: <VKzVY-01CEXUbQdlKMhDWjtjxUgpxs_6487x232VsAI=.3b9c5d8a-972b-4997-9f75-1951f98e1751@github.com>
 <X_7cTwpI8cxsVTCMi6oe6f1Fy6yPcw7b0-Pa-Ayou2Y=.69cba9c8-f6e4-40b4-a180-3eb79428692b@github.com>
 <EQm4vRIvMgIFwt3dwYO3YTdbCLyQEKjISTt-QudCNbE=.f2366e5b-b9fa-456d-bafa-6531293b2cc2@github.com>
 <gBKEb-EMtCvqvSZiS1ImsYpQg63tg6R8KaizkL-BrlE=.f51a4335-251c-4041-bd71-75ec13f0591d@github.com>
 <v4SsYZMv2DVW2v8KDDDrCMa-JlyDX6Nsa20ue9JZKqs=.2617d216-b696-48c9-b34e-b0a97bb3bf12@github.com>
 <C47zxVTOUeIMyATz4LgWhTZsmZ6Nk5ncQRbgNKSvTxg=.7570353c-862e-428d-b6bf-aed24b461ea9@github.com>
 <oNo87kApGGMUT6MJYpvDAlyjBzza1-GmLNZSwAGrmEc=.d8669c88-6882-4744-8a05-5cadaa48404f@github.com>
 <A-u0xkGoB54J-q4yyOu-fXBqvXkTRLnmje8qh1KUTTE=.75f97621-8e70-4ab4-b54f-f45b37bd84f5@github.com>
 <hZpMlhWW1rB89tC-Wj_DH9R05YcOFOaqkFprf9MwBD4=.755ccfc2-b743-4037-8f0c-69c078937c5e@github.com>
 <-mAEJ8TjIlhEHKFP0ybmVgqjhCIr8YoAz4Q-GilpZgs=.d1b01b4c-3c14-43ad-8203-b1cd4d2f7ad4@github.com>
 <6APNXM7Ih9TxHMNEPD-uOla7-w08UxJeP4e
 f3-f3joA=.77a8b309-1973-471d-87d7-f682b3ebdb32@github.com>
 <L8t5llrzyxpof_frsgyaf8jznTCckZF-h0t7rM8eAX8=.bb67bcc3-d8db-45a5-a365-7cc05faf27da@github.com>
 <BX2O5NH7WOa57DlDNDgWefirxYUBT7nsCnPhqjchfs0=.6df0ae15-a16b-4cbe-ba5c-02c10d4c332f@github.com>
 <uIKLse-ugmKBUDcOM37UbZkziorlrzcMFJAZa25eqTE=.9ad0afaa-37e6-4ee1-885a-936c60bfad7f@github.com>
 <Ze8CKZ6Auw1oW4J-XKuMpO7n7NTedBBmj0O2UKrOH6o=.a16e8ebb-1a0b-499b-a913-92375c486d76@github.com>
 <ZXHKiFA6-hVma_2MXvCzHMLUFspOl3coMjZ5-u2LBA4=.adbb69ca-f7e0-4189-8951-8619403cf835@github.com>
 <uYzejCgfjq5-bRCKx7RaZWH1zUPsDjBMFeBVIaM4B7o=.5a71658f-9431-4bcb-bde9-37970fbf6823@github.com>
 <LXv3U99qPkiJQxlV7UHbRMC9cDYwacPbF6pCVsA2jwg=.dd0dce40-490d-438e-905c-f6fc35c040b7@github.com>
 <mA-4bFE2CPUhPK00SY8G9DC9hjU3y_aJsxdMoy5Z9bA=.ab46dfe9-49c9-4bf2-bf42-d3e6ff81a712@github.com>
 <HFeNprAvlRyaSkwWJO7U8n4u9w8YwZpOCs-8ONl1a3o=.cd41fd5c-d90d-4931-a029-7a2156364eda@github.com>
 <jiD1W4vuwLTeiiZZvCYgiEl-w5XPErcvUeYUxZ1G5QA=.a4b665af-f973-4ec2-befb-e40ff332dee8@
 github.com>
 <BdD2NhK4j3NDO6MEPdgBqrjeqoMkLnLNdpY8Msbmt70=.bb352cad-388a-4d65-b672-dc9c3e2133ac@github.com>
 <FIfmotGSNufKVt5sEnmE2UlvdnokbdJbIbxmVlWa868=.623032fb-1a5e-40e4-8f92-e965a1cd381a@github.com>
 <1u3g8qfry7iEGQcvP6fiYy-vaulzJ9rQK1rWVAlR7LU=.4972c8f2-44a7-49b7-83cf-2771c0b16bfb@github.com>
 <vPaS5x8Dsl5iyfwApmU1cMEuzjSbP_l-I60NOd1X9VE=.718c4d1c-6871-4fb6-aa15-306c842e152d@github.com>
 <MxbDdxDbM5BzJejZYAEVFQ05T69o1rgML849zugREZY=.a3da781b-9b30-4331-b176-0d455fdd5123@github.com>
 <MMfaRF7ay6_yVGOxC6SvO7-b7GwYkMG7r2uIkzfhSJ4=.f8d0457e-bc40-4025-8555-f3921fe9b6d3@github.com>
 <bNl-kdwPZVRfceE1bR2Lt3nYencF6XHmIJdDUAsjdL8=.da92bc6f-41df-486b-8e8d-f90d764c64aa@github.com>
 <lcOubi8bD8nfjs6CyZ_VVq__wlq1md0-kgKam76Ibwo=.6c10a867-9b3a-4c7b-b460-cdfd278a23f1@github.com>
Message-ID: <xya5pLw2y95h8H4191fPxRii6_KSCwmPjY-geya5se4=.1e184d06-157a-4d99-b010-dfb7849dd73b@github.com>

On Sat, 20 Feb 2021 00:47:56 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> BTW, we have three PRs related to `parallel=<n>`. I think it would be best to hold off pushing any of them until they have all been reviewed and approved. One reason is because the `parallel=<n>` output should be consistent for all of them, and if there is a minor suggestion for a change in one, it should be applied to all 3.
>
>> BTW, we have three PRs related to `parallel=<n>`. I think it would be best to hold off pushing any of them until they have all been reviewed and approved. One reason is because the `parallel=<n>` output should be consistent for all of them, and if there is a minor suggestion for a change in one, it should be applied to all 3.
> 
> Sure, will hold off.
> Summarize the help messages as below:
> "Number of parallel threads to use for heap inspection. "
> "0: let the VM determine the number of threads to use. "
> "1: use one thread, i.e. disable parallelism. "
> "n: Request that threads be used. n must be positive. The VM will try to use n threads, but might use fewer threads than n."

For jmap -histo we have:

      parallel=<number>  parallel threads number for heap iteration:
                                  parallel=0 default behavior, use predefined number of threads
                                  parallel=1 disable parallel heap iteration
                                  parallel=<N> use N threads for parallel heap iteration

It's a bit inconsistent here in that it says <number>, <N>, and N. I'd like to see that cleaned up at some point along with a few other things (as part of a separate PR). However, my point is that the value of the argument is given a name, <number> in this case, so it can be referenced in the help output. However, jmap help is done differently than jcmd help, which doesn't give names to the value of options. For example, GC.heap_dump has:

Options: (options must be specified using the <key> or <key>=<value> syntax)
	-all : [optional] Dump all objects, including unreachable objects (BOOLEAN, false)
	-gz : [optional] If specified, the heap dump is written in gzipped format using the given compression level. 1 (recommended) is the fastest, 9 the strongest compression. (INT, 1)

The -gz option is much like -parallel in that a value is given for it, but there is no "name" for that value in the help output. So maybe we should avoid calling it "n" or <n>, or anything like that:

"Number of parallel threads to use for heap inspection."
"0 (the default) means let the VM determine the number of threads to use. "
"1 means use one thread (disable parallelism). "
"For any other value the VM will try to use the specified number of threads, but might use fewer."

I think we can leave out "Must be positive." It should be obvious, and I assume an error is generated if negative number is given.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2379

From ysuenaga at openjdk.java.net  Sat Feb 20 04:05:37 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Sat, 20 Feb 2021 04:05:37 GMT
Subject: RFR: 8261710: SA DSO objects have sizes that are too large [v4]
In-Reply-To: <RA4wgKJxRelMOnsGQN8APbj0c5Ldc7j_mCq0ypE50cg=.3e5fd8e8-6ae6-4f09-a6f0-3e1d06c3f2f9@github.com>
References: <rtxSvuvKLmHKrLtsnxf76vSK41b_HWPR_7Bn3wf9YuM=.cf1b54ae-f01d-48d5-9641-d7d9faa541f5@github.com>
 <-tUjqHsXhVl31QRbblNj5TjV6BVOOLtl6dmXjzVFheo=.498514c8-d0f8-4081-a036-1f9114a6a9c3@github.com>
 <ZpQrDMQXuzEUbe5qhXvKPi1fKgmWnz1n_gCpYxPib-M=.b365c936-b8d2-4115-92dd-4e117248f14c@github.com>
 <KtbKpVu273Kz9u1RpRPvwOH6DBgXIJyJXIlHPqHsi2U=.84f275e4-0123-4dd2-97ba-c2021faeccac@github.com>
 <RA4wgKJxRelMOnsGQN8APbj0c5Ldc7j_mCq0ypE50cg=.3e5fd8e8-6ae6-4f09-a6f0-3e1d06c3f2f9@github.com>
Message-ID: <lRE2m4Oz7EcVsB2FqixcvOG97Eg5ZcKY-oYNC8UJZsg=.ed8b4447-be18-407b-9419-feb69098f982@github.com>

On Fri, 19 Feb 2021 20:59:29 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> BTW, one way to test these changes might be to do a `clhsdb pmap` and then do a `findpc` on the last address of each library's map (should find a symbol) and the first address after the map (should not find a symbol unless that happens to be the start of the next mapped library). I'm not sure if this will always work. It's possible that no symbol covers the very end of the map, especially due to page alignment. Maybe try the first address of the last page then.

I thought similar tests, but I don't want to do so because it might fail as you said.
As an option, we can add the test to to compare address range of shared libraries between `clhsdb pmap` and `/proc/<PID>/maps`. But I can add it for Linux only, so I'm not sure it is worth to add.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2563

From stuefe at openjdk.java.net  Sat Feb 20 05:43:43 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Sat, 20 Feb 2021 05:43:43 GMT
Subject: RFR: 8261929: ClhsdbFindPC fails with java.lang.RuntimeException:
 'In java stack' missing from stdout/stderr
In-Reply-To: <yNakPYlp6Q6YF6NB6db7IyAhAqMvgUc9dq6p6CAJJYU=.41bdf544-1b81-4a90-a3a7-e3207fb1fc9d@github.com>
References: <yNakPYlp6Q6YF6NB6db7IyAhAqMvgUc9dq6p6CAJJYU=.41bdf544-1b81-4a90-a3a7-e3207fb1fc9d@github.com>
Message-ID: <kFxEGVIVIpcxyce-1y2EgNvyKhbOd4a_Pp9SjSeUKkw=.b8275ec4-1713-4097-aa64-e522c3a77b0c@github.com>

On Fri, 19 Feb 2021 01:04:20 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Sometimes due to the state of the java thread, jstack does cannot determine the address of the java frame and instead it is 0x. We need to special case this so the test does not fail.

LGTM

-------------

Marked as reviewed by stuefe (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2637

From mli at openjdk.java.net  Sat Feb 20 09:52:39 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Sat, 20 Feb 2021 09:52:39 GMT
Subject: RFR: JDK-8261034: improve jcmd GC.class_histogram to support
 parallel
In-Reply-To: <xya5pLw2y95h8H4191fPxRii6_KSCwmPjY-geya5se4=.1e184d06-157a-4d99-b010-dfb7849dd73b@github.com>
References: <VKzVY-01CEXUbQdlKMhDWjtjxUgpxs_6487x232VsAI=.3b9c5d8a-972b-4997-9f75-1951f98e1751@github.com>
 <X_7cTwpI8cxsVTCMi6oe6f1Fy6yPcw7b0-Pa-Ayou2Y=.69cba9c8-f6e4-40b4-a180-3eb79428692b@github.com>
 <EQm4vRIvMgIFwt3dwYO3YTdbCLyQEKjISTt-QudCNbE=.f2366e5b-b9fa-456d-bafa-6531293b2cc2@github.com>
 <gBKEb-EMtCvqvSZiS1ImsYpQg63tg6R8KaizkL-BrlE=.f51a4335-251c-4041-bd71-75ec13f0591d@github.com>
 <v4SsYZMv2DVW2v8KDDDrCMa-JlyDX6Nsa20ue9JZKqs=.2617d216-b696-48c9-b34e-b0a97bb3bf12@github.com>
 <C47zxVTOUeIMyATz4LgWhTZsmZ6Nk5ncQRbgNKSvTxg=.7570353c-862e-428d-b6bf-aed24b461ea9@github.com>
 <oNo87kApGGMUT6MJYpvDAlyjBzza1-GmLNZSwAGrmEc=.d8669c88-6882-4744-8a05-5cadaa48404f@github.com>
 <A-u0xkGoB54J-q4yyOu-fXBqvXkTRLnmje8qh1KUTTE=.75f97621-8e70-4ab4-b54f-f45b37bd84f5@github.com>
 <hZpMlhWW1rB89tC-Wj_DH9R05YcOFOaqkFprf9MwBD4=.755ccfc2-b743-4037-8f0c-69c078937c5e@github.com>
 <-mAEJ8TjIlhEHKFP0ybmVgqjhCIr8YoAz4Q-GilpZgs=.d1b01b4c-3c14-43ad-8203-b1cd4d2f7ad4@github.com>
 <6APNXM7Ih9TxHMNEPD-uOla7-w08UxJeP4e
 f3-f3joA=.77a8b309-1973-471d-87d7-f682b3ebdb32@github.com>
 <L8t5llrzyxpof_frsgyaf8jznTCckZF-h0t7rM8eAX8=.bb67bcc3-d8db-45a5-a365-7cc05faf27da@github.com>
 <BX2O5NH7WOa57DlDNDgWefirxYUBT7nsCnPhqjchfs0=.6df0ae15-a16b-4cbe-ba5c-02c10d4c332f@github.com>
 <uIKLse-ugmKBUDcOM37UbZkziorlrzcMFJAZa25eqTE=.9ad0afaa-37e6-4ee1-885a-936c60bfad7f@github.com>
 <Ze8CKZ6Auw1oW4J-XKuMpO7n7NTedBBmj0O2UKrOH6o=.a16e8ebb-1a0b-499b-a913-92375c486d76@github.com>
 <ZXHKiFA6-hVma_2MXvCzHMLUFspOl3coMjZ5-u2LBA4=.adbb69ca-f7e0-4189-8951-8619403cf835@github.com>
 <uYzejCgfjq5-bRCKx7RaZWH1zUPsDjBMFeBVIaM4B7o=.5a71658f-9431-4bcb-bde9-37970fbf6823@github.com>
 <LXv3U99qPkiJQxlV7UHbRMC9cDYwacPbF6pCVsA2jwg=.dd0dce40-490d-438e-905c-f6fc35c040b7@github.com>
 <mA-4bFE2CPUhPK00SY8G9DC9hjU3y_aJsxdMoy5Z9bA=.ab46dfe9-49c9-4bf2-bf42-d3e6ff81a712@github.com>
 <HFeNprAvlRyaSkwWJO7U8n4u9w8YwZpOCs-8ONl1a3o=.cd41fd5c-d90d-4931-a029-7a2156364eda@github.com>
 <jiD1W4vuwLTeiiZZvCYgiEl-w5XPErcvUeYUxZ1G5QA=.a4b665af-f973-4ec2-befb-e40ff332dee8@
 github.com>
 <BdD2NhK4j3NDO6MEPdgBqrjeqoMkLnLNdpY8Msbmt70=.bb352cad-388a-4d65-b672-dc9c3e2133ac@github.com>
 <FIfmotGSNufKVt5sEnmE2UlvdnokbdJbIbxmVlWa868=.623032fb-1a5e-40e4-8f92-e965a1cd381a@github.com>
 <1u3g8qfry7iEGQcvP6fiYy-vaulzJ9rQK1rWVAlR7LU=.4972c8f2-44a7-49b7-83cf-2771c0b16bfb@github.com>
 <vPaS5x8Dsl5iyfwApmU1cMEuzjSbP_l-I60NOd1X9VE=.718c4d1c-6871-4fb6-aa15-306c842e152d@github.com>
 <MxbDdxDbM5BzJejZYAEVFQ05T69o1rgML849zugREZY=.a3da781b-9b30-4331-b176-0d455fdd5123@github.com>
 <MMfaRF7ay6_yVGOxC6SvO7-b7GwYkMG7r2uIkzfhSJ4=.f8d0457e-bc40-4025-8555-f3921fe9b6d3@github.com>
 <bNl-kdwPZVRfceE1bR2Lt3nYencF6XHmIJdDUAsjdL8=.da92bc6f-41df-486b-8e8d-f90d764c64aa@github.com>
 <lcOubi8bD8nfjs6CyZ_VVq__wlq1md0-kgKam76Ibwo=.6c10a867-9b3a-4c7b-b460-cdfd278a23f1@github.com>
 <xya5pLw2y95h8H4191fPxRii6_KSCwmPjY-geya5se4=.1e184d06-157a-4d99-b010-dfb7849dd73b@github.com>
Message-ID: <J6dEvoIMVbF8oaLYaoNRCQU8FBqrxpbMY6sjBIYMNFo=.9799c171-5c70-4040-836d-b2a191199f5e@github.com>

On Sat, 20 Feb 2021 03:27:22 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>>> BTW, we have three PRs related to `parallel=<n>`. I think it would be best to hold off pushing any of them until they have all been reviewed and approved. One reason is because the `parallel=<n>` output should be consistent for all of them, and if there is a minor suggestion for a change in one, it should be applied to all 3.
>> 
>> Sure, will hold off.
>> Summarize the help messages as below:
>> "Number of parallel threads to use for heap inspection. "
>> "0: let the VM determine the number of threads to use. "
>> "1: use one thread, i.e. disable parallelism. "
>> "n: Request that threads be used. n must be positive. The VM will try to use n threads, but might use fewer threads than n."
>
> For jmap -histo we have:
> 
>       parallel=<number>  parallel threads number for heap iteration:
>                                   parallel=0 default behavior, use predefined number of threads
>                                   parallel=1 disable parallel heap iteration
>                                   parallel=<N> use N threads for parallel heap iteration
> 
> It's a bit inconsistent here in that it says <number>, <N>, and N. I'd like to see that cleaned up at some point along with a few other things (as part of a separate PR). However, my point is that the value of the argument is given a name, <number> in this case, so it can be referenced in the help output. However, jmap help is done differently than jcmd help, which doesn't give names to the value of options. For example, GC.heap_dump has:
> 
> Options: (options must be specified using the <key> or <key>=<value> syntax)
> 	-all : [optional] Dump all objects, including unreachable objects (BOOLEAN, false)
> 	-gz : [optional] If specified, the heap dump is written in gzipped format using the given compression level. 1 (recommended) is the fastest, 9 the strongest compression. (INT, 1)
> 
> The -gz option is much like -parallel in that a value is given for it, but there is no "name" for that value in the help output. So maybe we should avoid calling it "n" or <n>, or anything like that:
> 
> "Number of parallel threads to use for heap inspection."
> "0 (the default) means let the VM determine the number of threads to use. "
> "1 means use one thread (disable parallelism). "
> "For any other value the VM will try to use the specified number of threads, but might use fewer."
> 
> I think we can leave out "Must be positive." It should be obvious, and I assume an error is generated if negative number is given.

Sure, thanks for the detailed reviewing.
Let me record the help message as below:
    "Number of parallel threads to use for heap inspection."
    "0 (the default) means let the VM determine the number of threads to use. "
    "1 means use one thread (disable parallelism). "
    "For any other value the VM will try to use the specified number of threads, but might use fewer."

-------------

PR: https://git.openjdk.java.net/jdk/pull/2379

From sspitsyn at openjdk.java.net  Sat Feb 20 09:57:40 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Sat, 20 Feb 2021 09:57:40 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: <AZ06zVkTOrQvNols2nSkGc5eHV9bGWkGpQ4Ob4HPz7Y=.67f536d2-1073-4a4f-ba34-24ba88a0bf2b@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 sspitsyn (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2563

From sspitsyn at openjdk.java.net  Sat Feb 20 09:57:41 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Sat, 20 Feb 2021 09:57:41 GMT
Subject: RFR: 8261710: SA DSO objects have sizes that are too large [v4]
In-Reply-To: <lRE2m4Oz7EcVsB2FqixcvOG97Eg5ZcKY-oYNC8UJZsg=.ed8b4447-be18-407b-9419-feb69098f982@github.com>
References: <rtxSvuvKLmHKrLtsnxf76vSK41b_HWPR_7Bn3wf9YuM=.cf1b54ae-f01d-48d5-9641-d7d9faa541f5@github.com>
 <-tUjqHsXhVl31QRbblNj5TjV6BVOOLtl6dmXjzVFheo=.498514c8-d0f8-4081-a036-1f9114a6a9c3@github.com>
 <ZpQrDMQXuzEUbe5qhXvKPi1fKgmWnz1n_gCpYxPib-M=.b365c936-b8d2-4115-92dd-4e117248f14c@github.com>
 <KtbKpVu273Kz9u1RpRPvwOH6DBgXIJyJXIlHPqHsi2U=.84f275e4-0123-4dd2-97ba-c2021faeccac@github.com>
 <RA4wgKJxRelMOnsGQN8APbj0c5Ldc7j_mCq0ypE50cg=.3e5fd8e8-6ae6-4f09-a6f0-3e1d06c3f2f9@github.com>
 <lRE2m4Oz7EcVsB2FqixcvOG97Eg5ZcKY-oYNC8UJZsg=.ed8b4447-be18-407b-9419-feb69098f982@github.com>
Message-ID: <fWNjpDWJfY3FTBEpWyGs1_Ha44l_5COjqcBi_DOEqYc=.49e9552b-1e19-4186-9113-fe5fd301f2a3@github.com>

On Sat, 20 Feb 2021 04:02:37 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> BTW, one way to test these changes might be to do a `clhsdb pmap` and then do a `findpc` on the last address of each library's map (should find a symbol) and the first address after the map (should not find a symbol unless that happens to be the start of the next mapped library). I'm not sure if this will always work. It's possible that no symbol covers the very end of the map, especially due to page alignment. Maybe try the first address of the last page then. I'm not necessarily suggesting you write a test that does this, but maybe just do a bit of experimenting as a sanity check.
>
>> BTW, one way to test these changes might be to do a `clhsdb pmap` and then do a `findpc` on the last address of each library's map (should find a symbol) and the first address after the map (should not find a symbol unless that happens to be the start of the next mapped library). I'm not sure if this will always work. It's possible that no symbol covers the very end of the map, especially due to page alignment. Maybe try the first address of the last page then.
> 
> I thought similar tests, but I don't want to do so because it might fail as you said.
> As an option, we can add the test to to compare address range of shared libraries between `clhsdb pmap` and `/proc/<PID>/maps`. But I can add it for Linux only, so I'm not sure it is worth to add.

Thank you for the update.

> 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?

In general, I'm okay with your fix though.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2563

From sspitsyn at openjdk.java.net  Sat Feb 20 10:20:43 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Sat, 20 Feb 2021 10:20:43 GMT
Subject: RFR: 8261692:  Bugs in clhsdb history support
In-Reply-To: <3-9ngFZ9SzLX-MwIVN4fDjJAnbjqkt5Q0U8mah-tzHc=.ce625e90-080f-41b4-9227-771ea43b10b7@github.com>
References: <3-9ngFZ9SzLX-MwIVN4fDjJAnbjqkt5Q0U8mah-tzHc=.ce625e90-080f-41b4-9227-771ea43b10b7@github.com>
Message-ID: <OW4MJ7tEggC9Da-UHM3P1uNpQXNS09sjtkNbXoyatn0=.9286202e-4596-4f59-8631-ae420351cb99@github.com>

On Sun, 14 Feb 2021 08:45:26 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> See the CR for a description of the 3 issues fixed. There's also a new test added. I'll explain the fix related to quoting the '!' here since it's not that obvious how it works.
> 
> There's a complex pattern called `historyPattern` that is used to find various uses of ! to do expansion of commands and arguments in the history
> 
>     static Pattern historyPattern = Pattern.compile("([\\\]?)((!\*)|(!\$)|(!!-?)|(!-?[0-9][0-9]*)|(![a-zA-Z][^ ]*))");
> 
> I added the `([\\\]?)` part to handle allowing a '!' to be quoted with a backslash so it will just be treated as a '!' instead of being used for history expansion. This part of the pattern basically says match 1 backslash if present. Yes, you need 4 backslashes to do this. javac will reduce it to two, and then the pattern compilation reduces it down to just one backslash (not to be used for quoting).
> 
> The above pattern for searching for the backslash before a '!' is in the first pattern grouping, and the part that matches on the '!' and what follows is in the 2nd pattern grouping. Thus the code I added checks if the first pattern grouping matches something (and at most it will match just one backslash), and if so then we eat it and don't treat the '!' that follows as a history expansion:
> 
>                     if (m.group(1).length() != 0) {
>                         // This means we matched a `` before the '!'. Don't do any history
>                         // expansion in this case. Just capture what matched after the ``.
>                         result.append(m.group(2));
>                         continue;
>                     }

Looks good.

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2565

From sspitsyn at openjdk.java.net  Sat Feb 20 10:24:48 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Sat, 20 Feb 2021 10:24:48 GMT
Subject: RFR: 8261857: serviceability/sa/ClhsdbPrintAll.java failed with
 "Test ERROR java.lang.RuntimeException: 'cannot be cast to' found in stdout"
In-Reply-To: <Hb_DUhlaogiehEC-bhiW11Y4R0Y76X_KXJ7NYNJLmwY=.d2815725-6b32-4750-bbd0-ae90a88eb3e9@github.com>
References: <Hb_DUhlaogiehEC-bhiW11Y4R0Y76X_KXJ7NYNJLmwY=.d2815725-6b32-4750-bbd0-ae90a88eb3e9@github.com>
Message-ID: <vPPSAOSuM9tw6jDZUp49wHLBlRHm-aZqHl6wxGkCNI0=.3c3f9786-7178-474b-8015-8f531c69d358@github.com>

On Thu, 18 Feb 2021 06:13:27 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The test is checking for "cannot be cast to" because at one point there was a bug in `printall` that was causing a `ClassCastException`. See [JDK-8175384](https://bugs.openjdk.java.net/browse/JDK-8175384). However, there is also a "cannot be cast to" message in the `printall` output when disassembling since the java source actually has it in a string literal:
> 
>  3203 302 ldc #214(6) <String " cannot be cast to ResourceBundle"> [fast_aldc]
> 
> Which comes from the following in the ResourceBundle.java source:
> 
>                         throw new ClassCastException(c.getName()
>                                 + " cannot be cast to ResourceBundle"); 
> 
> So this occurrence of "cannot be cast" is fine. The one we don't want comes from `SharedRuntime::generate_class_cast_message()` in `sharedRuntime.cpp`:
> 
> `                 "class %s cannot be cast to class %s (%s%s%s)",`
> 
> So we can avoid this bug by changing the check to be a bit more explicit and check for "cannot be cast to class" instead.

This looks good and trivial.

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2624

From sspitsyn at openjdk.java.net  Sat Feb 20 10:26:46 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Sat, 20 Feb 2021 10:26:46 GMT
Subject: RFR: 8261929: ClhsdbFindPC fails with java.lang.RuntimeException:
 'In java stack' missing from stdout/stderr
In-Reply-To: <yNakPYlp6Q6YF6NB6db7IyAhAqMvgUc9dq6p6CAJJYU=.41bdf544-1b81-4a90-a3a7-e3207fb1fc9d@github.com>
References: <yNakPYlp6Q6YF6NB6db7IyAhAqMvgUc9dq6p6CAJJYU=.41bdf544-1b81-4a90-a3a7-e3207fb1fc9d@github.com>
Message-ID: <nc2-WikQv9OQzcUhIbdiiEHMJXqZhIW4GpgwL1HM7Fg=.b5e9e895-ef80-4c46-b8bc-c9b68ba21d13@github.com>

On Fri, 19 Feb 2021 01:04:20 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Sometimes due to the state of the java thread, jstack does cannot determine the address of the java frame and instead it is 0x. We need to special case this so the test does not fail.

LGTM++

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2637

From sspitsyn at openjdk.java.net  Sat Feb 20 10:50:42 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Sat, 20 Feb 2021 10:50:42 GMT
Subject: RFR: 8257234 : Add gz option to SA jmap to write a gzipped heap
 dump [v20]
In-Reply-To: <G_Lbe4FPO42wiU-W7Y_UkV53JzqVCql2sUWJAFObFm0=.74a3d2a7-fb24-4dc7-bac4-da347b61d98f@github.com>
References: <oTMRc7LWvx9_Uov01HPX9UgyEqFmXt_nMG920HUQBIM=.3651754b-e1f1-46f8-9f44-c118a5c56dbe@github.com>
 <G_Lbe4FPO42wiU-W7Y_UkV53JzqVCql2sUWJAFObFm0=.74a3d2a7-fb24-4dc7-bac4-da347b61d98f@github.com>
Message-ID: <ml2c6NAIFM-P7IQsOdq4FcjY6yI3C7GeD5_luCQfxH0=.91c08117-8389-4d4a-897d-b7539f0b2e67@github.com>

On Wed, 10 Feb 2021 04:04:56 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> 8257234 : Add gz option to SA jmap to write a gzipped heap dump
>
> Lin Zang has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - fix indentation isue
>  - fix help message issue and Use ByteBuffer for integer writing

Hi Lin,
I'm sorry for the delay.
The fix looks good to me.
I have one minor request below.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java

+    private static byte[] genByteArrayFromInt(int integer) {
. . .
+        private final void writeInteger(int v) {

Could you, please, replace both parameters 'integer' and 'v' with something like 'val' or 'value'?

Thanks,
Serguei

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1712

From sspitsyn at openjdk.java.net  Sat Feb 20 11:08:45 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Sat, 20 Feb 2021 11:08:45 GMT
Subject: RFR: 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: <ysHMwTHXALiy3M6IcSHt2IS7Io9Jq8rnTu7kmMMbbzw=.03d4c20e-df28-489f-8d21-d08e55217d42@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)

Looks good.
Thanks,
Serguei

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2633

From sspitsyn at openjdk.java.net  Sat Feb 20 11:16:47 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Sat, 20 Feb 2021 11:16:47 GMT
Subject: RFR: JDK-8261034: improve jcmd GC.class_histogram to support
 parallel [v3]
In-Reply-To: <S6IuLJ19Du-PSnI7KSeR7obqbNoS8GJ_wm0Z2U7Y_2w=.ac2466e0-8333-45e2-b030-ab240b31bd53@github.com>
References: <VKzVY-01CEXUbQdlKMhDWjtjxUgpxs_6487x232VsAI=.3b9c5d8a-972b-4997-9f75-1951f98e1751@github.com>
 <EtePCjI8QD6rSfd7DjihG3MT5XzPRGXVUhtKAl7ioY4=.b9c89460-7998-416e-8bec-60980abee6f6@github.com>
 <hTE1AreVDhxMyojIXd_VFAdY8-9BiUenSbW7E9VxyG0=.d116728f-7a36-43c3-be9a-53f613da5565@github.com>
 <S6IuLJ19Du-PSnI7KSeR7obqbNoS8GJ_wm0Z2U7Y_2w=.ac2466e0-8333-45e2-b030-ab240b31bd53@github.com>
Message-ID: <tnjP78W-MYqwyogPSqtvEV_PqaBTq4i3DX38I1EwZTA=.0b0860c8-0f28-4741-96d3-55c0a05c0350@github.com>

On Fri, 5 Feb 2021 02:40:13 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> src/hotspot/share/services/diagnosticCommand.cpp line 562:
>> 
>>> 560:        "0 use system determined number of threads, "
>>> 561:        "1 use one thread, i.e., disable parallelism, "
>>> 562:        "n use n threads, n must be positive.",
>> 
>> "Number of parallel threads for heap iteration. "
>>        "0 means let the VM determined the number of threads. "
>>        "1 means use one thread, i.e. disable parallelism. "
>>        "n means use n threads. n must be positive.",
>
> Thanks for detailed review, Chris, just modified as you suggested.

I like this approach - good idea.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2379

From sspitsyn at openjdk.java.net  Sat Feb 20 11:27:52 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Sat, 20 Feb 2021 11:27:52 GMT
Subject: RFR: JDK-8261034: improve jcmd GC.class_histogram to support
 parallel
In-Reply-To: <J6dEvoIMVbF8oaLYaoNRCQU8FBqrxpbMY6sjBIYMNFo=.9799c171-5c70-4040-836d-b2a191199f5e@github.com>
References: <VKzVY-01CEXUbQdlKMhDWjtjxUgpxs_6487x232VsAI=.3b9c5d8a-972b-4997-9f75-1951f98e1751@github.com>
 <X_7cTwpI8cxsVTCMi6oe6f1Fy6yPcw7b0-Pa-Ayou2Y=.69cba9c8-f6e4-40b4-a180-3eb79428692b@github.com>
 <EQm4vRIvMgIFwt3dwYO3YTdbCLyQEKjISTt-QudCNbE=.f2366e5b-b9fa-456d-bafa-6531293b2cc2@github.com>
 <gBKEb-EMtCvqvSZiS1ImsYpQg63tg6R8KaizkL-BrlE=.f51a4335-251c-4041-bd71-75ec13f0591d@github.com>
 <v4SsYZMv2DVW2v8KDDDrCMa-JlyDX6Nsa20ue9JZKqs=.2617d216-b696-48c9-b34e-b0a97bb3bf12@github.com>
 <C47zxVTOUeIMyATz4LgWhTZsmZ6Nk5ncQRbgNKSvTxg=.7570353c-862e-428d-b6bf-aed24b461ea9@github.com>
 <oNo87kApGGMUT6MJYpvDAlyjBzza1-GmLNZSwAGrmEc=.d8669c88-6882-4744-8a05-5cadaa48404f@github.com>
 <A-u0xkGoB54J-q4yyOu-fXBqvXkTRLnmje8qh1KUTTE=.75f97621-8e70-4ab4-b54f-f45b37bd84f5@github.com>
 <hZpMlhWW1rB89tC-Wj_DH9R05YcOFOaqkFprf9MwBD4=.755ccfc2-b743-4037-8f0c-69c078937c5e@github.com>
 <-mAEJ8TjIlhEHKFP0ybmVgqjhCIr8YoAz4Q-GilpZgs=.d1b01b4c-3c14-43ad-8203-b1cd4d2f7ad4@github.com>
 <6APNXM7Ih9TxHMNEPD-uOla7-w08UxJeP4e
 f3-f3joA=.77a8b309-1973-471d-87d7-f682b3ebdb32@github.com>
 <L8t5llrzyxpof_frsgyaf8jznTCckZF-h0t7rM8eAX8=.bb67bcc3-d8db-45a5-a365-7cc05faf27da@github.com>
 <BX2O5NH7WOa57DlDNDgWefirxYUBT7nsCnPhqjchfs0=.6df0ae15-a16b-4cbe-ba5c-02c10d4c332f@github.com>
 <uIKLse-ugmKBUDcOM37UbZkziorlrzcMFJAZa25eqTE=.9ad0afaa-37e6-4ee1-885a-936c60bfad7f@github.com>
 <Ze8CKZ6Auw1oW4J-XKuMpO7n7NTedBBmj0O2UKrOH6o=.a16e8ebb-1a0b-499b-a913-92375c486d76@github.com>
 <ZXHKiFA6-hVma_2MXvCzHMLUFspOl3coMjZ5-u2LBA4=.adbb69ca-f7e0-4189-8951-8619403cf835@github.com>
 <uYzejCgfjq5-bRCKx7RaZWH1zUPsDjBMFeBVIaM4B7o=.5a71658f-9431-4bcb-bde9-37970fbf6823@github.com>
 <LXv3U99qPkiJQxlV7UHbRMC9cDYwacPbF6pCVsA2jwg=.dd0dce40-490d-438e-905c-f6fc35c040b7@github.com>
 <mA-4bFE2CPUhPK00SY8G9DC9hjU3y_aJsxdMoy5Z9bA=.ab46dfe9-49c9-4bf2-bf42-d3e6ff81a712@github.com>
 <HFeNprAvlRyaSkwWJO7U8n4u9w8YwZpOCs-8ONl1a3o=.cd41fd5c-d90d-4931-a029-7a2156364eda@github.com>
 <jiD1W4vuwLTeiiZZvCYgiEl-w5XPErcvUeYUxZ1G5QA=.a4b665af-f973-4ec2-befb-e40ff332dee8@
 github.com>
 <BdD2NhK4j3NDO6MEPdgBqrjeqoMkLnLNdpY8Msbmt70=.bb352cad-388a-4d65-b672-dc9c3e2133ac@github.com>
 <FIfmotGSNufKVt5sEnmE2UlvdnokbdJbIbxmVlWa868=.623032fb-1a5e-40e4-8f92-e965a1cd381a@github.com>
 <1u3g8qfry7iEGQcvP6fiYy-vaulzJ9rQK1rWVAlR7LU=.4972c8f2-44a7-49b7-83cf-2771c0b16bfb@github.com>
 <vPaS5x8Dsl5iyfwApmU1cMEuzjSbP_l-I60NOd1X9VE=.718c4d1c-6871-4fb6-aa15-306c842e152d@github.com>
 <MxbDdxDbM5BzJejZYAEVFQ05T69o1rgML849zugREZY=.a3da781b-9b30-4331-b176-0d455fdd5123@github.com>
 <MMfaRF7ay6_yVGOxC6SvO7-b7GwYkMG7r2uIkzfhSJ4=.f8d0457e-bc40-4025-8555-f3921fe9b6d3@github.com>
 <bNl-kdwPZVRfceE1bR2Lt3nYencF6XHmIJdDUAsjdL8=.da92bc6f-41df-486b-8e8d-f90d764c64aa@github.com>
 <lcOubi8bD8nfjs6CyZ_VVq__wlq1md0-kgKam76Ibwo=.6c10a867-9b3a-4c7b-b460-cdfd278a23f1@github.com>
 <xya5pLw2y95h8H4191fPxRii6_KSCwmPjY-geya5se4=.1e184d06-157a-4d99-b010-dfb7849dd73b@github.com>
 <J6dEvoIMVbF8oaLYaoNRCQU8FBqrxpbMY6sjBIYMNFo=.9799c171-5c70-4040-836d-b2a191199f5e@github.com>
Message-ID: <tNmy7T_nHVzT9uorVyeWzm2IIkEeKSSsyzTdhFfMO9Y=.3a5116ea-2b95-4943-8817-6fe13e84dc10@github.com>

On Sat, 20 Feb 2021 09:50:05 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> For jmap -histo we have:
>> 
>>       parallel=<number>  parallel threads number for heap iteration:
>>                                   parallel=0 default behavior, use predefined number of threads
>>                                   parallel=1 disable parallel heap iteration
>>                                   parallel=<N> use N threads for parallel heap iteration
>> 
>> It's a bit inconsistent here in that it says <number>, <N>, and N. I'd like to see that cleaned up at some point along with a few other things (as part of a separate PR). However, my point is that the value of the argument is given a name, <number> in this case, so it can be referenced in the help output. However, jmap help is done differently than jcmd help, which doesn't give names to the value of options. For example, GC.heap_dump has:
>> 
>> Options: (options must be specified using the <key> or <key>=<value> syntax)
>> 	-all : [optional] Dump all objects, including unreachable objects (BOOLEAN, false)
>> 	-gz : [optional] If specified, the heap dump is written in gzipped format using the given compression level. 1 (recommended) is the fastest, 9 the strongest compression. (INT, 1)
>> 
>> The -gz option is much like -parallel in that a value is given for it, but there is no "name" for that value in the help output. So maybe we should avoid calling it "n" or <n>, or anything like that:
>> 
>> "Number of parallel threads to use for heap inspection."
>> "0 (the default) means let the VM determine the number of threads to use. "
>> "1 means use one thread (disable parallelism). "
>> "For any other value the VM will try to use the specified number of threads, but might use fewer."
>> 
>> I think we can leave out "Must be positive." It should be obvious, and I assume an error is generated if negative number is given.
>
> Sure, thanks for the detailed reviewing.
> Let me record the help message as below:
>     "Number of parallel threads to use for heap inspection."
>     "0 (the default) means let the VM determine the number of threads to use. "
>     "1 means use one thread (disable parallelism). "
>     "For any other value the VM will try to use the specified number of threads, but might use fewer."

"Number of parallel threads to use for heap inspection."
"0 (the default) means let the VM determine the number of threads to use. "
"1 means use one thread (disable parallelism). "
"For any other value the VM will try to use the specified number of threads, but might use fewer."
I like this approach - good idea.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2379

From lzang at openjdk.java.net  Sat Feb 20 11:27:52 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Sat, 20 Feb 2021 11:27:52 GMT
Subject: RFR: JDK-8261034: improve jcmd GC.class_histogram to support
 parallel
In-Reply-To: <J6dEvoIMVbF8oaLYaoNRCQU8FBqrxpbMY6sjBIYMNFo=.9799c171-5c70-4040-836d-b2a191199f5e@github.com>
References: <VKzVY-01CEXUbQdlKMhDWjtjxUgpxs_6487x232VsAI=.3b9c5d8a-972b-4997-9f75-1951f98e1751@github.com>
 <X_7cTwpI8cxsVTCMi6oe6f1Fy6yPcw7b0-Pa-Ayou2Y=.69cba9c8-f6e4-40b4-a180-3eb79428692b@github.com>
 <EQm4vRIvMgIFwt3dwYO3YTdbCLyQEKjISTt-QudCNbE=.f2366e5b-b9fa-456d-bafa-6531293b2cc2@github.com>
 <gBKEb-EMtCvqvSZiS1ImsYpQg63tg6R8KaizkL-BrlE=.f51a4335-251c-4041-bd71-75ec13f0591d@github.com>
 <v4SsYZMv2DVW2v8KDDDrCMa-JlyDX6Nsa20ue9JZKqs=.2617d216-b696-48c9-b34e-b0a97bb3bf12@github.com>
 <C47zxVTOUeIMyATz4LgWhTZsmZ6Nk5ncQRbgNKSvTxg=.7570353c-862e-428d-b6bf-aed24b461ea9@github.com>
 <oNo87kApGGMUT6MJYpvDAlyjBzza1-GmLNZSwAGrmEc=.d8669c88-6882-4744-8a05-5cadaa48404f@github.com>
 <A-u0xkGoB54J-q4yyOu-fXBqvXkTRLnmje8qh1KUTTE=.75f97621-8e70-4ab4-b54f-f45b37bd84f5@github.com>
 <hZpMlhWW1rB89tC-Wj_DH9R05YcOFOaqkFprf9MwBD4=.755ccfc2-b743-4037-8f0c-69c078937c5e@github.com>
 <-mAEJ8TjIlhEHKFP0ybmVgqjhCIr8YoAz4Q-GilpZgs=.d1b01b4c-3c14-43ad-8203-b1cd4d2f7ad4@github.com>
 <6APNXM7Ih9TxHMNEPD-uOla7-w08UxJeP4e
 f3-f3joA=.77a8b309-1973-471d-87d7-f682b3ebdb32@github.com>
 <L8t5llrzyxpof_frsgyaf8jznTCckZF-h0t7rM8eAX8=.bb67bcc3-d8db-45a5-a365-7cc05faf27da@github.com>
 <BX2O5NH7WOa57DlDNDgWefirxYUBT7nsCnPhqjchfs0=.6df0ae15-a16b-4cbe-ba5c-02c10d4c332f@github.com>
 <uIKLse-ugmKBUDcOM37UbZkziorlrzcMFJAZa25eqTE=.9ad0afaa-37e6-4ee1-885a-936c60bfad7f@github.com>
 <Ze8CKZ6Auw1oW4J-XKuMpO7n7NTedBBmj0O2UKrOH6o=.a16e8ebb-1a0b-499b-a913-92375c486d76@github.com>
 <ZXHKiFA6-hVma_2MXvCzHMLUFspOl3coMjZ5-u2LBA4=.adbb69ca-f7e0-4189-8951-8619403cf835@github.com>
 <uYzejCgfjq5-bRCKx7RaZWH1zUPsDjBMFeBVIaM4B7o=.5a71658f-9431-4bcb-bde9-37970fbf6823@github.com>
 <LXv3U99qPkiJQxlV7UHbRMC9cDYwacPbF6pCVsA2jwg=.dd0dce40-490d-438e-905c-f6fc35c040b7@github.com>
 <mA-4bFE2CPUhPK00SY8G9DC9hjU3y_aJsxdMoy5Z9bA=.ab46dfe9-49c9-4bf2-bf42-d3e6ff81a712@github.com>
 <HFeNprAvlRyaSkwWJO7U8n4u9w8YwZpOCs-8ONl1a3o=.cd41fd5c-d90d-4931-a029-7a2156364eda@github.com>
 <jiD1W4vuwLTeiiZZvCYgiEl-w5XPErcvUeYUxZ1G5QA=.a4b665af-f973-4ec2-befb-e40ff332dee8@
 github.com>
 <BdD2NhK4j3NDO6MEPdgBqrjeqoMkLnLNdpY8Msbmt70=.bb352cad-388a-4d65-b672-dc9c3e2133ac@github.com>
 <FIfmotGSNufKVt5sEnmE2UlvdnokbdJbIbxmVlWa868=.623032fb-1a5e-40e4-8f92-e965a1cd381a@github.com>
 <1u3g8qfry7iEGQcvP6fiYy-vaulzJ9rQK1rWVAlR7LU=.4972c8f2-44a7-49b7-83cf-2771c0b16bfb@github.com>
 <vPaS5x8Dsl5iyfwApmU1cMEuzjSbP_l-I60NOd1X9VE=.718c4d1c-6871-4fb6-aa15-306c842e152d@github.com>
 <MxbDdxDbM5BzJejZYAEVFQ05T69o1rgML849zugREZY=.a3da781b-9b30-4331-b176-0d455fdd5123@github.com>
 <MMfaRF7ay6_yVGOxC6SvO7-b7GwYkMG7r2uIkzfhSJ4=.f8d0457e-bc40-4025-8555-f3921fe9b6d3@github.com>
 <bNl-kdwPZVRfceE1bR2Lt3nYencF6XHmIJdDUAsjdL8=.da92bc6f-41df-486b-8e8d-f90d764c64aa@github.com>
 <lcOubi8bD8nfjs6CyZ_VVq__wlq1md0-kgKam76Ibwo=.6c10a867-9b3a-4c7b-b460-cdfd278a23f1@github.com>
 <xya5pLw2y95h8H4191fPxRii6_KSCwmPjY-geya5se4=.1e184d06-157a-4d99-b010-dfb7849dd73b@github.com>
 <J6dEvoIMVbF8oaLYaoNRCQU8FBqrxpbMY6sjBIYMNFo=.9799c171-5c70-4040-836d-b2a191199f5e@github.com>
Message-ID: <SH9dp5DW3MkxRCBxi_KwUMMmDOAJFXfWS2i7br9NjY4=.a722b4a6-66a4-4403-95ad-a4d81794dfc9@github.com>

On Sat, 20 Feb 2021 09:50:05 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Sure, thanks for the detailed reviewing.
> Let me record the help message as below:
> "Number of parallel threads to use for heap inspection."
> "0 (the default) means let the VM determine the number of threads to use. "
> "1 means use one thread (disable parallelism). "
> "For any other value the VM will try to use the specified number of threads, but might use fewer."

I like this one too.  Thanks for dicussion and finalize it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2379

From lzang at openjdk.java.net  Sat Feb 20 11:39:02 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Sat, 20 Feb 2021 11:39:02 GMT
Subject: RFR: 8257234 : Add gz option to SA jmap to write a gzipped heap
 dump [v20]
In-Reply-To: <ml2c6NAIFM-P7IQsOdq4FcjY6yI3C7GeD5_luCQfxH0=.91c08117-8389-4d4a-897d-b7539f0b2e67@github.com>
References: <oTMRc7LWvx9_Uov01HPX9UgyEqFmXt_nMG920HUQBIM=.3651754b-e1f1-46f8-9f44-c118a5c56dbe@github.com>
 <G_Lbe4FPO42wiU-W7Y_UkV53JzqVCql2sUWJAFObFm0=.74a3d2a7-fb24-4dc7-bac4-da347b61d98f@github.com>
 <ml2c6NAIFM-P7IQsOdq4FcjY6yI3C7GeD5_luCQfxH0=.91c08117-8389-4d4a-897d-b7539f0b2e67@github.com>
Message-ID: <NYXlJXXrOlaGZ4AHU2ZlIHQETgrY6BYfEwNxxYmA-dc=.eaeb6e3a-2c88-43ad-b00f-55256d56f1c1@github.com>

On Sat, 20 Feb 2021 10:48:22 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Lin Zang has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - fix indentation isue
>>  - fix help message issue and Use ByteBuffer for integer writing
>
> Hi Lin,
> I'm sorry for the delay.
> The fix looks good to me.
> I have one minor request below.
> 
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java
> 
> +    private static byte[] genByteArrayFromInt(int integer) {
> . . .
> +        private final void writeInteger(int v) {
> 
> Could you, please, replace both parameters 'integer' and 'v' with something like 'val' or 'value'?
> 
> Thanks,
> Serguei

Hi Serguei,
> Could you, please, replace both parameters 'integer' and 'v' with something like 'val' or 'value'?
Done.
Thanks a lot for reviewing.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1712

From lzang at openjdk.java.net  Sat Feb 20 11:39:01 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Sat, 20 Feb 2021 11:39:01 GMT
Subject: RFR: 8257234 : Add gz option to SA jmap to write a gzipped heap
 dump [v21]
In-Reply-To: <oTMRc7LWvx9_Uov01HPX9UgyEqFmXt_nMG920HUQBIM=.3651754b-e1f1-46f8-9f44-c118a5c56dbe@github.com>
References: <oTMRc7LWvx9_Uov01HPX9UgyEqFmXt_nMG920HUQBIM=.3651754b-e1f1-46f8-9f44-c118a5c56dbe@github.com>
Message-ID: <0RZk2ZtRwc0ZsfEWU-WYEANO61UqN9JZMMKHikt8zIE=.1f1e6f66-8489-4003-886b-a7961c63fece@github.com>

> 8257234 : Add gz option to SA jmap to write a gzipped heap dump

Lin Zang has updated the pull request incrementally with one additional commit since the last revision:

  refine the argument name

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1712/files
  - new: https://git.openjdk.java.net/jdk/pull/1712/files/7c25d58c..73b6c298

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1712&range=20
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1712&range=19-20

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1712.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1712/head:pull/1712

PR: https://git.openjdk.java.net/jdk/pull/1712

From lzang at openjdk.java.net  Sat Feb 20 11:39:02 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Sat, 20 Feb 2021 11:39:02 GMT
Subject: RFR: 8257234 : Add gz option to SA jmap to write a gzipped heap
 dump [v20]
In-Reply-To: <h-29LR29psutzoUwDZpIB96GNtd8BR1q4Vyt3IDbbKA=.534ce2d5-821a-41e2-94eb-9ea409c7fb9f@github.com>
References: <oTMRc7LWvx9_Uov01HPX9UgyEqFmXt_nMG920HUQBIM=.3651754b-e1f1-46f8-9f44-c118a5c56dbe@github.com>
 <G_Lbe4FPO42wiU-W7Y_UkV53JzqVCql2sUWJAFObFm0=.74a3d2a7-fb24-4dc7-bac4-da347b61d98f@github.com>
 <h-29LR29psutzoUwDZpIB96GNtd8BR1q4Vyt3IDbbKA=.534ce2d5-821a-41e2-94eb-9ea409c7fb9f@github.com>
Message-ID: <M-7yKHpuSyVsrbNv2XdMP4rKp0kvke0yxzZlz8P07BU=.2a8e487d-a8a3-4de9-b93f-13b56ceaaa5e@github.com>

On Fri, 19 Feb 2021 20:01:08 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Lin Zang has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - fix indentation isue
>>  - fix help message issue and Use ByteBuffer for integer writing
>
> Marked as reviewed by cjplummer (Reviewer).

Mark it as ready for pushing. Thanks @plummercj @sspitsyn and @YaSuenag for help reviewing!

-------------

PR: https://git.openjdk.java.net/jdk/pull/1712

From ysuenaga at openjdk.java.net  Sat Feb 20 12:30:43 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Sat, 20 Feb 2021 12:30:43 GMT
Subject: RFR: 8261710: SA DSO objects have sizes that are too large [v5]
In-Reply-To: <AZ06zVkTOrQvNols2nSkGc5eHV9bGWkGpQ4Ob4HPz7Y=.67f536d2-1073-4a4f-ba34-24ba88a0bf2b@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>
Message-ID: <52YX6zmd_t9GFBpis5DdKZ3SsrCVfYfFvjShHBFmiy4=.837101a6-d29c-40c3-a03e-ee7626fb6d80@github.com>

On Sat, 20 Feb 2021 09:55:18 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> 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 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.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2563

From dcubed at openjdk.java.net  Sat Feb 20 17:50:02 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sat, 20 Feb 2021 17:50:02 GMT
Subject: RFR: 8241403: JavaThread::get_thread_name() should be
 ThreadSMR-aware [v3]
In-Reply-To: <xVPLwLdUNsPogD1lTYOn6EQPsCxzX5xEz_Ywk83SsYE=.f7604702-37e0-43b8-942f-3eed91ab4080@github.com>
References: <wRdcRQurtpybntK9Qpji-6zVY-EcHKw3q87xpD0eoS4=.a6dc32f4-2919-42e9-80c3-5a264067f0e2@github.com>
 <yER6SKX-lfZsdJmls-clFnBnZd-SWbJkCF4kO_OZg-o=.64d2e6af-47ea-4f82-9a9a-fec6395a2ad5@github.com>
 <LwyuPftEZnuGNnUAjr3ar5upnTHEBRZF9JRtdciVc1s=.64695cc9-0139-4efd-aa4d-e5c57eddca9f@github.com>
 <xVPLwLdUNsPogD1lTYOn6EQPsCxzX5xEz_Ywk83SsYE=.f7604702-37e0-43b8-942f-3eed91ab4080@github.com>
Message-ID: <f2-3fMnQfaXdlEhsCVDZVbEFCbsR5-NDASaLs5ms_do=.20846bed-a318-4334-a833-ac4a3e8b68f9@github.com>

On Wed, 17 Feb 2021 17:33:27 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Hi Dan,
>> 
>> Sorry but I have a lot of issues with this. After thinking about it a lot I don't think the current approach is what is needed. To repeat what I wrote in one of the comments I think the simple fix here is to replace the use of Threads_lock in the caller with suitable use of a TLH, and then replace the assert_locked_or_safepoint(Threads_lock) with assert(is_JavaThread_protected(t)) where is_JavaThread_protected checks the target for either being the current thread or included in a TLH of the current thread. I don't think get_thread_name() should try to protect the target as that is the responsibility of the caller.
>> 
>> Thanks,
>> David
>
> @dholmes-ora - I'm really glad that I waited for your review! Thanks for taking the time.

The changes in CR2 are:

- Make Thread::is_JavaThread_protected() static and make it clear that
  it checks to see if the calling thread is protecting the target;
  added VMThread access as always protected.
- Revert changes in JvmtiTrace::safe_get_thread_name().
- Revert the JavaThread::get_thread_name() default_name parameter and
  don't create a ThreadsListHandle in the function; restore a simpler
  assert for the case where the target thread is not protected.
- Add Threads::threads_do() and Threads::java_threads_do() that work
  with a JavaThreadIteratorWithHandle.
- Update src/hotspot/share/services/management.cpp to switch from using
  the Threads_lock to using JavaThreadIteratorWithHandle.
- Redo compileBroker.cpp changes to use a ThreadsListHandle to protect 
  the CompilerThread/JavaThread.
- Remove a stale comment from src/hotspot/share/prims/jvm.cpp.

You'll notice some temporary testing code in JavaThread::get_thread_name():

  guarantee(false, "current_thread=" INTPTR_FORMAT
            " is not protecting this=" INTPTR_FORMAT,
            p2i(current_thread), p2i(this));

I'm doing my current Mach5 Tier[1-8] run with this guarantee() in place.
It hasn't fired in Mach5 Tier[1-7]; Tier8 is still running, but it hasn't
fired yet. What this means is that we don't currently have a test case that
always exercises the unprotected path; we might have a test case that 
sometimes exercises the unprotected path depending on timing and/or
options, but nothing so far. My intention with this fix is not to leave any
unprotected paths for JavaThread::get_thread_name() and these test results
give me confidence, but not complete assurance.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2535

From dcubed at openjdk.java.net  Sat Feb 20 17:50:01 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sat, 20 Feb 2021 17:50:01 GMT
Subject: RFR: 8241403: JavaThread::get_thread_name() should be
 ThreadSMR-aware [v4]
In-Reply-To: <wRdcRQurtpybntK9Qpji-6zVY-EcHKw3q87xpD0eoS4=.a6dc32f4-2919-42e9-80c3-5a264067f0e2@github.com>
References: <wRdcRQurtpybntK9Qpji-6zVY-EcHKw3q87xpD0eoS4=.a6dc32f4-2919-42e9-80c3-5a264067f0e2@github.com>
Message-ID: <6MUhGSRe79fD3SkU0sbPKDneAQMpJvpVvL1uwImO7vI=.d28b3e10-5527-4df6-b554-c21ba598db56@github.com>

> A minor fix to add a new function:
> 
>     bool Thread::is_JavaThread_protected(const JavaThread* p)
> 
> that returns true when the target JavaThread* is protected and false
> otherwise. Update JavaThread::get_thread_name() to create a
> ThreadsListHandle and use the new is_JavaThread_protected(). Also
> update JvmtiTrace::safe_get_thread_name() to use the new
> is_JavaThread_protected().
> 
> This fix is tested via a Mach5 Tier[1-8] run.

Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:

  Address dholmes-ora CR1 comments.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2535/files
  - new: https://git.openjdk.java.net/jdk/pull/2535/files/1401c327..cbb71a20

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2535&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2535&range=02-03

  Stats: 80 lines in 6 files changed: 48 ins; 10 del; 22 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2535.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2535/head:pull/2535

PR: https://git.openjdk.java.net/jdk/pull/2535

From dcubed at openjdk.java.net  Sat Feb 20 17:50:02 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sat, 20 Feb 2021 17:50:02 GMT
Subject: RFR: 8241403: JavaThread::get_thread_name() should be
 ThreadSMR-aware [v3]
In-Reply-To: <f2-3fMnQfaXdlEhsCVDZVbEFCbsR5-NDASaLs5ms_do=.20846bed-a318-4334-a833-ac4a3e8b68f9@github.com>
References: <wRdcRQurtpybntK9Qpji-6zVY-EcHKw3q87xpD0eoS4=.a6dc32f4-2919-42e9-80c3-5a264067f0e2@github.com>
 <yER6SKX-lfZsdJmls-clFnBnZd-SWbJkCF4kO_OZg-o=.64d2e6af-47ea-4f82-9a9a-fec6395a2ad5@github.com>
 <LwyuPftEZnuGNnUAjr3ar5upnTHEBRZF9JRtdciVc1s=.64695cc9-0139-4efd-aa4d-e5c57eddca9f@github.com>
 <xVPLwLdUNsPogD1lTYOn6EQPsCxzX5xEz_Ywk83SsYE=.f7604702-37e0-43b8-942f-3eed91ab4080@github.com>
 <f2-3fMnQfaXdlEhsCVDZVbEFCbsR5-NDASaLs5ms_do=.20846bed-a318-4334-a833-ac4a3e8b68f9@github.com>
Message-ID: <5gkJEEicbil9yoagDv5-SOKgPlfC-lXoJ0Ii8GBIRJA=.6df4da11-0487-4fa5-8897-d702dde7aba8@github.com>

On Sat, 20 Feb 2021 17:44:38 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> @dholmes-ora - I'm really glad that I waited for your review! Thanks for taking the time.
>
> The changes in CR2 are:
> 
> - Make Thread::is_JavaThread_protected() static and make it clear that
>   it checks to see if the calling thread is protecting the target;
>   added VMThread access as always protected.
> - Revert changes in JvmtiTrace::safe_get_thread_name().
> - Revert the JavaThread::get_thread_name() default_name parameter and
>   don't create a ThreadsListHandle in the function; restore a simpler
>   assert for the case where the target thread is not protected.
> - Add Threads::threads_do() and Threads::java_threads_do() that work
>   with a JavaThreadIteratorWithHandle.
> - Update src/hotspot/share/services/management.cpp to switch from using
>   the Threads_lock to using JavaThreadIteratorWithHandle.
> - Redo compileBroker.cpp changes to use a ThreadsListHandle to protect 
>   the CompilerThread/JavaThread.
> - Remove a stale comment from src/hotspot/share/prims/jvm.cpp.
> 
> You'll notice some temporary testing code in JavaThread::get_thread_name():
> 
>   guarantee(false, "current_thread=" INTPTR_FORMAT
>             " is not protecting this=" INTPTR_FORMAT,
>             p2i(current_thread), p2i(this));
> 
> I'm doing my current Mach5 Tier[1-8] run with this guarantee() in place.
> It hasn't fired in Mach5 Tier[1-7]; Tier8 is still running, but it hasn't
> fired yet. What this means is that we don't currently have a test case that
> always exercises the unprotected path; we might have a test case that 
> sometimes exercises the unprotected path depending on timing and/or
> options, but nothing so far. My intention with this fix is not to leave any
> unprotected paths for JavaThread::get_thread_name() and these test results
> give me confidence, but not complete assurance.

Here's another thing that I noticed and want to discuss with the reviwers:

I added a new comment above the simpler assert that I restored into
JavaThread::get_thread_name():

  // Note: Since this JavaThread isn't protected by a TLH, the call to
  // this->is_handshake_safe_for() may crash, but we have debug bits so...
  assert(SafepointSynchronize::is_at_safepoint() ||
         this->is_handshake_safe_for(current_thread), "JavaThread="
         INTPTR_FORMAT " is not protected, not at a safepoint and "
         "not handshake safe.", p2i(this));

The baseline code used:

  `assert_locked_or_safepoint_or_handshake(Threads_lock, this);`

and that function looks like this:

void assert_locked_or_safepoint_or_handshake(const Mutex* lock, const JavaThread* thread) {
  if (thread->is_handshake_safe_for(Thread::current())) return;
  assert_locked_or_safepoint(lock);
}

and is_handshake_safe_for() looks like this:

  // A JavaThread can always safely operate on it self and other threads
  // can do it safely if they are the active handshaker.
  bool is_handshake_safe_for(Thread* th) const {
    return _handshake.active_handshaker() == th || this == th;
  }

so the baseline code is also using "this" JavaThread without knowing that
it is safe. The interesting thing about is_handshake_safe_for() is that it
*is safe* if the target is the active handshaker for the current thread.
However, if the target is not the active handshaker for the current thread,
then calling `thread->is_handshake_safe_for()` and accessing the
`_handshake` field in that JavaThread may not be safe.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2535

From dcubed at openjdk.java.net  Sat Feb 20 17:52:46 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sat, 20 Feb 2021 17:52:46 GMT
Subject: RFR: 8241403: JavaThread::get_thread_name() should be
 ThreadSMR-aware [v3]
In-Reply-To: <5gkJEEicbil9yoagDv5-SOKgPlfC-lXoJ0Ii8GBIRJA=.6df4da11-0487-4fa5-8897-d702dde7aba8@github.com>
References: <wRdcRQurtpybntK9Qpji-6zVY-EcHKw3q87xpD0eoS4=.a6dc32f4-2919-42e9-80c3-5a264067f0e2@github.com>
 <yER6SKX-lfZsdJmls-clFnBnZd-SWbJkCF4kO_OZg-o=.64d2e6af-47ea-4f82-9a9a-fec6395a2ad5@github.com>
 <LwyuPftEZnuGNnUAjr3ar5upnTHEBRZF9JRtdciVc1s=.64695cc9-0139-4efd-aa4d-e5c57eddca9f@github.com>
 <xVPLwLdUNsPogD1lTYOn6EQPsCxzX5xEz_Ywk83SsYE=.f7604702-37e0-43b8-942f-3eed91ab4080@github.com>
 <f2-3fMnQfaXdlEhsCVDZVbEFCbsR5-NDASaLs5ms_do=.20846bed-a318-4334-a833-ac4a3e8b68f9@github.com>
 <5gkJEEicbil9yoagDv5-SOKgPlfC-lXoJ0Ii8GBIRJA=.6df4da11-0487-4fa5-8897-d702dde7aba8@github.com>
Message-ID: <IWbFkJKGwmqUF7ToRS4FiOo4WxFoqV2Gpg8-zKFdjjI=.5c88594d-1ecc-4076-b709-3f948c1d5b08@github.com>

On Sat, 20 Feb 2021 17:47:07 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> The changes in CR2 are:
>> 
>> - Make Thread::is_JavaThread_protected() static and make it clear that
>>   it checks to see if the calling thread is protecting the target;
>>   added VMThread access as always protected.
>> - Revert changes in JvmtiTrace::safe_get_thread_name().
>> - Revert the JavaThread::get_thread_name() default_name parameter and
>>   don't create a ThreadsListHandle in the function; restore a simpler
>>   assert for the case where the target thread is not protected.
>> - Add Threads::threads_do() and Threads::java_threads_do() that work
>>   with a JavaThreadIteratorWithHandle.
>> - Update src/hotspot/share/services/management.cpp to switch from using
>>   the Threads_lock to using JavaThreadIteratorWithHandle.
>> - Redo compileBroker.cpp changes to use a ThreadsListHandle to protect 
>>   the CompilerThread/JavaThread.
>> - Remove a stale comment from src/hotspot/share/prims/jvm.cpp.
>> 
>> You'll notice some temporary testing code in JavaThread::get_thread_name():
>> 
>>   guarantee(false, "current_thread=" INTPTR_FORMAT
>>             " is not protecting this=" INTPTR_FORMAT,
>>             p2i(current_thread), p2i(this));
>> 
>> I'm doing my current Mach5 Tier[1-8] run with this guarantee() in place.
>> It hasn't fired in Mach5 Tier[1-7]; Tier8 is still running, but it hasn't
>> fired yet. What this means is that we don't currently have a test case that
>> always exercises the unprotected path; we might have a test case that 
>> sometimes exercises the unprotected path depending on timing and/or
>> options, but nothing so far. My intention with this fix is not to leave any
>> unprotected paths for JavaThread::get_thread_name() and these test results
>> give me confidence, but not complete assurance.
>
> Here's another thing that I noticed and want to discuss with the reviwers:
> 
> I added a new comment above the simpler assert that I restored into
> JavaThread::get_thread_name():
> 
>   // Note: Since this JavaThread isn't protected by a TLH, the call to
>   // this->is_handshake_safe_for() may crash, but we have debug bits so...
>   assert(SafepointSynchronize::is_at_safepoint() ||
>          this->is_handshake_safe_for(current_thread), "JavaThread="
>          INTPTR_FORMAT " is not protected, not at a safepoint and "
>          "not handshake safe.", p2i(this));
> 
> The baseline code used:
> 
>   `assert_locked_or_safepoint_or_handshake(Threads_lock, this);`
> 
> and that function looks like this:
> 
> void assert_locked_or_safepoint_or_handshake(const Mutex* lock, const JavaThread* thread) {
>   if (thread->is_handshake_safe_for(Thread::current())) return;
>   assert_locked_or_safepoint(lock);
> }
> 
> and is_handshake_safe_for() looks like this:
> 
>   // A JavaThread can always safely operate on it self and other threads
>   // can do it safely if they are the active handshaker.
>   bool is_handshake_safe_for(Thread* th) const {
>     return _handshake.active_handshaker() == th || this == th;
>   }
> 
> so the baseline code is also using "this" JavaThread without knowing that
> it is safe. The interesting thing about is_handshake_safe_for() is that it
> *is safe* if the target is the active handshaker for the current thread.
> However, if the target is not the active handshaker for the current thread,
> then calling `thread->is_handshake_safe_for()` and accessing the
> `_handshake` field in that JavaThread may not be safe.

The CR2 changes are being tested with Mach5 Tier[1-8]:


    Mach5 Tier[1245] - no failures
    Mach5 Tier6 - 2 unrelated, known failures
    Mach5 Tier7 - 3 unrelated, known failures
    Mach5 Tier8 - still running, no failures so far

-------------

PR: https://git.openjdk.java.net/jdk/pull/2535

From cjplummer at openjdk.java.net  Sat Feb 20 20:49:40 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Sat, 20 Feb 2021 20:49:40 GMT
Subject: RFR: 8261857: serviceability/sa/ClhsdbPrintAll.java failed with
 "Test ERROR java.lang.RuntimeException: 'cannot be cast to' found in stdout"
In-Reply-To: <vPPSAOSuM9tw6jDZUp49wHLBlRHm-aZqHl6wxGkCNI0=.3c3f9786-7178-474b-8015-8f531c69d358@github.com>
References: <Hb_DUhlaogiehEC-bhiW11Y4R0Y76X_KXJ7NYNJLmwY=.d2815725-6b32-4750-bbd0-ae90a88eb3e9@github.com>
 <vPPSAOSuM9tw6jDZUp49wHLBlRHm-aZqHl6wxGkCNI0=.3c3f9786-7178-474b-8015-8f531c69d358@github.com>
Message-ID: <9JTrcJvGvj2S7078HERFYLU55soyjHFobOObsJ5Ltao=.a56add93-076c-49ea-ab95-4093b0fd64f6@github.com>

On Sat, 20 Feb 2021 10:21:52 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The test is checking for "cannot be cast to" because at one point there was a bug in `printall` that was causing a `ClassCastException`. See [JDK-8175384](https://bugs.openjdk.java.net/browse/JDK-8175384). However, there is also a "cannot be cast to" message in the `printall` output when disassembling since the java source actually has it in a string literal:
>> 
>>  3203 302 ldc #214(6) <String " cannot be cast to ResourceBundle"> [fast_aldc]
>> 
>> Which comes from the following in the ResourceBundle.java source:
>> 
>>                         throw new ClassCastException(c.getName()
>>                                 + " cannot be cast to ResourceBundle"); 
>> 
>> So this occurrence of "cannot be cast" is fine. The one we don't want comes from `SharedRuntime::generate_class_cast_message()` in `sharedRuntime.cpp`:
>> 
>> `                 "class %s cannot be cast to class %s (%s%s%s)",`
>> 
>> So we can avoid this bug by changing the check to be a bit more explicit and check for "cannot be cast to class" instead.
>
> This looks good and trivial.

Thanks Serguei!

-------------

PR: https://git.openjdk.java.net/jdk/pull/2624

From cjplummer at openjdk.java.net  Sat Feb 20 20:49:41 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Sat, 20 Feb 2021 20:49:41 GMT
Subject: Integrated: 8261857: serviceability/sa/ClhsdbPrintAll.java failed
 with "Test ERROR java.lang.RuntimeException: 'cannot be cast to' found in
 stdout"
In-Reply-To: <Hb_DUhlaogiehEC-bhiW11Y4R0Y76X_KXJ7NYNJLmwY=.d2815725-6b32-4750-bbd0-ae90a88eb3e9@github.com>
References: <Hb_DUhlaogiehEC-bhiW11Y4R0Y76X_KXJ7NYNJLmwY=.d2815725-6b32-4750-bbd0-ae90a88eb3e9@github.com>
Message-ID: <jSgdwL2BTru6zJiz7GEEjXdCv4Iuz8EP4MuqWsoVW2E=.f2265eac-06f6-4384-b5f6-48dcfc9ceaca@github.com>

On Thu, 18 Feb 2021 06:13:27 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The test is checking for "cannot be cast to" because at one point there was a bug in `printall` that was causing a `ClassCastException`. See [JDK-8175384](https://bugs.openjdk.java.net/browse/JDK-8175384). However, there is also a "cannot be cast to" message in the `printall` output when disassembling since the java source actually has it in a string literal:
> 
>  3203 302 ldc #214(6) <String " cannot be cast to ResourceBundle"> [fast_aldc]
> 
> Which comes from the following in the ResourceBundle.java source:
> 
>                         throw new ClassCastException(c.getName()
>                                 + " cannot be cast to ResourceBundle"); 
> 
> So this occurrence of "cannot be cast" is fine. The one we don't want comes from `SharedRuntime::generate_class_cast_message()` in `sharedRuntime.cpp`:
> 
> `                 "class %s cannot be cast to class %s (%s%s%s)",`
> 
> So we can avoid this bug by changing the check to be a bit more explicit and check for "cannot be cast to class" instead.

This pull request has now been integrated.

Changeset: c2509ea9
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c2509ea9
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8261857: serviceability/sa/ClhsdbPrintAll.java failed with "Test ERROR java.lang.RuntimeException: 'cannot be cast to' found in stdout"

Reviewed-by: sspitsyn

-------------

PR: https://git.openjdk.java.net/jdk/pull/2624

From cjplummer at openjdk.java.net  Sat Feb 20 20:51:42 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Sat, 20 Feb 2021 20:51:42 GMT
Subject: RFR: 8261929: ClhsdbFindPC fails with java.lang.RuntimeException:
 'In java stack' missing from stdout/stderr
In-Reply-To: <nc2-WikQv9OQzcUhIbdiiEHMJXqZhIW4GpgwL1HM7Fg=.b5e9e895-ef80-4c46-b8bc-c9b68ba21d13@github.com>
References: <yNakPYlp6Q6YF6NB6db7IyAhAqMvgUc9dq6p6CAJJYU=.41bdf544-1b81-4a90-a3a7-e3207fb1fc9d@github.com>
 <nc2-WikQv9OQzcUhIbdiiEHMJXqZhIW4GpgwL1HM7Fg=.b5e9e895-ef80-4c46-b8bc-c9b68ba21d13@github.com>
Message-ID: <PaVcAwXdW8Lb783G3hHkY8zObMEYkpCXjM0CThLjZAc=.93048842-794d-470c-88df-c2dc86f88c2b@github.com>

On Sat, 20 Feb 2021 10:24:02 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Sometimes due to the state of the java thread, jstack does cannot determine the address of the java frame and instead it is 0x. We need to special case this so the test does not fail.
>
> LGTM++

Thanks for the reviews!

-------------

PR: https://git.openjdk.java.net/jdk/pull/2637

From cjplummer at openjdk.java.net  Sat Feb 20 20:51:43 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Sat, 20 Feb 2021 20:51:43 GMT
Subject: Integrated: 8261929: ClhsdbFindPC fails with
 java.lang.RuntimeException: 'In java stack' missing from stdout/stderr
In-Reply-To: <yNakPYlp6Q6YF6NB6db7IyAhAqMvgUc9dq6p6CAJJYU=.41bdf544-1b81-4a90-a3a7-e3207fb1fc9d@github.com>
References: <yNakPYlp6Q6YF6NB6db7IyAhAqMvgUc9dq6p6CAJJYU=.41bdf544-1b81-4a90-a3a7-e3207fb1fc9d@github.com>
Message-ID: <eyisjgyjUZX_Y4kilJNmFDqbAmopD-noQWku9BtuXZM=.20053602-58ce-440f-9b66-0c4a71dfa3b0@github.com>

On Fri, 19 Feb 2021 01:04:20 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Sometimes due to the state of the java thread, jstack does cannot determine the address of the java frame and instead it is 0x. We need to special case this so the test does not fail.

This pull request has now been integrated.

Changeset: 0825bc55
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0825bc55
Stats:     9 lines in 1 file changed: 4 ins; 0 del; 5 mod

8261929: ClhsdbFindPC fails with java.lang.RuntimeException: 'In java stack' missing from stdout/stderr

Reviewed-by: amenkov, stuefe, sspitsyn

-------------

PR: https://git.openjdk.java.net/jdk/pull/2637

From cjplummer at openjdk.java.net  Sat Feb 20 23:22:40 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Sat, 20 Feb 2021 23:22:40 GMT
Subject: RFR: 8261692:  Bugs in clhsdb history support
In-Reply-To: <OW4MJ7tEggC9Da-UHM3P1uNpQXNS09sjtkNbXoyatn0=.9286202e-4596-4f59-8631-ae420351cb99@github.com>
References: <3-9ngFZ9SzLX-MwIVN4fDjJAnbjqkt5Q0U8mah-tzHc=.ce625e90-080f-41b4-9227-771ea43b10b7@github.com>
 <OW4MJ7tEggC9Da-UHM3P1uNpQXNS09sjtkNbXoyatn0=.9286202e-4596-4f59-8631-ae420351cb99@github.com>
Message-ID: <n_SZV8ADX_-8475u04ppIU-3cy3U8jVo3yyZOwDeS88=.28312daa-5012-42a9-be79-d866d7e3beb5@github.com>

On Sat, 20 Feb 2021 10:17:35 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> See the CR for a description of the 3 issues fixed. There's also a new test added. I'll explain the fix related to quoting the '!' here since it's not that obvious how it works.
>> 
>> There's a complex pattern called `historyPattern` that is used to find various uses of ! to do expansion of commands and arguments in the history
>> 
>>     static Pattern historyPattern = Pattern.compile("([\\\]?)((!\*)|(!\$)|(!!-?)|(!-?[0-9][0-9]*)|(![a-zA-Z][^ ]*))");
>> 
>> I added the `([\\\]?)` part to handle allowing a '!' to be quoted with a backslash so it will just be treated as a '!' instead of being used for history expansion. This part of the pattern basically says match 1 backslash if present. Yes, you need 4 backslashes to do this. javac will reduce it to two, and then the pattern compilation reduces it down to just one backslash (not to be used for quoting).
>> 
>> The above pattern for searching for the backslash before a '!' is in the first pattern grouping, and the part that matches on the '!' and what follows is in the 2nd pattern grouping. Thus the code I added checks if the first pattern grouping matches something (and at most it will match just one backslash), and if so then we eat it and don't treat the '!' that follows as a history expansion:
>> 
>>                     if (m.group(1).length() != 0) {
>>                         // This means we matched a `` before the '!'. Don't do any history
>>                         // expansion in this case. Just capture what matched after the ``.
>>                         result.append(m.group(2));
>>                         continue;
>>                     }
>
> Looks good.

Thanks for the reviews!

-------------

PR: https://git.openjdk.java.net/jdk/pull/2565

From cjplummer at openjdk.java.net  Sat Feb 20 23:22:42 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Sat, 20 Feb 2021 23:22:42 GMT
Subject: Integrated: 8261692:  Bugs in clhsdb history support
In-Reply-To: <3-9ngFZ9SzLX-MwIVN4fDjJAnbjqkt5Q0U8mah-tzHc=.ce625e90-080f-41b4-9227-771ea43b10b7@github.com>
References: <3-9ngFZ9SzLX-MwIVN4fDjJAnbjqkt5Q0U8mah-tzHc=.ce625e90-080f-41b4-9227-771ea43b10b7@github.com>
Message-ID: <1ERdEcSaFvTKI-_iqTeP2lCd5K2k8JfWajME2r8paSc=.1865663c-9ed7-4a20-8dd8-97b307374909@github.com>

On Sun, 14 Feb 2021 08:45:26 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> See the CR for a description of the 3 issues fixed. There's also a new test added. I'll explain the fix related to quoting the '!' here since it's not that obvious how it works.
> 
> There's a complex pattern called `historyPattern` that is used to find various uses of ! to do expansion of commands and arguments in the history
> 
>     static Pattern historyPattern = Pattern.compile("([\\\]?)((!\*)|(!\$)|(!!-?)|(!-?[0-9][0-9]*)|(![a-zA-Z][^ ]*))");
> 
> I added the `([\\\]?)` part to handle allowing a '!' to be quoted with a backslash so it will just be treated as a '!' instead of being used for history expansion. This part of the pattern basically says match 1 backslash if present. Yes, you need 4 backslashes to do this. javac will reduce it to two, and then the pattern compilation reduces it down to just one backslash (not to be used for quoting).
> 
> The above pattern for searching for the backslash before a '!' is in the first pattern grouping, and the part that matches on the '!' and what follows is in the 2nd pattern grouping. Thus the code I added checks if the first pattern grouping matches something (and at most it will match just one backslash), and if so then we eat it and don't treat the '!' that follows as a history expansion:
> 
>                     if (m.group(1).length() != 0) {
>                         // This means we matched a `` before the '!'. Don't do any history
>                         // expansion in this case. Just capture what matched after the ``.
>                         result.append(m.group(2));
>                         continue;
>                     }

This pull request has now been integrated.

Changeset: 18188c2a
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/18188c2a
Stats:     117 lines in 2 files changed: 114 ins; 0 del; 3 mod

8261692: Bugs in clhsdb history support

Reviewed-by: amenkov, sspitsyn

-------------

PR: https://git.openjdk.java.net/jdk/pull/2565

From prr at openjdk.java.net  Sun Feb 21 16:42:50 2021
From: prr at openjdk.java.net (Phil Race)
Date: Sun, 21 Feb 2021 16:42:50 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v18]
In-Reply-To: <ix6gQkIFb_3zkw3EwW6PbnsHBPwjoai9kux5-O3SM7E=.a36d66e9-97cc-4240-8512-4850a0daa02c@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <ix6gQkIFb_3zkw3EwW6PbnsHBPwjoai9kux5-O3SM7E=.a36d66e9-97cc-4240-8512-4850a0daa02c@github.com>
Message-ID: <xMEaKU7b3YMVWg-8k60DUpB6VB2iydn3eIdmiDRWOAs=.cbd4ab4d-3a5e-4c1f-9f2a-cbe4e7efdbac@github.com>

On Wed, 17 Feb 2021 12:36:10 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 88 commits:
> 
>  - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos
>  - Re-do safefetch.hpp
>  - Merge remote-tracking branch 'origin/jdk/8261075-stubroutines-inline' into jdk-macos
>  - stubRoutines.inline.hpp -> safefetch.hpp
>  - Update copyrights
>  - Merge remote-tracking branch 'upstream/jdk/master' into 8261075-stubroutines-inline
>  - Merge remote-tracking branch 'upstream/jdk/master' into 8261075-stubroutines-inline
>  - Extract SafeFetch32/N to stubRoutines.inline.hpp
>  - Revert "Extract SafeFetch32/N to stubRoutines.inline.hpp"
>    
>    This reverts commit b873c25f31dd21349d140b790713cc9ccb5f2dc0.
>  - Merge pull request #9 from VladimirKempik/pull/2200
>    
>    Removed unused variables
>  - ... and 78 more: https://git.openjdk.java.net/jdk/compare/b955f85e...ab72613c

Looks like the compiler warning changess are now the only desktop changes.
That is fine by me.

-------------

Marked as reviewed by prr (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2200

From cjplummer at openjdk.java.net  Sun Feb 21 19:01:39 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Sun, 21 Feb 2021 19:01:39 GMT
Subject: Integrated: 8261702: ClhsdbFindPC can fail due to PointerFinder
 incorrectly thinking an address is in a .so
In-Reply-To: <AFSFgu2cWGvCRDEq5jI67rk-Xwx1Xc3v2B3E81WjVJY=.3e2a4488-2e85-46b2-89f8-0da1bc349a99@github.com>
References: <AFSFgu2cWGvCRDEq5jI67rk-Xwx1Xc3v2B3E81WjVJY=.3e2a4488-2e85-46b2-89f8-0da1bc349a99@github.com>
Message-ID: <LNz2e6_2owdAD_Wu2gfy9PCZoJq3wsd-Yklme0VXCJU=.ac85a6d8-f0d3-468d-a1c4-1f05432f2e50@github.com>

On Sat, 13 Feb 2021 19:05:17 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> See bug description for details. The fix is simple and just a matter of moving some code to avoid incorrectly thinking an address is in a .so when it is in some other area of VM memory that occurs just after the last .so.

This pull request has now been integrated.

Changeset: 539c80bf
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/539c80bf
Stats:     24 lines in 1 file changed: 13 ins; 11 del; 0 mod

8261702: ClhsdbFindPC can fail due to PointerFinder incorrectly thinking an address is in a .so

Reviewed-by: ysuenaga, kevinw, sspitsyn

-------------

PR: https://git.openjdk.java.net/jdk/pull/2562

From dholmes at openjdk.java.net  Mon Feb 22 01:55:03 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 22 Feb 2021 01:55:03 GMT
Subject: RFR: 8241403: JavaThread::get_thread_name() should be
 ThreadSMR-aware [v4]
In-Reply-To: <6MUhGSRe79fD3SkU0sbPKDneAQMpJvpVvL1uwImO7vI=.d28b3e10-5527-4df6-b554-c21ba598db56@github.com>
References: <wRdcRQurtpybntK9Qpji-6zVY-EcHKw3q87xpD0eoS4=.a6dc32f4-2919-42e9-80c3-5a264067f0e2@github.com>
 <6MUhGSRe79fD3SkU0sbPKDneAQMpJvpVvL1uwImO7vI=.d28b3e10-5527-4df6-b554-c21ba598db56@github.com>
Message-ID: <hz-UIqnBo7HLeumeNfO_6YqGw13SebRDeMMb9yg71a0=.21788f6e-58f6-45ec-b3a2-eb57365e61ae@github.com>

On Sat, 20 Feb 2021 17:50:01 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> A minor fix to add a new function:
>> 
>>     bool Thread::is_JavaThread_protected(const JavaThread* p)
>> 
>> that returns true when the target JavaThread* is protected and false
>> otherwise. Update JavaThread::get_thread_name() to create a
>> ThreadsListHandle and use the new is_JavaThread_protected(). Also
>> update JvmtiTrace::safe_get_thread_name() to use the new
>> is_JavaThread_protected().
>> 
>> This fix is tested via a Mach5 Tier[1-8] run.
>
> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address dholmes-ora CR1 comments.

Hi Dan,

Still a few comments/concerns - see below.

Thanks,
David

src/hotspot/share/compiler/compileBroker.cpp line 1007:

> 1005:       assert(ct != NULL, "should have been handled for initial thread");
> 1006:       ThreadsListHandle tlh;
> 1007:       assert(tlh.includes(ct), "ct=" INTPTR_FORMAT " exited unexpectedly.", p2i(ct));

This case seems to be one where we are creating an immortal compiler thread (either because they are all immortal, or this is the first compiler thread and it is always immortal (verify that?)) - so the assert seems fine.

src/hotspot/share/compiler/compileBroker.cpp line 1028:

> 1026:       assert(ct != NULL, "should have been handled for initial thread");
> 1027:       ThreadsListHandle tlh;
> 1028:       assert(tlh.includes(ct), "ct=" INTPTR_FORMAT " exited unexpectedly.", p2i(ct));

Ditto

src/hotspot/share/compiler/compileBroker.cpp line 1115:

> 1113:       if (ct == NULL) break;
> 1114:       ThreadsListHandle tlh;
> 1115:       assert(tlh.includes(ct), "ct=" INTPTR_FORMAT " exited unexpectedly.", p2i(ct));

This seems to be the fully dynamic case. Here the TLH is potentially racing with thread termination and so may or may not capture ct. Rather than an assertion the call to  `get_thread_name()` below should be guarded by `tlh.includes(ct)`.

src/hotspot/share/compiler/compileBroker.cpp line 1136:

> 1134:       if (ct == NULL) break;
> 1135:       ThreadsListHandle tlh;
> 1136:       assert(tlh.includes(ct), "ct=" INTPTR_FORMAT " exited unexpectedly.", p2i(ct));

Ditto - the assert is not appropriate for this case.

src/hotspot/share/runtime/thread.cpp line 485:

> 483: #endif
> 484: 
> 485: // Is the target JavaThread protected by the calling Thread:

s/calling/current/ ?

We could also expand this to clarify that even if a target JavaThread is not explicitly protected by the current thread it can still be safe to access if the two threads engage in a suitable protocol.

src/hotspot/share/runtime/thread.cpp line 2568:

> 2566:   // this->is_handshake_safe_for() may crash, but we have debug bits so...
> 2567:   assert(SafepointSynchronize::is_at_safepoint() ||
> 2568:          this->is_handshake_safe_for(current_thread), "JavaThread="

I agree this is a pre-existing bug as accessing `this` may not be safe if the target is not protected. But if we crash attempting the access that implies the assert failed so ...

src/hotspot/share/services/management.cpp line 848:

> 846:   {
> 847:     JavaThreadIteratorWithHandle jtiwh;
> 848:     Threads::threads_do(&jtiwh, &vmtcc);

I'm not sure this is at all necessary. Threads::add and Threads::remove still use the Threads_lock so this code is safe as it stands. Switching to  use JTIWH may be an alternative, and may even be desirable, but that hasn't been established, and is not necessary for safety and so seems outside the scope of this bug IMO.

-------------

Changes requested by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2535

From rschmelter at openjdk.java.net  Mon Feb 22 05:55:40 2021
From: rschmelter at openjdk.java.net (Ralf Schmelter)
Date: Mon, 22 Feb 2021 05:55:40 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v10]
In-Reply-To: <6l7TqqEmupdBa2J8b_NlWif5oVY2SGpu7iKeJMM97ic=.bf63c6e2-878d-4c2a-9a1e-336419c88b58@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
 <6l7TqqEmupdBa2J8b_NlWif5oVY2SGpu7iKeJMM97ic=.bf63c6e2-878d-4c2a-9a1e-336419c88b58@github.com>
Message-ID: <CvuSjdeAKN93mwFqzHEya8ho-ONmC_TYAokqDeat3RQ=.ab576df3-1635-45d6-a72f-7aac0a55c34e@github.com>

On Fri, 19 Feb 2021 14:36:00 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:
> 
>   fix build fail issue on windows

Hi,

I've benchmarked the code on my machine (128GB memory, 56 logical CPUs) with an example creating a 32 GB heap dump. I only saw a 10 percent reduction in time, both using uncompressed and compressed dumps. Have you seen better numbers in your benchmarks?

And it seems to potentially use a lot more temporary memory. In my example I had a 4 GB array in the heap and the new code allocated 4 GB of additional memory to write this array. This could happen in more threads in parallel, increasing the memory consumption even more.

If the above problems could be fixed, I would suggest to just use the parallel code in all cases.

src/hotspot/share/services/heapDumper.cpp line 383:

> 381: };
> 382: 
> 383: // Supports I/O ooperations for a dump

ooperations->operations

src/hotspot/share/services/heapDumper.cpp line 650:

> 648:   void enqueue(ParWriterBufferQueueElem* entry) {
> 649:     if (_head == NULL) {
> 650:       assert(is_empty() && _tail == NULL, "Sanity check");

When I have run the code with assertions enabled, this one failed since _tail was not NULL.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2261

From lzang at openjdk.java.net  Mon Feb 22 07:38:56 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Mon, 22 Feb 2021 07:38:56 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v10]
In-Reply-To: <CvuSjdeAKN93mwFqzHEya8ho-ONmC_TYAokqDeat3RQ=.ab576df3-1635-45d6-a72f-7aac0a55c34e@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>
Message-ID: <ebrfA2bFIIPhcpZkO75uUvbJ3aMJFoHq_JR46AAEdfQ=.e3dee042-dff0-4b80-8cb0-5c9dae722be7@github.com>

On Mon, 22 Feb 2021 05:53:19 GMT, Ralf Schmelter <rschmelter at openjdk.org> wrote:

>> Lin Zang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix build fail issue on windows
>
> Hi,
> 
> I've benchmarked the code on my machine (128GB memory, 56 logical CPUs) with an example creating a 32 GB heap dump. I only saw a 10 percent reduction in time, both using uncompressed and compressed dumps. Have you seen better numbers in your benchmarks?
> 
> And it seems to potentially use a lot more temporary memory. In my example I had a 4 GB array in the heap and the new code allocated 4 GB of additional memory to write this array. This could happen in more threads in parallel, increasing the memory consumption even more.
> 
> If the above problems could be fixed, I would suggest to just use the parallel code in all cases.

Hi @schmelter-sap,
Thanks a lot for reviewing and benchmarking. 

> I've benchmarked the code on my machine (128GB memory, 56 logical CPUs) with an example creating a 32 GB heap dump. I only saw a 10 percent reduction in time, both using uncompressed and compressed dumps. Have you seen better numbers in your benchmarks?
>
> And it seems to potentially use a lot more temporary memory. In my example I had a 4 GB array in the heap and the new code allocated 4 GB of additional memory to write this array. This could happen in more threads in parallel, increasing the memory consumption even more.

I have done some preliminary test on my machine (16GB, 8 core), the data are shown as follow:
`$ jmap -dump:file=dump4.bin,parallel=4 127420`
`Dumping heap to /home/lzang1/Source/jdk/dump4.bin ...`
`Heap dump file created [932950649 bytes in 0.591 secs]`
`$ jmap -dump:file=dump1.bin,parallel=1 127420`
`Dumping heap to /home/lzang1/Source/jdk/dump1.bin ...`
`Heap dump file created [932950739 bytes in 2.957 secs]`

But I do have observed unstable data reported on a machine with more cores and larger RAM, plus a workload with more heap usage. I thought that may be related with the memory consumption as you mentioned. And I am investigating the way to optimize it.

> If the above problems could be fixed, I would suggest to just use the parallel code in all cases.
Thanks a lot! I will let you know when I make some progress on optimization.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2261

From kevinw at openjdk.java.net  Mon Feb 22 12:07:40 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Mon, 22 Feb 2021 12:07:40 GMT
Subject: RFR: 8261269: When using clhsdb to "inspect" a java object,
 clhsdb prints "Oop for..." twice [v2]
In-Reply-To: <IA04M2nZaQKP4T8SFUy1u66aJAbVgM5pouh7iNBoXYg=.f9c0559d-d75d-44ca-8b19-434b59fe865d@github.com>
References: <ZMXuV3A7BSpkJtmlUlvtMCL6beFGJNFWGxIbdMS9kYI=.b9e00805-9edc-4b29-b2e5-a8734791f4c0@github.com>
 <IA04M2nZaQKP4T8SFUy1u66aJAbVgM5pouh7iNBoXYg=.f9c0559d-d75d-44ca-8b19-434b59fe865d@github.com>
Message-ID: <tsF1_BPJHh74QVYliQOcVYyKaMOQQTB504qLyB_2LYQ=.a89868e6-6a71-4104-86c4-14ef9aa5a0b7@github.com>

On Thu, 18 Feb 2021 06:43:01 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> See CR for details. In brief, fixed the `inspect` command to remove duplicate output:
>> 
>> hsdb> inspect 0x00000007fef00770
>> instance of Oop for java/lang/Class @ 0x00000007fef00770 @ 0x00000007fef00770 (size = 160)
>> in: Oop for java/io/BufferedInputStream @ 0x0000000082005b08 Oop for java/io/BufferedInputStream @ 0x0000000082005b08
>> out: Oop for java/io/PrintStream @ 0x0000000082007b60 Oop for java/io/PrintStream @ 0x0000000082007b60
>> err: Oop for java/io/PrintStream @ 0x000000008200e0c8 Oop for java/io/PrintStream @ 0x000000008200e0c8 
>> It should be:
>> 
>> hsdb> inspect 0x00000007fef00770
>> instance of Oop for java/lang/Class @ 0x00000007fef00770 (size = 160)
>> in: Oop for java/io/BufferedInputStream @ 0x0000000082005b08
>> out: Oop for java/io/PrintStream @ 0x0000000082007b60
>> err: Oop for java/io/PrintStream @ 0x000000008200e0c8
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Put replicated strings into a local variable.

Marked as reviewed by kevinw (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2582

From kevinw at openjdk.java.net  Mon Feb 22 12:07:41 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Mon, 22 Feb 2021 12:07:41 GMT
Subject: RFR: 8261269: When using clhsdb to "inspect" a java object,
 clhsdb prints "Oop for..." twice [v2]
In-Reply-To: <3V_U0CgI3sW7LE1O6el65AkykEx3-Y6kwBcDp7GUPr4=.aa17426a-f31b-4f6f-a35f-f3f692d15181@github.com>
References: <ZMXuV3A7BSpkJtmlUlvtMCL6beFGJNFWGxIbdMS9kYI=.b9e00805-9edc-4b29-b2e5-a8734791f4c0@github.com>
 <XnpJKuLybz4Fcghw6bdu6cq34SapMCzpP0gLnwWKZUM=.57283da1-91d0-4d5f-a64a-fff049f8391d@github.com>
 <3V_U0CgI3sW7LE1O6el65AkykEx3-Y6kwBcDp7GUPr4=.aa17426a-f31b-4f6f-a35f-f3f692d15181@github.com>
Message-ID: <dhmJxHlx-vOt4tbtXFD-7VTDR2rxD5_kol0qII_4bk0=.569d764b-49f4-4722-a850-274433413ef9@github.com>

On Thu, 18 Feb 2021 06:43:04 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> It looks good to me.
>> One side comment about the test. It is not easy to read the code with the same pattern (e.g. "Oop for java/io/BufferedInputStream") repeated several times. I understand, you prefer to make it more explicit but it'd be more readable if a predefined pattern is used like below:
>>     String pattern = "Oop for java/io/BufferedInputStream";
>> +            expStrMap.put(cmd, List.of("instance of Oop for java/lang/Class @ " + examineResult,
>> +                                       "in: " + pattern + @"));
>> . . .
>> +            unexpStrMap.put(cmd, List.of(
>> +                    "instance of Oop for java/lang/Class @ "  + examineResult + " @ " + examineResult,
>> +                    "in: " + pattern + " .* " + pattern));
>> 
>> Just an opinion with no pressure. It is up to you.
>> 
>> Thanks,
>> Serguei
>
> Good idea. I've added the pattern strings. Thanks!

That's great, much more readable output!
Looks good.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2582

From dfuchs at openjdk.java.net  Mon Feb 22 17:36:40 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 22 Feb 2021 17:36:40 GMT
Subject: RFR: 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: <rtx358tyuPcu1urptoLF5-1nfxlDows1xCrle5hWp7c=.5934148d-0c0e-4fcb-9bff-94e6ca02e804@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)

I don't see any specific issue with the proposed change but I don't know the JDWP tests enough to provide more feedback than that. Do you have special test cases for the IPv6 loopback? AFAIU this code here will filter it out?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2633

From daniel.daugherty at oracle.com  Mon Feb 22 18:17:23 2021
From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com)
Date: Mon, 22 Feb 2021 13:17:23 -0500
Subject: JvmtiExport::can_walk_any_space() usage in hotspot
In-Reply-To: <365ef5a026a84e81917462643ea4bc97@tencent.com>
References: <365ef5a026a84e81917462643ea4bc97@tencent.com>
Message-ID: <15ea918b-2d8a-b021-f5d0-ed1af1f4c84c@oracle.com>

Adding serviceability-dev at ... to this email thread since JVM/TI
is maintained by the Serviceability Team...

Dan


On 2/22/21 3:29 AM, kalinshi(??) wrote:
> Hi hotspot experts,
>
> Would you help on my question about JvmtiExport::can_walk_any_space() check?
> Question is why JvmtiExport::can_walk_any_space() check is needed in CDS when mapping region?
>
> JvmtiExport::can_walk_any_space() method is only used in FileMapInfo::map_region for modifing region read-only mapping attribute.
> JvmtiExport::can_walk_any_space() is set true when jvmtiCapabilities.can_tag_objects is enabled.
> JVMTI capability can_tag_objects enables java heap iteration/object reference tracing, and JvmtiEnv::Set/GetTag doesn't modify read-only regions in shared archive (I might wrong).
>
> comments in latest code seems outdated, JvmtiExport::can_walk_any_space() doesn't disable sharing now.
> "
>    JvmtiExport::set_can_walk_any_space(
>      avail.can_tag_objects);   // disable sharing in onload phase
> "
>
> Back to initial code, class sharing is disabled when condition JvmtiExport::can_modify_any_class() || JvmtiExport::can_walk_any_space() is true.
> This matches above comment in JvmtiManageCapabilities::update.
> "
>    if (JvmtiExport::can_modify_any_class() || JvmtiExport::can_walk_any_space()) {
>      fail_continue("Tool agent requires sharing to be disabled.");
>      return false;
>    }
> "
>
> JvmtiExport::can_modify_any_class condition disables class data sharing when class file load hook (requires modify code and read only contents) is needed in initial code.
> Both checks are removed and used to determine region read/write attribute with following commits. These commits are mainly supporting class file load hook with CDS.
>
> 1. enable shared class when these tow checks on, modify/map all regions in shared archive as RW.
>     8054386: Allow Java debugging when CDS is enabled Map archive RW when debugging is enabled
>     8087153: EXCEPTION_ACCESS_VIOLATION when CDS RO section vanished on win32
>     
> 2. Support class file load hook with CDS
>     8141341: CDS should be disabled if JvmtiExport::should_post_class_file_load_hook() is true Disable loading shared class if JvmtiExport::should_post_class_file_load_hook is true.
>     8078644: CDS needs to support JVMTI CFLH Support posting CLFH for shared classes.
>     
> 3. Fix jvmtiCapabilities::can_generate_all_class_hook_events inconsistent state when shared
>     8161605: The '!UseSharedSpaces' check is not need in JvmtiManageCapabilities::recompute_always_capabilities
>     
> 4. Fix class file load hook error for early class hook event when shared
>     8212200: assert when shared java.lang.Object is redefined by JVMTI agent
>
> Regards
> Hui


From amenkov at openjdk.java.net  Mon Feb 22 20:05:46 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Mon, 22 Feb 2021 20:05:46 GMT
Subject: RFR: 8224775: test/jdk/com/sun/jdi/JdwpListenTest.java failed to
 attach
In-Reply-To: <rtx358tyuPcu1urptoLF5-1nfxlDows1xCrle5hWp7c=.5934148d-0c0e-4fcb-9bff-94e6ca02e804@github.com>
References: <pRiX1N1rR7NYrKg4y4BmHmB4vtRpCO0fVEZH0NMgkaM=.219d5434-25b9-4d5d-945a-27aaedefb6d2@github.com>
 <rtx358tyuPcu1urptoLF5-1nfxlDows1xCrle5hWp7c=.5934148d-0c0e-4fcb-9bff-94e6ca02e804@github.com>
Message-ID: <_gMHdO61dAhxqaV6sgpeK9j5ov_ZpMqKJwdVOxinkhY=.f12d083f-d593-41fd-90ba-4a16c3b0b2fe@github.com>

On Mon, 22 Feb 2021 17:34:03 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> 
> 
> I don't see any specific issue with the proposed change but I don't know the JDWP tests enough to provide more feedback than that. Do you have special test cases for the IPv6 loopback? AFAIU this code here will filter it out?

Good catch. IPv6 loopback addresses shouldn't be filtered out.
I'll update PR after re-testing

-------------

PR: https://git.openjdk.java.net/jdk/pull/2633

From amenkov at openjdk.java.net  Mon Feb 22 21:36:52 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Mon, 22 Feb 2021 21:36:52 GMT
Subject: RFR: 8224775: test/jdk/com/sun/jdi/JdwpListenTest.java failed to
 attach [v2]
In-Reply-To: <pRiX1N1rR7NYrKg4y4BmHmB4vtRpCO0fVEZH0NMgkaM=.219d5434-25b9-4d5d-945a-27aaedefb6d2@github.com>
References: <pRiX1N1rR7NYrKg4y4BmHmB4vtRpCO0fVEZH0NMgkaM=.219d5434-25b9-4d5d-945a-27aaedefb6d2@github.com>
Message-ID: <PmF4vYa0t07W4IJcPxGwFi3s0h2kCRMWo2oQF91poUM=.18a856cd-5e11-402c-ae7a-2afb6d36ae06@github.com>

> 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)

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  include loopback addresses in testing

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2633/files
  - new: https://git.openjdk.java.net/jdk/pull/2633/files/96176a61..4d59abf6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2633&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2633&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2633.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2633/head:pull/2633

PR: https://git.openjdk.java.net/jdk/pull/2633

From cjplummer at openjdk.java.net  Mon Feb 22 23:25:39 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Mon, 22 Feb 2021 23:25:39 GMT
Subject: RFR: 8261269: When using clhsdb to "inspect" a java object,
 clhsdb prints "Oop for..." twice [v2]
In-Reply-To: <tsF1_BPJHh74QVYliQOcVYyKaMOQQTB504qLyB_2LYQ=.a89868e6-6a71-4104-86c4-14ef9aa5a0b7@github.com>
References: <ZMXuV3A7BSpkJtmlUlvtMCL6beFGJNFWGxIbdMS9kYI=.b9e00805-9edc-4b29-b2e5-a8734791f4c0@github.com>
 <IA04M2nZaQKP4T8SFUy1u66aJAbVgM5pouh7iNBoXYg=.f9c0559d-d75d-44ca-8b19-434b59fe865d@github.com>
 <tsF1_BPJHh74QVYliQOcVYyKaMOQQTB504qLyB_2LYQ=.a89868e6-6a71-4104-86c4-14ef9aa5a0b7@github.com>
Message-ID: <sCzSszardJqdKKPWQIJef_HtQT9bUYq7EqvzkGgy9Hs=.277fd545-14c5-40aa-92d8-fe16837f3ddc@github.com>

On Mon, 22 Feb 2021 12:05:20 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Put replicated strings into a local variable.
>
> Marked as reviewed by kevinw (Committer).

Thanks Serguei and Kevin!

-------------

PR: https://git.openjdk.java.net/jdk/pull/2582

From cjplummer at openjdk.java.net  Mon Feb 22 23:25:40 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Mon, 22 Feb 2021 23:25:40 GMT
Subject: Integrated: 8261269: When using clhsdb to "inspect" a java object,
 clhsdb prints "Oop for..." twice
In-Reply-To: <ZMXuV3A7BSpkJtmlUlvtMCL6beFGJNFWGxIbdMS9kYI=.b9e00805-9edc-4b29-b2e5-a8734791f4c0@github.com>
References: <ZMXuV3A7BSpkJtmlUlvtMCL6beFGJNFWGxIbdMS9kYI=.b9e00805-9edc-4b29-b2e5-a8734791f4c0@github.com>
Message-ID: <RGU1dda67c6OEKyoywVHG4dWhkZs54Fcdij_ZGMkUp0=.6e23100e-c944-40d0-b62f-191d440b5e2b@github.com>

On Tue, 16 Feb 2021 07:28:45 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> See CR for details. In brief, fixed the `inspect` command to remove duplicate output:
> 
> hsdb> inspect 0x00000007fef00770
> instance of Oop for java/lang/Class @ 0x00000007fef00770 @ 0x00000007fef00770 (size = 160)
> in: Oop for java/io/BufferedInputStream @ 0x0000000082005b08 Oop for java/io/BufferedInputStream @ 0x0000000082005b08
> out: Oop for java/io/PrintStream @ 0x0000000082007b60 Oop for java/io/PrintStream @ 0x0000000082007b60
> err: Oop for java/io/PrintStream @ 0x000000008200e0c8 Oop for java/io/PrintStream @ 0x000000008200e0c8 
> It should be:
> 
> hsdb> inspect 0x00000007fef00770
> instance of Oop for java/lang/Class @ 0x00000007fef00770 (size = 160)
> in: Oop for java/io/BufferedInputStream @ 0x0000000082005b08
> out: Oop for java/io/PrintStream @ 0x0000000082007b60
> err: Oop for java/io/PrintStream @ 0x000000008200e0c8

This pull request has now been integrated.

Changeset: aea474c4
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/aea474c4
Stats:     117 lines in 2 files changed: 92 ins; 22 del; 3 mod

8261269: When using clhsdb to "inspect" a java object, clhsdb prints "Oop for..." twice

Reviewed-by: sspitsyn, kevinw

-------------

PR: https://git.openjdk.java.net/jdk/pull/2582

From cjplummer at openjdk.java.net  Tue Feb 23 02:57:39 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 23 Feb 2021 02:57:39 GMT
Subject: RFR: 8262157: LingeredApp.startAppExactJvmOpts does not print app
 output when launching fails
In-Reply-To: <w8znD1TZkMgc4oqfg0IHQRCp_Kv9tjEYR-hB7hpyngs=.1a422944-f3f0-427e-b7a9-ee5e78d2ef1f@github.com>
References: <w8znD1TZkMgc4oqfg0IHQRCp_Kv9tjEYR-hB7hpyngs=.1a422944-f3f0-427e-b7a9-ee5e78d2ef1f@github.com>
Message-ID: <I1MRRpGW3KiP4J1Eu8QeNtbAiqDGP4vgn0QL971w_FI=.c73543b0-b03e-4480-a3a5-fa86501c3c26@github.com>

On Mon, 22 Feb 2021 22:26:50 GMT, Yumin Qi <minqi at openjdk.org> wrote:

> Hi, Please review
> 
>  When debugging for other test case which uses jcmd to attach LingeredApp process, found there is no error information logged when the app started with function 'startAppExactJvmOpts' exits due to some reason. This is not convenient for trace what is the app failure.
>  This simple fix for adding finishApp to print out error information when LingeredApp could not start with startAppExactJvmOpts, this is similar to startApp.
> 
> Tests: This is a simple fix and done tests with test/jdk/sun/tools/jinfo which uses the function startAppExactJvmOpts to create LingeredApp, also the test case in debugging, which indeed captured the error message upon start error.
> 
> Thanks
> Yumin

test/lib/jdk/test/lib/apps/LingeredApp.java line 419:

> 417:             theApp.waitAppReady();
> 418:         } catch (Exception ex) {
> 419:             theApp.finishApp();

I'm worried about the output appearing twice in some tests:

        try {
            ...
            theApp = new LingeredAppWithLargeArray();
            LingeredApp.startAppExactJvmOpts(theApp, vmArgs);
            attachAndDump(heapDumpFileName, theApp.getPid());
        } finally {
            LingeredApp.stopApp(theApp);
            heapDumpFile.delete();
        }

So we always call `stopApp()`:

    public void stopApp() throws IOException {
           ...
           if (appProcess != null) {
           ...
            finishApp();
           ...
        }
    }


Which means we always call `finishApp()`, which means we always print the output. With your changes won't we see the output twice when there is an exception?

In the CR it looks like `LingeredApp.startAppExactJvmOpts()` is being call from `JCmdTest.java`. I don't see this test. Is it under development? Does it need a `stopApp()` call?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2679

From iklam at openjdk.java.net  Tue Feb 23 03:10:40 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Tue, 23 Feb 2021 03:10:40 GMT
Subject: RFR: 8262157: LingeredApp.startAppExactJvmOpts does not print app
 output when launching fails
In-Reply-To: <I1MRRpGW3KiP4J1Eu8QeNtbAiqDGP4vgn0QL971w_FI=.c73543b0-b03e-4480-a3a5-fa86501c3c26@github.com>
References: <w8znD1TZkMgc4oqfg0IHQRCp_Kv9tjEYR-hB7hpyngs=.1a422944-f3f0-427e-b7a9-ee5e78d2ef1f@github.com>
 <I1MRRpGW3KiP4J1Eu8QeNtbAiqDGP4vgn0QL971w_FI=.c73543b0-b03e-4480-a3a5-fa86501c3c26@github.com>
Message-ID: <2nCYR_nYg6wUxzfG6tYzVfbKT_2te8c0Z3YUMZFB0Ls=.b357ceed-fd29-4be9-bcc1-4e7faf330482@github.com>

On Tue, 23 Feb 2021 02:55:01 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Hi, Please review
>> 
>>  When debugging for other test case which uses jcmd to attach LingeredApp process, found there is no error information logged when the app started with function 'startAppExactJvmOpts' exits due to some reason. This is not convenient for trace what is the app failure.
>>  This simple fix for adding finishApp to print out error information when LingeredApp could not start with startAppExactJvmOpts, this is similar to startApp.
>> 
>> Tests: This is a simple fix and done tests with test/jdk/sun/tools/jinfo which uses the function startAppExactJvmOpts to create LingeredApp, also the test case in debugging, which indeed captured the error message upon start error.
>> 
>> Thanks
>> Yumin
>
> test/lib/jdk/test/lib/apps/LingeredApp.java line 419:
> 
>> 417:             theApp.waitAppReady();
>> 418:         } catch (Exception ex) {
>> 419:             theApp.finishApp();
> 
> I'm worried about the output appearing twice in some tests:
> 
>         try {
>             ...
>             theApp = new LingeredAppWithLargeArray();
>             LingeredApp.startAppExactJvmOpts(theApp, vmArgs);
>             attachAndDump(heapDumpFileName, theApp.getPid());
>         } finally {
>             LingeredApp.stopApp(theApp);
>             heapDumpFile.delete();
>         }
> 
> So we always call `stopApp()`:
> 
>     public void stopApp() throws IOException {
>            ...
>            if (appProcess != null) {
>            ...
>             finishApp();
>            ...
>         }
>     }
> 
> 
> Which means we always call `finishApp()`, which means we always print the output. With your changes won't we see the output twice when there is an exception?
> 
> In the CR it looks like `LingeredApp.startAppExactJvmOpts()` is being call from `JCmdTest.java`. I don't see this test. Is it under development? Does it need a `stopApp()` call?

It seems error prone to have to call finishApp() manually in order to see the error log. Since LingeredApp.startApp calls finishApp() on exceptions, shouldn't startAppExactJvmOpts do the same thing?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2679

From cjplummer at openjdk.java.net  Tue Feb 23 03:46:39 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 23 Feb 2021 03:46:39 GMT
Subject: RFR: 8262157: LingeredApp.startAppExactJvmOpts does not print app
 output when launching fails
In-Reply-To: <2nCYR_nYg6wUxzfG6tYzVfbKT_2te8c0Z3YUMZFB0Ls=.b357ceed-fd29-4be9-bcc1-4e7faf330482@github.com>
References: <w8znD1TZkMgc4oqfg0IHQRCp_Kv9tjEYR-hB7hpyngs=.1a422944-f3f0-427e-b7a9-ee5e78d2ef1f@github.com>
 <I1MRRpGW3KiP4J1Eu8QeNtbAiqDGP4vgn0QL971w_FI=.c73543b0-b03e-4480-a3a5-fa86501c3c26@github.com>
 <2nCYR_nYg6wUxzfG6tYzVfbKT_2te8c0Z3YUMZFB0Ls=.b357ceed-fd29-4be9-bcc1-4e7faf330482@github.com>
Message-ID: <Ht65sMGyeMCtpmkKpOjsyN_xDE69sDfS_g6VJS4amT4=.b8d32d1c-ede0-49dd-9de1-c3d6779eaf8c@github.com>

On Tue, 23 Feb 2021 03:08:16 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> test/lib/jdk/test/lib/apps/LingeredApp.java line 419:
>> 
>>> 417:             theApp.waitAppReady();
>>> 418:         } catch (Exception ex) {
>>> 419:             theApp.finishApp();
>> 
>> I'm worried about the output appearing twice in some tests:
>> 
>>         try {
>>             ...
>>             theApp = new LingeredAppWithLargeArray();
>>             LingeredApp.startAppExactJvmOpts(theApp, vmArgs);
>>             attachAndDump(heapDumpFileName, theApp.getPid());
>>         } finally {
>>             LingeredApp.stopApp(theApp);
>>             heapDumpFile.delete();
>>         }
>> 
>> So we always call `stopApp()`:
>> 
>>     public void stopApp() throws IOException {
>>            ...
>>            if (appProcess != null) {
>>            ...
>>             finishApp();
>>            ...
>>         }
>>     }
>> 
>> 
>> Which means we always call `finishApp()`, which means we always print the output. With your changes won't we see the output twice when there is an exception?
>> 
>> In the CR it looks like `LingeredApp.startAppExactJvmOpts()` is being call from `JCmdTest.java`. I don't see this test. Is it under development? Does it need a `stopApp()` call?
>
> It seems error prone to have to call finishApp() manually in order to see the error log. Since LingeredApp.startApp calls finishApp() on exceptions, shouldn't startAppExactJvmOpts do the same thing?

Although you have a point, you've also pointed out another problem with this fix.  I think users of `startApp()` are already going to see the output twice because of the `finishApp()` call present there. By adding yet another `finishApp()` call to `startAppExactJvmOpts()`, now they will see it 3 times.

If you want to "move" the `finishApp()` call from `startApp()` to `startAppExactJvmOpts()`, then at least that will maintain the status quo with existing `startApp()` users, but we still have an issue with the output appearing twice, even before this change, and with this change it is now more common as `startAppExactJvmOpts()` will also start seeing it.

Maybe `finishApp()` should maintain an `alreadyCalled` flag so it does nothing on subsequent calls.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2679

From minqi at openjdk.java.net  Tue Feb 23 04:11:39 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Tue, 23 Feb 2021 04:11:39 GMT
Subject: RFR: 8262157: LingeredApp.startAppExactJvmOpts does not print app
 output when launching fails
In-Reply-To: <Ht65sMGyeMCtpmkKpOjsyN_xDE69sDfS_g6VJS4amT4=.b8d32d1c-ede0-49dd-9de1-c3d6779eaf8c@github.com>
References: <w8znD1TZkMgc4oqfg0IHQRCp_Kv9tjEYR-hB7hpyngs=.1a422944-f3f0-427e-b7a9-ee5e78d2ef1f@github.com>
 <I1MRRpGW3KiP4J1Eu8QeNtbAiqDGP4vgn0QL971w_FI=.c73543b0-b03e-4480-a3a5-fa86501c3c26@github.com>
 <2nCYR_nYg6wUxzfG6tYzVfbKT_2te8c0Z3YUMZFB0Ls=.b357ceed-fd29-4be9-bcc1-4e7faf330482@github.com>
 <Ht65sMGyeMCtpmkKpOjsyN_xDE69sDfS_g6VJS4amT4=.b8d32d1c-ede0-49dd-9de1-c3d6779eaf8c@github.com>
Message-ID: <ufVxQYo6C2TH4473g98juY0LX0NtNwRUimEeN7GmvD0=.bf9f7611-a9d5-4c70-91f3-4a04539fed2f@github.com>

On Tue, 23 Feb 2021 03:43:41 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> It seems error prone to have to call finishApp() manually in order to see the error log. Since LingeredApp.startApp calls finishApp() on exceptions, shouldn't startAppExactJvmOpts do the same thing?
>
> Although you have a point, you've also pointed out another problem with this fix.  I think users of `startApp()` are already going to see the output twice because of the `finishApp()` call present there. By adding yet another `finishApp()` call to `startAppExactJvmOpts()`, now they will see it 3 times.
> 
> If you want to "move" the `finishApp()` call from `startApp()` to `startAppExactJvmOpts()`, then at least that will maintain the status quo with existing `startApp()` users, but we still have an issue with the output appearing twice, even before this change, and with this change it is now more common as `startAppExactJvmOpts()` will also start seeing it.
> 
> Maybe `finishApp()` should maintain an `alreadyCalled` flag so it does nothing on subsequent calls.

@plummercj @iklam Thanks for review. I will add a flag for finishApp so we will not call it more than once.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2679

From minqi at openjdk.java.net  Tue Feb 23 05:02:58 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Tue, 23 Feb 2021 05:02:58 GMT
Subject: RFR: 8262157: LingeredApp.startAppExactJvmOpts does not print app
 output when launching fails [v2]
In-Reply-To: <w8znD1TZkMgc4oqfg0IHQRCp_Kv9tjEYR-hB7hpyngs=.1a422944-f3f0-427e-b7a9-ee5e78d2ef1f@github.com>
References: <w8znD1TZkMgc4oqfg0IHQRCp_Kv9tjEYR-hB7hpyngs=.1a422944-f3f0-427e-b7a9-ee5e78d2ef1f@github.com>
Message-ID: <bcKGNmOB1gLNmbSx7mp39yRSSBar5H8ZIodVm1iSeug=.76aa8f9b-a77e-4943-a4f2-000be9a540aa@github.com>

> Hi, Please review
> 
>  When debugging for other test case which uses jcmd to attach LingeredApp process, found there is no error information logged when the app started with function 'startAppExactJvmOpts' exits due to some reason. This is not convenient for trace what is the app failure.
>  This simple fix for adding finishApp to print out error information when LingeredApp could not start with startAppExactJvmOpts, this is similar to startApp.
> 
> Tests: This is a simple fix and done tests with test/jdk/sun/tools/jinfo which uses the function startAppExactJvmOpts to create LingeredApp, also the test case in debugging, which indeed captured the error message upon start error.
> 
> Thanks
> Yumin

Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:

  Add a flag to remember finishApp already called

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2679/files
  - new: https://git.openjdk.java.net/jdk/pull/2679/files/68a564f5..f8cbc91b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2679&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2679&range=00-01

  Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2679.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2679/head:pull/2679

PR: https://git.openjdk.java.net/jdk/pull/2679

From rschmelter at openjdk.java.net  Tue Feb 23 08:08:43 2021
From: rschmelter at openjdk.java.net (Ralf Schmelter)
Date: Tue, 23 Feb 2021 08:08:43 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v10]
In-Reply-To: <ebrfA2bFIIPhcpZkO75uUvbJ3aMJFoHq_JR46AAEdfQ=.e3dee042-dff0-4b80-8cb0-5c9dae722be7@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>
Message-ID: <HrPwAUu3BrXj3C5fPIjZD3xEO0n2fKoQywKfOiebc7o=.193f9f06-0025-4251-baef-4288aea793b1@github.com>

On Mon, 22 Feb 2021 07:36:55 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> Hi,
>> 
>> I've benchmarked the code on my machine (128GB memory, 56 logical CPUs) with an example creating a 32 GB heap dump. I only saw a 10 percent reduction in time, both using uncompressed and compressed dumps. Have you seen better numbers in your benchmarks?
>> 
>> And it seems to potentially use a lot more temporary memory. In my example I had a 4 GB array in the heap and the new code allocated 4 GB of additional memory to write this array. This could happen in more threads in parallel, increasing the memory consumption even more.
>> 
>> If the above problems could be fixed, I would suggest to just use the parallel code in all cases.
>
> Hi @schmelter-sap,
> Thanks a lot for reviewing and benchmarking. 
> 
>> I've benchmarked the code on my machine (128GB memory, 56 logical CPUs) with an example creating a 32 GB heap dump. I only saw a 10 percent reduction in time, both using uncompressed and compressed dumps. Have you seen better numbers in your benchmarks?
>>
>> And it seems to potentially use a lot more temporary memory. In my example I had a 4 GB array in the heap and the new code allocated 4 GB of additional memory to write this array. This could happen in more threads in parallel, increasing the memory consumption even more.
> 
> I have done some preliminary test on my machine (16GB, 8 core), the data are shown as follow:
> `$ jmap -dump:file=dump4.bin,parallel=4 127420`
> `Dumping heap to /home/lzang1/Source/jdk/dump4.bin ...`
> `Heap dump file created [932950649 bytes in 0.591 secs]`
> `$ jmap -dump:file=dump1.bin,parallel=1 127420`
> `Dumping heap to /home/lzang1/Source/jdk/dump1.bin ...`
> `Heap dump file created [932950739 bytes in 2.957 secs]`
> 
> But I do have observed unstable data reported on a machine with more cores and larger RAM, plus a workload with more heap usage. I thought that may be related with the memory consumption as you mentioned. And I am investigating the way to optimize it.
> 
>> If the above problems could be fixed, I would suggest to just use the parallel code in all cases.
> 
> Thanks a lot! I will let you know when I make some progress on optimization.
> 
> BRs,
> Lin

Hi @linzang,

I've done more benchmarking using different numbers of threads for parallel heap iteration and have found values which give at least a factor of 2 speedup (for gzipped dumps) or 1.6 (for unzipped dumps). For my scenario using gzip compression about 10 percent of the available CPUs for parallel iteration gave the best speedup, for the uncompressed one it was about 7 percent. 

Note that the baseline I compared against was not the parallel=1 case, but the old code. The parallel=1 case was always 10 to 20 percent slower than the old code.

Best regards,
Ralf

-------------

PR: https://git.openjdk.java.net/jdk/pull/2261

From lzang at openjdk.java.net  Tue Feb 23 08:26:40 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Tue, 23 Feb 2021 08:26:40 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v10]
In-Reply-To: <HrPwAUu3BrXj3C5fPIjZD3xEO0n2fKoQywKfOiebc7o=.193f9f06-0025-4251-baef-4288aea793b1@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>
Message-ID: <89stqatP7KevfaFqJiTJyoi1q9PdIjR9VpYrK4KzVLE=.120ae881-06b8-4f75-9d51-ff8ea05cac63@github.com>

On Tue, 23 Feb 2021 08:06:14 GMT, Ralf Schmelter <rschmelter at openjdk.org> wrote:

>> Hi @schmelter-sap,
>> Thanks a lot for reviewing and benchmarking. 
>> 
>>> I've benchmarked the code on my machine (128GB memory, 56 logical CPUs) with an example creating a 32 GB heap dump. I only saw a 10 percent reduction in time, both using uncompressed and compressed dumps. Have you seen better numbers in your benchmarks?
>>>
>>> And it seems to potentially use a lot more temporary memory. In my example I had a 4 GB array in the heap and the new code allocated 4 GB of additional memory to write this array. This could happen in more threads in parallel, increasing the memory consumption even more.
>> 
>> I have done some preliminary test on my machine (16GB, 8 core), the data are shown as follow:
>> `$ jmap -dump:file=dump4.bin,parallel=4 127420`
>> `Dumping heap to /home/lzang1/Source/jdk/dump4.bin ...`
>> `Heap dump file created [932950649 bytes in 0.591 secs]`
>> `$ jmap -dump:file=dump1.bin,parallel=1 127420`
>> `Dumping heap to /home/lzang1/Source/jdk/dump1.bin ...`
>> `Heap dump file created [932950739 bytes in 2.957 secs]`
>> 
>> But I do have observed unstable data reported on a machine with more cores and larger RAM, plus a workload with more heap usage. I thought that may be related with the memory consumption as you mentioned. And I am investigating the way to optimize it.
>> 
>>> If the above problems could be fixed, I would suggest to just use the parallel code in all cases.
>> 
>> Thanks a lot! I will let you know when I make some progress on optimization.
>> 
>> BRs,
>> Lin
>
> Hi @linzang,
> 
> I've done more benchmarking using different numbers of threads for parallel heap iteration and have found values which give at least a factor of 2 speedup (for gzipped dumps) or 1.6 (for unzipped dumps). For my scenario using gzip compression about 10 percent of the available CPUs for parallel iteration gave the best speedup, for the uncompressed one it was about 7 percent. 
> 
> Note that the baseline I compared against was not the parallel=1 case, but the old code. The parallel=1 case was always 10 to 20 percent slower than the old code.
> 
> Best regards,
> Ralf

Dear @ralf,
Really Thanks for benchmarking it!
It is a little surprise to me that "parallel=1" is 10~20 percent slower than before. I believe this can be avoid with some revise in code. And I also found a potential memory leak in the implementation, WIP in fixing it.

> I've done more benchmarking using different numbers of threads for parallel heap iteration and have found values which give at least a factor of 2 speedup (for gzipped dumps) or 1.6 (for unzipped dumps). For my scenario using gzip compression about 10 percent of the available CPUs for parallel iteration gave the best speedup, for the uncompressed one it was about 7 percent.

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~
Thanks a lot!

BRs,
Lin

-------------

PR: https://git.openjdk.java.net/jdk/pull/2261

From lzang at openjdk.java.net  Tue Feb 23 08:40:40 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Tue, 23 Feb 2021 08:40:40 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v10]
In-Reply-To: <89stqatP7KevfaFqJiTJyoi1q9PdIjR9VpYrK4KzVLE=.120ae881-06b8-4f75-9d51-ff8ea05cac63@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>
Message-ID: <W2I3fgh9yhgn7dm7PM491TkzQ-wbhe_hvqNdZqfW8wU=.7e2e1b13-9138-4c00-94e7-f500e9432c33@github.com>

On Tue, 23 Feb 2021 08:23:49 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> Hi @linzang,
>> 
>> I've done more benchmarking using different numbers of threads for parallel heap iteration and have found values which give at least a factor of 2 speedup (for gzipped dumps) or 1.6 (for unzipped dumps). For my scenario using gzip compression about 10 percent of the available CPUs for parallel iteration gave the best speedup, for the uncompressed one it was about 7 percent. 
>> 
>> Note that the baseline I compared against was not the parallel=1 case, but the old code. The parallel=1 case was always 10 to 20 percent slower than the old code.
>> 
>> Best regards,
>> Ralf
>
> Dear @ralf,
> Really Thanks for benchmarking it!
> It is a little surprise to me that "parallel=1" is 10~20 percent slower than before. I believe this can be avoid with some revise in code. And I also found a potential memory leak in the implementation, WIP in fixing it.
> 
>> I've done more benchmarking using different numbers of threads for parallel heap iteration and have found values which give at least a factor of 2 speedup (for gzipped dumps) or 1.6 (for unzipped dumps). For my scenario using gzip compression about 10 percent of the available CPUs for parallel iteration gave the best speedup, for the uncompressed one it was about 7 percent.
> 
> 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~
> Thanks a lot!
> 
> BRs,
> Lin

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

-------------

PR: https://git.openjdk.java.net/jdk/pull/2261

From rschmelter at openjdk.java.net  Tue Feb 23 08:53:40 2021
From: rschmelter at openjdk.java.net (Ralf Schmelter)
Date: Tue, 23 Feb 2021 08:53:40 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v10]
In-Reply-To: <W2I3fgh9yhgn7dm7PM491TkzQ-wbhe_hvqNdZqfW8wU=.7e2e1b13-9138-4c00-94e7-f500e9432c33@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>
Message-ID: <MExJEiIs3e_zBbegggS5C4LSZBcPwDplOchJaztsWeg=.60fc0ca0-3958-4a89-af53-65c896b0c573@github.com>

On Tue, 23 Feb 2021 08:37:34 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> Dear @ralf,
>> Really Thanks for benchmarking it!
>> It is a little surprise to me that "parallel=1" is 10~20 percent slower than before. I believe this can be avoid with some revise in code. And I also found a potential memory leak in the implementation, WIP in fixing it.
>> 
>>> I've done more benchmarking using different numbers of threads for parallel heap iteration and have found values which give at least a factor of 2 speedup (for gzipped dumps) or 1.6 (for unzipped dumps). For my scenario using gzip compression about 10 percent of the available CPUs for parallel iteration gave the best speedup, for the uncompressed one it was about 7 percent.
>> 
>> 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~
>> Thanks a lot!
>> 
>> BRs,
>> Lin
>
> 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

-------------

PR: https://git.openjdk.java.net/jdk/pull/2261

From dfuchs at openjdk.java.net  Tue Feb 23 10:50:41 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 23 Feb 2021 10:50:41 GMT
Subject: RFR: 8224775: test/jdk/com/sun/jdi/JdwpListenTest.java failed to
 attach [v2]
In-Reply-To: <PmF4vYa0t07W4IJcPxGwFi3s0h2kCRMWo2oQF91poUM=.18a856cd-5e11-402c-ae7a-2afb6d36ae06@github.com>
References: <pRiX1N1rR7NYrKg4y4BmHmB4vtRpCO0fVEZH0NMgkaM=.219d5434-25b9-4d5d-945a-27aaedefb6d2@github.com>
 <PmF4vYa0t07W4IJcPxGwFi3s0h2kCRMWo2oQF91poUM=.18a856cd-5e11-402c-ae7a-2afb6d36ae06@github.com>
Message-ID: <_AqYCxXzBjry4HdfMHHNs6-h1R9aYP4rMpHHa-Fw2B8=.381843d8-9881-481a-a001-6bc1e4bfbf8c@github.com>

On Mon, 22 Feb 2021 21:36:52 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)
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   include loopback addresses in testing

The last changes look good to me.

-------------

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2633

From iklam at openjdk.java.net  Tue Feb 23 19:40:41 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Tue, 23 Feb 2021 19:40:41 GMT
Subject: RFR: 8262157: LingeredApp.startAppExactJvmOpts does not print app
 output when launching fails [v2]
In-Reply-To: <bcKGNmOB1gLNmbSx7mp39yRSSBar5H8ZIodVm1iSeug=.76aa8f9b-a77e-4943-a4f2-000be9a540aa@github.com>
References: <w8znD1TZkMgc4oqfg0IHQRCp_Kv9tjEYR-hB7hpyngs=.1a422944-f3f0-427e-b7a9-ee5e78d2ef1f@github.com>
 <bcKGNmOB1gLNmbSx7mp39yRSSBar5H8ZIodVm1iSeug=.76aa8f9b-a77e-4943-a4f2-000be9a540aa@github.com>
Message-ID: <ZWhEVvUuc34h-qolswKQSdHCsmg9TGMBaNEafGSHweg=.6d99d32f-dd96-40ac-9e42-2b066e7b7de2@github.com>

On Tue, 23 Feb 2021 05:02:58 GMT, Yumin Qi <minqi at openjdk.org> wrote:

>> Hi, Please review
>> 
>>  When debugging for other test case which uses jcmd to attach LingeredApp process, found there is no error information logged when the app started with function 'startAppExactJvmOpts' exits due to some reason. This is not convenient for trace what is the app failure.
>>  This simple fix for adding finishApp to print out error information when LingeredApp could not start with startAppExactJvmOpts, this is similar to startApp.
>> 
>> Tests: This is a simple fix and done tests with test/jdk/sun/tools/jinfo which uses the function startAppExactJvmOpts to create LingeredApp, also the test case in debugging, which indeed captured the error message upon start error.
>> 
>> Thanks
>> Yumin
>
> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a flag to remember finishApp already called

LGTM

-------------

Marked as reviewed by iklam (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2679

From cjplummer at openjdk.java.net  Tue Feb 23 19:57:46 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 23 Feb 2021 19:57:46 GMT
Subject: RFR: 8262157: LingeredApp.startAppExactJvmOpts does not print app
 output when launching fails [v2]
In-Reply-To: <ufVxQYo6C2TH4473g98juY0LX0NtNwRUimEeN7GmvD0=.bf9f7611-a9d5-4c70-91f3-4a04539fed2f@github.com>
References: <w8znD1TZkMgc4oqfg0IHQRCp_Kv9tjEYR-hB7hpyngs=.1a422944-f3f0-427e-b7a9-ee5e78d2ef1f@github.com>
 <I1MRRpGW3KiP4J1Eu8QeNtbAiqDGP4vgn0QL971w_FI=.c73543b0-b03e-4480-a3a5-fa86501c3c26@github.com>
 <2nCYR_nYg6wUxzfG6tYzVfbKT_2te8c0Z3YUMZFB0Ls=.b357ceed-fd29-4be9-bcc1-4e7faf330482@github.com>
 <Ht65sMGyeMCtpmkKpOjsyN_xDE69sDfS_g6VJS4amT4=.b8d32d1c-ede0-49dd-9de1-c3d6779eaf8c@github.com>
 <ufVxQYo6C2TH4473g98juY0LX0NtNwRUimEeN7GmvD0=.bf9f7611-a9d5-4c70-91f3-4a04539fed2f@github.com>
Message-ID: <wyW9Xf1FnXTC-EbJtuCRcSw3KkT_Hogv5s8P4QkR3_c=.96adaaae-3f97-4b34-9320-fa7e5fc169de@github.com>

On Tue, 23 Feb 2021 04:09:21 GMT, Yumin Qi <minqi at openjdk.org> wrote:

>> Although you have a point, you've also pointed out another problem with this fix.  I think users of `startApp()` are already going to see the output twice because of the `finishApp()` call present there. By adding yet another `finishApp()` call to `startAppExactJvmOpts()`, now they will see it 3 times.
>> 
>> If you want to "move" the `finishApp()` call from `startApp()` to `startAppExactJvmOpts()`, then at least that will maintain the status quo with existing `startApp()` users, but we still have an issue with the output appearing twice, even before this change, and with this change it is now more common as `startAppExactJvmOpts()` will also start seeing it.
>> 
>> Maybe `finishApp()` should maintain an `alreadyCalled` flag so it does nothing on subsequent calls.
>
> @plummercj @iklam Thanks for review. I will add a flag for finishApp so we will not call it more than once.

I still think the `finishApp()` call should be removed from `startApp()` since it is now in `startAppExactJvmOpts()`. Also move the `println()` to `startAppExactJvmOpts()` and then `startApp()` can just be:

             LingeredApp a = new LingeredApp();
             startApp(a, additionalJvmOpts);

No need for the exception handling anymore since `startAppExactJvmOpts()` is alread doing that.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2679

From minqi at openjdk.java.net  Tue Feb 23 21:19:56 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Tue, 23 Feb 2021 21:19:56 GMT
Subject: RFR: 8262157: LingeredApp.startAppExactJvmOpts does not print app
 output when launching fails [v3]
In-Reply-To: <w8znD1TZkMgc4oqfg0IHQRCp_Kv9tjEYR-hB7hpyngs=.1a422944-f3f0-427e-b7a9-ee5e78d2ef1f@github.com>
References: <w8znD1TZkMgc4oqfg0IHQRCp_Kv9tjEYR-hB7hpyngs=.1a422944-f3f0-427e-b7a9-ee5e78d2ef1f@github.com>
Message-ID: <OFe5TTkdoUvLhwEPyoJOMq3o_yvupKMQ65u-0XSqaLA=.4e11bf77-c465-48a8-89c1-aa0e1280e86d@github.com>

> Hi, Please review
> 
>  When debugging for other test case which uses jcmd to attach LingeredApp process, found there is no error information logged when the app started with function 'startAppExactJvmOpts' exits due to some reason. This is not convenient for trace what is the app failure.
>  This simple fix for adding finishApp to print out error information when LingeredApp could not start with startAppExactJvmOpts, this is similar to startApp.
> 
> Tests: This is a simple fix and done tests with test/jdk/sun/tools/jinfo which uses the function startAppExactJvmOpts to create LingeredApp, also the test case in debugging, which indeed captured the error message upon start error.
> 
> Thanks
> Yumin

Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:

  Remove finishApp from startApp, move printout to startAppExactJvmOpts.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2679/files
  - new: https://git.openjdk.java.net/jdk/pull/2679/files/f8cbc91b..f0476031

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2679&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2679&range=01-02

  Stats: 9 lines in 1 file changed: 1 ins; 7 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2679.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2679/head:pull/2679

PR: https://git.openjdk.java.net/jdk/pull/2679

From cjplummer at openjdk.java.net  Tue Feb 23 22:52:06 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 23 Feb 2021 22:52:06 GMT
Subject: RFR: 8262157: LingeredApp.startAppExactJvmOpts does not print app
 output when launching fails [v3]
In-Reply-To: <OFe5TTkdoUvLhwEPyoJOMq3o_yvupKMQ65u-0XSqaLA=.4e11bf77-c465-48a8-89c1-aa0e1280e86d@github.com>
References: <w8znD1TZkMgc4oqfg0IHQRCp_Kv9tjEYR-hB7hpyngs=.1a422944-f3f0-427e-b7a9-ee5e78d2ef1f@github.com>
 <OFe5TTkdoUvLhwEPyoJOMq3o_yvupKMQ65u-0XSqaLA=.4e11bf77-c465-48a8-89c1-aa0e1280e86d@github.com>
Message-ID: <K443Glqgln46rQ2hIbU0SRYcdnGhGfo8UOXi3L9UKh0=.52fd000f-bf42-4b46-931b-b9776b8ae910@github.com>

On Tue, 23 Feb 2021 21:19:56 GMT, Yumin Qi <minqi at openjdk.org> wrote:

>> Hi, Please review
>> 
>>  When debugging for other test case which uses jcmd to attach LingeredApp process, found there is no error information logged when the app started with function 'startAppExactJvmOpts' exits due to some reason. This is not convenient for trace what is the app failure.
>>  This simple fix for adding finishApp to print out error information when LingeredApp could not start with startAppExactJvmOpts, this is similar to startApp.
>> 
>> Tests: This is a simple fix and done tests with test/jdk/sun/tools/jinfo which uses the function startAppExactJvmOpts to create LingeredApp, also the test case in debugging, which indeed captured the error message upon start error.
>> 
>> Thanks
>> Yumin
>
> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove finishApp from startApp, move printout to startAppExactJvmOpts.

Marked as reviewed by cjplummer (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2679

From cjplummer at openjdk.java.net  Tue Feb 23 22:52:07 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 23 Feb 2021 22:52:07 GMT
Subject: RFR: 8262157: LingeredApp.startAppExactJvmOpts does not print app
 output when launching fails [v2]
In-Reply-To: <ZWhEVvUuc34h-qolswKQSdHCsmg9TGMBaNEafGSHweg=.6d99d32f-dd96-40ac-9e42-2b066e7b7de2@github.com>
References: <w8znD1TZkMgc4oqfg0IHQRCp_Kv9tjEYR-hB7hpyngs=.1a422944-f3f0-427e-b7a9-ee5e78d2ef1f@github.com>
 <bcKGNmOB1gLNmbSx7mp39yRSSBar5H8ZIodVm1iSeug=.76aa8f9b-a77e-4943-a4f2-000be9a540aa@github.com>
 <ZWhEVvUuc34h-qolswKQSdHCsmg9TGMBaNEafGSHweg=.6d99d32f-dd96-40ac-9e42-2b066e7b7de2@github.com>
Message-ID: <Q5rjaylLTAjJDQXZ0mXkSBrcPKI8HMHTb2FgdDtDPX4=.9996f69e-a286-49de-a23e-4d2cc76f8af4@github.com>

On Tue, 23 Feb 2021 19:37:47 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add a flag to remember finishApp already called
>
> LGTM

Looks good. Thanks!

-------------

PR: https://git.openjdk.java.net/jdk/pull/2679

From cjplummer at openjdk.java.net  Tue Feb 23 23:03:39 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 23 Feb 2021 23:03:39 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v10]
In-Reply-To: <W2I3fgh9yhgn7dm7PM491TkzQ-wbhe_hvqNdZqfW8wU=.7e2e1b13-9138-4c00-94e7-f500e9432c33@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>
Message-ID: <qvSH7yKPvHChpZAjPZL-moQ2VhipQA5F67hfERe3DyQ=.a010a4fc-4792-4e8a-ae30-12a21495d029@github.com>

On Tue, 23 Feb 2021 08:37:34 GMT, Lin Zang <lzang at openjdk.org> wrote:

> 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?

Well, if you want to go that route, maybe you just add a new command called "attachcmd", and it can support any command, new and old. But then that kind of points out the real issue with existing commands in that they are rigid with how many arguments they support, and I think they all suffer from that.

There have been other suggestions on how to deal with this, including having the 1st argument include all the arguments. I think the issue there is that it fails with older JDKs. However, the solution for older JDKs might just be the same as is suggested with "dumpheapext", which is just retry using the old argument passing method if the first one fails (and not including any of the new arguments that the old JDK won't understand anyway). So in general, I think any solution we come up with will fail with older JDKs, and need to fallback to retrying with a command we know will work.

How is `jmap dump:gz=...` working with older JDKs? I tried it against JDK8 and didn't get any errors, but it wasn't gzipped either.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2261

From dcubed at openjdk.java.net  Tue Feb 23 23:12:49 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 23 Feb 2021 23:12:49 GMT
Subject: RFR: 8241403: JavaThread::get_thread_name() should be
 ThreadSMR-aware [v4]
In-Reply-To: <hz-UIqnBo7HLeumeNfO_6YqGw13SebRDeMMb9yg71a0=.21788f6e-58f6-45ec-b3a2-eb57365e61ae@github.com>
References: <wRdcRQurtpybntK9Qpji-6zVY-EcHKw3q87xpD0eoS4=.a6dc32f4-2919-42e9-80c3-5a264067f0e2@github.com>
 <6MUhGSRe79fD3SkU0sbPKDneAQMpJvpVvL1uwImO7vI=.d28b3e10-5527-4df6-b554-c21ba598db56@github.com>
 <hz-UIqnBo7HLeumeNfO_6YqGw13SebRDeMMb9yg71a0=.21788f6e-58f6-45ec-b3a2-eb57365e61ae@github.com>
Message-ID: <CtPkCIY0IBr6rVx9OyUJDh3mopAydC82tzRofbqrUXU=.c2bd9767-8600-45dd-a068-82b7b40d5386@github.com>

On Mon, 22 Feb 2021 01:37:25 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address dholmes-ora CR1 comments.
>
> src/hotspot/share/compiler/compileBroker.cpp line 1115:
> 
>> 1113:       if (ct == NULL) break;
>> 1114:       ThreadsListHandle tlh;
>> 1115:       assert(tlh.includes(ct), "ct=" INTPTR_FORMAT " exited unexpectedly.", p2i(ct));
> 
> This seems to be the fully dynamic case. Here the TLH is potentially racing with thread termination and so may or may not capture ct. Rather than an assertion the call to  `get_thread_name()` below should be guarded by `tlh.includes(ct)`.

Agreed. Here's the new block:

      JavaThread *ct = make_thread(compiler_t, compiler2_object(i), _c2_compile_queue, _compilers[1], THREAD);
      if (ct == NULL) break;
      ThreadsListHandle tlh;
      if (!tlh.includes(ct)) break;
      _compilers[1]->set_num_compiler_threads(i + 1);
So we "break" if the `tlh` doesn't include the JavaThread which is the same
behavior as when `ct == NULL)`. Please note that I followed the existing
code style of putting the if-statement break on a single line.

> src/hotspot/share/compiler/compileBroker.cpp line 1136:
> 
>> 1134:       if (ct == NULL) break;
>> 1135:       ThreadsListHandle tlh;
>> 1136:       assert(tlh.includes(ct), "ct=" INTPTR_FORMAT " exited unexpectedly.", p2i(ct));
> 
> Ditto - the assert is not appropriate for this case.

Ditto for the resolution.

> src/hotspot/share/runtime/thread.cpp line 485:
> 
>> 483: #endif
>> 484: 
>> 485: // Is the target JavaThread protected by the calling Thread:
> 
> s/calling/current/ ?
> 
> We could also expand this to clarify that even if a target JavaThread is not explicitly protected by the current thread it can still be safe to access if the two threads engage in a suitable protocol.

That comment used to be:

`// Is the target JavaThread protected by this Thread:`

so I changed it to "the calling Thread" because I wanted it to be clear that
we're checking to see if the Thread that's calling is_JavaThread_protected()
is protecting the target JavaThread. I didn't use "current" because I thought
"calling" would be more clear.

I could add more comments about the target JavaThread being possibly
protected by other protocols, but I thought that might raise questions
about why the code doesn't check for those things and I didn't want to
go down that rabbit hole...

> src/hotspot/share/runtime/thread.cpp line 2568:
> 
>> 2566:   // this->is_handshake_safe_for() may crash, but we have debug bits so...
>> 2567:   assert(SafepointSynchronize::is_at_safepoint() ||
>> 2568:          this->is_handshake_safe_for(current_thread), "JavaThread="
> 
> I agree this is a pre-existing bug as accessing `this` may not be safe if the target is not protected. But if we crash attempting the access that implies the assert failed so ...

... that will tell us that we have a spot in the code where a TLH is
missing once we've analyzed the crash. So are you okay with this
assert() having a bug since the original assert has the same bug?

> src/hotspot/share/services/management.cpp line 848:
> 
>> 846:   {
>> 847:     JavaThreadIteratorWithHandle jtiwh;
>> 848:     Threads::threads_do(&jtiwh, &vmtcc);
> 
> I'm not sure this is at all necessary. Threads::add and Threads::remove still use the Threads_lock so this code is safe as it stands. Switching to  use JTIWH may be an alternative, and may even be desirable, but that hasn't been established, and is not necessary for safety and so seems outside the scope of this bug IMO.

Holding the Threads_lock is no longer being considered as
proper protection for the JavaThread::get_thread_name() call
so I had to change the code to use a JavaThreadIteratorWithHandle
so that we have the protection of the TLH. That closure eventually
gets us down to a JavaThread::get_thread_name() call...

-------------

PR: https://git.openjdk.java.net/jdk/pull/2535

From dcubed at openjdk.java.net  Tue Feb 23 23:12:46 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 23 Feb 2021 23:12:46 GMT
Subject: RFR: 8241403: JavaThread::get_thread_name() should be
 ThreadSMR-aware [v4]
In-Reply-To: <6MUhGSRe79fD3SkU0sbPKDneAQMpJvpVvL1uwImO7vI=.d28b3e10-5527-4df6-b554-c21ba598db56@github.com>
References: <wRdcRQurtpybntK9Qpji-6zVY-EcHKw3q87xpD0eoS4=.a6dc32f4-2919-42e9-80c3-5a264067f0e2@github.com>
 <6MUhGSRe79fD3SkU0sbPKDneAQMpJvpVvL1uwImO7vI=.d28b3e10-5527-4df6-b554-c21ba598db56@github.com>
Message-ID: <JdpDlFC3Xijrt4Hb2Si58pcs_Ffy6C2k-8MUWCOqq9A=.b74f04e0-2285-4c70-8a04-79265926bf58@github.com>

On Sat, 20 Feb 2021 17:50:01 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> A minor fix to add a new function:
>> 
>>     bool Thread::is_JavaThread_protected(const JavaThread* p)
>> 
>> that returns true when the target JavaThread* is protected and false
>> otherwise. Update JavaThread::get_thread_name() to create a
>> ThreadsListHandle and use the new is_JavaThread_protected(). Also
>> update JvmtiTrace::safe_get_thread_name() to use the new
>> is_JavaThread_protected().
>> 
>> This fix is tested via a Mach5 Tier[1-8] run.
>
> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address dholmes-ora CR1 comments.

@dholmes-ora - thanks for the re-review!

-------------

PR: https://git.openjdk.java.net/jdk/pull/2535

From dcubed at openjdk.java.net  Tue Feb 23 23:52:15 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 23 Feb 2021 23:52:15 GMT
Subject: RFR: 8241403: JavaThread::get_thread_name() should be
 ThreadSMR-aware [v5]
In-Reply-To: <wRdcRQurtpybntK9Qpji-6zVY-EcHKw3q87xpD0eoS4=.a6dc32f4-2919-42e9-80c3-5a264067f0e2@github.com>
References: <wRdcRQurtpybntK9Qpji-6zVY-EcHKw3q87xpD0eoS4=.a6dc32f4-2919-42e9-80c3-5a264067f0e2@github.com>
Message-ID: <zkmwEDyUrIwqBqt2kGhlLZCRHBTB1krLO43PMmLSUC8=.fd503b8f-c79d-4f03-89bc-16f65e62f475@github.com>

> A minor fix to add a new function:
> 
>     bool Thread::is_JavaThread_protected(const JavaThread* p)
> 
> that returns true when the target JavaThread* is protected and false
> otherwise. Update JavaThread::get_thread_name() to create a
> ThreadsListHandle and use the new is_JavaThread_protected(). Also
> update JvmtiTrace::safe_get_thread_name() to use the new
> is_JavaThread_protected().
> 
> This fix is tested via a Mach5 Tier[1-8] run.

Daniel D. Daugherty 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 six additional commits since the last revision:

 - Merge branch 'master' into JDK-8241403
 - Address dholmes-ora CR2 comments.
 - Address dholmes-ora CR1 comments.
 - Merge branch 'master' into JDK-8241403
 - Address coleenp CR0 comments.
 - 8241403: JavaThread::get_thread_name() should be ThreadSMR-aware

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2535/files
  - new: https://git.openjdk.java.net/jdk/pull/2535/files/cbb71a20..19fe9538

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2535&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2535&range=03-04

  Stats: 13293 lines in 368 files changed: 9145 ins; 2347 del; 1801 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2535.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2535/head:pull/2535

PR: https://git.openjdk.java.net/jdk/pull/2535

From lzang at openjdk.java.net  Wed Feb 24 00:05:41 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Wed, 24 Feb 2021 00:05:41 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v10]
In-Reply-To: <qvSH7yKPvHChpZAjPZL-moQ2VhipQA5F67hfERe3DyQ=.a010a4fc-4792-4e8a-ae30-12a21495d029@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>
 <qvSH7yKPvHChpZAjPZL-moQ2VhipQA5F67hfERe3DyQ=.a010a4fc-4792-4e8a-ae30-12a21495d029@github.com>
Message-ID: <lMPu_htCJNLuQKrM6ef1bLHwkODw9D89bWN8WBGP4zU=.f07ed9a1-bb8d-49c6-a4aa-b898eb6c2129@github.com>

On Tue, 23 Feb 2021 23:00:30 GMT, Chris Plummer <cjplummer 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
>
>> 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?
> 
> Well, if you want to go that route, maybe you just add a new command called "attachcmd", and it can support any command, new and old. But then that kind of points out the real issue with existing commands in that they are rigid with how many arguments they support, and I think they all suffer from that.
> 
> There have been other suggestions on how to deal with this, including having the 1st argument include all the arguments. I think the issue there is that it fails with older JDKs. However, the solution for older JDKs might just be the same as is suggested with "dumpheapext", which is just retry using the old argument passing method if the first one fails (and not including any of the new arguments that the old JDK won't understand anyway). So in general, I think any solution we come up with will fail with older JDKs, and need to fallback to retrying with a command we know will work.
> 
> How is `jmap dump:gz=...` working with older JDKs? I tried it against JDK8 and didn't get any errors, but it wasn't gzipped either.

Hi @plummercj ,

> maybe you just add a new command called "attachcmd", and it can support any command, new and old

I think make it work only for newly added arguments for different command could reduce the implementation complexity. The old command doesn't need to handle the exception. 
And I also found in this way the "attachcmd" will be quite similar with `jcmd` command, it accept different command and pass all argument with one string. Then there maybe another solution -- for "parallel" argument of `jmap -dump`, just change it to the `jcmd` command and passing all arguments as a string.  Then we don't bother with adding the `dumpheapext` command.
 

> So in general, I think any solution we come up with will fail with older JDKs, and need to fallback to retrying with a command we know will work

Yes, no matter what name it is, the new command must have the ablility to eat the unsupported command exception and then print error info. 



> How is `jmap dump:gz=...` working with older JDKs? I tried it against JDK8 and didn't get any errors, but it wasn't gzipped either.

The older version for `jmap dump` only passing arguments that is recognized (`file` and `live or all`), and siliently drop the unrecognized arguments without any output. 
I added the logic of print error message in JDK16, with JBS https://bugs.openjdk.java.net/browse/JDK-8251347

-------------

PR: https://git.openjdk.java.net/jdk/pull/2261

From lzang at openjdk.java.net  Wed Feb 24 00:10:41 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Wed, 24 Feb 2021 00:10:41 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v10]
In-Reply-To: <lMPu_htCJNLuQKrM6ef1bLHwkODw9D89bWN8WBGP4zU=.f07ed9a1-bb8d-49c6-a4aa-b898eb6c2129@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>
 <qvSH7yKPvHChpZAjPZL-moQ2VhipQA5F67hfERe3DyQ=.a010a4fc-4792-4e8a-ae30-12a21495d029@github.com>
 <lMPu_htCJNLuQKrM6ef1bLHwkODw9D89bWN8WBGP4zU=.f07ed9a1-bb8d-49c6-a4aa-b898eb6c2129@github.com>
Message-ID: <7P5eo_8F64YfjJhrF3j5S-rv1KOHjgSj84hQB8gM4VA=.3cc2b495-dec6-4ed4-b1ae-4d5e9b60246e@github.com>

On Wed, 24 Feb 2021 00:02:33 GMT, Lin Zang <lzang at openjdk.org> wrote:

>>> 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?
>> 
>> Well, if you want to go that route, maybe you just add a new command called "attachcmd", and it can support any command, new and old. But then that kind of points out the real issue with existing commands in that they are rigid with how many arguments they support, and I think they all suffer from that.
>> 
>> There have been other suggestions on how to deal with this, including having the 1st argument include all the arguments. I think the issue there is that it fails with older JDKs. However, the solution for older JDKs might just be the same as is suggested with "dumpheapext", which is just retry using the old argument passing method if the first one fails (and not including any of the new arguments that the old JDK won't understand anyway). So in general, I think any solution we come up with will fail with older JDKs, and need to fallback to retrying with a command we know will work.
>> 
>> How is `jmap dump:gz=...` working with older JDKs? I tried it against JDK8 and didn't get any errors, but it wasn't gzipped either.
>
> Hi @plummercj ,
> 
>> maybe you just add a new command called "attachcmd", and it can support any command, new and old
> 
> I think make it work only for newly added arguments for different command could reduce the implementation complexity. The old command doesn't need to handle the exception. 
> And I also found in this way the "attachcmd" will be quite similar with `jcmd` command, it accept different command and pass all argument with one string. Then there maybe another solution -- for "parallel" argument of `jmap -dump`, just change it to the `jcmd` command and passing all arguments as a string.  Then we don't bother with adding the `dumpheapext` command.
>  
> 
>> So in general, I think any solution we come up with will fail with older JDKs, and need to fallback to retrying with a command we know will work
> 
> Yes, no matter what name it is, the new command must have the ablility to eat the unsupported command exception and then print error info. 
> 
> 
> 
>> How is `jmap dump:gz=...` working with older JDKs? I tried it against JDK8 and didn't get any errors, but it wasn't gzipped either.
> 
> The older version for `jmap dump` only passing arguments that is recognized (`file` and `live or all`), and siliently drop the unrecognized arguments without any output. 
> I added the logic of print error message in JDK16, with JBS https://bugs.openjdk.java.net/browse/JDK-8251347

> 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

Hi Ralf, 

The data are really helpful. Thanks for the thorough listing and sharing!

BRs,
Lin

-------------

PR: https://git.openjdk.java.net/jdk/pull/2261

From lzang at openjdk.java.net  Wed Feb 24 00:26:40 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Wed, 24 Feb 2021 00:26:40 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v10]
In-Reply-To: <lMPu_htCJNLuQKrM6ef1bLHwkODw9D89bWN8WBGP4zU=.f07ed9a1-bb8d-49c6-a4aa-b898eb6c2129@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>
 <qvSH7yKPvHChpZAjPZL-moQ2VhipQA5F67hfERe3DyQ=.a010a4fc-4792-4e8a-ae30-12a21495d029@github.com>
 <lMPu_htCJNLuQKrM6ef1bLHwkODw9D89bWN8WBGP4zU=.f07ed9a1-bb8d-49c6-a4aa-b898eb6c2129@github.com>
Message-ID: <RhtewCm33ykTf7s8SBHb5hRm9jsxkv83MYbETh5Y4dU=.97cf3fd2-5b14-4c9e-b246-45df4bde67e7@github.com>

On Wed, 24 Feb 2021 00:02:33 GMT, Lin Zang <lzang at openjdk.org> wrote:

> So in general, I think any solution we come up with will fail with older JDKs, and need to fallback to retrying with a command we know will work.

Dear Chris, 
I just realized that my understand is a little different with the "retrying" -  if we already know what is newly added argument, we can assume old jvm can not accept it. So it seems print error message is enough.   This is consistent with JDK16. 
But for older jvm, since there is no error message for unrecogized arguments, we need to fall back as you mentioned.
So maybe we can also revert the argument parsing logic introduced in JDK16? But it is wierd to me that jmap dump command siliently accept all strings as arguments without any error message.

BRs,
Lin

-------------

PR: https://git.openjdk.java.net/jdk/pull/2261

From minqi at openjdk.java.net  Wed Feb 24 00:34:41 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Wed, 24 Feb 2021 00:34:41 GMT
Subject: Integrated: 8262157: LingeredApp.startAppExactJvmOpts does not print
 app output when launching fails
In-Reply-To: <w8znD1TZkMgc4oqfg0IHQRCp_Kv9tjEYR-hB7hpyngs=.1a422944-f3f0-427e-b7a9-ee5e78d2ef1f@github.com>
References: <w8znD1TZkMgc4oqfg0IHQRCp_Kv9tjEYR-hB7hpyngs=.1a422944-f3f0-427e-b7a9-ee5e78d2ef1f@github.com>
Message-ID: <XCs8dGAWdI_iEopbB1KnJQxi356WZR3l-k3yNCmnIzs=.4d3397d9-cc3e-41e0-aecf-3cbdee17b7a6@github.com>

On Mon, 22 Feb 2021 22:26:50 GMT, Yumin Qi <minqi at openjdk.org> wrote:

> Hi, Please review
> 
>  When debugging for other test case which uses jcmd to attach LingeredApp process, found there is no error information logged when the app started with function 'startAppExactJvmOpts' exits due to some reason. This is not convenient for trace what is the app failure.
>  This simple fix for adding finishApp to print out error information when LingeredApp could not start with startAppExactJvmOpts, this is similar to startApp.
> 
> Tests: This is a simple fix and done tests with test/jdk/sun/tools/jinfo which uses the function startAppExactJvmOpts to create LingeredApp, also the test case in debugging, which indeed captured the error message upon start error.
> 
> Thanks
> Yumin

This pull request has now been integrated.

Changeset: 3e13b66e
Author:    Yumin Qi <minqi at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/3e13b66e
Stats:     17 lines in 1 file changed: 8 ins; 7 del; 2 mod

8262157: LingeredApp.startAppExactJvmOpts does not print app output when launching fails

Reviewed-by: iklam, cjplummer

-------------

PR: https://git.openjdk.java.net/jdk/pull/2679

From cjplummer at openjdk.java.net  Wed Feb 24 00:42:39 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 24 Feb 2021 00:42:39 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v10]
In-Reply-To: <RhtewCm33ykTf7s8SBHb5hRm9jsxkv83MYbETh5Y4dU=.97cf3fd2-5b14-4c9e-b246-45df4bde67e7@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>
 <qvSH7yKPvHChpZAjPZL-moQ2VhipQA5F67hfERe3DyQ=.a010a4fc-4792-4e8a-ae30-12a21495d029@github.com>
 <lMPu_htCJNLuQKrM6ef1bLHwkODw9D89bWN8WBGP4zU=.f07ed9a1-bb8d-49c6-a4aa-b898eb6c2129@github.com>
 <RhtewCm33ykTf7s8SBHb5hRm9jsxkv83MYbETh5Y4dU=.97cf3fd2-5b14-4c9e-b246-45df4bde67e7@github.com>
Message-ID: <dcndd6MSvXV9xvokXKFqLTYj2HB7-xMTDUD9ePVUTmE=.fd8b109f-df5f-45b8-beec-bc031323736a@github.com>

On Wed, 24 Feb 2021 00:22:16 GMT, Lin Zang <lzang at openjdk.org> wrote:

>  I just realized that my understand is a little different with the "retrying" - if we already know what is newly added argument, we can assume old jvm can not accept it. So it seems print error message is enough. This is consistent with JDK16.
> But for older jvm, since there is no error message for unrecogized arguments, we need to fall back as you mentioned.

It still not clear to me what is happening when `jmap -dump:gz=...` is used by JDK17 jmap to query and older JDK. When I tried it, it silently worked, but without compressing the output file. Since jmap doesn't know what JDK it is communicating with, I can only assume it tried passing `gz=`, and when that failed and retried without it. Or maybe the old JDK is just silently consuming the unrecognized `gz=` argument. I'd like to understand the implementation behind this behavior.

> So maybe we can also revert the argument parsing logic introduced in JDK16? 
I'm not sure what you are referring to here.

> But it is wierd to me that jmap dump command siliently accept all strings as arguments without any error message.
If the target VM cannot accept the argument, our choices are either silently ignore that and retry without the argument (which might mean using a different attach command), or produce an error message. I can see an argument for either approach. I tend to favor the error message (and therefore no retry), but if you have scripts that might target various VM versions, you might want the bad argument to be silently ignored. This is especially true for `parallel` since it doesn't impact the output, but for `gz=`, silently not compressing the output can also lead to issues for any scripts being run, since they might assume it is compressed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2261

From lzang at openjdk.java.net  Wed Feb 24 01:11:41 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Wed, 24 Feb 2021 01:11:41 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v10]
In-Reply-To: <dcndd6MSvXV9xvokXKFqLTYj2HB7-xMTDUD9ePVUTmE=.fd8b109f-df5f-45b8-beec-bc031323736a@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>
 <qvSH7yKPvHChpZAjPZL-moQ2VhipQA5F67hfERe3DyQ=.a010a4fc-4792-4e8a-ae30-12a21495d029@github.com>
 <lMPu_htCJNLuQKrM6ef1bLHwkODw9D89bWN8WBGP4zU=.f07ed9a1-bb8d-49c6-a4aa-b898eb6c2129@github.com>
 <RhtewCm33ykTf7s8SBHb5hRm9jsxkv83MYbETh5Y4dU=.97cf3fd2-5b14-4c9e-b246-45df4bde67e7@github.com>
 <dcndd6MSvXV9xvokXKFqLTYj2HB7-xMTDUD
 9ePVUTmE=.fd8b109f-df5f-45b8-beec-bc031323736a@github.com>
Message-ID: <jc6EZENV75QtVskMR4yEPLOqvqPI7E4aHIf7YRjdtfQ=.f9ccc952-3528-4718-8d26-dd8ebe797273@github.com>

On Wed, 24 Feb 2021 00:40:03 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>>> So in general, I think any solution we come up with will fail with older JDKs, and need to fallback to retrying with a command we know will work.
>> 
>> Dear Chris, 
>> I just realized that my understand is a little different with the "retrying" -  if we already know what is newly added argument, we can assume old jvm can not accept it. So it seems print error message is enough.   This is consistent with JDK16. 
>> But for older jvm, since there is no error message for unrecogized arguments, we need to fall back as you mentioned.
>> So maybe we can also revert the argument parsing logic introduced in JDK16? But it is wierd to me that jmap dump command siliently accept all strings as arguments without any error message.
>> 
>> BRs,
>> Lin
>
>>  I just realized that my understand is a little different with the "retrying" - if we already know what is newly added argument, we can assume old jvm can not accept it. So it seems print error message is enough. This is consistent with JDK16.
>> But for older jvm, since there is no error message for unrecogized arguments, we need to fall back as you mentioned.
> 
> It still not clear to me what is happening when `jmap -dump:gz=...` is used by JDK17 jmap to query and older JDK. When I tried it, it silently worked, but without compressing the output file. Since jmap doesn't know what JDK it is communicating with, I can only assume it tried passing `gz=`, and when that failed and retried without it. Or maybe the old JDK is just silently consuming the unrecognized `gz=` argument. I'd like to understand the implementation behind this behavior.
> 
>> So maybe we can also revert the argument parsing logic introduced in JDK16? 
> I'm not sure what you are referring to here.
> 
>> But it is wierd to me that jmap dump command siliently accept all strings as arguments without any error message.
> If the target VM cannot accept the argument, our choices are either silently ignore that and retry without the argument (which might mean using a different attach command), or produce an error message. I can see an argument for either approach. I tend to favor the error message (and therefore no retry), but if you have scripts that might target various VM versions, you might want the bad argument to be silently ignored. This is especially true for `parallel` since it doesn't impact the output, but for `gz=`, silently not compressing the output can also lead to issues for any scripts being run, since they might assume it is compressed.

Hi @plummercj, 
I think maybe you missed my previous reply just before the latest one :-) 
> The older version for jmap dump only passing arguments that is recognized (file and live or all), and siliently drop the unrecognized arguments without any output.
I added the logic of print error message in JDK16, with JBS https://bugs.openjdk.java.net/browse/JDK-8251347

To make it clear,  the jvm (attachListener) just accept what arguments are passed from attach API and parsing the known ones ("file" and "all, live") and ingore the others.

And the jmap command before JDK16 behaves nearly the same -  accept known arguments and ingore illegal ones. 
However, in JDK16 , I introduced https://bugs.openjdk.java.net/browse/JDK-8251347, so the jmap command in JDK16 would print error message when unknown argument is parsed. 

but no matter what version is, the jvm part do the same thing as desribed before.

> It still not clear to me what is happening when `jmap -dump:gz=...` is used by JDK17 jmap to query and older JDK.

Let me give more info about this scenario: 
The JDK17's jmap would then passing gzlevel as the 3rd arguments.  (filename, live or all for the first 2) and then pass it with attach API.  However, the old version JVM's attachlistener onle parse the first 2 argument, and hence the gzlevel is ignored. So the jmap dump works but no compressed file generated.

> but for `gz=`, silently not compressing the output can also lead to issues for any scripts being run, since they might assume it is compressed.

Yes, I agree with this, because at present there is no info from the result that the generated dump file is gziped or not. And user can usually use ".gz" as suffix in the filename when specify `gz=`, which could be misleading.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2261

From dholmes at openjdk.java.net  Wed Feb 24 01:37:52 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 24 Feb 2021 01:37:52 GMT
Subject: RFR: 8241403: JavaThread::get_thread_name() should be
 ThreadSMR-aware [v4]
In-Reply-To: <CtPkCIY0IBr6rVx9OyUJDh3mopAydC82tzRofbqrUXU=.c2bd9767-8600-45dd-a068-82b7b40d5386@github.com>
References: <wRdcRQurtpybntK9Qpji-6zVY-EcHKw3q87xpD0eoS4=.a6dc32f4-2919-42e9-80c3-5a264067f0e2@github.com>
 <6MUhGSRe79fD3SkU0sbPKDneAQMpJvpVvL1uwImO7vI=.d28b3e10-5527-4df6-b554-c21ba598db56@github.com>
 <hz-UIqnBo7HLeumeNfO_6YqGw13SebRDeMMb9yg71a0=.21788f6e-58f6-45ec-b3a2-eb57365e61ae@github.com>
 <CtPkCIY0IBr6rVx9OyUJDh3mopAydC82tzRofbqrUXU=.c2bd9767-8600-45dd-a068-82b7b40d5386@github.com>
Message-ID: <vI72u_d8c32LSOQtLdExu1F4HztWBH8D4KNmS9CTeOc=.26e279da-1078-439b-b304-810e55de34de@github.com>

On Tue, 23 Feb 2021 23:03:00 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> src/hotspot/share/runtime/thread.cpp line 2568:
>> 
>>> 2566:   // this->is_handshake_safe_for() may crash, but we have debug bits so...
>>> 2567:   assert(SafepointSynchronize::is_at_safepoint() ||
>>> 2568:          this->is_handshake_safe_for(current_thread), "JavaThread="
>> 
>> I agree this is a pre-existing bug as accessing `this` may not be safe if the target is not protected. But if we crash attempting the access that implies the assert failed so ...
>
> ... that will tell us that we have a spot in the code where a TLH is
> missing once we've analyzed the crash. So are you okay with this
> assert() having a bug since the original assert has the same bug?

Yes

>> src/hotspot/share/services/management.cpp line 848:
>> 
>>> 846:   {
>>> 847:     JavaThreadIteratorWithHandle jtiwh;
>>> 848:     Threads::threads_do(&jtiwh, &vmtcc);
>> 
>> I'm not sure this is at all necessary. Threads::add and Threads::remove still use the Threads_lock so this code is safe as it stands. Switching to  use JTIWH may be an alternative, and may even be desirable, but that hasn't been established, and is not necessary for safety and so seems outside the scope of this bug IMO.
>
> Holding the Threads_lock is no longer being considered as
> proper protection for the JavaThread::get_thread_name() call
> so I had to change the code to use a JavaThreadIteratorWithHandle
> so that we have the protection of the TLH. That closure eventually
> gets us down to a JavaThread::get_thread_name() call...

But the code is now broken as it needs the Threads_lock to guard against non-JavaThreads being created or terminating.
The code also appears misleading because the passing of the JTIWH makes it look (to me) like it only deals with JavaThreads.
I think this code needs to be:
    JavaThreadIteratorWithHandle jtiwh;  // ensure JavaThreads are safe to access
    MutexLocker ml(Threads_lock);        // ensure non_JavaThreads are safe to access
    Threads::threads_do(&jtiwh, &vmtcc); // process all threads

-------------

PR: https://git.openjdk.java.net/jdk/pull/2535

From dholmes at openjdk.java.net  Wed Feb 24 01:37:50 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 24 Feb 2021 01:37:50 GMT
Subject: RFR: 8241403: JavaThread::get_thread_name() should be
 ThreadSMR-aware [v5]
In-Reply-To: <zkmwEDyUrIwqBqt2kGhlLZCRHBTB1krLO43PMmLSUC8=.fd503b8f-c79d-4f03-89bc-16f65e62f475@github.com>
References: <wRdcRQurtpybntK9Qpji-6zVY-EcHKw3q87xpD0eoS4=.a6dc32f4-2919-42e9-80c3-5a264067f0e2@github.com>
 <zkmwEDyUrIwqBqt2kGhlLZCRHBTB1krLO43PMmLSUC8=.fd503b8f-c79d-4f03-89bc-16f65e62f475@github.com>
Message-ID: <3E4aN8avhZIGL3w8YUPHlu1HF3t4wW-NWZTuH8Ty52k=.270b79d6-8024-4f1c-9b54-37007c6b93e3@github.com>

On Tue, 23 Feb 2021 23:52:15 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> A minor fix to add a new function:
>> 
>>     bool Thread::is_JavaThread_protected(const JavaThread* p)
>> 
>> that returns true when the target JavaThread* is protected and false
>> otherwise. Update JavaThread::get_thread_name() to create a
>> ThreadsListHandle and use the new is_JavaThread_protected(). Also
>> update JvmtiTrace::safe_get_thread_name() to use the new
>> is_JavaThread_protected().
>> 
>> This fix is tested via a Mach5 Tier[1-8] run.
>
> Daniel D. Daugherty 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 six additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8241403
>  - Address dholmes-ora CR2 comments.
>  - Address dholmes-ora CR1 comments.
>  - Merge branch 'master' into JDK-8241403
>  - Address coleenp CR0 comments.
>  - 8241403: JavaThread::get_thread_name() should be ThreadSMR-aware

Hi Dan,

Sorry still some issue here.

Okay let me back up again. The old code for get_thread_name() thinks it is only safe to access the name of another thread if we hold the Threads_lock or we are at a safepoint. That isn't true as I've pointed out before - there are other ways for the access to be safe. And as a result of this, code calling get_thread_name() would acquire the Threads_lock just to get past the assertion e.g the CompilerBroker code. I've now ascertained that the CompilerBroker calls to get_thread_name() are perfectly safe by construction due to holding the CompilerThread_lock and/or dealing with an immortal thread.

The intent of filing this issue was for get_thread_name() to also (instead?) recognise that it is safe if the target is protected by a TLH - thus relaxing the original constraint by adding another checkable condition - and to recognise that a handshake also makes things safe. I didn't recognise at the time that these are still overly strong requirements.

So the change you are proposing is to replace the "needs the Threads_lock" condition with "must have an active TLH" condition when calling get_thread_name(). So now the unnecessary use of the Threads_lock in the CompileBroker is replaced by unnecessary use of the TLH - which is unfortunate IMO but a fix for that is out of scope for this change.

Also the management code changes now require use of a TLH  - but there is a bug in replacing the Threads_lock usage: see below!

As a Threads_lock->TLH conversion for users of get_thread_name() I can accept the change in its current form. But it needs to restore the asserts in the CompileBroker code as commented below and fixing the Threads_lock bug in the management code.

Thanks,
David

src/hotspot/share/compiler/compileBroker.cpp line 1115:

> 1113:       if (ct == NULL) break;
> 1114:       ThreadsListHandle tlh;
> 1115:       if (!tlh.includes(ct)) break;

This change raised a red flag because if the new thread already terminated it should decrement the number of compiler threads on its way out, but we are skipping the increment by breaking here. So that prompted me to look closer at the bigger picture for these compiler threads and their lifecycle. The current code is called whilst holding the CompilerThread_lock, which means that the new thread can't terminate because it has to also acquire the CompilerThread_lock to decide whether it needs to terminate. So access to ct is guaranteed to be safe and no TLH is needed at all - other than because get_thread_name() requires it. So this should be a simple assertion afterall.

src/hotspot/share/compiler/compileBroker.cpp line 1136:

> 1134:       if (ct == NULL) break;
> 1135:       ThreadsListHandle tlh;
> 1136:       if (!tlh.includes(ct)) break;

Ditto.

src/hotspot/share/runtime/thread.cpp line 2955:

> 2953: void Threads::threads_do(JavaThreadIteratorWithHandle* jtiwh_p, ThreadClosure* tc) {
> 2954:   java_threads_do(jtiwh_p, tc);
> 2955:   non_java_threads_do(tc);

You should still have

(Threads_lock);```

for non-JavaThread access.

src/hotspot/share/services/management.cpp line 1704:

> 1702:   {
> 1703:     JavaThreadIteratorWithHandle jtiwh;
> 1704:     Threads::threads_do(&jtiwh, &ttc);

Same comments as above re need for Threads_lock.

-------------

Changes requested by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2535

From cjplummer at openjdk.java.net  Wed Feb 24 02:50:40 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 24 Feb 2021 02:50:40 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v10]
In-Reply-To: <jc6EZENV75QtVskMR4yEPLOqvqPI7E4aHIf7YRjdtfQ=.f9ccc952-3528-4718-8d26-dd8ebe797273@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>
 <qvSH7yKPvHChpZAjPZL-moQ2VhipQA5F67hfERe3DyQ=.a010a4fc-4792-4e8a-ae30-12a21495d029@github.com>
 <lMPu_htCJNLuQKrM6ef1bLHwkODw9D89bWN8WBGP4zU=.f07ed9a1-bb8d-49c6-a4aa-b898eb6c2129@github.com>
 <RhtewCm33ykTf7s8SBHb5hRm9jsxkv83MYbETh5Y4dU=.97cf3fd2-5b14-4c9e-b246-45df4bde67e7@github.com>
 <dcndd6MSvXV9xvokXKFqLTYj2HB7-xMTDUD
 9ePVUTmE=.fd8b109f-df5f-45b8-beec-bc031323736a@github.com>
 <jc6EZENV75QtVskMR4yEPLOqvqPI7E4aHIf7YRjdtfQ=.f9ccc952-3528-4718-8d26-dd8ebe797273@github.com>
Message-ID: <fXkLIJ7l-QppUAN3Xbglu7zkHASsGZCYzTIYyKy8xUc=.bab3707f-6558-4d66-aa0a-d1deb1951b30@github.com>

On Wed, 24 Feb 2021 01:08:58 GMT, Lin Zang <lzang at openjdk.org> wrote:

>>>  I just realized that my understand is a little different with the "retrying" - if we already know what is newly added argument, we can assume old jvm can not accept it. So it seems print error message is enough. This is consistent with JDK16.
>>> But for older jvm, since there is no error message for unrecogized arguments, we need to fall back as you mentioned.
>> 
>> It still not clear to me what is happening when `jmap -dump:gz=...` is used by JDK17 jmap to query and older JDK. When I tried it, it silently worked, but without compressing the output file. Since jmap doesn't know what JDK it is communicating with, I can only assume it tried passing `gz=`, and when that failed and retried without it. Or maybe the old JDK is just silently consuming the unrecognized `gz=` argument. I'd like to understand the implementation behind this behavior.
>> 
>>> So maybe we can also revert the argument parsing logic introduced in JDK16? 
>> I'm not sure what you are referring to here.
>> 
>>> But it is wierd to me that jmap dump command siliently accept all strings as arguments without any error message.
>> If the target VM cannot accept the argument, our choices are either silently ignore that and retry without the argument (which might mean using a different attach command), or produce an error message. I can see an argument for either approach. I tend to favor the error message (and therefore no retry), but if you have scripts that might target various VM versions, you might want the bad argument to be silently ignored. This is especially true for `parallel` since it doesn't impact the output, but for `gz=`, silently not compressing the output can also lead to issues for any scripts being run, since they might assume it is compressed.
>
> Hi @plummercj, 
> I think maybe you missed my previous reply just before the latest one :-) 
>> The older version for jmap dump only passing arguments that is recognized (file and live or all), and siliently drop the unrecognized arguments without any output.
> I added the logic of print error message in JDK16, with JBS https://bugs.openjdk.java.net/browse/JDK-8251347
> 
> To make it clear,  the jvm (attachListener) just accept what arguments are passed from attach API and parsing the known ones ("file" and "all, live") and ingore the others.
> 
> And the jmap command before JDK16 behaves nearly the same -  accept known arguments and ingore illegal ones. 
> However, in JDK16 , I introduced https://bugs.openjdk.java.net/browse/JDK-8251347, so the jmap command in JDK16 would print error message when unknown argument is parsed. 
> 
> but no matter what version is, the jvm part do the same thing as desribed before.
> 
>> It still not clear to me what is happening when `jmap -dump:gz=...` is used by JDK17 jmap to query and older JDK.
> 
> Let me give more info about this scenario: 
> The JDK17's jmap would then passing gzlevel as the 3rd arguments.  (filename, live or all for the first 2) and then pass it with attach API.  However, the old version JVM's attachlistener only parse the first 2 argument, and hence the gzlevel is ignored. So the jmap dump works but no compressed file generated.
> 
>> but for `gz=`, silently not compressing the output can also lead to issues for any scripts being run, since they might assume it is compressed.
> 
> Yes, I agree with this, because at present there is no info from the result that the generated dump file is gziped or not. And user can usually use ".gz" as suffix in the filename when specify `gz=`, which could be misleading.
> 
> BTW, just want to mention I have an idea for reusing jcmd for jmap -dump:parallel= in previous reply:
> 
>> And I also found in this way the "attachcmd" will be quite similar with jcmd command, it accept different command and pass all argument with one string. Then there maybe another solution -- for "parallel" argument of jmap -dump, just change it to the jcmd command and passing all arguments as a string. Then we don't bother with adding the dumpheapext command.
> 
> Not sure whether it is considerable :-)
> Thanks!

JDK-8251347 does not appear to be the correct bug. Can you find the one you are referring too?

It's too bad that the `dumpheap` command in previous JDKs has a slot for a 3rd argument, but doesn't look at it. Maybe that was intentional to allow for a new argument without causing a failure. What it means is if we want a failure, we need to either send a different command, or use the suggestion of having all the arguments in the first argument, both of which would result in a failure when used with an older JDK (in which case we would retry with older argument passing).

> And I also found in this way the "attachcmd" will be quite similar with jcmd command, it accept different command and pass all argument with one string. Then there maybe another solution -- for "parallel" argument of jmap -dump, just change it to the jcmd command and passing all arguments as a string. Then we don't bother with adding the dumpheapext command.

The irony here is that we've considered dropping `jstack`, `jmap`, and `jinfo` since their functionality is also supported by `jcmd`. But they are far more convenient and easier to understand than `jcmd`, so will probably stay around. But you are right in that they could still all be converted to use `jcmd` internally.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2261

From lzang at openjdk.java.net  Wed Feb 24 03:27:42 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Wed, 24 Feb 2021 03:27:42 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v10]
In-Reply-To: <fXkLIJ7l-QppUAN3Xbglu7zkHASsGZCYzTIYyKy8xUc=.bab3707f-6558-4d66-aa0a-d1deb1951b30@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>
 <qvSH7yKPvHChpZAjPZL-moQ2VhipQA5F67hfERe3DyQ=.a010a4fc-4792-4e8a-ae30-12a21495d029@github.com>
 <lMPu_htCJNLuQKrM6ef1bLHwkODw9D89bWN8WBGP4zU=.f07ed9a1-bb8d-49c6-a4aa-b898eb6c2129@github.com>
 <RhtewCm33ykTf7s8SBHb5hRm9jsxkv83MYbETh5Y4dU=.97cf3fd2-5b14-4c9e-b246-45df4bde67e7@github.com>
 <dcndd6MSvXV9xvokXKFqLTYj2HB7-xMTDUD
 9ePVUTmE=.fd8b109f-df5f-45b8-beec-bc031323736a@github.com>
 <jc6EZENV75QtVskMR4yEPLOqvqPI7E4aHIf7YRjdtfQ=.f9ccc952-3528-4718-8d26-dd8ebe797273@github.com>
 <fXkLIJ7l-QppUAN3Xbglu7zkHASsGZCYzTIYyKy8xUc=.bab3707f-6558-4d66-aa0a-d1deb1951b30@github.com>
Message-ID: <Qs2YbKY_T_VPV_8kUqsrTONCe2nhNAxwBBnHkKIpi_U=.806d2e31-d2f5-460b-b617-521a82e0809b@github.com>

On Wed, 24 Feb 2021 02:48:06 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> JDK-8251347 does not appear to be the correct bug. Can you find the one you are referring too?

oops, It should be https://bugs.openjdk.java.net/browse/JDK-8251374, sorry.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2261

From cjplummer at openjdk.java.net  Wed Feb 24 03:36:40 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 24 Feb 2021 03:36:40 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v10]
In-Reply-To: <Qs2YbKY_T_VPV_8kUqsrTONCe2nhNAxwBBnHkKIpi_U=.806d2e31-d2f5-460b-b617-521a82e0809b@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>
 <qvSH7yKPvHChpZAjPZL-moQ2VhipQA5F67hfERe3DyQ=.a010a4fc-4792-4e8a-ae30-12a21495d029@github.com>
 <lMPu_htCJNLuQKrM6ef1bLHwkODw9D89bWN8WBGP4zU=.f07ed9a1-bb8d-49c6-a4aa-b898eb6c2129@github.com>
 <RhtewCm33ykTf7s8SBHb5hRm9jsxkv83MYbETh5Y4dU=.97cf3fd2-5b14-4c9e-b246-45df4bde67e7@github.com>
 <dcndd6MSvXV9xvokXKFqLTYj2HB7-xMTDUD
 9ePVUTmE=.fd8b109f-df5f-45b8-beec-bc031323736a@github.com>
 <jc6EZENV75QtVskMR4yEPLOqvqPI7E4aHIf7YRjdtfQ=.f9ccc952-3528-4718-8d26-dd8ebe797273@github.com>
 <fXkLIJ7l-QppUAN3Xbglu7zkHASsGZCYzTIYyKy8xUc=.bab3707f-6558-4d66-aa0a-d1deb1951b30@github.com>
 <Qs2YbKY_T_VPV_8kUqsrTONCe2nhNAxwBBnHkKIpi_U=.806d2e31-d2f5-460b-b617-521a82e0809b@github.com>
Message-ID: <EhPwcWYds_wAmu9AnGVFOnfoHefpEoQ2z7yKeHlCKwQ=.1174090a-fee7-4b03-b497-f78d34e61efc@github.com>

On Wed, 24 Feb 2021 03:24:46 GMT, Lin Zang <lzang at openjdk.org> wrote:

> > JDK-8251347 does not appear to be the correct bug. Can you find the one you are referring too?
> 
> oops, It should be https://bugs.openjdk.java.net/browse/JDK-8251374, sorry.

Ok, but that fix is on the client side, not the target VM side.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2261

From lzang at openjdk.java.net  Wed Feb 24 03:49:42 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Wed, 24 Feb 2021 03:49:42 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v10]
In-Reply-To: <fXkLIJ7l-QppUAN3Xbglu7zkHASsGZCYzTIYyKy8xUc=.bab3707f-6558-4d66-aa0a-d1deb1951b30@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>
 <qvSH7yKPvHChpZAjPZL-moQ2VhipQA5F67hfERe3DyQ=.a010a4fc-4792-4e8a-ae30-12a21495d029@github.com>
 <lMPu_htCJNLuQKrM6ef1bLHwkODw9D89bWN8WBGP4zU=.f07ed9a1-bb8d-49c6-a4aa-b898eb6c2129@github.com>
 <RhtewCm33ykTf7s8SBHb5hRm9jsxkv83MYbETh5Y4dU=.97cf3fd2-5b14-4c9e-b246-45df4bde67e7@github.com>
 <dcndd6MSvXV9xvokXKFqLTYj2HB7-xMTDUD
 9ePVUTmE=.fd8b109f-df5f-45b8-beec-bc031323736a@github.com>
 <jc6EZENV75QtVskMR4yEPLOqvqPI7E4aHIf7YRjdtfQ=.f9ccc952-3528-4718-8d26-dd8ebe797273@github.com>
 <fXkLIJ7l-QppUAN3Xbglu7zkHASsGZCYzTIYyKy8xUc=.bab3707f-6558-4d66-aa0a-d1deb1951b30@github.com>
Message-ID: <2TigA_-oOnothuzJIe4evP9QnGxaa0AyfukiQe_9ygU=.c9b6d54b-489f-41e6-8870-b90aee733594@github.com>

On Wed, 24 Feb 2021 02:48:06 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> It's too bad that the `dumpheap` command in previous JDKs has a slot for a 3rd argument, but doesn't look at it. Maybe that was intentional to allow for a new argument without causing a failure. What it means is if we want a failure, we need to either send a different command, or use the suggestion of having all the arguments in the first argument, both of which would result in a failure when used with an older JDK (in which case we would retry with older argument passing).

Yes, I believe the argument max set to 3 was based on assumption that there can be at most 3 arguments from client side, no matter which tool it is (jmap, jstack, jinfo). 

And the jcmd command actually already passed all arguemnt as a single string, so there is no issue for accepting more arguments.
 
> But they are far more convenient and easier to understand than jcmd, so will probably stay around. But you are right in that they could still all be converted to use jcmd internally.

Maybe we could consider using `jcmd` internally to replace the current implementation of these tools, and keep their usage as before, then we get same result from `jcmd` and `jmap` alike tools, get rid of the argument passing limitation (because jcmd make all argument as a string), and also reduce the overhead of maintanence (e.g. don't bothering adding new options for both jmap and jcmd )

> Ok, but that fix is on the client side, not the target VM side.

Yes, it only change the client side to reject illegal arguments, the JVM side still work as it is -  ingore unknown argument silicently. However, the client side could at least reject unknown option and hence pass correct ones as expected to JVM.
So if we agree on this change, at least for "parallel=" option, we don't need to retry when get the exception. :-)

-------------

PR: https://git.openjdk.java.net/jdk/pull/2261

From cjplummer at openjdk.java.net  Wed Feb 24 04:14:39 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 24 Feb 2021 04:14:39 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v10]
In-Reply-To: <2TigA_-oOnothuzJIe4evP9QnGxaa0AyfukiQe_9ygU=.c9b6d54b-489f-41e6-8870-b90aee733594@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>
 <qvSH7yKPvHChpZAjPZL-moQ2VhipQA5F67hfERe3DyQ=.a010a4fc-4792-4e8a-ae30-12a21495d029@github.com>
 <lMPu_htCJNLuQKrM6ef1bLHwkODw9D89bWN8WBGP4zU=.f07ed9a1-bb8d-49c6-a4aa-b898eb6c2129@github.com>
 <RhtewCm33ykTf7s8SBHb5hRm9jsxkv83MYbETh5Y4dU=.97cf3fd2-5b14-4c9e-b246-45df4bde67e7@github.com>
 <dcndd6MSvXV9xvokXKFqLTYj2HB7-xMTDUD
 9ePVUTmE=.fd8b109f-df5f-45b8-beec-bc031323736a@github.com>
 <jc6EZENV75QtVskMR4yEPLOqvqPI7E4aHIf7YRjdtfQ=.f9ccc952-3528-4718-8d26-dd8ebe797273@github.com>
 <fXkLIJ7l-QppUAN3Xbglu7zkHASsGZCYzTIYyKy8xUc=.bab3707f-6558-4d66-aa0a-d1deb1951b30@github.com>
 <2TigA_-oOnothuzJIe4evP9QnGxaa0AyfukiQe_9ygU=.c9b6d54b-489f-41e6-8870-b90aee733594@github.com>
Message-ID: <GO6ucQvERsY13TAxZHiwOTbzaMPVDpo_QKVVx4fBuZI=.51a1730e-ac8c-48e4-a6b7-5e41b6f52681@github.com>

On Wed, 24 Feb 2021 03:46:42 GMT, Lin Zang <lzang at openjdk.org> wrote:

> > But they are far more convenient and easier to understand than jcmd, so will probably stay around. But you are right in that they could still all be converted to use jcmd internally.
> 
> Maybe we could consider using `jcmd` internally to replace the current implementation of these tools, and keep their usage as before, then we get same result from `jcmd` and `jmap` alike tools, get rid of the argument passing limitation (because jcmd make all argument as a string), and also reduce the overhead of maintanence (e.g. don't bothering adding new options for both jmap and jcmd )

It does reduce the maintenance overhead, but you still need to parse the arguments on the client side and package them up the way jcmd likes to see them.

> 
> > Ok, but that fix is on the client side, not the target VM side.
> 
> Yes, it only change the client side to reject illegal arguments, the JVM side still work as it is - ingore unknown argument silicently. However, the client side could at least reject unknown option and hence pass correct ones as expected to JVM.
> So if we agree on this change, at least for "parallel=" option, we don't need to retry when get the exception. :-)

Actually you should still see an error when using `parallel` or `gz` when the target VM doesn't understand them. This is because `jcmd` will reject them on the target VM side. Then the question is whether to retry without them, or pass the error to the user and let them adjust their `jmap` command. The problem with the latter is that the arguments in the `jcmd` error message might not look exactly the same as the way they were specified by the user to `jmap`. We'd have take a closer look at the `jcmd` error messages to see if they are appropriate for `jmap` users.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2261

From ralf.schmelter at sap.com  Wed Feb 24 07:45:01 2021
From: ralf.schmelter at sap.com (Schmelter, Ralf)
Date: Wed, 24 Feb 2021 07:45:01 +0000
Subject: RFC: Allowing existing file when writing a heap dump
Message-ID: <AM6PR0202MB335209150317D1A1D9863C739F809@AM6PR0202MB3352.eurprd02.prod.outlook.com>

Hi,

as described in https://bugs.openjdk.java.net/browse/JDK-8200579 it could be useful to be able to specify an already existing 'file' to be able to stream the heap dump directly to a named pipe on Windows or a tty or domain socket on Unix, especially on systems with low disk space. Since we now don't have the requirement to seek anymore, when we open the file with os::create_binary_file(<path>, true) instead of os::create_binary_file(<path>, false) we could just do that.

However, I'm not sure how this would be feasible from a security perspective, since this would allow users who have the permission to trigger a heap dump to overwrite files. One could check if the opened file is one of the special types (pipes, tty, domain sockets) and allow it only for these cases.

What do you think?

Best regards,
Ralf

From andrew at openjdk.java.net  Wed Feb 24 15:29:39 2021
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Wed, 24 Feb 2021 15:29:39 GMT
Subject: RFR: 8254001: [Metrics] Enhance parsing of cgroup interface files
 for version detection [v4]
In-Reply-To: <SvMY9wiRTmT3frc0g-IiS1zdT81lKoLyqn-fhF59FK8=.5aba8058-3c87-4c76-9586-5a3927d68675@github.com>
References: <52vN8j9B_6s6amMHb8b_1QKyhwjCvThIz5T17aNix28=.31113ef4-61d0-4525-a3df-9aa20d408935@github.com>
 <3x47AFywS6_XcwXLLRw-js174URG35nifn1_G19vsKc=.b5ad4fdc-e040-44bc-a7fd-6fe7268dc341@github.com>
 <rXq1Ad-_1c9NU7PI8ukyb1OG0XbEvQKi_krW6I2NAJQ=.732d2731-d617-4808-be1a-41a243a2d9c3@github.com>
 <bRbPXPcV1Ouis3yX6AqUcz4G3bWsxP7G5kUAGPRlilA=.50d3cdb7-5e2c-48f4-ba64-cd2ae99e8d22@github.com>
 <SvMY9wiRTmT3frc0g-IiS1zdT81lKoLyqn-fhF59FK8=.5aba8058-3c87-4c76-9586-5a3927d68675@github.com>
Message-ID: <61MUyznDzo9Uonb9DO0SRkhAPtWy3gy9yjY03bJI4iM=.ebc347b1-b549-413c-86cf-a2b053b7a030@github.com>

On Fri, 12 Feb 2021 12:49:19 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Setting reviewers to 2 since I want @gnu-andrew to be OK with it too.
>
> Hi Harold,
> 
>> Thanks for doing this! Sorry for taking so long to review this change. The change looks good.
> 
> Thanks for the review!
> 
>> Before pushing it, could you add a comment explaining what the code in lines 185-194 of CgroupSubsystemFactory.java is doing?
> 
> Done.
> 
>> Also, please don't overwrite the fix for JDK-8257746.
> 
> AFAIK this patch doesn't touch this code. So this should not happen (overwrite of the fix). FWIW, once this is in I intend to propose a patch which adds a regression test for JDK-8257746. It would depend on this change.
> 
> Thanks,
> Severin

Thanks, this version looks better.
Sorry for the delay. I didn't realise you'd replied until I received your e-mail. Not sure where notifications for these git PRs end up.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1393

From andrew at openjdk.java.net  Wed Feb 24 16:27:41 2021
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Wed, 24 Feb 2021 16:27:41 GMT
Subject: RFR: 8254001: [Metrics] Enhance parsing of cgroup interface files
 for version detection [v5]
In-Reply-To: <BM4m3jWxpZgdvU9DgoXcz4iftbqkWzL1q-uTqzly258=.4f268544-d629-47fe-bd18-2c4fea02e495@github.com>
References: <52vN8j9B_6s6amMHb8b_1QKyhwjCvThIz5T17aNix28=.31113ef4-61d0-4525-a3df-9aa20d408935@github.com>
 <BM4m3jWxpZgdvU9DgoXcz4iftbqkWzL1q-uTqzly258=.4f268544-d629-47fe-bd18-2c4fea02e495@github.com>
Message-ID: <e_zaGEJMiUW7BLlnEWPlUi5r1We9BoPRWAWhxwa_0yI=.961739d0-0a3a-4c41-ab8f-258d99940c2d@github.com>

On Fri, 12 Feb 2021 12:49:01 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> This is an enhancement which solves two issues:
>> 
>> 1. Multiple reads of relevant cgroup interface files. Now interface files are only read once per file (just like Hotspot).
>> 2. Proxies creation of the impl specific subsystem via `determineType()` as before, but now reads all relevant interface files: `/proc/cgroups`, `/proc/self/mountinfo` and `/proc/self/cgroup`. Once read it passes the parsed information to the impl specific subsystem classes for instantiation. This allows for more flexibility of testing as interface files can be mocked and, thus, more cases can be tested that way without having access to these specific systems. For example, proper regression tests for JDK-8217766 and JDK-8253435 have been added now with this in place.
>> 
>> * [x] Tested on Linux x86_64 on cgroups v1 and cgroups v2. Container tests pass.
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment to parsing logic of /proc/self/cgroup

Marked as reviewed by andrew (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1393

From sgehwolf at openjdk.java.net  Wed Feb 24 17:40:17 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Wed, 24 Feb 2021 17:40:17 GMT
Subject: RFR: 8254001: [Metrics] Enhance parsing of cgroup interface files
 for version detection [v6]
In-Reply-To: <52vN8j9B_6s6amMHb8b_1QKyhwjCvThIz5T17aNix28=.31113ef4-61d0-4525-a3df-9aa20d408935@github.com>
References: <52vN8j9B_6s6amMHb8b_1QKyhwjCvThIz5T17aNix28=.31113ef4-61d0-4525-a3df-9aa20d408935@github.com>
Message-ID: <GfAI3os-aI8ManImBgVnoFS6ZqqnvaYU5SKofGbihgU=.2a86b548-953b-453a-aaec-6d667eecaa65@github.com>

> This is an enhancement which solves two issues:
> 
> 1. Multiple reads of relevant cgroup interface files. Now interface files are only read once per file (just like Hotspot).
> 2. Proxies creation of the impl specific subsystem via `determineType()` as before, but now reads all relevant interface files: `/proc/cgroups`, `/proc/self/mountinfo` and `/proc/self/cgroup`. Once read it passes the parsed information to the impl specific subsystem classes for instantiation. This allows for more flexibility of testing as interface files can be mocked and, thus, more cases can be tested that way without having access to these specific systems. For example, proper regression tests for JDK-8217766 and JDK-8253435 have been added now with this in place.
> 
> * [x] Tested on Linux x86_64 on cgroups v1 and cgroups v2. Container tests pass.

Severin Gehwolf 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 jdk-8254001-enhance-file-parsing-java-metrics
 - Merge branch 'master' into jdk-8254001-enhance-file-parsing-java-metrics
 - Add comment to parsing logic of /proc/self/cgroup
 - Fix jcheck
 - Add documentation and reduce code running in the critical section
 - Add some documentation
 - Merge branch 'master' into jdk-8254001-enhance-file-parsing-java-metrics
 - Merge branch 'master' into jdk-8254001-enhance-file-parsing-java-metrics
 - Merge branch 'master' into jdk-8254001-enhance-file-parsing-java-metrics
 - 8254001: [Metrics] Enhance parsing of cgroup interface files for version detection

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1393/files
  - new: https://git.openjdk.java.net/jdk/pull/1393/files/078e16db..5d5275e7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1393&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1393&range=04-05

  Stats: 29136 lines in 793 files changed: 18085 ins; 6354 del; 4697 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1393.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1393/head:pull/1393

PR: https://git.openjdk.java.net/jdk/pull/1393

From sgehwolf at openjdk.java.net  Wed Feb 24 17:40:18 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Wed, 24 Feb 2021 17:40:18 GMT
Subject: RFR: 8254001: [Metrics] Enhance parsing of cgroup interface files
 for version detection [v5]
In-Reply-To: <e_zaGEJMiUW7BLlnEWPlUi5r1We9BoPRWAWhxwa_0yI=.961739d0-0a3a-4c41-ab8f-258d99940c2d@github.com>
References: <52vN8j9B_6s6amMHb8b_1QKyhwjCvThIz5T17aNix28=.31113ef4-61d0-4525-a3df-9aa20d408935@github.com>
 <BM4m3jWxpZgdvU9DgoXcz4iftbqkWzL1q-uTqzly258=.4f268544-d629-47fe-bd18-2c4fea02e495@github.com>
 <e_zaGEJMiUW7BLlnEWPlUi5r1We9BoPRWAWhxwa_0yI=.961739d0-0a3a-4c41-ab8f-258d99940c2d@github.com>
Message-ID: <g8Mtz-1kUga26ZM_B6RCEp-yjpn6qB2SXpHZeA1jBVA=.bdf9979d-391b-4853-a329-76d048dcbc77@github.com>

On Wed, 24 Feb 2021 16:24:32 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add comment to parsing logic of /proc/self/cgroup
>
> Marked as reviewed by andrew (Reviewer).

@gnu-andrew Thanks for the review! I'll retest and then integrate.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1393

From sgehwolf at openjdk.java.net  Wed Feb 24 19:42:40 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Wed, 24 Feb 2021 19:42:40 GMT
Subject: Integrated: 8254001: [Metrics] Enhance parsing of cgroup interface
 files for version detection
In-Reply-To: <52vN8j9B_6s6amMHb8b_1QKyhwjCvThIz5T17aNix28=.31113ef4-61d0-4525-a3df-9aa20d408935@github.com>
References: <52vN8j9B_6s6amMHb8b_1QKyhwjCvThIz5T17aNix28=.31113ef4-61d0-4525-a3df-9aa20d408935@github.com>
Message-ID: <4LRVddMlQLbwuj3ucT_svgTklw2_BA9X_9fk4hfraW0=.57849a24-52e5-47a8-a79f-1e783678f0f4@github.com>

On Mon, 23 Nov 2020 15:46:56 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> This is an enhancement which solves two issues:
> 
> 1. Multiple reads of relevant cgroup interface files. Now interface files are only read once per file (just like Hotspot).
> 2. Proxies creation of the impl specific subsystem via `determineType()` as before, but now reads all relevant interface files: `/proc/cgroups`, `/proc/self/mountinfo` and `/proc/self/cgroup`. Once read it passes the parsed information to the impl specific subsystem classes for instantiation. This allows for more flexibility of testing as interface files can be mocked and, thus, more cases can be tested that way without having access to these specific systems. For example, proper regression tests for JDK-8217766 and JDK-8253435 have been added now with this in place.
> 
> * [x] Tested on Linux x86_64 on cgroups v1 and cgroups v2. Container tests pass.

This pull request has now been integrated.

Changeset: a50725db
Author:    Severin Gehwolf <sgehwolf at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a50725db
Stats:     596 lines in 5 files changed: 323 ins; 144 del; 129 mod

8254001: [Metrics] Enhance parsing of cgroup interface files for version detection

Reviewed-by: hseigel, andrew

-------------

PR: https://git.openjdk.java.net/jdk/pull/1393

From sgehwolf at openjdk.java.net  Wed Feb 24 19:42:39 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Wed, 24 Feb 2021 19:42:39 GMT
Subject: RFR: 8254001: [Metrics] Enhance parsing of cgroup interface files
 for version detection [v5]
In-Reply-To: <g8Mtz-1kUga26ZM_B6RCEp-yjpn6qB2SXpHZeA1jBVA=.bdf9979d-391b-4853-a329-76d048dcbc77@github.com>
References: <52vN8j9B_6s6amMHb8b_1QKyhwjCvThIz5T17aNix28=.31113ef4-61d0-4525-a3df-9aa20d408935@github.com>
 <BM4m3jWxpZgdvU9DgoXcz4iftbqkWzL1q-uTqzly258=.4f268544-d629-47fe-bd18-2c4fea02e495@github.com>
 <e_zaGEJMiUW7BLlnEWPlUi5r1We9BoPRWAWhxwa_0yI=.961739d0-0a3a-4c41-ab8f-258d99940c2d@github.com>
 <g8Mtz-1kUga26ZM_B6RCEp-yjpn6qB2SXpHZeA1jBVA=.bdf9979d-391b-4853-a329-76d048dcbc77@github.com>
Message-ID: <6B8DAqhpPjrUXnner51bG8C3JqkOugul-vJzfj2T_ho=.eec814fb-e9c7-401f-96b8-ad327d123801@github.com>

On Wed, 24 Feb 2021 17:37:13 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Marked as reviewed by andrew (Reviewer).
>
> @gnu-andrew Thanks for the review! I'll retest and then integrate.

Tests look good on my end. Also this check passed all Linux tests (it's a no-op everywhere else):
https://github.com/jerboaa/jdk/actions/runs/596859548

-------------

PR: https://git.openjdk.java.net/jdk/pull/1393

From chris.plummer at oracle.com  Wed Feb 24 20:16:52 2021
From: chris.plummer at oracle.com (Chris Plummer)
Date: Wed, 24 Feb 2021 12:16:52 -0800
Subject: RFC: Allowing existing file when writing a heap dump
In-Reply-To: <AM6PR0202MB335209150317D1A1D9863C739F809@AM6PR0202MB3352.eurprd02.prod.outlook.com>
References: <AM6PR0202MB335209150317D1A1D9863C739F809@AM6PR0202MB3352.eurprd02.prod.outlook.com>
Message-ID: <39181c11-2c0e-0308-9c6f-7678fb047557@oracle.com>

Right now the failure helps the user avoid potentially inadvertently 
overwriting a file, so I think at the very least it should continue to 
fail for regular files. I'm a bit less clear on how pipes, ttys, and 
domain sockets work here. Are you saying they are all pseudo files that 
already exist and can't be deleted, and therefore you currently can't 
dump the heap to them?

Chris

On 2/23/21 11:45 PM, Schmelter, Ralf wrote:
> Hi,
>
> as described in https://bugs.openjdk.java.net/browse/JDK-8200579 it could be useful to be able to specify an already existing 'file' to be able to stream the heap dump directly to a named pipe on Windows or a tty or domain socket on Unix, especially on systems with low disk space. Since we now don't have the requirement to seek anymore, when we open the file with os::create_binary_file(<path>, true) instead of os::create_binary_file(<path>, false) we could just do that.
>
> However, I'm not sure how this would be feasible from a security perspective, since this would allow users who have the permission to trigger a heap dump to overwrite files. One could check if the opened file is one of the special types (pipes, tty, domain sockets) and allow it only for these cases.
>
> What do you think?
>
> Best regards,
> Ralf


From Alan.Bateman at oracle.com  Wed Feb 24 20:39:45 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 24 Feb 2021 20:39:45 +0000
Subject: RFC: Allowing existing file when writing a heap dump
In-Reply-To: <39181c11-2c0e-0308-9c6f-7678fb047557@oracle.com>
References: <AM6PR0202MB335209150317D1A1D9863C739F809@AM6PR0202MB3352.eurprd02.prod.outlook.com>
 <39181c11-2c0e-0308-9c6f-7678fb047557@oracle.com>
Message-ID: <b4fd0301-46e2-4d6d-a066-55b91a8f7a41@oracle.com>

On 24/02/2021 20:16, Chris Plummer wrote:
> Right now the failure helps the user avoid potentially inadvertently 
> overwriting a file, so I think at the very least it should continue to 
> fail for regular files. I'm a bit less clear on how pipes, ttys, and 
> domain sockets work here. Are you saying they are all pseudo files 
> that already exist and can't be deleted, and therefore you currently 
> can't dump the heap to them?
I added the built-in heap dumper in JDK 6 and changed jmap at the time 
to invoke it. The reason for not overriding existing files was security 
concerns and also the potential for accidents. One use-case at the time 
for specifying an existing file was to append the dump to an existing 
heap dump, meaning several heap dumps in the same file that could be 
used for comparison purposes. We didn't go too far on extending the 
hprof binary format to support that. For the current discussion then I 
think it will be ambiguous when the file already exists, it doesn't 
matter if it's a tty or socket file. I think it would require an 
additional hint from the user as to whether they are trying to override 
the file or write to the tty or socket.

-Alan

From lmesnik at openjdk.java.net  Wed Feb 24 22:15:47 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Wed, 24 Feb 2021 22:15:47 GMT
Subject: RFR: 8262332: serviceability/sa/ClhsdbJhisto.java fails with Test
 ERROR java.lang.RuntimeException: 'ParselTongue' missing from stdout/stderr
Message-ID: <wG6Y_igoyKfkwgjXS3zGSbtkjun8q8OZKN-nqgOKkzk=.fe93b3ce-95e1-4a85-92b9-309cb427f319@github.com>

?va.lang.RuntimeException: 'ParselTongue' missing from stdout/stderr

-------------

Commit messages:
 - 8262332: serviceability/sa/ClhsdbJhisto.java fails with Test ERROR java.lang.RuntimeException: 'ParselTongue' missing from stdout/stderr

Changes: https://git.openjdk.java.net/jdk/pull/2717/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2717&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8262332
  Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2717.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2717/head:pull/2717

PR: https://git.openjdk.java.net/jdk/pull/2717

From mdoerr at openjdk.java.net  Wed Feb 24 22:38:40 2021
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Wed, 24 Feb 2021 22:38:40 GMT
Subject: RFR: 8261447: MethodInvocationCounters frequently run into
 overflow [v7]
In-Reply-To: <Aj0149Vh2JIXvEwJ3Vxj7ThRz93rAmZv8hcJtkFdNLo=.bf8765cf-6c33-4bd9-85bc-c18f41eb62b5@github.com>
References: <FsHAKG6KwqJeHLIhE6JroDUjiebdevi1asoLi-7pQ1s=.15d96719-36f2-4f9b-ae80-fcb17a3b6659@github.com>
 <Aj0149Vh2JIXvEwJ3Vxj7ThRz93rAmZv8hcJtkFdNLo=.bf8765cf-6c33-4bd9-85bc-c18f41eb62b5@github.com>
Message-ID: <w8hYdtpgQ8mlcOQbyqmXldRTRv1Pb7r7hjavwuEJJ7w=.19cfe028-1f64-40a4-be64-9788fc698823@github.com>

On Wed, 17 Feb 2021 18:22:01 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 (185 days 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:
> 
>   update copyright year

This version looks ok. I understand that you don't want to clean up the whole singed / unsigned mess. That's fine with me. I'd only like to see one confusing comment removed or replaced.
You may also want to check your 64 bit overflow time in the description: I guess 185 days matches a 1 THz counter update frequency. With 1 GHz it should be above 500 years.

src/hotspot/share/runtime/java.cpp line 100:

> 98: int compare_methods(Method** a, Method** b) {
> 99:   // invocation_count() may have overflowed already. Interpret it's result as
> 100:   // unsigned int to shift the limit of meaningless results by a factor of 2.

Code is fine, but this comment doesn't make sense to me. The result is the same with your version. But it has the advantage that it avoids signed integer overflow (undefined behavior).

-------------

Changes requested by mdoerr (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2511

From cjplummer at openjdk.java.net  Wed Feb 24 22:59:40 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 24 Feb 2021 22:59:40 GMT
Subject: RFR: 8262332: serviceability/sa/ClhsdbJhisto.java fails with Test
 ERROR java.lang.RuntimeException: 'ParselTongue' missing from stdout/stderr
In-Reply-To: <wG6Y_igoyKfkwgjXS3zGSbtkjun8q8OZKN-nqgOKkzk=.fe93b3ce-95e1-4a85-92b9-309cb427f319@github.com>
References: <wG6Y_igoyKfkwgjXS3zGSbtkjun8q8OZKN-nqgOKkzk=.fe93b3ce-95e1-4a85-92b9-309cb427f319@github.com>
Message-ID: <p3UqVevsS8Tq6xFjkpASzA3cS0eIgX4Cd85_SbvAeJ0=.64894eec-5e90-4aad-85d3-28e52c61e317@github.com>

On Wed, 24 Feb 2021 22:10:49 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> ?va.lang.RuntimeException: 'ParselTongue' missing from stdout/stderr

Looks good.

-------------

Marked as reviewed by cjplummer (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2717

From cjplummer at openjdk.java.net  Wed Feb 24 23:09:39 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 24 Feb 2021 23:09:39 GMT
Subject: RFR: 8262332: serviceability/sa/ClhsdbJhisto.java fails with Test
 ERROR java.lang.RuntimeException: 'ParselTongue' missing from stdout/stderr
In-Reply-To: <p3UqVevsS8Tq6xFjkpASzA3cS0eIgX4Cd85_SbvAeJ0=.64894eec-5e90-4aad-85d3-28e52c61e317@github.com>
References: <wG6Y_igoyKfkwgjXS3zGSbtkjun8q8OZKN-nqgOKkzk=.fe93b3ce-95e1-4a85-92b9-309cb427f319@github.com>
 <p3UqVevsS8Tq6xFjkpASzA3cS0eIgX4Cd85_SbvAeJ0=.64894eec-5e90-4aad-85d3-28e52c61e317@github.com>
Message-ID: <AVw_v_3gs3SBb3cnqT0KXRX8JkhByX5CilygMQVW0J4=.afa94b47-97df-4fe2-ac30-09252863d692@github.com>

On Wed, 24 Feb 2021 22:57:05 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> ?va.lang.RuntimeException: 'ParselTongue' missing from stdout/stderr
>
> Looks good.

I had some more thoughts after my review. Please see the CR for comments.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2717

From cjplummer at openjdk.java.net  Thu Feb 25 03:59:56 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 25 Feb 2021 03:59:56 GMT
Subject: RFR: 8262271: SA: Add new stress test that tests getting the stack
 trace of an active thread
Message-ID: <59yxshwLvp5MVCYf2F2THU0T-SJjWbQfQTRLpJ3o2K4=.0e2e73cb-71dd-41b1-a86c-3460631c544c@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.

-------------

Commit messages:
 - Fix @bug
 - Add JStackStressTest

Changes: https://git.openjdk.java.net/jdk/pull/2720/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2720&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8262271
  Stats: 115 lines in 1 file changed: 115 ins; 0 del; 0 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 david.holmes at oracle.com  Thu Feb 25 05:20:11 2021
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 25 Feb 2021 15:20:11 +1000
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: <676fa12d-d49c-215a-64c7-4f054364682a@oracle.com>

Hi Chris,

On 25/02/2021 1:59 pm, Chris Plummer 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.

Cheers,
David

> -------------
> 
> Commit messages:
>   - Fix @bug
>   - Add JStackStressTest
> 
> Changes: https://git.openjdk.java.net/jdk/pull/2720/files
>   Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2720&range=00
>    Issue: https://bugs.openjdk.java.net/browse/JDK-8262271
>    Stats: 115 lines in 1 file changed: 115 ins; 0 del; 0 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  Thu Feb 25 07:03:40 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 25 Feb 2021 07:03:40 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: <_K-vQe2ii1xQ6eUI1tlrMr1Jzln35Enmb_wO_XIFc4w=.9e23582a-2fcf-4044-bd97-d6c653b200d3@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.

> 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.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2720

From lucy at openjdk.java.net  Thu Feb 25 09:01:11 2021
From: lucy at openjdk.java.net (Lutz Schmidt)
Date: Thu, 25 Feb 2021 09:01:11 GMT
Subject: RFR: 8261447: MethodInvocationCounters frequently run into
 overflow [v7]
In-Reply-To: <w8hYdtpgQ8mlcOQbyqmXldRTRv1Pb7r7hjavwuEJJ7w=.19cfe028-1f64-40a4-be64-9788fc698823@github.com>
References: <FsHAKG6KwqJeHLIhE6JroDUjiebdevi1asoLi-7pQ1s=.15d96719-36f2-4f9b-ae80-fcb17a3b6659@github.com>
 <Aj0149Vh2JIXvEwJ3Vxj7ThRz93rAmZv8hcJtkFdNLo=.bf8765cf-6c33-4bd9-85bc-c18f41eb62b5@github.com>
 <w8hYdtpgQ8mlcOQbyqmXldRTRv1Pb7r7hjavwuEJJ7w=.19cfe028-1f64-40a4-be64-9788fc698823@github.com>
Message-ID: <Eoe-t08FQCv_zHUD_ZCDmHT8eyibJN0dpJet4WB3E34=.1bd8213a-2eb3-4934-92b9-8300fd3901bf@github.com>

On Wed, 24 Feb 2021 22:28:15 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Lutz Schmidt has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update copyright year
>
> src/hotspot/share/runtime/java.cpp line 100:
> 
>> 98: int compare_methods(Method** a, Method** b) {
>> 99:   // invocation_count() may have overflowed already. Interpret it's result as
>> 100:   // unsigned int to shift the limit of meaningless results by a factor of 2.
> 
> Code is fine, but this comment doesn't make sense to me. The result is the same with your version. But it has the advantage that it avoids signed integer overflow (undefined behavior).

I agree. The comments could be misleading. They are gone.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2511

From lucy at openjdk.java.net  Thu Feb 25 09:01:10 2021
From: lucy at openjdk.java.net (Lutz Schmidt)
Date: Thu, 25 Feb 2021 09:01:10 GMT
Subject: RFR: 8261447: MethodInvocationCounters frequently run into
 overflow [v8]
In-Reply-To: <FsHAKG6KwqJeHLIhE6JroDUjiebdevi1asoLi-7pQ1s=.15d96719-36f2-4f9b-ae80-fcb17a3b6659@github.com>
References: <FsHAKG6KwqJeHLIhE6JroDUjiebdevi1asoLi-7pQ1s=.15d96719-36f2-4f9b-ae80-fcb17a3b6659@github.com>
Message-ID: <Ul6OJXuqVlRZxy7OxB0SRre44bZaZAg7e757hdZf34A=.37ac8cdd-c438-436b-9f84-6176f329b735@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:

  comment changes requested by TheRealMDoerr

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2511/files
  - new: https://git.openjdk.java.net/jdk/pull/2511/files/0f220ee3..e8af119b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2511&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2511&range=06-07

  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 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 ralf.schmelter at sap.com  Thu Feb 25 09:07:36 2021
From: ralf.schmelter at sap.com (Schmelter, Ralf)
Date: Thu, 25 Feb 2021 09:07:36 +0000
Subject: RFC: Allowing existing file when writing a heap dump
In-Reply-To: <39181c11-2c0e-0308-9c6f-7678fb047557@oracle.com>
References: <AM6PR0202MB335209150317D1A1D9863C739F809@AM6PR0202MB3352.eurprd02.prod.outlook.com>
 <39181c11-2c0e-0308-9c6f-7678fb047557@oracle.com>
Message-ID: <AM6PR0202MB3352C9DCE2150A0CF06248449F9E9@AM6PR0202MB3352.eurprd02.prod.outlook.com>

Hi Chris,

> Are you saying they are all pseudo files that 
> already exist and can't be deleted, and therefore you currently
> can't dump the heap to them?

Yes, these are pseudo files and have to be created by special calls.
But you can open and write to them using the usual file APIs, so
No big changes are required in the heap dump code.

For domain sockets or named pipes you need another program
(like nc on Unix) which creates them and reads the output. 

And I think this should not work be default, but only is requested
By the used via a flag or something.

Best regards,
Ralf

From mdoerr at openjdk.java.net  Thu Feb 25 09:53:41 2021
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Thu, 25 Feb 2021 09:53:41 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: <OP0SNLcg3VCRecXWPim1t-q49tpNXk-xIZFqAxvw4DQ=.4cdcc86b-a679-466d-bdd6-ba4eaebb8321@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

Marked as reviewed by mdoerr (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2511

From lzang at openjdk.java.net  Thu Feb 25 12:00:41 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Thu, 25 Feb 2021 12:00:41 GMT
Subject: RFR: 8261131: jcmd jmap dump should not accept gz option with no
 value [v3]
In-Reply-To: <oHPlWMiUzIcTABQ_br7GYLv9jTfz8Z0CjHzZxBYz-O8=.408ce287-7269-44fb-9a67-bb091ac603fe@github.com>
References: <qUp1tOUkdsvzPGH03MyAhSokYQUUYm9xz-2X6GjsSC4=.21007ed7-65f7-4768-a2f8-e7d2ac2533f6@github.com>
 <_wOxIScREVJ2249eVGInbc9G8hiihHCU110IgLDUFBo=.7b656721-b847-420d-b8f8-e7298cc4f5ba@github.com>
 <oHPlWMiUzIcTABQ_br7GYLv9jTfz8Z0CjHzZxBYz-O8=.408ce287-7269-44fb-9a67-bb091ac603fe@github.com>
Message-ID: <rXy9aqiDWmy3D9eL_VD-tvci2auETX3o-yR-SD8q5MI=.d849a01c-d164-479f-9528-44a3328a69b8@github.com>

On Tue, 9 Feb 2021 05:49:51 GMT, Serguei Spitsyn <sspitsyn 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 three additional commits since the last revision:
>> 
>>  - Merge branch 'master' into gz-fix
>>  - remove useless code and update copyright
>>  - 8261131: jcmd jmap dump should not accept gz option with no value
>
> Hi Lin,
> The fix looks good to me.
> Thanks,
> Serguei

Dear All?
May I ask your help to push this PR as it is ready. 
Thanks!
Lin

-------------

PR: https://git.openjdk.java.net/jdk/pull/2399

From lzang at openjdk.java.net  Thu Feb 25 12:00:49 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Thu, 25 Feb 2021 12:00:49 GMT
Subject: RFR: 8257234 : Add gz option to SA jmap to write a gzipped heap
 dump [v20]
In-Reply-To: <M-7yKHpuSyVsrbNv2XdMP4rKp0kvke0yxzZlz8P07BU=.2a8e487d-a8a3-4de9-b93f-13b56ceaaa5e@github.com>
References: <oTMRc7LWvx9_Uov01HPX9UgyEqFmXt_nMG920HUQBIM=.3651754b-e1f1-46f8-9f44-c118a5c56dbe@github.com>
 <G_Lbe4FPO42wiU-W7Y_UkV53JzqVCql2sUWJAFObFm0=.74a3d2a7-fb24-4dc7-bac4-da347b61d98f@github.com>
 <h-29LR29psutzoUwDZpIB96GNtd8BR1q4Vyt3IDbbKA=.534ce2d5-821a-41e2-94eb-9ea409c7fb9f@github.com>
 <M-7yKHpuSyVsrbNv2XdMP4rKp0kvke0yxzZlz8P07BU=.2a8e487d-a8a3-4de9-b93f-13b56ceaaa5e@github.com>
Message-ID: <NcbNUyJ4WQyWteYw0QYVR-g7H5zXoNMG38_TDu70kXo=.5c283481-559e-4ee0-9fb4-79223b4c56a6@github.com>

On Sat, 20 Feb 2021 11:35:18 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> Marked as reviewed by cjplummer (Reviewer).
>
> Mark it as ready for pushing. Thanks @plummercj @sspitsyn and @YaSuenag for help reviewing!

Dear All?
May I ask your help to push this PR as it is ready. 
Thanks!
Lin

-------------

PR: https://git.openjdk.java.net/jdk/pull/1712

From lzang at openjdk.java.net  Thu Feb 25 12:08:40 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Thu, 25 Feb 2021 12:08:40 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v10]
In-Reply-To: <GO6ucQvERsY13TAxZHiwOTbzaMPVDpo_QKVVx4fBuZI=.51a1730e-ac8c-48e4-a6b7-5e41b6f52681@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>
 <qvSH7yKPvHChpZAjPZL-moQ2VhipQA5F67hfERe3DyQ=.a010a4fc-4792-4e8a-ae30-12a21495d029@github.com>
 <lMPu_htCJNLuQKrM6ef1bLHwkODw9D89bWN8WBGP4zU=.f07ed9a1-bb8d-49c6-a4aa-b898eb6c2129@github.com>
 <RhtewCm33ykTf7s8SBHb5hRm9jsxkv83MYbETh5Y4dU=.97cf3fd2-5b14-4c9e-b246-45df4bde67e7@github.com>
 <dcndd6MSvXV9xvokXKFqLTYj2HB7-xMTDUD
 9ePVUTmE=.fd8b109f-df5f-45b8-beec-bc031323736a@github.com>
 <jc6EZENV75QtVskMR4yEPLOqvqPI7E4aHIf7YRjdtfQ=.f9ccc952-3528-4718-8d26-dd8ebe797273@github.com>
 <fXkLIJ7l-QppUAN3Xbglu7zkHASsGZCYzTIYyKy8xUc=.bab3707f-6558-4d66-aa0a-d1deb1951b30@github.com>
 <2TigA_-oOnothuzJIe4evP9QnGxaa0AyfukiQe_9ygU=.c9b6d54b-489f-41e6-8870-b90aee733594@github.com>
 <GO6ucQvERsY13TAxZHiwOTbzaMPVDpo_QKVVx4fBuZI=.51a1730e-ac8c-48e4-a6b7-5e41b6f52681@github.com>
Message-ID: <02rkw2Zw9IoWQOHiZBe9p_W2ECuvgv0A0E9MwLkV9WI=.d4b6853c-9e0c-47be-8e02-953707faf637@github.com>

On Wed, 24 Feb 2021 04:12:13 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>>> It's too bad that the `dumpheap` command in previous JDKs has a slot for a 3rd argument, but doesn't look at it. Maybe that was intentional to allow for a new argument without causing a failure. What it means is if we want a failure, we need to either send a different command, or use the suggestion of having all the arguments in the first argument, both of which would result in a failure when used with an older JDK (in which case we would retry with older argument passing).
>> 
>> Yes, I believe the argument max set to 3 was based on assumption that there can be at most 3 arguments from client side, no matter which tool it is (jmap, jstack, jinfo). 
>> 
>> And the jcmd command actually already passed all arguemnt as a single string, so there is no issue for accepting more arguments.
>>  
>>> But they are far more convenient and easier to understand than jcmd, so will probably stay around. But you are right in that they could still all be converted to use jcmd internally.
>> 
>> Maybe we could consider using `jcmd` internally to replace the current implementation of these tools, and keep their usage as before, then we get same result from `jcmd` and `jmap` alike tools, get rid of the argument passing limitation (because jcmd make all argument as a string), and also reduce the overhead of maintanence (e.g. don't bothering adding new options for both jmap and jcmd )
>> 
>>> Ok, but that fix is on the client side, not the target VM side.
>> 
>> Yes, it only change the client side to reject illegal arguments, the JVM side still work as it is -  ingore unknown argument silicently. However, the client side could at least reject unknown option and hence pass correct ones as expected to JVM.
>> So if we agree on this change, at least for "parallel=" option, we don't need to retry when get the exception. :-)
>
>> > But they are far more convenient and easier to understand than jcmd, so will probably stay around. But you are right in that they could still all be converted to use jcmd internally.
>> 
>> Maybe we could consider using `jcmd` internally to replace the current implementation of these tools, and keep their usage as before, then we get same result from `jcmd` and `jmap` alike tools, get rid of the argument passing limitation (because jcmd make all argument as a string), and also reduce the overhead of maintanence (e.g. don't bothering adding new options for both jmap and jcmd )
> 
> It does reduce the maintenance overhead, but you still need to parse the arguments on the client side and package them up the way jcmd likes to see them.
> 
>> 
>> > Ok, but that fix is on the client side, not the target VM side.
>> 
>> Yes, it only change the client side to reject illegal arguments, the JVM side still work as it is - ingore unknown argument silicently. However, the client side could at least reject unknown option and hence pass correct ones as expected to JVM.
>> So if we agree on this change, at least for "parallel=" option, we don't need to retry when get the exception. :-)
> 
> Actually you should still see an error when using `parallel` or `gz` when the target VM doesn't understand them. This is because `jcmd` will reject them on the target VM side. Then the question is whether to retry without them, or pass the error to the user and let them adjust their `jmap` command. The problem with the latter is that the arguments in the `jcmd` error message might not look exactly the same as the way they were specified by the user to `jmap`. We'd have take a closer look at the `jcmd` error messages to see if they are appropriate for `jmap` users.

Hi @plummercj, 
I agree, the output data must already be used by some parsing tools I believe. So the output format must keep the same no matter what change we want to make.
I will mark CSR to this PR as we agreed the on introducing the `parallel=` option.  

Thanks

-------------

PR: https://git.openjdk.java.net/jdk/pull/2261

From lzang at openjdk.java.net  Thu Feb 25 12:09:43 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Thu, 25 Feb 2021 12:09:43 GMT
Subject: Integrated: 8261131: jcmd jmap dump should not accept gz option with
 no value
In-Reply-To: <qUp1tOUkdsvzPGH03MyAhSokYQUUYm9xz-2X6GjsSC4=.21007ed7-65f7-4768-a2f8-e7d2ac2533f6@github.com>
References: <qUp1tOUkdsvzPGH03MyAhSokYQUUYm9xz-2X6GjsSC4=.21007ed7-65f7-4768-a2f8-e7d2ac2533f6@github.com>
Message-ID: <-vnjK8iTFPHqLwuG-87gjoReGCWPj-N33Fv3V7H4LzA=.b27409b7-a5ce-4414-805b-b2f2b5c640c0@github.com>

On Thu, 4 Feb 2021 07:11:19 GMT, Lin Zang <lzang at openjdk.org> wrote:

> 8261131: jcmd jmap dump should not accept gz option with no value

This pull request has now been integrated.

Changeset: aa35b423
Author:    Lin Zang <lzang at openjdk.org>
Committer: Jie Fu <jiefu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/aa35b423
Stats:     28 lines in 2 files changed: 19 ins; 0 del; 9 mod

8261131: jcmd jmap dump should not accept gz option with no value

Reviewed-by: cjplummer, sspitsyn

-------------

PR: https://git.openjdk.java.net/jdk/pull/2399

From lzang at openjdk.java.net  Thu Feb 25 12:12:45 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Thu, 25 Feb 2021 12:12:45 GMT
Subject: Integrated: 8257234 : Add gz option to SA jmap to write a gzipped
 heap dump
In-Reply-To: <oTMRc7LWvx9_Uov01HPX9UgyEqFmXt_nMG920HUQBIM=.3651754b-e1f1-46f8-9f44-c118a5c56dbe@github.com>
References: <oTMRc7LWvx9_Uov01HPX9UgyEqFmXt_nMG920HUQBIM=.3651754b-e1f1-46f8-9f44-c118a5c56dbe@github.com>
Message-ID: <4usAz0vYNC-C7nKOHyeSG8IAYowsLfh-ATtTs_kC3Oo=.4bd34e77-8e1d-4374-93b4-c54059366d24@github.com>

On Wed, 9 Dec 2020 08:51:48 GMT, Lin Zang <lzang at openjdk.org> wrote:

> 8257234 : Add gz option to SA jmap to write a gzipped heap dump

This pull request has now been integrated.

Changeset: c54724da
Author:    Lin Zang <lzang at openjdk.org>
Committer: Jie Fu <jiefu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c54724da
Stats:     657 lines in 7 files changed: 552 ins; 23 del; 82 mod

8257234: Add gz option to SA jmap to write a gzipped heap dump

Reviewed-by: cjplummer, ysuenaga, sspitsyn

-------------

PR: https://git.openjdk.java.net/jdk/pull/1712

From lzang at openjdk.java.net  Thu Feb 25 12:21:41 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Thu, 25 Feb 2021 12:21:41 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v10]
In-Reply-To: <GO6ucQvERsY13TAxZHiwOTbzaMPVDpo_QKVVx4fBuZI=.51a1730e-ac8c-48e4-a6b7-5e41b6f52681@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>
 <qvSH7yKPvHChpZAjPZL-moQ2VhipQA5F67hfERe3DyQ=.a010a4fc-4792-4e8a-ae30-12a21495d029@github.com>
 <lMPu_htCJNLuQKrM6ef1bLHwkODw9D89bWN8WBGP4zU=.f07ed9a1-bb8d-49c6-a4aa-b898eb6c2129@github.com>
 <RhtewCm33ykTf7s8SBHb5hRm9jsxkv83MYbETh5Y4dU=.97cf3fd2-5b14-4c9e-b246-45df4bde67e7@github.com>
 <dcndd6MSvXV9xvokXKFqLTYj2HB7-xMTDUD
 9ePVUTmE=.fd8b109f-df5f-45b8-beec-bc031323736a@github.com>
 <jc6EZENV75QtVskMR4yEPLOqvqPI7E4aHIf7YRjdtfQ=.f9ccc952-3528-4718-8d26-dd8ebe797273@github.com>
 <fXkLIJ7l-QppUAN3Xbglu7zkHASsGZCYzTIYyKy8xUc=.bab3707f-6558-4d66-aa0a-d1deb1951b30@github.com>
 <2TigA_-oOnothuzJIe4evP9QnGxaa0AyfukiQe_9ygU=.c9b6d54b-489f-41e6-8870-b90aee733594@github.com>
 <GO6ucQvERsY13TAxZHiwOTbzaMPVDpo_QKVVx4fBuZI=.51a1730e-ac8c-48e4-a6b7-5e41b6f52681@github.com>
Message-ID: <ADSUctjMOWwWdM6Hy2VzHoq-bK73GL9XV8jkLqzhksk=.a28e7949-7b43-4554-b0ef-94c9e9769ddc@github.com>

On Wed, 24 Feb 2021 04:12:13 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>>> It's too bad that the `dumpheap` command in previous JDKs has a slot for a 3rd argument, but doesn't look at it. Maybe that was intentional to allow for a new argument without causing a failure. What it means is if we want a failure, we need to either send a different command, or use the suggestion of having all the arguments in the first argument, both of which would result in a failure when used with an older JDK (in which case we would retry with older argument passing).
>> 
>> Yes, I believe the argument max set to 3 was based on assumption that there can be at most 3 arguments from client side, no matter which tool it is (jmap, jstack, jinfo). 
>> 
>> And the jcmd command actually already passed all arguemnt as a single string, so there is no issue for accepting more arguments.
>>  
>>> But they are far more convenient and easier to understand than jcmd, so will probably stay around. But you are right in that they could still all be converted to use jcmd internally.
>> 
>> Maybe we could consider using `jcmd` internally to replace the current implementation of these tools, and keep their usage as before, then we get same result from `jcmd` and `jmap` alike tools, get rid of the argument passing limitation (because jcmd make all argument as a string), and also reduce the overhead of maintanence (e.g. don't bothering adding new options for both jmap and jcmd )
>> 
>>> Ok, but that fix is on the client side, not the target VM side.
>> 
>> Yes, it only change the client side to reject illegal arguments, the JVM side still work as it is -  ingore unknown argument silicently. However, the client side could at least reject unknown option and hence pass correct ones as expected to JVM.
>> So if we agree on this change, at least for "parallel=" option, we don't need to retry when get the exception. :-)
>
>> > But they are far more convenient and easier to understand than jcmd, so will probably stay around. But you are right in that they could still all be converted to use jcmd internally.
>> 
>> Maybe we could consider using `jcmd` internally to replace the current implementation of these tools, and keep their usage as before, then we get same result from `jcmd` and `jmap` alike tools, get rid of the argument passing limitation (because jcmd make all argument as a string), and also reduce the overhead of maintanence (e.g. don't bothering adding new options for both jmap and jcmd )
> 
> It does reduce the maintenance overhead, but you still need to parse the arguments on the client side and package them up the way jcmd likes to see them.
> 
>> 
>> > Ok, but that fix is on the client side, not the target VM side.
>> 
>> Yes, it only change the client side to reject illegal arguments, the JVM side still work as it is - ingore unknown argument silicently. However, the client side could at least reject unknown option and hence pass correct ones as expected to JVM.
>> So if we agree on this change, at least for "parallel=" option, we don't need to retry when get the exception. :-)
> 
> Actually you should still see an error when using `parallel` or `gz` when the target VM doesn't understand them. This is because `jcmd` will reject them on the target VM side. Then the question is whether to retry without them, or pass the error to the user and let them adjust their `jmap` command. The problem with the latter is that the arguments in the `jcmd` error message might not look exactly the same as the way they were specified by the user to `jmap`. We'd have take a closer look at the `jcmd` error messages to see if they are appropriate for `jmap` users.

Dear @plummercj, 
Do you think it is ok if I change the help message of `parallel` option `jmap -histo` in this PR together?  specificly, change the sentence 
`n use n threads, n must be positive` to 
` For any other value the VM will try to use the specified number of threads, but might use fewer. ` 

BRs,
Lin

-------------

PR: https://git.openjdk.java.net/jdk/pull/2261

From sgehwolf at openjdk.java.net  Thu Feb 25 16:33:05 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Thu, 25 Feb 2021 16:33:05 GMT
Subject: RFR: 8262379: Add regression test for JDK-8257746
Message-ID: <bePB-zu9tc6Pp6B_wqVakmQ_Ouh5iDJSdKyO4sWLDFQ=.78bdb2de-9d5a-47c6-8679-b1ac9304e3d4@github.com>

Fails prior the patch of JDK-8257746, passes after. As expected.

Thoughts?

-------------

Commit messages:
 - 8262379: Add regression test for JDK-8257746

Changes: https://git.openjdk.java.net/jdk/pull/2725/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2725&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8262379
  Stats: 56 lines in 1 file changed: 56 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2725.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2725/head:pull/2725

PR: https://git.openjdk.java.net/jdk/pull/2725

From gziemski at openjdk.java.net  Thu Feb 25 17:34:58 2021
From: gziemski at openjdk.java.net (Gerard Ziemski)
Date: Thu, 25 Feb 2021 17:34:58 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v18]
In-Reply-To: <ix6gQkIFb_3zkw3EwW6PbnsHBPwjoai9kux5-O3SM7E=.a36d66e9-97cc-4240-8512-4850a0daa02c@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <ix6gQkIFb_3zkw3EwW6PbnsHBPwjoai9kux5-O3SM7E=.a36d66e9-97cc-4240-8512-4850a0daa02c@github.com>
Message-ID: <G2xel1nVI8Xp3hGWP93QFF-E1ZisTeIQSt2x9oTb1Cc=.0bc38bcf-f1bc-42f1-8881-c7177c9d5e90@github.com>

On Wed, 17 Feb 2021 12:36:10 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 88 commits:
> 
>  - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos
>  - Re-do safefetch.hpp
>  - Merge remote-tracking branch 'origin/jdk/8261075-stubroutines-inline' into jdk-macos
>  - stubRoutines.inline.hpp -> safefetch.hpp
>  - Update copyrights
>  - Merge remote-tracking branch 'upstream/jdk/master' into 8261075-stubroutines-inline
>  - Merge remote-tracking branch 'upstream/jdk/master' into 8261075-stubroutines-inline
>  - Extract SafeFetch32/N to stubRoutines.inline.hpp
>  - Revert "Extract SafeFetch32/N to stubRoutines.inline.hpp"
>    
>    This reverts commit b873c25f31dd21349d140b790713cc9ccb5f2dc0.
>  - Merge pull request #9 from VladimirKempik/pull/2200
>    
>    Removed unused variables
>  - ... and 78 more: https://git.openjdk.java.net/jdk/compare/b955f85e...ab72613c

Marked as reviewed by gziemski (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From dcubed at openjdk.java.net  Thu Feb 25 17:52:48 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 25 Feb 2021 17:52:48 GMT
Subject: RFR: 8241403: JavaThread::get_thread_name() should be
 ThreadSMR-aware [v5]
In-Reply-To: <zkmwEDyUrIwqBqt2kGhlLZCRHBTB1krLO43PMmLSUC8=.fd503b8f-c79d-4f03-89bc-16f65e62f475@github.com>
References: <wRdcRQurtpybntK9Qpji-6zVY-EcHKw3q87xpD0eoS4=.a6dc32f4-2919-42e9-80c3-5a264067f0e2@github.com>
 <zkmwEDyUrIwqBqt2kGhlLZCRHBTB1krLO43PMmLSUC8=.fd503b8f-c79d-4f03-89bc-16f65e62f475@github.com>
Message-ID: <qgjoVq1KVMIM3E7o1r8fEmMaYEJ9dwaOWwCQrz33LPg=.dab3a15e-36ee-4c34-b396-5e5ba5814162@github.com>

On Tue, 23 Feb 2021 23:52:15 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> A minor fix to add a new function:
>> 
>>     bool Thread::is_JavaThread_protected(const JavaThread* p)
>> 
>> that returns true when the target JavaThread* is protected and false
>> otherwise. Update JavaThread::get_thread_name() to create a
>> ThreadsListHandle and use the new is_JavaThread_protected(). Also
>> update JvmtiTrace::safe_get_thread_name() to use the new
>> is_JavaThread_protected().
>> 
>> This fix is tested via a Mach5 Tier[1-8] run.
>
> Daniel D. Daugherty 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 six additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8241403
>  - Address dholmes-ora CR2 comments.
>  - Address dholmes-ora CR1 comments.
>  - Merge branch 'master' into JDK-8241403
>  - Address coleenp CR0 comments.
>  - 8241403: JavaThread::get_thread_name() should be ThreadSMR-aware

@dholmes-ora - Thanks for reviewing CR3. I've made more changes
and once my testing looks good, I'll checkpoint and push to update the PR.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2535

From dcubed at openjdk.java.net  Thu Feb 25 17:52:52 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 25 Feb 2021 17:52:52 GMT
Subject: RFR: 8241403: JavaThread::get_thread_name() should be
 ThreadSMR-aware [v5]
In-Reply-To: <3E4aN8avhZIGL3w8YUPHlu1HF3t4wW-NWZTuH8Ty52k=.270b79d6-8024-4f1c-9b54-37007c6b93e3@github.com>
References: <wRdcRQurtpybntK9Qpji-6zVY-EcHKw3q87xpD0eoS4=.a6dc32f4-2919-42e9-80c3-5a264067f0e2@github.com>
 <zkmwEDyUrIwqBqt2kGhlLZCRHBTB1krLO43PMmLSUC8=.fd503b8f-c79d-4f03-89bc-16f65e62f475@github.com>
 <3E4aN8avhZIGL3w8YUPHlu1HF3t4wW-NWZTuH8Ty52k=.270b79d6-8024-4f1c-9b54-37007c6b93e3@github.com>
Message-ID: <3XdE0lvhPac-DXHQVvDXtjCT46hvfGNfwCAxQ-QYWJw=.78baec27-83e5-4893-a517-51fb8306f766@github.com>

On Wed, 24 Feb 2021 00:36:28 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Daniel D. Daugherty 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 six additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8241403
>>  - Address dholmes-ora CR2 comments.
>>  - Address dholmes-ora CR1 comments.
>>  - Merge branch 'master' into JDK-8241403
>>  - Address coleenp CR0 comments.
>>  - 8241403: JavaThread::get_thread_name() should be ThreadSMR-aware
>
> src/hotspot/share/compiler/compileBroker.cpp line 1115:
> 
>> 1113:       if (ct == NULL) break;
>> 1114:       ThreadsListHandle tlh;
>> 1115:       if (!tlh.includes(ct)) break;
> 
> This change raised a red flag because if the new thread already terminated it should decrement the number of compiler threads on its way out, but we are skipping the increment by breaking here. So that prompted me to look closer at the bigger picture for these compiler threads and their lifecycle. The current code is called whilst holding the CompilerThread_lock, which means that the new thread can't terminate because it has to also acquire the CompilerThread_lock to decide whether it needs to terminate. So access to ct is guaranteed to be safe and no TLH is needed at all - other than because get_thread_name() requires it. So this should be a simple assertion afterall.

Okay. I've switched this one back to an assertion after the TLH.
Thanks for the analysis.

> src/hotspot/share/compiler/compileBroker.cpp line 1136:
> 
>> 1134:       if (ct == NULL) break;
>> 1135:       ThreadsListHandle tlh;
>> 1136:       if (!tlh.includes(ct)) break;
> 
> Ditto.

Okay. I've switched this one back to an assertion after the TLH.

> src/hotspot/share/runtime/thread.cpp line 2955:
> 
>> 2953: void Threads::threads_do(JavaThreadIteratorWithHandle* jtiwh_p, ThreadClosure* tc) {
>> 2954:   java_threads_do(jtiwh_p, tc);
>> 2955:   non_java_threads_do(tc);
> 
> You should still have
> 
> (Threads_lock);```
> 
> for non-JavaThread access.

I'm backing out both:
Threads::java_threads_do(JavaThreadIteratorWithHandle* jtiwh_p, ThreadClosure* tc)
Threads::threads_do(JavaThreadIteratorWithHandle* jtiwh_p, ThreadClosure* tc)

and I'm backing out the changes to src/hotspot/share/services/management.cpp.
By removing the Threads_lock usage, I'm allowing those closures to run in parallel
with other closures that are using the original Threads::java_threads_do() and
Threads::threads_do() calls that do use the Threads_lock. Those other uses might
be assuming exclusivity for their algorithms and my M&M changes break that.

> src/hotspot/share/services/management.cpp line 1704:
> 
>> 1702:   {
>> 1703:     JavaThreadIteratorWithHandle jtiwh;
>> 1704:     Threads::threads_do(&jtiwh, &ttc);
> 
> Same comments as above re need for Threads_lock.

I'm backing out the changes to src/hotspot/share/services/management.cpp.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2535

From dcubed at openjdk.java.net  Thu Feb 25 17:52:52 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 25 Feb 2021 17:52:52 GMT
Subject: RFR: 8241403: JavaThread::get_thread_name() should be
 ThreadSMR-aware [v4]
In-Reply-To: <vI72u_d8c32LSOQtLdExu1F4HztWBH8D4KNmS9CTeOc=.26e279da-1078-439b-b304-810e55de34de@github.com>
References: <wRdcRQurtpybntK9Qpji-6zVY-EcHKw3q87xpD0eoS4=.a6dc32f4-2919-42e9-80c3-5a264067f0e2@github.com>
 <6MUhGSRe79fD3SkU0sbPKDneAQMpJvpVvL1uwImO7vI=.d28b3e10-5527-4df6-b554-c21ba598db56@github.com>
 <hz-UIqnBo7HLeumeNfO_6YqGw13SebRDeMMb9yg71a0=.21788f6e-58f6-45ec-b3a2-eb57365e61ae@github.com>
 <CtPkCIY0IBr6rVx9OyUJDh3mopAydC82tzRofbqrUXU=.c2bd9767-8600-45dd-a068-82b7b40d5386@github.com>
 <vI72u_d8c32LSOQtLdExu1F4HztWBH8D4KNmS9CTeOc=.26e279da-1078-439b-b304-810e55de34de@github.com>
Message-ID: <1fKII2MPGP3ZKTpzzM0nsLHmS4GllRmv0sljWXqMiYo=.e2b32e25-d76b-44a4-bf89-c3297ccbe7da@github.com>

On Wed, 24 Feb 2021 00:42:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Holding the Threads_lock is no longer being considered as
>> proper protection for the JavaThread::get_thread_name() call
>> so I had to change the code to use a JavaThreadIteratorWithHandle
>> so that we have the protection of the TLH. That closure eventually
>> gets us down to a JavaThread::get_thread_name() call...
>
> But the code is now broken as it needs the Threads_lock to guard against non-JavaThreads being created or terminating.
> The code also appears misleading because the passing of the JTIWH makes it look (to me) like it only deals with JavaThreads.
> I think this code needs to be:
>     JavaThreadIteratorWithHandle jtiwh;  // ensure JavaThreads are safe to access
>     MutexLocker ml(Threads_lock);        // ensure non_JavaThreads are safe to access
>     Threads::threads_do(&jtiwh, &vmtcc); // process all threads

I'm backing out the changes to src/hotspot/share/services/management.cpp.
By removing the Threads_lock usage, I'm allowing those closures to run in parallel
with other closures that are using the original Threads::java_threads_do() and
Threads::threads_do() calls that do use the Threads_lock. Those other uses might
be assuming exclusivity for their algorithms and my M&M changes break that.

>> ... that will tell us that we have a spot in the code where a TLH is
>> missing once we've analyzed the crash. So are you okay with this
>> assert() having a bug since the original assert has the same bug?
>
> Yes

It has occurred to me that I should have moved all of the
protection checking logic and assertion checks into the
new Thread::is_JavaThread_protected() function. That will
allow JavaThread::get_thread_name() to become very simple.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2535

From cjplummer at openjdk.java.net  Thu Feb 25 19:50:42 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 25 Feb 2021 19:50:42 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v10]
In-Reply-To: <ADSUctjMOWwWdM6Hy2VzHoq-bK73GL9XV8jkLqzhksk=.a28e7949-7b43-4554-b0ef-94c9e9769ddc@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>
 <qvSH7yKPvHChpZAjPZL-moQ2VhipQA5F67hfERe3DyQ=.a010a4fc-4792-4e8a-ae30-12a21495d029@github.com>
 <lMPu_htCJNLuQKrM6ef1bLHwkODw9D89bWN8WBGP4zU=.f07ed9a1-bb8d-49c6-a4aa-b898eb6c2129@github.com>
 <RhtewCm33ykTf7s8SBHb5hRm9jsxkv83MYbETh5Y4dU=.97cf3fd2-5b14-4c9e-b246-45df4bde67e7@github.com>
 <dcndd6MSvXV9xvokXKFqLTYj2HB7-xMTDUD
 9ePVUTmE=.fd8b109f-df5f-45b8-beec-bc031323736a@github.com>
 <jc6EZENV75QtVskMR4yEPLOqvqPI7E4aHIf7YRjdtfQ=.f9ccc952-3528-4718-8d26-dd8ebe797273@github.com>
 <fXkLIJ7l-QppUAN3Xbglu7zkHASsGZCYzTIYyKy8xUc=.bab3707f-6558-4d66-aa0a-d1deb1951b30@github.com>
 <2TigA_-oOnothuzJIe4evP9QnGxaa0AyfukiQe_9ygU=.c9b6d54b-489f-41e6-8870-b90aee733594@github.com>
 <GO6ucQvERsY13TAxZHiwOTbzaMPVDpo_QKVVx4fBuZI=.51a1730e-ac8c-48e4-a6b7-5e41b6f52681@github.com>
 <ADSUctjMOWwWdM6Hy2VzHoq-bK73GL9XV8jkLqzhksk=.a28e7949-7b43-4554-b0ef-94c9e9769ddc@github.com>
Message-ID: <Ygqd7yoXZOKp9dozlLHp2Jpj1LOlbxysi4MIqPZ5II0=.3d0c0796-a029-4294-b7db-9065326472dd@github.com>

On Thu, 25 Feb 2021 12:18:55 GMT, Lin Zang <lzang at openjdk.org> wrote:

>  Do you think it is ok if I change the help message of `parallel` option `jmap -histo` in this PR together?

Yes, I think that would be ok.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2261

From david.holmes at oracle.com  Thu Feb 25 22:18:35 2021
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 26 Feb 2021 08:18:35 +1000
Subject: RFR: 8241403: JavaThread::get_thread_name() should be
 ThreadSMR-aware [v4]
In-Reply-To: <1fKII2MPGP3ZKTpzzM0nsLHmS4GllRmv0sljWXqMiYo=.e2b32e25-d76b-44a4-bf89-c3297ccbe7da@github.com>
References: <wRdcRQurtpybntK9Qpji-6zVY-EcHKw3q87xpD0eoS4=.a6dc32f4-2919-42e9-80c3-5a264067f0e2@github.com>
 <6MUhGSRe79fD3SkU0sbPKDneAQMpJvpVvL1uwImO7vI=.d28b3e10-5527-4df6-b554-c21ba598db56@github.com>
 <hz-UIqnBo7HLeumeNfO_6YqGw13SebRDeMMb9yg71a0=.21788f6e-58f6-45ec-b3a2-eb57365e61ae@github.com>
 <CtPkCIY0IBr6rVx9OyUJDh3mopAydC82tzRofbqrUXU=.c2bd9767-8600-45dd-a068-82b7b40d5386@github.com>
 <vI72u_d8c32LSOQtLdExu1F4HztWBH8D4KNmS9CTeOc=.26e279da-1078-439b-b304-810e55de34de@github.com>
 <1fKII2MPGP3ZKTpzzM0nsLHmS4GllRmv0sljWXqMiYo=.e2b32e25-d76b-44a4-bf89-c3297ccbe7da@github.com>
Message-ID: <efe19546-2862-a828-cde7-98828128f42a@oracle.com>

On 26/02/2021 3:52 am, Daniel D.Daugherty wrote:
> On Wed, 24 Feb 2021 00:42:11 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>>> Holding the Threads_lock is no longer being considered as
>>> proper protection for the JavaThread::get_thread_name() call
>>> so I had to change the code to use a JavaThreadIteratorWithHandle
>>> so that we have the protection of the TLH. That closure eventually
>>> gets us down to a JavaThread::get_thread_name() call...
>>
>> But the code is now broken as it needs the Threads_lock to guard against non-JavaThreads being created or terminating.
>> The code also appears misleading because the passing of the JTIWH makes it look (to me) like it only deals with JavaThreads.
>> I think this code needs to be:
>>      JavaThreadIteratorWithHandle jtiwh;  // ensure JavaThreads are safe to access
>>      MutexLocker ml(Threads_lock);        // ensure non_JavaThreads are safe to access
>>      Threads::threads_do(&jtiwh, &vmtcc); // process all threads
> 
> I'm backing out the changes to src/hotspot/share/services/management.cpp.
> By removing the Threads_lock usage, I'm allowing those closures to run in parallel
> with other closures that are using the original Threads::java_threads_do() and
> Threads::threads_do() calls that do use the Threads_lock. Those other uses might
> be assuming exclusivity for their algorithms and my M&M changes break that.

True. So I'm unclear how you will reconcile this code with the use of 
get_thread_name() now.

Thanks,
David

>>> ... that will tell us that we have a spot in the code where a TLH is
>>> missing once we've analyzed the crash. So are you okay with this
>>> assert() having a bug since the original assert has the same bug?
>>
>> Yes
> 
> It has occurred to me that I should have moved all of the
> protection checking logic and assertion checks into the
> new Thread::is_JavaThread_protected() function. That will
> allow JavaThread::get_thread_name() to become very simple.
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/2535
> 

From dcubed at openjdk.java.net  Thu Feb 25 22:44:07 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 25 Feb 2021 22:44:07 GMT
Subject: RFR: 8241403: JavaThread::get_thread_name() should be
 ThreadSMR-aware [v6]
In-Reply-To: <wRdcRQurtpybntK9Qpji-6zVY-EcHKw3q87xpD0eoS4=.a6dc32f4-2919-42e9-80c3-5a264067f0e2@github.com>
References: <wRdcRQurtpybntK9Qpji-6zVY-EcHKw3q87xpD0eoS4=.a6dc32f4-2919-42e9-80c3-5a264067f0e2@github.com>
Message-ID: <mA_x8P12wem176qSrSye1hObpYhcy9ceTHOGMkgjpa8=.edeeb563-1380-4a16-8851-2235190ab4db@github.com>

> A minor fix to add a new function:
> 
>     bool Thread::is_JavaThread_protected(const JavaThread* p)
> 
> that returns true when the target JavaThread* is protected and false
> otherwise. Update JavaThread::get_thread_name() to create a
> ThreadsListHandle and use the new is_JavaThread_protected(). Also
> update JvmtiTrace::safe_get_thread_name() to use the new
> is_JavaThread_protected().
> 
> This fix is tested via a Mach5 Tier[1-8] run.

Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:

  Address dholmes-ora CR3 comments.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2535/files
  - new: https://git.openjdk.java.net/jdk/pull/2535/files/19fe9538..71aec8c2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2535&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2535&range=04-05

  Stats: 85 lines in 4 files changed: 31 ins; 33 del; 21 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2535.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2535/head:pull/2535

PR: https://git.openjdk.java.net/jdk/pull/2535

From dcubed at openjdk.java.net  Thu Feb 25 22:44:10 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 25 Feb 2021 22:44:10 GMT
Subject: RFR: 8241403: JavaThread::get_thread_name() should be
 ThreadSMR-aware [v5]
In-Reply-To: <qgjoVq1KVMIM3E7o1r8fEmMaYEJ9dwaOWwCQrz33LPg=.dab3a15e-36ee-4c34-b396-5e5ba5814162@github.com>
References: <wRdcRQurtpybntK9Qpji-6zVY-EcHKw3q87xpD0eoS4=.a6dc32f4-2919-42e9-80c3-5a264067f0e2@github.com>
 <zkmwEDyUrIwqBqt2kGhlLZCRHBTB1krLO43PMmLSUC8=.fd503b8f-c79d-4f03-89bc-16f65e62f475@github.com>
 <qgjoVq1KVMIM3E7o1r8fEmMaYEJ9dwaOWwCQrz33LPg=.dab3a15e-36ee-4c34-b396-5e5ba5814162@github.com>
Message-ID: <rYp030xRoytRDRso5p5vPB0B1GRaZXrQqCt2XcTPNN8=.ea6d6589-cd37-45f3-8df9-9e33012db098@github.com>

On Thu, 25 Feb 2021 17:49:43 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Daniel D. Daugherty 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 six additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8241403
>>  - Address dholmes-ora CR2 comments.
>>  - Address dholmes-ora CR1 comments.
>>  - Merge branch 'master' into JDK-8241403
>>  - Address coleenp CR0 comments.
>>  - 8241403: JavaThread::get_thread_name() should be ThreadSMR-aware
>
> @dholmes-ora - Thanks for reviewing CR3. I've made more changes
> and once my testing looks good, I'll checkpoint and push to update the PR.

You'll see that in the next update. Pushing it now...

-------------

PR: https://git.openjdk.java.net/jdk/pull/2535

From dholmes at openjdk.java.net  Thu Feb 25 23:01:45 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 25 Feb 2021 23:01:45 GMT
Subject: RFR: 8241403: JavaThread::get_thread_name() should be
 ThreadSMR-aware [v6]
In-Reply-To: <mA_x8P12wem176qSrSye1hObpYhcy9ceTHOGMkgjpa8=.edeeb563-1380-4a16-8851-2235190ab4db@github.com>
References: <wRdcRQurtpybntK9Qpji-6zVY-EcHKw3q87xpD0eoS4=.a6dc32f4-2919-42e9-80c3-5a264067f0e2@github.com>
 <mA_x8P12wem176qSrSye1hObpYhcy9ceTHOGMkgjpa8=.edeeb563-1380-4a16-8851-2235190ab4db@github.com>
Message-ID: <14WQ7qOlYgqTYwVyjhZOAogTZ-lw6yUvVyBxLVsEheE=.06c5c3cb-0346-4892-9f29-44f58d498587@github.com>

On Thu, 25 Feb 2021 22:44:07 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> A minor fix to add a new function:
>> 
>>     bool Thread::is_JavaThread_protected(const JavaThread* p)
>> 
>> that returns true when the target JavaThread* is protected and false
>> otherwise. Update JavaThread::get_thread_name() to create a
>> ThreadsListHandle and use the new is_JavaThread_protected(). Also
>> update JvmtiTrace::safe_get_thread_name() to use the new
>> is_JavaThread_protected().
>> 
>> This fix is tested via a Mach5 Tier[1-8] run.
>
> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address dholmes-ora CR3 comments.

Hi Dan,

I'm good with holding the Threads_lock remaining as a safe condition for use of get_thread_name().

Minor comments on code placement that should have been made earlier - sorry.

Thanks,
David

src/hotspot/share/runtime/thread.cpp line 520:

> 518:   guarantee(false, "current_thread=" INTPTR_FORMAT " is not protecting p="
> 519:             INTPTR_FORMAT, p2i(current_thread), p2i(p));
> 520: 

This will be deleted before pushing - right?

src/hotspot/share/compiler/compileBroker.cpp line 1028:

> 1026:       assert(ct != NULL, "should have been handled for initial thread");
> 1027:       ThreadsListHandle tlh;  // get_thread_name() depends on the TLH.
> 1028:       assert(tlh.includes(ct), "ct=" INTPTR_FORMAT " exited unexpectedly.", p2i(ct));

This can be placed inside the if-clause where the MutexLocker was.

src/hotspot/share/compiler/compileBroker.cpp line 1115:

> 1113:       if (ct == NULL) break;
> 1114:       ThreadsListHandle tlh;  // get_thread_name() depends on the TLH.
> 1115:       assert(tlh.includes(ct), "ct=" INTPTR_FORMAT " exited unexpectedly.", p2i(ct));

This can be placed inside the if-clause where the MutexLocker was.

src/hotspot/share/compiler/compileBroker.cpp line 1136:

> 1134:       if (ct == NULL) break;
> 1135:       ThreadsListHandle tlh;  // get_thread_name() depends on the TLH.
> 1136:       assert(tlh.includes(ct), "ct=" INTPTR_FORMAT " exited unexpectedly.", p2i(ct));

This can be placed inside the if-clause where the MutexLocker was.

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2535

From dcubed at openjdk.java.net  Thu Feb 25 23:01:46 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 25 Feb 2021 23:01:46 GMT
Subject: RFR: 8241403: JavaThread::get_thread_name() should be
 ThreadSMR-aware [v6]
In-Reply-To: <14WQ7qOlYgqTYwVyjhZOAogTZ-lw6yUvVyBxLVsEheE=.06c5c3cb-0346-4892-9f29-44f58d498587@github.com>
References: <wRdcRQurtpybntK9Qpji-6zVY-EcHKw3q87xpD0eoS4=.a6dc32f4-2919-42e9-80c3-5a264067f0e2@github.com>
 <mA_x8P12wem176qSrSye1hObpYhcy9ceTHOGMkgjpa8=.edeeb563-1380-4a16-8851-2235190ab4db@github.com>
 <14WQ7qOlYgqTYwVyjhZOAogTZ-lw6yUvVyBxLVsEheE=.06c5c3cb-0346-4892-9f29-44f58d498587@github.com>
Message-ID: <JFV2czuoTyj6cDYfzTUNocHQUianYXnCS9R3tv1gT9k=.464a5733-4123-4f46-b507-327191e03097@github.com>

On Thu, 25 Feb 2021 22:47:21 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address dholmes-ora CR3 comments.
>
> src/hotspot/share/runtime/thread.cpp line 520:
> 
>> 518:   guarantee(false, "current_thread=" INTPTR_FORMAT " is not protecting p="
>> 519:             INTPTR_FORMAT, p2i(current_thread), p2i(p));
>> 520: 
> 
> This will be deleted before pushing - right?

Yup. It's just for the current Tier[1-8] test cycle.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2535

From dcubed at openjdk.java.net  Thu Feb 25 23:04:49 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 25 Feb 2021 23:04:49 GMT
Subject: RFR: 8241403: JavaThread::get_thread_name() should be
 ThreadSMR-aware [v6]
In-Reply-To: <mA_x8P12wem176qSrSye1hObpYhcy9ceTHOGMkgjpa8=.edeeb563-1380-4a16-8851-2235190ab4db@github.com>
References: <wRdcRQurtpybntK9Qpji-6zVY-EcHKw3q87xpD0eoS4=.a6dc32f4-2919-42e9-80c3-5a264067f0e2@github.com>
 <mA_x8P12wem176qSrSye1hObpYhcy9ceTHOGMkgjpa8=.edeeb563-1380-4a16-8851-2235190ab4db@github.com>
Message-ID: <AkaJD0Ff1-Lx6awsItrEN7IWx3bV9E1fmGUDqE2C9ds=.6c711335-a6a2-4171-bfc6-a4e96f967a20@github.com>

On Thu, 25 Feb 2021 22:44:07 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> A minor fix to add a new function:
>> 
>>     bool Thread::is_JavaThread_protected(const JavaThread* p)
>> 
>> that returns true when the target JavaThread* is protected and false
>> otherwise. Update JavaThread::get_thread_name() to create a
>> ThreadsListHandle and use the new is_JavaThread_protected(). Also
>> update JvmtiTrace::safe_get_thread_name() to use the new
>> is_JavaThread_protected().
>> 
>> This fix is tested via a Mach5 Tier[1-8] run.
>
> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address dholmes-ora CR3 comments.

@dholmes-ora - Thanks for reviewing CR4.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2535

From dcubed at openjdk.java.net  Thu Feb 25 23:04:51 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 25 Feb 2021 23:04:51 GMT
Subject: RFR: 8241403: JavaThread::get_thread_name() should be
 ThreadSMR-aware [v6]
In-Reply-To: <14WQ7qOlYgqTYwVyjhZOAogTZ-lw6yUvVyBxLVsEheE=.06c5c3cb-0346-4892-9f29-44f58d498587@github.com>
References: <wRdcRQurtpybntK9Qpji-6zVY-EcHKw3q87xpD0eoS4=.a6dc32f4-2919-42e9-80c3-5a264067f0e2@github.com>
 <mA_x8P12wem176qSrSye1hObpYhcy9ceTHOGMkgjpa8=.edeeb563-1380-4a16-8851-2235190ab4db@github.com>
 <14WQ7qOlYgqTYwVyjhZOAogTZ-lw6yUvVyBxLVsEheE=.06c5c3cb-0346-4892-9f29-44f58d498587@github.com>
Message-ID: <JsSVSXoD_qpKVBA7zMU0z9GZIdew9s18qqOPo2Aj3ns=.ccebd1ca-5988-45a6-a039-160a8d46eb67@github.com>

On Thu, 25 Feb 2021 22:49:32 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address dholmes-ora CR3 comments.
>
> src/hotspot/share/compiler/compileBroker.cpp line 1028:
> 
>> 1026:       assert(ct != NULL, "should have been handled for initial thread");
>> 1027:       ThreadsListHandle tlh;  // get_thread_name() depends on the TLH.
>> 1028:       assert(tlh.includes(ct), "ct=" INTPTR_FORMAT " exited unexpectedly.", p2i(ct));
> 
> This can be placed inside the if-clause where the MutexLocker was.

True. That would be better.

> src/hotspot/share/compiler/compileBroker.cpp line 1115:
> 
>> 1113:       if (ct == NULL) break;
>> 1114:       ThreadsListHandle tlh;  // get_thread_name() depends on the TLH.
>> 1115:       assert(tlh.includes(ct), "ct=" INTPTR_FORMAT " exited unexpectedly.", p2i(ct));
> 
> This can be placed inside the if-clause where the MutexLocker was.

True. That would be better.

> src/hotspot/share/compiler/compileBroker.cpp line 1136:
> 
>> 1134:       if (ct == NULL) break;
>> 1135:       ThreadsListHandle tlh;  // get_thread_name() depends on the TLH.
>> 1136:       assert(tlh.includes(ct), "ct=" INTPTR_FORMAT " exited unexpectedly.", p2i(ct));
> 
> This can be placed inside the if-clause where the MutexLocker was.

True. That would be better.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2535

From dcubed at openjdk.java.net  Thu Feb 25 23:14:01 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 25 Feb 2021 23:14:01 GMT
Subject: RFR: 8241403: JavaThread::get_thread_name() should be
 ThreadSMR-aware [v7]
In-Reply-To: <wRdcRQurtpybntK9Qpji-6zVY-EcHKw3q87xpD0eoS4=.a6dc32f4-2919-42e9-80c3-5a264067f0e2@github.com>
References: <wRdcRQurtpybntK9Qpji-6zVY-EcHKw3q87xpD0eoS4=.a6dc32f4-2919-42e9-80c3-5a264067f0e2@github.com>
Message-ID: <3f3Vp9iZJP_MmQTVIXkww59NJ8llWH52slhahExVfuQ=.6f306fe7-4f37-4226-ad7b-487017aa34d2@github.com>

> A minor fix to add a new function:
> 
>     bool Thread::is_JavaThread_protected(const JavaThread* p)
> 
> that returns true when the target JavaThread* is protected and false
> otherwise. Update JavaThread::get_thread_name() to create a
> ThreadsListHandle and use the new is_JavaThread_protected(). Also
> update JvmtiTrace::safe_get_thread_name() to use the new
> is_JavaThread_protected().
> 
> This fix is tested via a Mach5 Tier[1-8] run.

Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:

  Address dholmes-ora CR4 comments.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2535/files
  - new: https://git.openjdk.java.net/jdk/pull/2535/files/71aec8c2..4298bb4d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2535&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2535&range=05-06

  Stats: 16 lines in 1 file changed: 8 ins; 8 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2535.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2535/head:pull/2535

PR: https://git.openjdk.java.net/jdk/pull/2535

From dholmes at openjdk.java.net  Thu Feb 25 23:40:49 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 25 Feb 2021 23:40:49 GMT
Subject: RFR: 8241403: JavaThread::get_thread_name() should be
 ThreadSMR-aware [v7]
In-Reply-To: <3f3Vp9iZJP_MmQTVIXkww59NJ8llWH52slhahExVfuQ=.6f306fe7-4f37-4226-ad7b-487017aa34d2@github.com>
References: <wRdcRQurtpybntK9Qpji-6zVY-EcHKw3q87xpD0eoS4=.a6dc32f4-2919-42e9-80c3-5a264067f0e2@github.com>
 <3f3Vp9iZJP_MmQTVIXkww59NJ8llWH52slhahExVfuQ=.6f306fe7-4f37-4226-ad7b-487017aa34d2@github.com>
Message-ID: <61nydPskp0lUO05Zd1oJ3CgpeObFQJs3iX9G4-BVLdg=.3fd58f01-6707-4179-9744-075644d14c4b@github.com>

On Thu, 25 Feb 2021 23:14:01 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> A minor fix to add a new function:
>> 
>>     bool Thread::is_JavaThread_protected(const JavaThread* p)
>> 
>> that returns true when the target JavaThread* is protected and false
>> otherwise. Update JavaThread::get_thread_name() to create a
>> ThreadsListHandle and use the new is_JavaThread_protected(). Also
>> update JvmtiTrace::safe_get_thread_name() to use the new
>> is_JavaThread_protected().
>> 
>> This fix is tested via a Mach5 Tier[1-8] run.
>
> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address dholmes-ora CR4 comments.

Looks good!

Thanks,
David

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2535

From dcubed at openjdk.java.net  Fri Feb 26 03:55:44 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 26 Feb 2021 03:55:44 GMT
Subject: RFR: 8241403: JavaThread::get_thread_name() should be
 ThreadSMR-aware [v7]
In-Reply-To: <61nydPskp0lUO05Zd1oJ3CgpeObFQJs3iX9G4-BVLdg=.3fd58f01-6707-4179-9744-075644d14c4b@github.com>
References: <wRdcRQurtpybntK9Qpji-6zVY-EcHKw3q87xpD0eoS4=.a6dc32f4-2919-42e9-80c3-5a264067f0e2@github.com>
 <3f3Vp9iZJP_MmQTVIXkww59NJ8llWH52slhahExVfuQ=.6f306fe7-4f37-4226-ad7b-487017aa34d2@github.com>
 <61nydPskp0lUO05Zd1oJ3CgpeObFQJs3iX9G4-BVLdg=.3fd58f01-6707-4179-9744-075644d14c4b@github.com>
Message-ID: <4PN4nc7O1odZse3WXElo_p1HLUvj7R7HyxiGJidgqeI=.2150b993-03c5-454e-849d-d48568d76fd9@github.com>

On Thu, 25 Feb 2021 23:37:31 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address dholmes-ora CR4 comments.
>
> Looks good!
> 
> Thanks,
> David

@dholmes-ora - Thanks for yet another re-review.
@coleenp, @robehn and/or @sspitsyn - If any of you have the time, I could
use one more re-review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2535

From kalinshi at tencent.com  Fri Feb 26 03:15:39 2021
From: kalinshi at tencent.com (=?gb2312?B?a2FsaW5zaGkoyqm72yk=?=)
Date: Fri, 26 Feb 2021 03:15:39 +0000
Subject: =?gb2312?B?u9i4tDogSnZtdGlFeHBvcnQ6OmNhbl93YWxrX2FueV9zcGFjZSgpIHVzYWdl?=
 =?gb2312?Q?_in_hotspot(Internet_mail)?=
In-Reply-To: <15ea918b-2d8a-b021-f5d0-ed1af1f4c84c@oracle.com>
References: <365ef5a026a84e81917462643ea4bc97@tencent.com>
 <15ea918b-2d8a-b021-f5d0-ed1af1f4c84c@oracle.com>
Message-ID: <f6209f62ac1a499d90033e34786bb318@tencent.com>

Thanks Dan!

   ping!

Regards
Hui

-----????-----
???: daniel.daugherty at oracle.com <daniel.daugherty at oracle.com> 
????: 2021?2?23? 2:17
???: kalinshi(??) <kalinshi at tencent.com>; hotspot-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net; serviceability-dev at openjdk.java.net
??: Re: JvmtiExport::can_walk_any_space() usage in hotspot(Internet mail)

Adding serviceability-dev at ... to this email thread since JVM/TI is maintained by the Serviceability Team...

Dan


On 2/22/21 3:29 AM, kalinshi(??) wrote:
> Hi hotspot experts,
>
> Would you help on my question about JvmtiExport::can_walk_any_space() check?
> Question is why JvmtiExport::can_walk_any_space() check is needed in CDS when mapping region?
>
> JvmtiExport::can_walk_any_space() method is only used in FileMapInfo::map_region for modifing region read-only mapping attribute.
> JvmtiExport::can_walk_any_space() is set true when jvmtiCapabilities.can_tag_objects is enabled.
> JVMTI capability can_tag_objects enables java heap iteration/object reference tracing, and JvmtiEnv::Set/GetTag doesn't modify read-only regions in shared archive (I might wrong).
>
> comments in latest code seems outdated, JvmtiExport::can_walk_any_space() doesn't disable sharing now.
> "
>    JvmtiExport::set_can_walk_any_space(
>      avail.can_tag_objects);   // disable sharing in onload phase
> "
>
> Back to initial code, class sharing is disabled when condition JvmtiExport::can_modify_any_class() || JvmtiExport::can_walk_any_space() is true.
> This matches above comment in JvmtiManageCapabilities::update.
> "
>    if (JvmtiExport::can_modify_any_class() || JvmtiExport::can_walk_any_space()) {
>      fail_continue("Tool agent requires sharing to be disabled.");
>      return false;
>    }
> "
>
> JvmtiExport::can_modify_any_class condition disables class data sharing when class file load hook (requires modify code and read only contents) is needed in initial code.
> Both checks are removed and used to determine region read/write attribute with following commits. These commits are mainly supporting class file load hook with CDS.
>
> 1. enable shared class when these tow checks on, modify/map all regions in shared archive as RW.
>     8054386: Allow Java debugging when CDS is enabled Map archive RW when debugging is enabled
>     8087153: EXCEPTION_ACCESS_VIOLATION when CDS RO section vanished 
> on win32
>     
> 2. Support class file load hook with CDS
>     8141341: CDS should be disabled if JvmtiExport::should_post_class_file_load_hook() is true Disable loading shared class if JvmtiExport::should_post_class_file_load_hook is true.
>     8078644: CDS needs to support JVMTI CFLH Support posting CLFH for shared classes.
>     
> 3. Fix jvmtiCapabilities::can_generate_all_class_hook_events inconsistent state when shared
>     8161605: The '!UseSharedSpaces' check is not need in 
> JvmtiManageCapabilities::recompute_always_capabilities
>     
> 4. Fix class file load hook error for early class hook event when shared
>     8212200: assert when shared java.lang.Object is redefined by JVMTI 
> agent
>
> Regards
> Hui



From rehn at openjdk.java.net  Fri Feb 26 07:36:42 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Fri, 26 Feb 2021 07:36:42 GMT
Subject: RFR: 8241403: JavaThread::get_thread_name() should be
 ThreadSMR-aware [v7]
In-Reply-To: <3f3Vp9iZJP_MmQTVIXkww59NJ8llWH52slhahExVfuQ=.6f306fe7-4f37-4226-ad7b-487017aa34d2@github.com>
References: <wRdcRQurtpybntK9Qpji-6zVY-EcHKw3q87xpD0eoS4=.a6dc32f4-2919-42e9-80c3-5a264067f0e2@github.com>
 <3f3Vp9iZJP_MmQTVIXkww59NJ8llWH52slhahExVfuQ=.6f306fe7-4f37-4226-ad7b-487017aa34d2@github.com>
Message-ID: <RJ81ghvzreb_ZbP2a2_GXUtY-LIEURuYqIcMNLek1RM=.f4263a4e-f485-4d83-8a6e-d35127bfb415@github.com>

On Thu, 25 Feb 2021 23:14:01 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> A minor fix to add a new function:
>> 
>>     bool Thread::is_JavaThread_protected(const JavaThread* p)
>> 
>> that returns true when the target JavaThread* is protected and false
>> otherwise. Update JavaThread::get_thread_name() to create a
>> ThreadsListHandle and use the new is_JavaThread_protected(). Also
>> update JvmtiTrace::safe_get_thread_name() to use the new
>> is_JavaThread_protected().
>> 
>> This fix is tested via a Mach5 Tier[1-8] run.
>
> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address dholmes-ora CR4 comments.

Marked as reviewed by rehn (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2535

From akozlov at openjdk.java.net  Fri Feb 26 12:26:18 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Fri, 26 Feb 2021 12:26:18 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v19]
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: <NvSWZNsK4eBydZGxBRE13ScnlGV5R5P4hWd9jZck1pI=.67cf8f47-7605-49c0-b879-67d93c5a084f@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 89 commits:

 - Merge branch 'master' into jdk-macos
 - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos
 - Re-do safefetch.hpp
 - Merge remote-tracking branch 'origin/jdk/8261075-stubroutines-inline' into jdk-macos
 - stubRoutines.inline.hpp -> safefetch.hpp
 - Update copyrights
 - Merge remote-tracking branch 'upstream/jdk/master' into 8261075-stubroutines-inline
 - Merge remote-tracking branch 'upstream/jdk/master' into 8261075-stubroutines-inline
 - Extract SafeFetch32/N to stubRoutines.inline.hpp
 - Revert "Extract SafeFetch32/N to stubRoutines.inline.hpp"
   
   This reverts commit b873c25f31dd21349d140b790713cc9ccb5f2dc0.
 - ... and 79 more: https://git.openjdk.java.net/jdk/compare/d7efb4cc...74687c0b

-------------

Changes: https://git.openjdk.java.net/jdk/pull/2200/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=18
  Stats: 2953 lines in 74 files changed: 2862 ins; 27 del; 64 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  Fri Feb 26 12:53:11 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Fri, 26 Feb 2021 12:53:11 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v20]
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: <4ipGJ8KKE0_KPuWfExCo1jo3Tg9iewQkSKuZTcntoNE=.8c1c3dcb-4db2-4e0a-b42f-6db5f78c6406@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 two additional commits since the last revision:

 - Merge pull request #10 from VladimirKempik/pull/2200
   
   Fix build after merge with master
 - Fix build after merge with master

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2200/files
  - new: https://git.openjdk.java.net/jdk/pull/2200/files/74687c0b..241aedee

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=19
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=18-19

  Stats: 7 lines in 1 file changed: 0 ins; 1 del; 6 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 Feb 26 12:55:50 2021
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Fri, 26 Feb 2021 12:55:50 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: <tIBOh-GXmxiYMN2Qvj9YTw1JU5s3qWdsL2qKHe7A9-0=.327b93c6-9eba-4974-a6b8-d855075b773b@github.com>

On Tue, 2 Feb 2021 23:07:08 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/java.base/macosx/native/libjli/java_md_macosx.m line 210:
> 
>> 208:     if (preferredJVM == NULL) {
>> 209: #if defined(__i386__)
>> 210:         preferredJVM = "client";
> 
> #if defined(__i386__)
>         preferredJVM = "client";
> Not your bug, but Oracle/OpenJDK never supported 32-bit __i386__ on macOS.

Hello
I thought the openjdk7 supported 32-bit macos at some point in time

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From sspitsyn at openjdk.java.net  Fri Feb 26 13:45:43 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Fri, 26 Feb 2021 13:45:43 GMT
Subject: RFR: 8241403: JavaThread::get_thread_name() should be
 ThreadSMR-aware [v7]
In-Reply-To: <3f3Vp9iZJP_MmQTVIXkww59NJ8llWH52slhahExVfuQ=.6f306fe7-4f37-4226-ad7b-487017aa34d2@github.com>
References: <wRdcRQurtpybntK9Qpji-6zVY-EcHKw3q87xpD0eoS4=.a6dc32f4-2919-42e9-80c3-5a264067f0e2@github.com>
 <3f3Vp9iZJP_MmQTVIXkww59NJ8llWH52slhahExVfuQ=.6f306fe7-4f37-4226-ad7b-487017aa34d2@github.com>
Message-ID: <nW3YBL5modr-7e3pjfcr1HwJp65o7aYPLwYlLmky7PI=.fe374e26-de23-41fa-a8f9-a9ff66694895@github.com>

On Thu, 25 Feb 2021 23:14:01 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> A minor fix to add a new function:
>> 
>>     bool Thread::is_JavaThread_protected(const JavaThread* p)
>> 
>> that returns true when the target JavaThread* is protected and false
>> otherwise. Update JavaThread::get_thread_name() to create a
>> ThreadsListHandle and use the new is_JavaThread_protected(). Also
>> update JvmtiTrace::safe_get_thread_name() to use the new
>> is_JavaThread_protected().
>> 
>> This fix is tested via a Mach5 Tier[1-8] run.
>
> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address dholmes-ora CR4 comments.

Hi Dan,
The update looks okay, but I have one question.
So, the fix in jvmtiTrace.cpp is not needed anymore?
Thanks,
Serguei

-------------

PR: https://git.openjdk.java.net/jdk/pull/2535

From dcubed at openjdk.java.net  Fri Feb 26 14:10:45 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 26 Feb 2021 14:10:45 GMT
Subject: RFR: 8241403: JavaThread::get_thread_name() should be
 ThreadSMR-aware [v7]
In-Reply-To: <RJ81ghvzreb_ZbP2a2_GXUtY-LIEURuYqIcMNLek1RM=.f4263a4e-f485-4d83-8a6e-d35127bfb415@github.com>
References: <wRdcRQurtpybntK9Qpji-6zVY-EcHKw3q87xpD0eoS4=.a6dc32f4-2919-42e9-80c3-5a264067f0e2@github.com>
 <3f3Vp9iZJP_MmQTVIXkww59NJ8llWH52slhahExVfuQ=.6f306fe7-4f37-4226-ad7b-487017aa34d2@github.com>
 <RJ81ghvzreb_ZbP2a2_GXUtY-LIEURuYqIcMNLek1RM=.f4263a4e-f485-4d83-8a6e-d35127bfb415@github.com>
Message-ID: <5QFLniVjmpA-LhUZc5Bz1cF2Eji-SV4hwrapHmUuEsw=.54a188c5-c73b-4270-96a7-8ee2dd425364@github.com>

On Fri, 26 Feb 2021 07:34:06 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address dholmes-ora CR4 comments.
>
> Marked as reviewed by rehn (Reviewer).

@robehn - Thanks for the re-review!
@sspitsyn - Thanks for the re-review!
We backed out the jvmtiTrace.cpp changes because the semantics were
changed subtlety by switching to JavaThread::get_thread_name_string().
@dholmes-ora pointed out the change in behavior in one of his reviews.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2535

From daniel.daugherty at oracle.com  Fri Feb 26 14:37:11 2021
From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com)
Date: Fri, 26 Feb 2021 09:37:11 -0500
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
In-Reply-To: <tIBOh-GXmxiYMN2Qvj9YTw1JU5s3qWdsL2qKHe7A9-0=.327b93c6-9eba-4974-a6b8-d855075b773b@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>
 <tIBOh-GXmxiYMN2Qvj9YTw1JU5s3qWdsL2qKHe7A9-0=.327b93c6-9eba-4974-a6b8-d855075b773b@github.com>
Message-ID: <77712482-850c-3945-2c4e-7865544a412b@oracle.com>

On 2/26/21 7:55 AM, Vladimir Kempik wrote:
> On Tue, 2 Feb 2021 23:07:08 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/java.base/macosx/native/libjli/java_md_macosx.m line 210:
>>
>>> 208:     if (preferredJVM == NULL) {
>>> 209: #if defined(__i386__)
>>> 210:         preferredJVM = "client";
>> #if defined(__i386__)
>>          preferredJVM = "client";
>> Not your bug, but Oracle/OpenJDK never supported 32-bit __i386__ on macOS.
> Hello
> I thought the openjdk7 supported 32-bit macos at some point in time

The macOS porting project supported 32-bit macOS, but when the code
was integrated into OpenJDK7 I don't believe that 32-bit macOS was
supported. I could be wrong... it was quite a while ago...

Dan


>
> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/2200


From erik.joelsson at oracle.com  Fri Feb 26 15:06:39 2021
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Fri, 26 Feb 2021 07:06:39 -0800
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
In-Reply-To: <77712482-850c-3945-2c4e-7865544a412b@oracle.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>
 <tIBOh-GXmxiYMN2Qvj9YTw1JU5s3qWdsL2qKHe7A9-0=.327b93c6-9eba-4974-a6b8-d855075b773b@github.com>
 <77712482-850c-3945-2c4e-7865544a412b@oracle.com>
Message-ID: <a9f85f16-e20f-8a09-1106-5d8656267c0d@oracle.com>


On 2021-02-26 06:37, daniel.daugherty at oracle.com wrote:
> On 2/26/21 7:55 AM, Vladimir Kempik wrote:
>> On Tue, 2 Feb 2021 23:07:08 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/java.base/macosx/native/libjli/java_md_macosx.m line 210:
>>>
>>>> 208:???? if (preferredJVM == NULL) {
>>>> 209: #if defined(__i386__)
>>>> 210:???????? preferredJVM = "client";
>>> #if defined(__i386__)
>>> ???????? preferredJVM = "client";
>>> Not your bug, but Oracle/OpenJDK never supported 32-bit __i386__ on 
>>> macOS.
>> Hello
>> I thought the openjdk7 supported 32-bit macos at some point in time
>
> The macOS porting project supported 32-bit macOS, but when the code
> was integrated into OpenJDK7 I don't believe that 32-bit macOS was
> supported. I could be wrong... it was quite a while ago...
>
AFAIK, OpenJDK never supported 32bit macos, but there are certainly 
leftovers here and there indicating that the original source did at some 
point. In the build system we cleaned that up a long time ago.

/Erik


From dcubed at openjdk.java.net  Fri Feb 26 15:44:00 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 26 Feb 2021 15:44:00 GMT
Subject: Integrated: 8241403: JavaThread::get_thread_name() should be
 ThreadSMR-aware
In-Reply-To: <wRdcRQurtpybntK9Qpji-6zVY-EcHKw3q87xpD0eoS4=.a6dc32f4-2919-42e9-80c3-5a264067f0e2@github.com>
References: <wRdcRQurtpybntK9Qpji-6zVY-EcHKw3q87xpD0eoS4=.a6dc32f4-2919-42e9-80c3-5a264067f0e2@github.com>
Message-ID: <oVFOf-PIDyUQbujv4upvUePoPhyFOGXd0GqYHLcgw-0=.33c4337c-07cc-4f22-95a0-1a84db84117f@github.com>

On Thu, 11 Feb 2021 22:04:53 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A minor fix to add a new function:
> 
>     bool Thread::is_JavaThread_protected(const JavaThread* p)
> 
> that returns true when the target JavaThread* is protected and false
> otherwise. Update JavaThread::get_thread_name() to create a
> ThreadsListHandle and use the new is_JavaThread_protected(). Also
> update JvmtiTrace::safe_get_thread_name() to use the new
> is_JavaThread_protected().
> 
> This fix is tested via a Mach5 Tier[1-8] run.

This pull request has now been integrated.

Changeset: 47a08426
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/47a08426
Stats:     70 lines in 4 files changed: 53 ins; 7 del; 10 mod

8241403: JavaThread::get_thread_name() should be ThreadSMR-aware

Reviewed-by: rehn, coleenp, dholmes

-------------

PR: https://git.openjdk.java.net/jdk/pull/2535

From dcubed at openjdk.java.net  Fri Feb 26 15:43:59 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 26 Feb 2021 15:43:59 GMT
Subject: RFR: 8241403: JavaThread::get_thread_name() should be
 ThreadSMR-aware [v8]
In-Reply-To: <wRdcRQurtpybntK9Qpji-6zVY-EcHKw3q87xpD0eoS4=.a6dc32f4-2919-42e9-80c3-5a264067f0e2@github.com>
References: <wRdcRQurtpybntK9Qpji-6zVY-EcHKw3q87xpD0eoS4=.a6dc32f4-2919-42e9-80c3-5a264067f0e2@github.com>
Message-ID: <-wPbQ6HSwVprz5LePFP4-mfXtR5IFikM4_oH992H7l8=.0b636c92-c8a9-42ed-8d94-abec11da1467@github.com>

> A minor fix to add a new function:
> 
>     bool Thread::is_JavaThread_protected(const JavaThread* p)
> 
> that returns true when the target JavaThread* is protected and false
> otherwise. Update JavaThread::get_thread_name() to create a
> ThreadsListHandle and use the new is_JavaThread_protected(). Also
> update JvmtiTrace::safe_get_thread_name() to use the new
> is_JavaThread_protected().
> 
> This fix is tested via a Mach5 Tier[1-8] run.

Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:

  Delete temporary guarantee included for testing.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2535/files
  - new: https://git.openjdk.java.net/jdk/pull/2535/files/4298bb4d..089727c7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2535&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2535&range=06-07

  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2535.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2535/head:pull/2535

PR: https://git.openjdk.java.net/jdk/pull/2535

From lmesnik at openjdk.java.net  Fri Feb 26 16:38:02 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Fri, 26 Feb 2021 16:38:02 GMT
Subject: Integrated: 8262332: serviceability/sa/ClhsdbJhisto.java fails with
 Test ERROR java.lang.RuntimeException: 'ParselTongue' missing from
 stdout/stderr
In-Reply-To: <wG6Y_igoyKfkwgjXS3zGSbtkjun8q8OZKN-nqgOKkzk=.fe93b3ce-95e1-4a85-92b9-309cb427f319@github.com>
References: <wG6Y_igoyKfkwgjXS3zGSbtkjun8q8OZKN-nqgOKkzk=.fe93b3ce-95e1-4a85-92b9-309cb427f319@github.com>
Message-ID: <0ADiJ4ewlLhUf3q1yZF-RIdyv7n3Bv3CV-FOPiXirV0=.b8d71f44-81cf-4195-99a8-871284592dcb@github.com>

On Wed, 24 Feb 2021 22:10:49 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> ?va.lang.RuntimeException: 'ParselTongue' missing from stdout/stderr

This pull request has now been integrated.

Changeset: 2515c42b
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2515c42b
Stats:     4 lines in 1 file changed: 3 ins; 0 del; 1 mod

8262332: serviceability/sa/ClhsdbJhisto.java fails with Test ERROR java.lang.RuntimeException: 'ParselTongue' missing from stdout/stderr

Reviewed-by: cjplummer

-------------

PR: https://git.openjdk.java.net/jdk/pull/2717

From akozlov at openjdk.java.net  Fri Feb 26 19:17:12 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Fri, 26 Feb 2021 19:17:12 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v21]
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: <ZfRwLBDhh3K6u3NaWzLWVyoYqBuZVJbipXCZKzPclBs=.bedc9c24-2178-400a-8868-fbbb61b298cc@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 two additional commits since the last revision:

 - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos
 - Minor fixes

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2200/files
  - new: https://git.openjdk.java.net/jdk/pull/2200/files/241aedee..663cb4a1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=20
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=19-20

  Stats: 85 lines in 5 files changed: 0 ins; 80 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 ccheung at openjdk.java.net  Fri Feb 26 22:07:40 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Fri, 26 Feb 2021 22:07:40 GMT
Subject: RFR: 8259070: Add jcmd option to dump CDS
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: <vYtu_WYJ_s19-jmj6lxvwsS4025cmF6tX-xkS-kQRqc=.afc0066d-84e2-405d-850f-39b349f96921@github.com>

On Fri, 26 Feb 2021 00:03:40 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

Looks like a good usability enhancement to CDS.
Some comments below...

Thanks,
Calvin

Below are my comments...

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()`?

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?

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?

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?

src/hotspot/share/memory/metaspaceShared.cpp line 856:

> 854:   char classlist_name[JVM_MAXPATHLEN];
> 855: 
> 856:   os::snprintf(classlist_name, sizeof(classlist_name), "%s.classlist", file);

I think the `file` contains the ".jsa" suffix. So the `classlist_name` would be <name>.jsa.classlist.
Maybe only the prefix of `file` should be passed into cmd_dump_static() and cmd_dump_dynamic() and have the functions append the suffix for the names for the classlist and archive?

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.

-------------

Changes requested by ccheung (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2737

From iklam at openjdk.java.net  Fri Feb 26 23:06:42 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Fri, 26 Feb 2021 23:06:42 GMT
Subject: RFR: 8259070: Add jcmd option to dump CDS
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: <wwBek7Yf05ftyApvSnOfw3CL3Yb8T38kdpCcv0gOXfM=.c19076b2-25ea-48cf-bc8b-4700b5549fc1@github.com>

On Fri, 26 Feb 2021 00:03:40 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

Changes requested by iklam (Reviewer).

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.

src/hotspot/share/memory/metaspaceShared.cpp line 811:

> 809:     if (!RecordDynamicDumpInfo) {
> 810:       output->print_cr("Please run with -Xshare:auto -XX:+RecordDynamicDumpInfo dumping dynamic archive!");
> 811:       return;

There are several error conditions:

(1) CDS is not configured for this VM build. In this case, `INCLUDE_CDS` is false. The DumpSharedArchiveDCmd should be placed inside `#if INCLUDE_CDS`, so the user won't be able to issue `jcmd VM.cds` at all, and we will never come to here.

(2) CDS is configured, but the JVM process is not running with CDS enabled. This could have several causes:

- The JVM does not have a built-in archive.
- User has specified `-XX:SharedArchiveFile=foo.jsa`, but foo.jsa doesn't exist
- The shared archive exists, but has failed to map
- `-Xshare:off` is specified in the command-line.

I think all of the above can be checked inside metaspce.cpp. Note that if you have specified `DynamicDumpSharedSpaces` but the base archive fails to map, you will get a similar error.

if (RecordDynamicDumpInfo && !UseSharedSpaces) {
  vm_exit_during_initialization("RecordDynamicDumpInfo is unsupported when base CDS archive is not loaded
");
}

(3) `jcmd VM.cds dynamic_dump` is used on a JVM process without RecordDynamicDumpInfo:

We can do the check here, but I think we can change the error message to be more specific:

if (!RecordDynamicDumpInfo) {
  output->print_cr("Unable to dump dynamic shared archive. "
                   "Please restart the JVM with -XX:+RecordDynamicDumpInfo");
}

Note that the user can get to (3) with incorrect command-line options such as `java -Xshare:off .....`, but we don't need to list all those conditions here. Instead, if the user follows the suggestion of (3) and add `-XX:+RecordDynamicDumpInfo` to the command-line, they will then get the error message of (2) and will know how to proceed further.

src/hotspot/share/memory/metaspaceShared.cpp line 795:

> 793:     if (file_name ==nullptr) {
> 794:       os::snprintf(filename, sizeof(filename), "java_pid%d_static.jsa", os::current_process_id());
> 795:       file = filename;

I think the above `os::snprintf` can be combined for both dynamic and static case:

int n = os::snprintf(filename, sizeof(filename), "java_pid%d_%s.jsa", os::current_process_id()
                     (is_static ? "static" : "dynamic");
assert(n < sizeof(filename), "should not truncate");

`snprintf` man page says "a return value of size or more  means  that  the  output was truncated."

src/hotspot/share/memory/metaspaceShared.cpp line 799:

> 797:       if (strstr(file_name, ".jsa") == nullptr) {
> 798:         os::snprintf(filename, sizeof(filename), "%s.jsa", file_name);
> 799:         file = filename;

This could potentially overflow the buffer. I think it's best to just leave `file_name` alone. If the user doesn't want the `.jsa` extension, that's fine. Similarly, we don't add `.jsa` to `-XX:ArchiveClassesAtExit` or `-XX:SharedArchiveFile`.

src/hotspot/share/memory/metaspaceShared.cpp line 856:

> 854:   char classlist_name[JVM_MAXPATHLEN];
> 855: 
> 856:   os::snprintf(classlist_name, sizeof(classlist_name), "%s.classlist", file);

Need to check for truncation. We should also add a test case for a very long file names specified in "jcmd VM.cds ...."

src/hotspot/share/memory/metaspaceShared.cpp line 868:

> 866:     return;
> 867:   }
> 868:   os::snprintf(exec_path, sizeof(exec_path),

Need to check for buffer overflow. I think it's better to use a stringStream so you don't need to worry about buffer allocation and overflow.

Also, if any of the arguments you append to the command line contain space characters, `os::fork_and_exec` is not going to work. I think it's best to check for space characters (and maybe other special characters such as single quote, double quote, $, etc) and return an error (something like `"special character "%c" in the command-line is not supported"`)

src/hotspot/share/memory/metaspaceShared.cpp line 881:

> 879:   }
> 880:   char* buff_start = exec_path + strlen(exec_path);
> 881:   snprintf(buff_start, sizeof(exec_path), " -cp %s %s", app_class_path, java_command);

Do we need to pass `java_command`?

src/hotspot/share/memory/metaspaceShared.cpp line 889:

> 887:   if (DynamicArchive::has_been_dumped_once()) {
> 888:     output->print_cr("Dynamic dump has been done, and should only be done once.");
> 889:     return;

How about "Dynamic dump cannot be done more than once"?

src/hotspot/share/memory/metaspaceShared.cpp line 898:

> 896:   ArchiveClassesAtExit = file;
> 897:   if (Arguments::init_shared_archive_paths()) {
> 898:     DynamicArchive::dump();

Instead of modifying the global `ArchiveClassesAtExit`, I think it's better to change `DynamicArchive::dump()` to take an argument of the file to write.

`SharedDynamicArchivePath` should be changed to be used only when mapping the dynamic archive (not for writing).

src/hotspot/share/oops/instanceKlass.cpp line 4249:

> 4247:     if (is_hidden() || unsafe_anonymous_host() != NULL) {
> 4248:       return false;
> 4249:     }

Maybe `InstanceKlass::log_to_classlist` should be refactored to use this function? Also, I think a better name would be `bool InstanceKlass::can_be_logged_to_classlist()`.

src/hotspot/share/runtime/arguments.cpp line 3138:

> 3136:     FLAG_SET_DEFAULT(DynamicDumpSharedSpaces, false);
> 3137:   } else {
> 3138:     FLAG_SET_DEFAULT(DynamicDumpSharedSpaces, true);

I think this will be more readable:

if (ArchiveClassesAtExit != NULL || RecordDynamicDumpInfo) {
    FLAG_SET_DEFAULT(DynamicDumpSharedSpaces, true);
} else {
    FLAG_SET_DEFAULT(DynamicDumpSharedSpaces, false);

BTW, what happens if you specify `-XX:-DynamicDumpSharedSpaces -XX:+RecordDynamicDumpInfo`?

src/hotspot/share/runtime/arguments.cpp line 3525:

> 3523:       os::free(SharedDynamicArchivePath);
> 3524:       SharedDynamicArchivePath = nullptr;
> 3525:     }

Is this necessary?

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"?

src/hotspot/share/services/diagnosticCommand.cpp line 1084:

> 1082: 
> 1083: DumpSharedArchiveDCmd::DumpSharedArchiveDCmd(outputStream* output, bool heap) :
> 1084:                                      DCmdWithParser(output, heap),

Should be inside `#if INCLUE_CDS`

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`.

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.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2737

From stuefe at openjdk.java.net  Sat Feb 27 05:50:40 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Sat, 27 Feb 2021 05:50:40 GMT
Subject: RFR: 8259070: Add jcmd option to dump CDS
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: <VPPi7bt4PVTZP_0mb-UYL5Mi8t6ZHjJ_v3c85QRtVI0=.91b36925-333c-416f-82fd-15a47ecda9bf@github.com>

On Fri, 26 Feb 2021 00:03:40 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

Hi Yumin,

This is a very useful addition.

My biggest concern with this patch though is the use of `os::fork_and_exec()` in regular, non-fatal situations. I had a look at that function and I think that is very unsafe.

- it does not close file descriptors, so the child vm will inherit all file descriptors not opened with FD_CLOEXEC. In Runtime.exec, we do this whole dance around safely closing off all unused file descriptors, which is missing here. Note that even though we mostly open all fds with CLOEXEC, this does not matter, since user code may not do that.
- It uses vfork "if available", which is probably always, but that may be okay since the child exec's right away. Still, vfork makes me nervous.
- Weirdly enough, it always spawns the child program via one indirection using a shell; so there is always the shell between you and your spawned VM, and you probably wont get the return code of your child vm process back.
 
Until now, os::fork_and_exec() was only used in fatal situations where the VM was about to die anyway. And where it did not really matter if it worked or not. 

If we now want to use it in regular situations, we need to give that thing an overhaul and make it a first class fork api, and also test it better that it is today. The file descriptor issue has to be addressed at the very least.

I really would consider rewriting the whole thing using posix_spawn. Since JDK15 I think posix_spawn is the default for Runtime.exec, so we know it works well. I would also do this in a separate RFE.

Alternatively, you could call into java and use Runtime.exec().

Further remarks inline.

Thanks, Thomas

src/hotspot/share/memory/metaspaceShared.cpp line 883:

> 881:   snprintf(buff_start, sizeof(exec_path), " -cp %s %s", app_class_path, java_command);
> 882:   output->print_cr("%s", exec_path);
> 883:   os::fork_and_exec(exec_path);

Apart from what I wrote above, how do you handle fork/exec errors? There are a number of things that can go wrong here. At the very least I would scan the return code. And the return code of the child VM.

-------------

Changes requested by stuefe (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2737

From stuefe at openjdk.java.net  Sat Feb 27 05:50:41 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Sat, 27 Feb 2021 05:50:41 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: <8BIT_U1LoH-XHUajzOHKBe7xSETc4go9iVbaAlPcTlg=.6d34cc08-ed03-400e-9176-2d809bf1e6a5@github.com>

On Fri, 26 Feb 2021 22:01:09 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
>
> 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()

-------------

PR: https://git.openjdk.java.net/jdk/pull/2737

From stuefe at openjdk.java.net  Sat Feb 27 05:50:41 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Sat, 27 Feb 2021 05:50:41 GMT
Subject: RFR: 8259070: Add jcmd option to dump CDS
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: <2ARkZBqUR_xMiSXQYcq-rmOVxB62xIiIjzsJo0ZB9Xo=.1e29924e-5aaf-4356-ac6a-5b4b46c177ee@github.com>

On Fri, 26 Feb 2021 22:15:12 GMT, Ioi Lam <iklam 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
>
> src/hotspot/share/memory/metaspaceShared.cpp line 799:
> 
>> 797:       if (strstr(file_name, ".jsa") == nullptr) {
>> 798:         os::snprintf(filename, sizeof(filename), "%s.jsa", file_name);
>> 799:         file = filename;
> 
> This could potentially overflow the buffer. I think it's best to just leave `file_name` alone. If the user doesn't want the `.jsa` extension, that's fine. Similarly, we don't add `.jsa` to `-XX:ArchiveClassesAtExit` or `-XX:SharedArchiveFile`.

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.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2737

From lzang at openjdk.java.net  Sat Feb 27 16:14:56 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Sat, 27 Feb 2021 16:14:56 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v11]
In-Reply-To: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
Message-ID: <PnCjpTgD9ZrTMDw4baPzIOZ8m9tq2z2XXWlXMKyBf4E=.2ce80a92-dd22-41c8-ae1e-ed22432501cb@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 13 commits:

 - Merge master
 - fix build fail issue on windows
 - hide the dumpheapext error message
 - Merge branch 'master' into pd
 - use parallel= option instead of noparallel
 - Add dumpheapext command for extra argument passing
 - Fix logic in thread number calculation and code refine
 - Merge branch 'master' into par-dump
 - fix buffer queue issue
 - code refine
 - ... and 3 more: https://git.openjdk.java.net/jdk/compare/03d888f4...f0b60d75

-------------

Changes: https://git.openjdk.java.net/jdk/pull/2261/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2261&range=10
  Stats: 841 lines in 6 files changed: 654 ins; 57 del; 130 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  Sat Feb 27 16:28:00 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Sat, 27 Feb 2021 16:28:00 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v12]
In-Reply-To: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
Message-ID: <igMw90mds-eYKLD94O1TnzJvsc5pCDNmbj7lzjL1E2A=.d07e0c5f-5272-4352-8637-41f50c2dc9e0@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:

  Revise jmap help info

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2261/files
  - new: https://git.openjdk.java.net/jdk/pull/2261/files/f0b60d75..6789ba29

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2261&range=11
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2261&range=10-11

  Stats: 17 lines in 1 file changed: 0 ins; 0 del; 17 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 iklam at openjdk.java.net  Sat Feb 27 18:14:40 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Sat, 27 Feb 2021 18:14:40 GMT
Subject: RFR: 8259070: Add jcmd option to dump CDS
In-Reply-To: <2ARkZBqUR_xMiSXQYcq-rmOVxB62xIiIjzsJo0ZB9Xo=.1e29924e-5aaf-4356-ac6a-5b4b46c177ee@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>
Message-ID: <KwV5lKZ8BOdhaeyc-W9XOxJCdwahl3L_T8_DpJstiW8=.e5173cc7-a897-4b98-842c-07ce4984bb34@github.com>

On Sat, 27 Feb 2021 05:19:01 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> src/hotspot/share/memory/metaspaceShared.cpp line 799:
>> 
>>> 797:       if (strstr(file_name, ".jsa") == nullptr) {
>>> 798:         os::snprintf(filename, sizeof(filename), "%s.jsa", file_name);
>>> 799:         file = filename;
>> 
>> This could potentially overflow the buffer. I think it's best to just leave `file_name` alone. If the user doesn't want the `.jsa` extension, that's fine. Similarly, we don't add `.jsa` to `-XX:ArchiveClassesAtExit` or `-XX:SharedArchiveFile`.
>
> 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.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2737

From iklam at openjdk.java.net  Sat Feb 27 18:23:39 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Sat, 27 Feb 2021 18:23:39 GMT
Subject: RFR: 8259070: Add jcmd option to dump CDS
In-Reply-To: <VPPi7bt4PVTZP_0mb-UYL5Mi8t6ZHjJ_v3c85QRtVI0=.91b36925-333c-416f-82fd-15a47ecda9bf@github.com>
References: <hwrc1zAz8G180ToL-C3EuUIF-5R17F5Gm1zcPMBpOtE=.e002a377-e0e2-485b-a08e-b63675a9746b@github.com>
 <VPPi7bt4PVTZP_0mb-UYL5Mi8t6ZHjJ_v3c85QRtVI0=.91b36925-333c-416f-82fd-15a47ecda9bf@github.com>
Message-ID: <gCQGdWg2uZyh0kpceXlwE4UDSGkI1dVYtwHL6Nw6lXs=.2aa338ec-3dd1-47b4-9d61-e46ae22b8a6d@github.com>

On Sat, 27 Feb 2021 05:48:04 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> I really would consider rewriting the whole thing using posix_spawn. Since JDK15 I think posix_spawn is the default for Runtime.exec, so we know it works well. I would also do this in a separate RFE.
> 
> Alternatively, you could call into java and use Runtime.exec().

I think we should call into Java and use `Runtime.exec()`. Running a subprocess is very complicated, so we shouldn't try to duplicate the code in the VM.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2737

From thomas.stuefe at gmail.com  Sun Feb 28 05:36:41 2021
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Sun, 28 Feb 2021 06:36:41 +0100
Subject: RFR: 8259070: Add jcmd option to dump CDS
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: <CAA-vtUyEWqnZARH308kKmbpzBTkh=Ygkaxotn6rE06-71LW0QQ@mail.gmail.com>

Oh right, then it could get truncated, but should not overflow.

On Sat, Feb 27, 2021 at 7:15 PM Ioi Lam <iklam at openjdk.java.net> wrote:

> On Sat, 27 Feb 2021 05:19:01 GMT, Thomas Stuefe <stuefe at openjdk.org>
> wrote:
>
> >> src/hotspot/share/memory/metaspaceShared.cpp line 799:
> >>
> >>> 797:       if (strstr(file_name, ".jsa") == nullptr) {
> >>> 798:         os::snprintf(filename, sizeof(filename), "%s.jsa",
> file_name);
> >>> 799:         file = filename;
> >>
> >> This could potentially overflow the buffer. I think it's best to just
> leave `file_name` alone. If the user doesn't want the `.jsa` extension,
> that's fine. Similarly, we don't add `.jsa` to `-XX:ArchiveClassesAtExit`
> or `-XX:SharedArchiveFile`.
> >
> > 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.
>
> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/2737
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20210228/eeefceec/attachment-0001.htm>