From rehn at openjdk.org  Mon Oct  3 06:43:10 2022
From: rehn at openjdk.org (Robbin Ehn)
Date: Mon, 3 Oct 2022 06:43:10 GMT
Subject: RFR: 8282900: runtime/stringtable/StringTableCleaningTest.java verify
 unavailable at this moment
Message-ID: <rB06qYn4ntJNAAokUKRsDjEei1uzh7IsM2HBzndbmLM=.fac54cf9-2fee-49bb-9666-3c22c158a184@github.com>

Hi, please consider:

verify() is called by GC in safepoint so it should use the corresponding scanning method.
verify_and_compare_entries() can wait for until there is no resize.

This makes these methods always succeed, passes t1-t6.

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

Commit messages:
 - Use non-failable CHT scan methods.

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

PR: https://git.openjdk.org/jdk/pull/10527

From dholmes at openjdk.org  Mon Oct  3 07:58:23 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 3 Oct 2022 07:58:23 GMT
Subject: RFR: 8294406: Test runtime/handshake/HandshakeDirectTest.java
 failed: JVMTI_ERROR_WRONG_PHASE
In-Reply-To: <jfhigC5fMxowY9aOlzqiIjmWkdlEksRsUNAGMnG2NUc=.ebb41b5e-97c7-441c-952a-72b787cab3ef@github.com>
References: <jfhigC5fMxowY9aOlzqiIjmWkdlEksRsUNAGMnG2NUc=.ebb41b5e-97c7-441c-952a-72b787cab3ef@github.com>
Message-ID: <g6m86cdFmfzEoBqpYTSmtx5etbJf8gZ96VNXfmWkbNk=.2d19b278-a249-4858-bfed-bed58b50a08c@github.com>

On Fri, 30 Sep 2022 01:32:44 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> 8294406: Test runtime/handshake/HandshakeDirectTest.java failed: JVMTI_ERROR_WRONG_PHASE

So what is the "wrong phase" that we are in? I don't like just accepting any wrong phase because only termination phases are expected to be encountered not startup phases.

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

PR: https://git.openjdk.org/jdk/pull/10502

From coleenp at openjdk.org  Mon Oct  3 12:03:27 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 3 Oct 2022 12:03:27 GMT
Subject: RFR: 8282900: runtime/stringtable/StringTableCleaningTest.java
 verify unavailable at this moment
In-Reply-To: <rB06qYn4ntJNAAokUKRsDjEei1uzh7IsM2HBzndbmLM=.fac54cf9-2fee-49bb-9666-3c22c158a184@github.com>
References: <rB06qYn4ntJNAAokUKRsDjEei1uzh7IsM2HBzndbmLM=.fac54cf9-2fee-49bb-9666-3c22c158a184@github.com>
Message-ID: <h93GcyY5h9GyeEmQJazPXunLrRC6fsF0BIAONKT2GFg=.1036e53b-aad6-41d3-abcd-d1badd535868@github.com>

On Mon, 3 Oct 2022 06:30:40 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> Hi, please consider:
> 
> verify() is called by GC in safepoint so it should use the corresponding scanning method.
> verify_and_compare_entries() can wait for until there is no resize.
> 
> This makes these methods always succeed, passes t1-t6.

Looks good! Thanks for fixing this.

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

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10527

From coleenp at openjdk.org  Mon Oct  3 15:06:29 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 3 Oct 2022 15:06:29 GMT
Subject: RFR: 8282900: runtime/stringtable/StringTableCleaningTest.java
 verify unavailable at this moment
In-Reply-To: <rB06qYn4ntJNAAokUKRsDjEei1uzh7IsM2HBzndbmLM=.fac54cf9-2fee-49bb-9666-3c22c158a184@github.com>
References: <rB06qYn4ntJNAAokUKRsDjEei1uzh7IsM2HBzndbmLM=.fac54cf9-2fee-49bb-9666-3c22c158a184@github.com>
Message-ID: <4nayGkBN_wEaRNPfREYgB_jrqFulPyn8rTdOSQVR80k=.56eac769-bd01-4bf9-8adf-bf59ed12c6cc@github.com>

On Mon, 3 Oct 2022 06:30:40 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> Hi, please consider:
> 
> verify() is called by GC in safepoint so it should use the corresponding scanning method.
> verify_and_compare_entries() can wait for until there is no resize.
> 
> This makes these methods always succeed, passes t1-t6.

Is there an equivalent problem in SymbolTable?

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

PR: https://git.openjdk.org/jdk/pull/10527

From rehn at openjdk.org  Mon Oct  3 17:46:04 2022
From: rehn at openjdk.org (Robbin Ehn)
Date: Mon, 3 Oct 2022 17:46:04 GMT
Subject: RFR: 8282900: runtime/stringtable/StringTableCleaningTest.java
 verify unavailable at this moment
In-Reply-To: <rB06qYn4ntJNAAokUKRsDjEei1uzh7IsM2HBzndbmLM=.fac54cf9-2fee-49bb-9666-3c22c158a184@github.com>
References: <rB06qYn4ntJNAAokUKRsDjEei1uzh7IsM2HBzndbmLM=.fac54cf9-2fee-49bb-9666-3c22c158a184@github.com>
Message-ID: <kczY7aM5P2UZWux42G6f9WtoTsBtA-H3bjqLEbb0E8E=.46dc5426-1e76-4069-aba3-562028191884@github.com>

On Mon, 3 Oct 2022 06:30:40 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> Hi, please consider:
> 
> verify() is called by GC in safepoint so it should use the corresponding scanning method.
> verify_and_compare_entries() can wait for until there is no resize.
> 
> This makes these methods always succeed, passes t1-t6.

I'll check.

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

PR: https://git.openjdk.org/jdk/pull/10527

From sspitsyn at openjdk.org  Mon Oct  3 20:40:18 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 3 Oct 2022 20:40:18 GMT
Subject: RFR: 8294406: Test runtime/handshake/HandshakeDirectTest.java
 failed: JVMTI_ERROR_WRONG_PHASE
In-Reply-To: <jfhigC5fMxowY9aOlzqiIjmWkdlEksRsUNAGMnG2NUc=.ebb41b5e-97c7-441c-952a-72b787cab3ef@github.com>
References: <jfhigC5fMxowY9aOlzqiIjmWkdlEksRsUNAGMnG2NUc=.ebb41b5e-97c7-441c-952a-72b787cab3ef@github.com>
Message-ID: <AgrUiSHGOUtFj1W8LanEALNaI7UG6Xk02H2wxla0Xck=.4b2d70ab-84fb-438c-be6e-1b85e731ab89@github.com>

On Fri, 30 Sep 2022 01:32:44 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> 8294406: Test runtime/handshake/HandshakeDirectTest.java failed: JVMTI_ERROR_WRONG_PHASE

In this particular case the wrong phase that we are in can be only JVMTI_PHASE_DEAD. It can't be any phase before JVMTI_PHASE_LIVE because it happens when we execute a java code. The WRONG_PHASE error code has to be always expected by any tests that use JVM TI.

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

PR: https://git.openjdk.org/jdk/pull/10502

From dholmes at openjdk.org  Mon Oct  3 23:24:07 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 3 Oct 2022 23:24:07 GMT
Subject: RFR: 8294406: Test runtime/handshake/HandshakeDirectTest.java
 failed: JVMTI_ERROR_WRONG_PHASE
In-Reply-To: <jfhigC5fMxowY9aOlzqiIjmWkdlEksRsUNAGMnG2NUc=.ebb41b5e-97c7-441c-952a-72b787cab3ef@github.com>
References: <jfhigC5fMxowY9aOlzqiIjmWkdlEksRsUNAGMnG2NUc=.ebb41b5e-97c7-441c-952a-72b787cab3ef@github.com>
Message-ID: <y_WQjzp6rPYA9EkR0JrEmsEq-YLqvtFJC2BDlGEB7Bk=.3c26ea7b-71b5-49db-ba24-3b5a2e71c96b@github.com>

On Fri, 30 Sep 2022 01:32:44 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> 8294406: Test runtime/handshake/HandshakeDirectTest.java failed: JVMTI_ERROR_WRONG_PHASE

Marked as reviewed by dholmes (Reviewer).

Okay so because this is a daemon thread it can be hit up to when the final termination safepoint is initiated, and this is after the VM is marked as "dead". Thanks.

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

PR: https://git.openjdk.org/jdk/pull/10502

From dholmes at openjdk.org  Tue Oct  4 04:22:20 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 4 Oct 2022 04:22:20 GMT
Subject: RFR: 8282900: runtime/stringtable/StringTableCleaningTest.java
 verify unavailable at this moment
In-Reply-To: <rB06qYn4ntJNAAokUKRsDjEei1uzh7IsM2HBzndbmLM=.fac54cf9-2fee-49bb-9666-3c22c158a184@github.com>
References: <rB06qYn4ntJNAAokUKRsDjEei1uzh7IsM2HBzndbmLM=.fac54cf9-2fee-49bb-9666-3c22c158a184@github.com>
Message-ID: <q4ZHyOQS5thuGOiWx9NLLIQb0WC9OdgxFK9IBV_SQJk=.2f89e1ec-371b-4729-92a2-dd7c81c68170@github.com>

On Mon, 3 Oct 2022 06:30:40 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> Hi, please consider:
> 
> verify() is called by GC in safepoint so it should use the corresponding scanning method.
> verify_and_compare_entries() can wait for until there is no resize.
> 
> This makes these methods always succeed, passes t1-t6.

Using `do_scan` in verify seems appropriate as it is at a safepoint as you note. But the code says that the `resize_lock` may be dropped to allow a safepoint, but I can't see where exactly this dropping occurs? If we were to drop in the middle of a resize then it need not follow that the CHT can be scanned safely at a safepoint. ??

Why is it okay to have `verify_and_compare_entries` wait? What thread, doing what action, will it be waiting for? The fact it is only used during VM shutdown somewhat mitigates concerns as we only have to establish that one case is correct.

Thanks.

src/hotspot/share/classfile/stringTable.cpp line 606:

> 604: // This verification is part of Universe::verify() and needs to be quick.
> 605: void StringTable::verify() {
> 606:   Thread* thr = Thread::current();

You don't need `thr` now

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

PR: https://git.openjdk.org/jdk/pull/10527

From fjiang at openjdk.org  Tue Oct  4 07:17:23 2022
From: fjiang at openjdk.org (Feilong Jiang)
Date: Tue, 4 Oct 2022 07:17:23 GMT
Subject: RFR: 8294679: RISC-V: Misc crash dump improvements
In-Reply-To: <Z3nOQB1iSj9LJLM8jvbUP80OeJyxZOKZ87Dzm6hkpHU=.b8df2e3d-fea3-4cd2-a37d-f8618b03a975@github.com>
References: <Z3nOQB1iSj9LJLM8jvbUP80OeJyxZOKZ87Dzm6hkpHU=.b8df2e3d-fea3-4cd2-a37d-f8618b03a975@github.com>
Message-ID: <JKuHnCUYu-vBS0DBDx-aMiKiywWyxjM-fO6CN6_pSZ0=.073de068-79f8-48bd-bd1d-80bd7dbc0717@github.com>

On Fri, 30 Sep 2022 14:41:05 GMT, Fei Yang <fyang at openjdk.org> wrote:

> Issue https://bugs.openjdk.org/browse/JDK-8294160 only handles x86 & aarch64.
> This adds handling for this case on RISC-V: When calling a bad address, we usually don't get a meaningful stack backtrace, but in many situations we can if we know where to find the caller information.
> 
> Testing: Tier1 tested on HiFive Unmatched board.

LGTM

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

Marked as reviewed by fjiang (Author).

PR: https://git.openjdk.org/jdk/pull/10512

From rehn at openjdk.org  Tue Oct  4 08:40:52 2022
From: rehn at openjdk.org (Robbin Ehn)
Date: Tue, 4 Oct 2022 08:40:52 GMT
Subject: RFR: 8282900: runtime/stringtable/StringTableCleaningTest.java
 verify unavailable at this moment
In-Reply-To: <q4ZHyOQS5thuGOiWx9NLLIQb0WC9OdgxFK9IBV_SQJk=.2f89e1ec-371b-4729-92a2-dd7c81c68170@github.com>
References: <rB06qYn4ntJNAAokUKRsDjEei1uzh7IsM2HBzndbmLM=.fac54cf9-2fee-49bb-9666-3c22c158a184@github.com>
 <q4ZHyOQS5thuGOiWx9NLLIQb0WC9OdgxFK9IBV_SQJk=.2f89e1ec-371b-4729-92a2-dd7c81c68170@github.com>
Message-ID: <BBl0JCg0IBeag9QlaUUk-UZaTFnmtw_CIac8iqg1u6c=.ed251e30-7c45-4f60-98b4-8883da86485e@github.com>

On Tue, 4 Oct 2022 04:18:47 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Using `do_scan` in verify seems appropriate as it is at a safepoint as you note. But the code says that the `resize_lock` may be dropped to allow a safepoint, but I can't see where exactly this dropping occurs? If we were to drop in the middle of a resize then it need not follow that the CHT can be scanned safely at a safepoint. ??
> 
> Why is it okay to have `verify_and_compare_entries` wait? What thread, doing what action, will it be waiting for? The fact it is only used during VM shutdown somewhat mitigates concerns as we only have to establish that one case is correct.
> 

When we are resizing some data (nodes) can be reached from both old table and new table.
(a concurrent scan could visits data (nodes) multiple time.
During a safepoint data/nodes are exclusively accessible from old or new table.
Safepoint scanning thus scans first old table and then new table. 

The ServiceThread does the resizing, and only doing 4096 buckets at the time before safepoint checking.
The exact code would in "StringTable::grow(...)" when calling "gt.pause(jt)".

The ServiceThread is stopped by the final VM_Exit which happens after "before_exit".

> Thanks.

#

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

PR: https://git.openjdk.org/jdk/pull/10527

From rehn at openjdk.org  Tue Oct  4 08:46:18 2022
From: rehn at openjdk.org (Robbin Ehn)
Date: Tue, 4 Oct 2022 08:46:18 GMT
Subject: RFR: 8282900: runtime/stringtable/StringTableCleaningTest.java
 verify unavailable at this moment
In-Reply-To: <q4ZHyOQS5thuGOiWx9NLLIQb0WC9OdgxFK9IBV_SQJk=.2f89e1ec-371b-4729-92a2-dd7c81c68170@github.com>
References: <rB06qYn4ntJNAAokUKRsDjEei1uzh7IsM2HBzndbmLM=.fac54cf9-2fee-49bb-9666-3c22c158a184@github.com>
 <q4ZHyOQS5thuGOiWx9NLLIQb0WC9OdgxFK9IBV_SQJk=.2f89e1ec-371b-4729-92a2-dd7c81c68170@github.com>
Message-ID: <PVYEVU0l_bA7R35tbfmXw0cv1Fy2cRwZtwdjK0AaWKU=.9dd0fccd-b691-47b3-b03b-94a5099f0f6e@github.com>

On Tue, 4 Oct 2022 04:02:02 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Hi, please consider:
>> 
>> verify() is called by GC in safepoint so it should use the corresponding scanning method.
>> verify_and_compare_entries() can wait for until there is no resize.
>> 
>> This makes these methods always succeed, passes t1-t6.
>
> src/hotspot/share/classfile/stringTable.cpp line 606:
> 
>> 604: // This verification is part of Universe::verify() and needs to be quick.
>> 605: void StringTable::verify() {
>> 606:   Thread* thr = Thread::current();
> 
> You don't need `thr` now

Thanks, fixing!

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

PR: https://git.openjdk.org/jdk/pull/10527

From shade at openjdk.org  Tue Oct  4 09:15:52 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 4 Oct 2022 09:15:52 GMT
Subject: Integrated: 8292847: Zero: Allow ergonomics to select the GC
In-Reply-To: <SmLTWWEaOd1QcQSNYh61idfBRpfdrRbI3vDqJk1jqbE=.07bf5f56-28b1-4c5a-b0d9-675b14fb0d5f@github.com>
References: <SmLTWWEaOd1QcQSNYh61idfBRpfdrRbI3vDqJk1jqbE=.07bf5f56-28b1-4c5a-b0d9-675b14fb0d5f@github.com>
Message-ID: <5CrHMm7lvLxS2QAO-5UAFo17rohg92jWkxI_NQ9OAj8=.b454cc80-0398-46d9-bbbd-aa6f51389557@github.com>

On Wed, 24 Aug 2022 06:01:05 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Zero is currently defaulting to Serial GC on all machines, due to the fact that `NeverActAsServerClassMachine` is `true`. It is set in `compiler_globals.pd` under `#if !defined(COMPILER1) && !defined(COMPILER2) && !INCLUDE_JVMCI`. `NeverActAsServerClassMachine` mostly affects compiler ergonomics, which Zero does not need, but it also affects the selection of default GC.
> 
> After [JDK-8256497](https://bugs.openjdk.org/browse/JDK-8256497), we can let Zero default to G1. After [JDK-8292329](https://bugs.openjdk.org/browse/JDK-8292329), it would help Zero to use the CDS shared heap.
> 
> Additional testing:
>  - [x] Linux x86_64 Zero fastdebug, `make bootcycle-images`
>  - [x]  Linux x86_64 Zero fastdebug, `tier1` tests (many known failures)

This pull request has now been integrated.

Changeset: 3b476a17
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3b476a1758cb35a688d70f9518531510666541d6
Stats:     6 lines in 1 file changed: 6 ins; 0 del; 0 mod

8292847: Zero: Allow ergonomics to select the GC

Reviewed-by: tschatzl, stuefe

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

PR: https://git.openjdk.org/jdk/pull/9994

From shade at openjdk.org  Tue Oct  4 09:48:33 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 4 Oct 2022 09:48:33 GMT
Subject: RFR: 8294751: Zero: Allow larger default heaps
Message-ID: <onIurPQPJzorzHjZNvhxPk12j0zySZeRR1rid9KW0Yg=.e42155f8-d8af-4496-b72b-350e1dbf8e09@github.com>

Zero is currently defaulting to `MaxRAM=1G` on all machines. It is set in `compiler_globals.pd` under `#if !defined(COMPILER1) && !defined(COMPILER2) && !INCLUDE_JVMCI`.

Zero supports lots of GCs, and there is little sense to penalize it unnecessarily with too small heaps. After [JDK-8292847](https://bugs.openjdk.org/browse/JDK-8292847), this would allow G1 with reasonable heap size on most machines.

Motivational improvements, `SPECjvm2008:serial`:


# Baseline, G1
Serial.test  thrpt   10  1619.863 ? 16.694  ops/s

# Baseline, Serial
Serial.test  thrpt   10  1094.438 ? 20.425  ops/s

# Patched, G1
Serial.test  thrpt   10  1623.090 ? 17.553  ops/s

# Patched, Serial
Serial.test  thrpt   10  1624.531 ? 15.792  ops/s  ; <---- matches G1 now, because young is not tiny


Before:


$ build/linux-x86_64-zero-release/jdk/bin/java -Xlog:gc -Xlog:gc+init Alloc.java
[0.003s][info][gc     ] Using G1
...
[0.005s][info][gc,init] Memory: 125G
...
[0.005s][info][gc,init] Heap Region Size: 1M
[0.005s][info][gc,init] Heap Min Capacity: 8M
[0.005s][info][gc,init] Heap Initial Capacity: 16M
[0.005s][info][gc,init] Heap Max Capacity: 256M


After:


$ build/linux-x86_64-zero-release/jdk/bin/java -Xlog:gc -Xlog:gc+init Alloc.java
[0.003s][info][gc     ] Using G1
...
[0.007s][info][gc,init] Memory: 125G
...
[0.007s][info][gc,init] Heap Region Size: 16M
[0.007s][info][gc,init] Heap Min Capacity: 16M
[0.007s][info][gc,init] Heap Initial Capacity: 2016M
[0.007s][info][gc,init] Heap Max Capacity: 30208M

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

Commit messages:
 - Fix

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

PR: https://git.openjdk.org/jdk/pull/10552

From shade at openjdk.org  Tue Oct  4 10:03:21 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 4 Oct 2022 10:03:21 GMT
Subject: RFR: 8294679: RISC-V: Misc crash dump improvements
In-Reply-To: <Z3nOQB1iSj9LJLM8jvbUP80OeJyxZOKZ87Dzm6hkpHU=.b8df2e3d-fea3-4cd2-a37d-f8618b03a975@github.com>
References: <Z3nOQB1iSj9LJLM8jvbUP80OeJyxZOKZ87Dzm6hkpHU=.b8df2e3d-fea3-4cd2-a37d-f8618b03a975@github.com>
Message-ID: <NO8JW2l44LGc7Q36k9mfm7jAoLCdk7bX2emAs-v_nug=.29d375b8-3f16-40ab-82b9-82218e4f89a7@github.com>

On Fri, 30 Sep 2022 14:41:05 GMT, Fei Yang <fyang at openjdk.org> wrote:

> Issue https://bugs.openjdk.org/browse/JDK-8294160 only handles x86 & aarch64.
> This adds handling for this case on RISC-V: When calling a bad address, we usually don't get a meaningful stack backtrace, but in many situations we can if we know where to find the caller information.
> 
> Testing: Tier1 tested on HiFive Unmatched board.

Marked as reviewed by shade (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10512

From rehn at openjdk.org  Tue Oct  4 11:10:18 2022
From: rehn at openjdk.org (Robbin Ehn)
Date: Tue, 4 Oct 2022 11:10:18 GMT
Subject: RFR: 8282900: runtime/stringtable/StringTableCleaningTest.java
 verify unavailable at this moment
In-Reply-To: <4nayGkBN_wEaRNPfREYgB_jrqFulPyn8rTdOSQVR80k=.56eac769-bd01-4bf9-8adf-bf59ed12c6cc@github.com>
References: <rB06qYn4ntJNAAokUKRsDjEei1uzh7IsM2HBzndbmLM=.fac54cf9-2fee-49bb-9666-3c22c158a184@github.com>
 <4nayGkBN_wEaRNPfREYgB_jrqFulPyn8rTdOSQVR80k=.56eac769-bd01-4bf9-8adf-bf59ed12c6cc@github.com>
Message-ID: <frRzpx0vtFP0jAeNN5MlUgUiUDVZroENZTny1OS0fSo=.38458d14-bb43-4374-ab29-0c49b45b8bdb@github.com>

On Mon, 3 Oct 2022 15:02:04 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Is there an equivalent problem in SymbolTable?

Kind of yes, but it looks the verify() is used both inside and out side of safepoints.
Create a new issue for SymbolTable if you like.

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

PR: https://git.openjdk.org/jdk/pull/10527

From rehn at openjdk.org  Tue Oct  4 11:26:01 2022
From: rehn at openjdk.org (Robbin Ehn)
Date: Tue, 4 Oct 2022 11:26:01 GMT
Subject: RFR: 8282900: runtime/stringtable/StringTableCleaningTest.java
 verify unavailable at this moment [v2]
In-Reply-To: <rB06qYn4ntJNAAokUKRsDjEei1uzh7IsM2HBzndbmLM=.fac54cf9-2fee-49bb-9666-3c22c158a184@github.com>
References: <rB06qYn4ntJNAAokUKRsDjEei1uzh7IsM2HBzndbmLM=.fac54cf9-2fee-49bb-9666-3c22c158a184@github.com>
Message-ID: <kxFARHbjp2RuG0KrQNvBEn4cBH4jAnzi60M0mgvSJHY=.14720867-2e9a-45bd-bca4-fdb6d1d29bf7@github.com>

> Hi, please consider:
> 
> verify() is called by GC in safepoint so it should use the corresponding scanning method.
> verify_and_compare_entries() can wait for until there is no resize.
> 
> This makes these methods always succeed, passes t1-t6.

Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:

  Fixed review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10527/files
  - new: https://git.openjdk.org/jdk/pull/10527/files/29e957c4..2861af72

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10527&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10527&range=00-01

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

PR: https://git.openjdk.org/jdk/pull/10527

From jsjolen at openjdk.org  Tue Oct  4 12:00:52 2022
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 4 Oct 2022 12:00:52 GMT
Subject: RFR: 8294362: UL: Replace the internal usage of manual buffers with
 stringStream in LogSelection
Message-ID: <mUB0Ir5oWoGxE_mHp3IiZdObb96m4XFF5eFjDWq7IKo=.292a92ed-8957-4ae2-a930-2c942d7f3cc0@github.com>

Hi,

This is only a refactoring where the usage of manual character buffers are replaced with output streams, leading to much simpler code.

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

Commit messages:
 - Simplify string handling in LogSelection

Changes: https://git.openjdk.org/jdk/pull/10553/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10553&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294362
  Stats: 78 lines in 6 files changed: 2 ins; 44 del; 32 mod
  Patch: https://git.openjdk.org/jdk/pull/10553.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10553/head:pull/10553

PR: https://git.openjdk.org/jdk/pull/10553

From rrich at openjdk.org  Tue Oct  4 12:05:06 2022
From: rrich at openjdk.org (Richard Reingruber)
Date: Tue, 4 Oct 2022 12:05:06 GMT
Subject: RFR: 8289925: Shared code shouldn't reference the platform
 specific method frame::interpreter_frame_last_sp() [v4]
In-Reply-To: <8WISmA_G-lrsl2anFmiC9ENTg3D2e7E9P1IpZxelphk=.7f9790e7-aecf-4481-ada1-a53ea96e147a@github.com>
References: <ajPsCcqYGI_Nnz_dazduYGlJUMRPkbm7vYZLX_2NZBI=.ae53a301-68bd-4668-8ca9-f1b06386e872@github.com>
 <8WISmA_G-lrsl2anFmiC9ENTg3D2e7E9P1IpZxelphk=.7f9790e7-aecf-4481-ada1-a53ea96e147a@github.com>
Message-ID: <e2Akv577CPV-PHQpa85luc7VeXmDYbijdzJ1ql6x99Q=.d5a4e72f-33fd-4f00-8dd3-a4f23b7462d8@github.com>

On Wed, 21 Sep 2022 07:04:08 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> The method `frame::interpreter_frame_last_sp()` is a platform method in the sense that it is not declared in a shared header file. It is declared and defined on some platforms though (x86 and aarch64 I think).
>> 
>> `frame::interpreter_frame_last_sp()` existed on these platforms before vm continuations (aka loom). Shared code that is part of the vm continuations implementation references it. This breaks the platform abstraction.
>> 
>> Using unextended_sp is problematic too because there are no guarantees by the platform abstraction layer for it. In fact unextended_sp < sp is possible on ppc64 and aarch64.
>> 
>> This fix changes the callers of is_sp_in_continuation()
>> 
>> ```c++
>> static inline bool is_sp_in_continuation(const ContinuationEntry* entry, intptr_t* const sp) {
>>   return entry->entry_sp() > sp;
>> }
>> 
>> 
>> to pass the actual sp. This is correct because the following is true on all platforms:
>> 
>> ```c++
>> a.sp() > E->entry_sp() > b.sp() > c.sp()
>> 
>> 
>> where `a`, `b`, `c` are stack frames in call order and `E` is a ContinuationEntry. `a` is the caller frame of the continuation entry frame that corresponds to `E`.
>> 
>> is_sp_in_continuation() will then return true for `b.sp()` and `c.sp()` and false for `a.sp()`
>> 
>> Testing: hotspot_loom and jdk_loom on x86_64 and aarch64.
>
> Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove `Unimplemented` definitions of interpreter_frame_last_sp

I think this ready to be integrated. I'll do so tomorrow if there are no further comments until then.
Thanks again for your reviews @fisk and @dean-long

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

PR: https://git.openjdk.org/jdk/pull/9411

From lmesnik at openjdk.org  Tue Oct  4 13:02:31 2022
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 4 Oct 2022 13:02:31 GMT
Subject: Integrated: 8294406: Test runtime/handshake/HandshakeDirectTest.java
 failed: JVMTI_ERROR_WRONG_PHASE
In-Reply-To: <jfhigC5fMxowY9aOlzqiIjmWkdlEksRsUNAGMnG2NUc=.ebb41b5e-97c7-441c-952a-72b787cab3ef@github.com>
References: <jfhigC5fMxowY9aOlzqiIjmWkdlEksRsUNAGMnG2NUc=.ebb41b5e-97c7-441c-952a-72b787cab3ef@github.com>
Message-ID: <VutYYjOrbplR4Ok5OAn8hiL3_dn3e_3DKP9v97LUnSE=.123f22e3-24fd-4fb5-b934-6ffa14b53a20@github.com>

On Fri, 30 Sep 2022 01:32:44 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> 8294406: Test runtime/handshake/HandshakeDirectTest.java failed: JVMTI_ERROR_WRONG_PHASE

This pull request has now been integrated.

Changeset: 2dbedf0e
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2dbedf0e9326d8b3d79206787528d18e9fef25bd
Stats:     5 lines in 2 files changed: 3 ins; 0 del; 2 mod

8294406: Test runtime/handshake/HandshakeDirectTest.java failed: JVMTI_ERROR_WRONG_PHASE

Reviewed-by: dholmes, sspitsyn

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

PR: https://git.openjdk.org/jdk/pull/10502

From shade at openjdk.org  Tue Oct  4 13:04:48 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 4 Oct 2022 13:04:48 GMT
Subject: RFR: 8294759: Print actual lock/monitor ranking
Message-ID: <OWmG-86gxFSht-26qctihYkIdKz3f8kI86Lum7e8Lw8=.2330c15f-7d5e-4811-a78c-7742d761e650@github.com>

When relative lock ranks are changing, it is useful to see what are the final lock ranks are. It can be dumped as optional logging shortly after VM startup. 

Sample output:


$ build/linux-x86_64-server-fastdebug/images/jdk/bin/java -Xlog:vmmutex
[0.073s][info][vmmutex] VM Mutex/Monitor ranks: 
[0.073s][info][vmmutex] 
[0.073s][info][vmmutex] Rank "service-2":
[0.073s][info][vmmutex]   Uncommit_lock
[0.073s][info][vmmutex] 
[0.073s][info][vmmutex] Rank "service-1":
[0.073s][info][vmmutex]   FreeList_lock
[0.073s][info][vmmutex]   MonitoringSupport_lock
[0.073s][info][vmmutex] 
[0.073s][info][vmmutex] Rank "service":
[0.073s][info][vmmutex]   Service_lock
[0.073s][info][vmmutex]   Notification_lock
[0.073s][info][vmmutex] 
[0.073s][info][vmmutex] Rank "stackwatermark-1":
[0.073s][info][vmmutex]   JfrStacktrace_lock
[0.073s][info][vmmutex] 
[0.073s][info][vmmutex] Rank "tty-1":
[0.073s][info][vmmutex]   SharedDecoder_lock
[0.073s][info][vmmutex] 
[0.073s][info][vmmutex] Rank "tty":
[0.073s][info][vmmutex]   tty_lock
[0.073s][info][vmmutex] 
[0.073s][info][vmmutex] Rank "nosafepoint-3":
[0.073s][info][vmmutex]   Metaspace_lock
[0.073s][info][vmmutex]   JfrMsg_lock
[0.073s][info][vmmutex]   ContinuationRelativize_lock
[0.073s][info][vmmutex]   ThreadsSMRDelete_lock
[0.073s][info][vmmutex]   CompiledMethod_lock
[0.073s][info][vmmutex] 
[0.073s][info][vmmutex] Rank "nosafepoint-2":
[0.073s][info][vmmutex]   G1DetachedRefinementStats_lock
[0.073s][info][vmmutex]   JmethodIdCreation_lock
[0.073s][info][vmmutex]   CodeCache_lock
[0.073s][info][vmmutex] 
[0.073s][info][vmmutex] Rank "nosafepoint-1":
[0.073s][info][vmmutex]   RootRegionScan_lock
[0.073s][info][vmmutex]   RawMonitor_lock
[0.073s][info][vmmutex]   MetaspaceCritical_lock
[0.073s][info][vmmutex]   NonJavaThreadsList_lock
[0.073s][info][vmmutex]   Zip_lock
[0.073s][info][vmmutex]   InlineCacheBuffer_lock
[0.073s][info][vmmutex]   VtableStubs_lock
[0.073s][info][vmmutex] 
[0.073s][info][vmmutex] Rank "nosafepoint":
[0.073s][info][vmmutex]   STS_lock
[0.073s][info][vmmutex]   CGC_lock
[0.073s][info][vmmutex]   OldSets_lock
[0.073s][info][vmmutex]   MarkStackFreeList_lock
[0.073s][info][vmmutex]   MarkStackChunkList_lock
[0.073s][info][vmmutex]   StringDedup_lock
[0.073s][info][vmmutex]   StringDedupIntern_lock
[0.073s][info][vmmutex]   Patching_lock
[0.073s][info][vmmutex]   MonitorDeflation_lock
[0.073s][info][vmmutex]   SymbolArena_lock
[0.073s][info][vmmutex]   NonJavaThreadsListSync_lock
[0.073s][info][vmmutex]   InitCompleted_lock
[0.073s][info][vmmutex]   CompiledIC_lock
[0.073s][info][vmmutex]   DirectivesStack_lock
[0.073s][info][vmmutex]   EscapeBarrier_lock
[0.073s][info][vmmutex]   JvmtiVTMSTransition_lock
[0.073s][info][vmmutex]   JfrBuffer_lock
[0.073s][info][vmmutex]   JfrThreadSampler_lock
[0.073s][info][vmmutex]   DCmdFactory_lock
[0.073s][info][vmmutex]   DumpTimeTable_lock
[0.073s][info][vmmutex]   CDSLambda_lock
[0.073s][info][vmmutex]   DumpRegion_lock
[0.073s][info][vmmutex]   ClassListFile_lock
[0.073s][info][vmmutex]   Bootclasspath_lock
[0.073s][info][vmmutex] 
[0.073s][info][vmmutex] Rank "safepoint-3":
[0.073s][info][vmmutex]   PerfDataMemAlloc_lock
[0.073s][info][vmmutex]   PerfDataManager_lock
[0.073s][info][vmmutex]   VMOperation_lock
[0.073s][info][vmmutex]   SystemDictionary_lock
[0.073s][info][vmmutex] 
[0.073s][info][vmmutex] Rank "safepoint-2":
[0.073s][info][vmmutex]   Heap_lock
[0.073s][info][vmmutex]   ClassInitError_lock
[0.073s][info][vmmutex]   G1OldGCCount_lock
[0.073s][info][vmmutex]   ParGCRareEvent_lock
[0.073s][info][vmmutex]   OopMapCacheAlloc_lock
[0.073s][info][vmmutex]   Module_lock
[0.073s][info][vmmutex] 
[0.073s][info][vmmutex] Rank "safepoint-1":
[0.073s][info][vmmutex]   Threads_lock
[0.073s][info][vmmutex]   Compile_lock
[0.073s][info][vmmutex]   AdapterHandlerLibrary_lock
[0.073s][info][vmmutex]   ClassLoaderDataGraph_lock
[0.073s][info][vmmutex]   CompileTaskAlloc_lock
[0.073s][info][vmmutex]   JNICritical_lock
[0.073s][info][vmmutex]   JVMCI_lock
[0.073s][info][vmmutex] 
[0.073s][info][vmmutex] Rank "safepoint":
[0.073s][info][vmmutex]   InvokeMethodTable_lock
[0.073s][info][vmmutex]   SharedDictionary_lock
[0.073s][info][vmmutex]   VMStatistic_lock
[0.073s][info][vmmutex]   SignatureHandlerLibrary_lock
[0.073s][info][vmmutex]   ExceptionCache_lock
[0.073s][info][vmmutex]   FullGCALot_lock
[0.073s][info][vmmutex]   BeforeExit_lock
[0.073s][info][vmmutex]   RetData_lock
[0.073s][info][vmmutex]   Terminator_lock
[0.073s][info][vmmutex]   Notify_lock
[0.073s][info][vmmutex]   Heap_lock
[0.073s][info][vmmutex]   JfieldIdCreation_lock
[0.073s][info][vmmutex]   MethodCompileQueue_lock
[0.073s][info][vmmutex]   CompileStatistics_lock
[0.073s][info][vmmutex]   MultiArray_lock
[0.073s][info][vmmutex]   JvmtiThreadState_lock
[0.073s][info][vmmutex]   Management_lock
[0.073s][info][vmmutex]   ConcurrentGCBreakpoints_lock
[0.073s][info][vmmutex]   MethodData_lock
[0.073s][info][vmmutex]   TouchedMethodLog_lock
[0.073s][info][vmmutex]   CompileThread_lock
[0.073s][info][vmmutex]   PeriodicTask_lock
[0.073s][info][vmmutex]   RedefineClasses_lock
[0.073s][info][vmmutex]   Verify_lock
[0.073s][info][vmmutex]   CodeHeapStateAnalytics_lock
[0.073s][info][vmmutex]   ThreadIdTableCreate_lock
[0.073s][info][vmmutex]   NMTQuery_lock
[0.073s][info][vmmutex]   CDSClassFileStream_lock
[0.073s][info][vmmutex]   LambdaFormInvokers_lock
[0.073s][info][vmmutex]   JVMCIRuntime_lock


Additional testing:
 - [x] New test on Linux x86_64 {release,fastdebug,slowdebug}

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

Commit messages:
 - Fix

Changes: https://git.openjdk.org/jdk/pull/10556/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10556&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294759
  Stats: 101 lines in 4 files changed: 101 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10556.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10556/head:pull/10556

PR: https://git.openjdk.org/jdk/pull/10556

From sakatakui at oss.nttdata.com  Tue Oct  4 14:21:51 2022
From: sakatakui at oss.nttdata.com (Koichi Sakata)
Date: Tue, 04 Oct 2022 23:21:51 +0900
Subject: Proposal of Outputting Unified Logging to TCP socket
Message-ID: <b7b8a4524752e2ebc34f2d7930e68c7b@oss.nttdata.com>

Hello,

I would like to propose outputting unified logging (UL) to the TCP 
socket. I know that this has been discussed before [1]. However, 
circumstances have changed. Asynchronous logging was added to UL. If we 
output logs to TCP with async mode, we will be able to solve some issues 
raised in the past discussion (e.g. lag of log() calls). So I will take 
up this subject again.

This feature is useful, especially in the container environment. Take 
Kubernetes for example, there are many containers. It is recommended 
that containers send logs to standard output, but the mixture of Java 
application logs and UL logs in stdout is not handy to parse or search 
in a log aggregator like Elasticsearch. I believe that it's beneficial 
to deal with each type of log individually.

When we have files of UL logs, we have another issue. That is where to 
persist those files. As you know, we lose logs when pods are removed. I 
would rather not use volumes like Persistent Volume because of the cost 
of using volumes and the effort of managing files. When using the 
volume, we need to determine the file size and the volume size and put 
many log files of containers in it.

UL via TCP socket answers these issues. In the Kubernetes example, we 
use a log forwarder like Fluent Bit, Filebeat or something as a 
DaemonSet. It gets UL logs from the socket, gets application logs from 
stdout, and sends each log to corresponding log aggregators. As a 
result, we don't have UL log files and volumes to persist them anymore. 
This is premised on asynchronous logging. So the lag will not be a 
problem, I think.

For these reasons, I would like to propose outputting UL logs to TCP 
inputs. It seems to be unnecessary for traditional java applications, 
but it's of great use for applications in container environments. This 
makes it easier to build and operate applications on Kubernetes. There 
is also a bonus that this is os independent.

I will create a prototype of this proposal if it is worth trying.

By the way, there is a network stream class that is used to send node 
information to Ideal Graph Visualizer via socket. I'm not sure whether 
we can divert it or not for this new feature.

Best Regards,
Koichi Sakata

[1] 
https://mail.openjdk.org/pipermail/hotspot-runtime-dev/2020-November/043221.html

From jsjolen at openjdk.org  Tue Oct  4 14:39:48 2022
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 4 Oct 2022 14:39:48 GMT
Subject: RFR: 8294772: Remove workaround in os::dll_address_to_library_name
Message-ID: <XxV07mEZMfIMNuve5mZDn7dQA8NzLrrXTULALA88G9Y=.1cd2c6ad-8880-4bc9-ae04-76a75e739c5d@github.com>

I ported the BSD implementation of this function. According to the comment this bug should be fixed, as the oldest glibc I can see us supporting is 2.12.x. I've made an attempt at finding the bug that the comment refers to on glibc's bug tracker but has been unsuccesful in this.

The second commit deletes what seems like an outdated comment (in os_bsd this refers to a code snippet right below the comment).

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

Commit messages:
 - Delete copy-pasted comment
 - We should be on glibc > 2.3 for a long time now

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

PR: https://git.openjdk.org/jdk/pull/10559

From coleenp at openjdk.org  Tue Oct  4 17:37:33 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 4 Oct 2022 17:37:33 GMT
Subject: RFR: 8294759: Print actual lock/monitor ranking
In-Reply-To: <OWmG-86gxFSht-26qctihYkIdKz3f8kI86Lum7e8Lw8=.2330c15f-7d5e-4811-a78c-7742d761e650@github.com>
References: <OWmG-86gxFSht-26qctihYkIdKz3f8kI86Lum7e8Lw8=.2330c15f-7d5e-4811-a78c-7742d761e650@github.com>
Message-ID: <IVKtRZCD334u9fT64KZZ4M4u531zSm7Wkx4g__6S14g=.ef2e7590-5ca8-4716-81f2-113f4ddce069@github.com>

On Tue, 4 Oct 2022 12:46:42 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> When relative lock ranks are changing, it is useful to see what are the final lock ranks are. It can be dumped as optional logging shortly after VM startup. 
> 
> Sample output:
> 
> 
> $ build/linux-x86_64-server-fastdebug/images/jdk/bin/java -Xlog:vmmutex
> [0.073s][info][vmmutex] VM Mutex/Monitor ranks: 
> [0.073s][info][vmmutex] 
> [0.073s][info][vmmutex] Rank "service-2":
> [0.073s][info][vmmutex]   Uncommit_lock
> [0.073s][info][vmmutex] 
> [0.073s][info][vmmutex] Rank "service-1":
> [0.073s][info][vmmutex]   FreeList_lock
> [0.073s][info][vmmutex]   MonitoringSupport_lock
> [0.073s][info][vmmutex] 
> [0.073s][info][vmmutex] Rank "service":
> [0.073s][info][vmmutex]   Service_lock
> [0.073s][info][vmmutex]   Notification_lock
> [0.073s][info][vmmutex] 
> [0.073s][info][vmmutex] Rank "stackwatermark-1":
> [0.073s][info][vmmutex]   JfrStacktrace_lock
> [0.073s][info][vmmutex] 
> [0.073s][info][vmmutex] Rank "tty-1":
> [0.073s][info][vmmutex]   SharedDecoder_lock
> [0.073s][info][vmmutex] 
> [0.073s][info][vmmutex] Rank "tty":
> [0.073s][info][vmmutex]   tty_lock
> [0.073s][info][vmmutex] 
> [0.073s][info][vmmutex] Rank "nosafepoint-3":
> [0.073s][info][vmmutex]   Metaspace_lock
> [0.073s][info][vmmutex]   JfrMsg_lock
> [0.073s][info][vmmutex]   ContinuationRelativize_lock
> [0.073s][info][vmmutex]   ThreadsSMRDelete_lock
> [0.073s][info][vmmutex]   CompiledMethod_lock
> [0.073s][info][vmmutex] 
> [0.073s][info][vmmutex] Rank "nosafepoint-2":
> [0.073s][info][vmmutex]   G1DetachedRefinementStats_lock
> [0.073s][info][vmmutex]   JmethodIdCreation_lock
> [0.073s][info][vmmutex]   CodeCache_lock
> [0.073s][info][vmmutex] 
> [0.073s][info][vmmutex] Rank "nosafepoint-1":
> [0.073s][info][vmmutex]   RootRegionScan_lock
> [0.073s][info][vmmutex]   RawMonitor_lock
> [0.073s][info][vmmutex]   MetaspaceCritical_lock
> [0.073s][info][vmmutex]   NonJavaThreadsList_lock
> [0.073s][info][vmmutex]   Zip_lock
> [0.073s][info][vmmutex]   InlineCacheBuffer_lock
> [0.073s][info][vmmutex]   VtableStubs_lock
> [0.073s][info][vmmutex] 
> [0.073s][info][vmmutex] Rank "nosafepoint":
> [0.073s][info][vmmutex]   STS_lock
> [0.073s][info][vmmutex]   CGC_lock
> [0.073s][info][vmmutex]   OldSets_lock
> [0.073s][info][vmmutex]   MarkStackFreeList_lock
> [0.073s][info][vmmutex]   MarkStackChunkList_lock
> [0.073s][info][vmmutex]   StringDedup_lock
> [0.073s][info][vmmutex]   StringDedupIntern_lock
> [0.073s][info][vmmutex]   Patching_lock
> [0.073s][info][vmmutex]   MonitorDeflation_lock
> [0.073s][info][vmmutex]   SymbolArena_lock
> [0.073s][info][vmmutex]   NonJavaThreadsListSync_lock
> [0.073s][info][vmmutex]   InitCompleted_lock
> [0.073s][info][vmmutex]   CompiledIC_lock
> [0.073s][info][vmmutex]   DirectivesStack_lock
> [0.073s][info][vmmutex]   EscapeBarrier_lock
> [0.073s][info][vmmutex]   JvmtiVTMSTransition_lock
> [0.073s][info][vmmutex]   JfrBuffer_lock
> [0.073s][info][vmmutex]   JfrThreadSampler_lock
> [0.073s][info][vmmutex]   DCmdFactory_lock
> [0.073s][info][vmmutex]   DumpTimeTable_lock
> [0.073s][info][vmmutex]   CDSLambda_lock
> [0.073s][info][vmmutex]   DumpRegion_lock
> [0.073s][info][vmmutex]   ClassListFile_lock
> [0.073s][info][vmmutex]   Bootclasspath_lock
> [0.073s][info][vmmutex] 
> [0.073s][info][vmmutex] Rank "safepoint-3":
> [0.073s][info][vmmutex]   PerfDataMemAlloc_lock
> [0.073s][info][vmmutex]   PerfDataManager_lock
> [0.073s][info][vmmutex]   VMOperation_lock
> [0.073s][info][vmmutex]   SystemDictionary_lock
> [0.073s][info][vmmutex] 
> [0.073s][info][vmmutex] Rank "safepoint-2":
> [0.073s][info][vmmutex]   Heap_lock
> [0.073s][info][vmmutex]   ClassInitError_lock
> [0.073s][info][vmmutex]   G1OldGCCount_lock
> [0.073s][info][vmmutex]   ParGCRareEvent_lock
> [0.073s][info][vmmutex]   OopMapCacheAlloc_lock
> [0.073s][info][vmmutex]   Module_lock
> [0.073s][info][vmmutex] 
> [0.073s][info][vmmutex] Rank "safepoint-1":
> [0.073s][info][vmmutex]   Threads_lock
> [0.073s][info][vmmutex]   Compile_lock
> [0.073s][info][vmmutex]   AdapterHandlerLibrary_lock
> [0.073s][info][vmmutex]   ClassLoaderDataGraph_lock
> [0.073s][info][vmmutex]   CompileTaskAlloc_lock
> [0.073s][info][vmmutex]   JNICritical_lock
> [0.073s][info][vmmutex]   JVMCI_lock
> [0.073s][info][vmmutex] 
> [0.073s][info][vmmutex] Rank "safepoint":
> [0.073s][info][vmmutex]   InvokeMethodTable_lock
> [0.073s][info][vmmutex]   SharedDictionary_lock
> [0.073s][info][vmmutex]   VMStatistic_lock
> [0.073s][info][vmmutex]   SignatureHandlerLibrary_lock
> [0.073s][info][vmmutex]   ExceptionCache_lock
> [0.073s][info][vmmutex]   FullGCALot_lock
> [0.073s][info][vmmutex]   BeforeExit_lock
> [0.073s][info][vmmutex]   RetData_lock
> [0.073s][info][vmmutex]   Terminator_lock
> [0.073s][info][vmmutex]   Notify_lock
> [0.073s][info][vmmutex]   Heap_lock
> [0.073s][info][vmmutex]   JfieldIdCreation_lock
> [0.073s][info][vmmutex]   MethodCompileQueue_lock
> [0.073s][info][vmmutex]   CompileStatistics_lock
> [0.073s][info][vmmutex]   MultiArray_lock
> [0.073s][info][vmmutex]   JvmtiThreadState_lock
> [0.073s][info][vmmutex]   Management_lock
> [0.073s][info][vmmutex]   ConcurrentGCBreakpoints_lock
> [0.073s][info][vmmutex]   MethodData_lock
> [0.073s][info][vmmutex]   TouchedMethodLog_lock
> [0.073s][info][vmmutex]   CompileThread_lock
> [0.073s][info][vmmutex]   PeriodicTask_lock
> [0.073s][info][vmmutex]   RedefineClasses_lock
> [0.073s][info][vmmutex]   Verify_lock
> [0.073s][info][vmmutex]   CodeHeapStateAnalytics_lock
> [0.073s][info][vmmutex]   ThreadIdTableCreate_lock
> [0.073s][info][vmmutex]   NMTQuery_lock
> [0.073s][info][vmmutex]   CDSClassFileStream_lock
> [0.073s][info][vmmutex]   LambdaFormInvokers_lock
> [0.073s][info][vmmutex]   JVMCIRuntime_lock
> 
> 
> Additional testing:
>  - [x] New test on Linux x86_64 {release,fastdebug,slowdebug}

This seems nice.

src/hotspot/share/runtime/mutexLocker.cpp line 440:

> 438:   }
> 439: 
> 440:   for (int r = min_rank; r <= max_rank; r++) {

I'm confused by this first loop. why can't min_rank be Mutex::event or static_cast<int>0 and max_rank should be Mutex::safepoint.

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

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10556

From shade at openjdk.org  Tue Oct  4 17:40:22 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 4 Oct 2022 17:40:22 GMT
Subject: RFR: 8294759: Print actual lock/monitor ranking
In-Reply-To: <IVKtRZCD334u9fT64KZZ4M4u531zSm7Wkx4g__6S14g=.ef2e7590-5ca8-4716-81f2-113f4ddce069@github.com>
References: <OWmG-86gxFSht-26qctihYkIdKz3f8kI86Lum7e8Lw8=.2330c15f-7d5e-4811-a78c-7742d761e650@github.com>
 <IVKtRZCD334u9fT64KZZ4M4u531zSm7Wkx4g__6S14g=.ef2e7590-5ca8-4716-81f2-113f4ddce069@github.com>
Message-ID: <2cJQ_XYvvSMoqDDmu6tK6VFQUQ6PmFspKKSn88Gbw-w=.21f2e25e-9d64-44fa-8f8f-8aec324d00a0@github.com>

On Tue, 4 Oct 2022 17:33:04 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> When relative lock ranks are changing, it is useful to see what are the final lock ranks are. It can be dumped as optional logging shortly after VM startup. 
>> 
>> Sample output:
>> 
>> 
>> $ build/linux-x86_64-server-fastdebug/images/jdk/bin/java -Xlog:vmmutex
>> [0.073s][info][vmmutex] VM Mutex/Monitor ranks: 
>> [0.073s][info][vmmutex] 
>> [0.073s][info][vmmutex] Rank "service-2":
>> [0.073s][info][vmmutex]   Uncommit_lock
>> [0.073s][info][vmmutex] 
>> [0.073s][info][vmmutex] Rank "service-1":
>> [0.073s][info][vmmutex]   FreeList_lock
>> [0.073s][info][vmmutex]   MonitoringSupport_lock
>> [0.073s][info][vmmutex] 
>> [0.073s][info][vmmutex] Rank "service":
>> [0.073s][info][vmmutex]   Service_lock
>> [0.073s][info][vmmutex]   Notification_lock
>> [0.073s][info][vmmutex] 
>> [0.073s][info][vmmutex] Rank "stackwatermark-1":
>> [0.073s][info][vmmutex]   JfrStacktrace_lock
>> [0.073s][info][vmmutex] 
>> [0.073s][info][vmmutex] Rank "tty-1":
>> [0.073s][info][vmmutex]   SharedDecoder_lock
>> [0.073s][info][vmmutex] 
>> [0.073s][info][vmmutex] Rank "tty":
>> [0.073s][info][vmmutex]   tty_lock
>> [0.073s][info][vmmutex] 
>> [0.073s][info][vmmutex] Rank "nosafepoint-3":
>> [0.073s][info][vmmutex]   Metaspace_lock
>> [0.073s][info][vmmutex]   JfrMsg_lock
>> [0.073s][info][vmmutex]   ContinuationRelativize_lock
>> [0.073s][info][vmmutex]   ThreadsSMRDelete_lock
>> [0.073s][info][vmmutex]   CompiledMethod_lock
>> [0.073s][info][vmmutex] 
>> [0.073s][info][vmmutex] Rank "nosafepoint-2":
>> [0.073s][info][vmmutex]   G1DetachedRefinementStats_lock
>> [0.073s][info][vmmutex]   JmethodIdCreation_lock
>> [0.073s][info][vmmutex]   CodeCache_lock
>> [0.073s][info][vmmutex] 
>> [0.073s][info][vmmutex] Rank "nosafepoint-1":
>> [0.073s][info][vmmutex]   RootRegionScan_lock
>> [0.073s][info][vmmutex]   RawMonitor_lock
>> [0.073s][info][vmmutex]   MetaspaceCritical_lock
>> [0.073s][info][vmmutex]   NonJavaThreadsList_lock
>> [0.073s][info][vmmutex]   Zip_lock
>> [0.073s][info][vmmutex]   InlineCacheBuffer_lock
>> [0.073s][info][vmmutex]   VtableStubs_lock
>> [0.073s][info][vmmutex] 
>> [0.073s][info][vmmutex] Rank "nosafepoint":
>> [0.073s][info][vmmutex]   STS_lock
>> [0.073s][info][vmmutex]   CGC_lock
>> [0.073s][info][vmmutex]   OldSets_lock
>> [0.073s][info][vmmutex]   MarkStackFreeList_lock
>> [0.073s][info][vmmutex]   MarkStackChunkList_lock
>> [0.073s][info][vmmutex]   StringDedup_lock
>> [0.073s][info][vmmutex]   StringDedupIntern_lock
>> [0.073s][info][vmmutex]   Patching_lock
>> [0.073s][info][vmmutex]   MonitorDeflation_lock
>> [0.073s][info][vmmutex]   SymbolArena_lock
>> [0.073s][info][vmmutex]   NonJavaThreadsListSync_lock
>> [0.073s][info][vmmutex]   InitCompleted_lock
>> [0.073s][info][vmmutex]   CompiledIC_lock
>> [0.073s][info][vmmutex]   DirectivesStack_lock
>> [0.073s][info][vmmutex]   EscapeBarrier_lock
>> [0.073s][info][vmmutex]   JvmtiVTMSTransition_lock
>> [0.073s][info][vmmutex]   JfrBuffer_lock
>> [0.073s][info][vmmutex]   JfrThreadSampler_lock
>> [0.073s][info][vmmutex]   DCmdFactory_lock
>> [0.073s][info][vmmutex]   DumpTimeTable_lock
>> [0.073s][info][vmmutex]   CDSLambda_lock
>> [0.073s][info][vmmutex]   DumpRegion_lock
>> [0.073s][info][vmmutex]   ClassListFile_lock
>> [0.073s][info][vmmutex]   Bootclasspath_lock
>> [0.073s][info][vmmutex] 
>> [0.073s][info][vmmutex] Rank "safepoint-3":
>> [0.073s][info][vmmutex]   PerfDataMemAlloc_lock
>> [0.073s][info][vmmutex]   PerfDataManager_lock
>> [0.073s][info][vmmutex]   VMOperation_lock
>> [0.073s][info][vmmutex]   SystemDictionary_lock
>> [0.073s][info][vmmutex] 
>> [0.073s][info][vmmutex] Rank "safepoint-2":
>> [0.073s][info][vmmutex]   Heap_lock
>> [0.073s][info][vmmutex]   ClassInitError_lock
>> [0.073s][info][vmmutex]   G1OldGCCount_lock
>> [0.073s][info][vmmutex]   ParGCRareEvent_lock
>> [0.073s][info][vmmutex]   OopMapCacheAlloc_lock
>> [0.073s][info][vmmutex]   Module_lock
>> [0.073s][info][vmmutex] 
>> [0.073s][info][vmmutex] Rank "safepoint-1":
>> [0.073s][info][vmmutex]   Threads_lock
>> [0.073s][info][vmmutex]   Compile_lock
>> [0.073s][info][vmmutex]   AdapterHandlerLibrary_lock
>> [0.073s][info][vmmutex]   ClassLoaderDataGraph_lock
>> [0.073s][info][vmmutex]   CompileTaskAlloc_lock
>> [0.073s][info][vmmutex]   JNICritical_lock
>> [0.073s][info][vmmutex]   JVMCI_lock
>> [0.073s][info][vmmutex] 
>> [0.073s][info][vmmutex] Rank "safepoint":
>> [0.073s][info][vmmutex]   InvokeMethodTable_lock
>> [0.073s][info][vmmutex]   SharedDictionary_lock
>> [0.073s][info][vmmutex]   VMStatistic_lock
>> [0.073s][info][vmmutex]   SignatureHandlerLibrary_lock
>> [0.073s][info][vmmutex]   ExceptionCache_lock
>> [0.073s][info][vmmutex]   FullGCALot_lock
>> [0.073s][info][vmmutex]   BeforeExit_lock
>> [0.073s][info][vmmutex]   RetData_lock
>> [0.073s][info][vmmutex]   Terminator_lock
>> [0.073s][info][vmmutex]   Notify_lock
>> [0.073s][info][vmmutex]   Heap_lock
>> [0.073s][info][vmmutex]   JfieldIdCreation_lock
>> [0.073s][info][vmmutex]   MethodCompileQueue_lock
>> [0.073s][info][vmmutex]   CompileStatistics_lock
>> [0.073s][info][vmmutex]   MultiArray_lock
>> [0.073s][info][vmmutex]   JvmtiThreadState_lock
>> [0.073s][info][vmmutex]   Management_lock
>> [0.073s][info][vmmutex]   ConcurrentGCBreakpoints_lock
>> [0.073s][info][vmmutex]   MethodData_lock
>> [0.073s][info][vmmutex]   TouchedMethodLog_lock
>> [0.073s][info][vmmutex]   CompileThread_lock
>> [0.073s][info][vmmutex]   PeriodicTask_lock
>> [0.073s][info][vmmutex]   RedefineClasses_lock
>> [0.073s][info][vmmutex]   Verify_lock
>> [0.073s][info][vmmutex]   CodeHeapStateAnalytics_lock
>> [0.073s][info][vmmutex]   ThreadIdTableCreate_lock
>> [0.073s][info][vmmutex]   NMTQuery_lock
>> [0.073s][info][vmmutex]   CDSClassFileStream_lock
>> [0.073s][info][vmmutex]   LambdaFormInvokers_lock
>> [0.073s][info][vmmutex]   JVMCIRuntime_lock
>> 
>> 
>> Additional testing:
>>  - [x] New test on Linux x86_64 {release,fastdebug,slowdebug}
>
> src/hotspot/share/runtime/mutexLocker.cpp line 440:
> 
>> 438:   }
>> 439: 
>> 440:   for (int r = min_rank; r <= max_rank; r++) {
> 
> I'm confused by this first loop. why can't min_rank be Mutex::event or static_cast<int>0 and max_rank should be Mutex::safepoint.

Ah, I was being defensive about this: computing min/max without relying on the actual `Rank` definition. While `0` is plausibly the lowest rank, I don't really want to rely on `safepoint` being the last rank. This is debugging code, so we can spend some time on this. Makes sense?

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

PR: https://git.openjdk.org/jdk/pull/10556

From coleenp at openjdk.org  Tue Oct  4 21:53:30 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 4 Oct 2022 21:53:30 GMT
Subject: RFR: 8294759: Print actual lock/monitor ranking
In-Reply-To: <2cJQ_XYvvSMoqDDmu6tK6VFQUQ6PmFspKKSn88Gbw-w=.21f2e25e-9d64-44fa-8f8f-8aec324d00a0@github.com>
References: <OWmG-86gxFSht-26qctihYkIdKz3f8kI86Lum7e8Lw8=.2330c15f-7d5e-4811-a78c-7742d761e650@github.com>
 <IVKtRZCD334u9fT64KZZ4M4u531zSm7Wkx4g__6S14g=.ef2e7590-5ca8-4716-81f2-113f4ddce069@github.com>
 <2cJQ_XYvvSMoqDDmu6tK6VFQUQ6PmFspKKSn88Gbw-w=.21f2e25e-9d64-44fa-8f8f-8aec324d00a0@github.com>
Message-ID: <owyW4UuVRmQsk0N52Q2G850PPw_vthF_vCfCJOw-2Y4=.1d968544-d33a-4b53-8b36-506a4ce7fe9a@github.com>

On Tue, 4 Oct 2022 17:37:40 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> src/hotspot/share/runtime/mutexLocker.cpp line 440:
>> 
>>> 438:   }
>>> 439: 
>>> 440:   for (int r = min_rank; r <= max_rank; r++) {
>> 
>> I'm confused by this first loop. why can't min_rank be Mutex::event or static_cast<int>0 and max_rank should be Mutex::safepoint.
>
> Ah, I was being defensive about this: computing min/max without relying on the actual `Rank` definition. While `0` is plausibly the lowest rank, I don't really want to rely on `safepoint` being the last rank. This is debugging code, so we can spend some time on this. Makes sense?

All the other code in this file thinks safepoint is the last rank (it's an invariant) and INT_MAX is a bit large even for debugging code.  I think safepoint would be better. I marked it as reviewed so am not really insistent., but it looked weird to me.

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

PR: https://git.openjdk.org/jdk/pull/10556

From dholmes at openjdk.org  Wed Oct  5 01:45:20 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 5 Oct 2022 01:45:20 GMT
Subject: RFR: 8282900: runtime/stringtable/StringTableCleaningTest.java
 verify unavailable at this moment [v2]
In-Reply-To: <BBl0JCg0IBeag9QlaUUk-UZaTFnmtw_CIac8iqg1u6c=.ed251e30-7c45-4f60-98b4-8883da86485e@github.com>
References: <rB06qYn4ntJNAAokUKRsDjEei1uzh7IsM2HBzndbmLM=.fac54cf9-2fee-49bb-9666-3c22c158a184@github.com>
 <q4ZHyOQS5thuGOiWx9NLLIQb0WC9OdgxFK9IBV_SQJk=.2f89e1ec-371b-4729-92a2-dd7c81c68170@github.com>
 <BBl0JCg0IBeag9QlaUUk-UZaTFnmtw_CIac8iqg1u6c=.ed251e30-7c45-4f60-98b4-8883da86485e@github.com>
Message-ID: <9QbUkXULbzjhFE2OTLKgLKsvGOH2Ofnd3g_UEBOAOkY=.457b1bd9-4b1c-412c-be68-3260a6558bbc@github.com>

On Tue, 4 Oct 2022 08:34:41 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> But the code says that the resize_lock may be dropped to allow a safepoint, but I can't see where exactly this dropping occurs? 

Can you answer this query? Thanks

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

PR: https://git.openjdk.org/jdk/pull/10527

From dholmes at openjdk.org  Wed Oct  5 02:04:07 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 5 Oct 2022 02:04:07 GMT
Subject: RFR: 8294362: UL: Replace the internal usage of manual buffers
 with stringStream in LogSelection
In-Reply-To: <mUB0Ir5oWoGxE_mHp3IiZdObb96m4XFF5eFjDWq7IKo=.292a92ed-8957-4ae2-a930-2c942d7f3cc0@github.com>
References: <mUB0Ir5oWoGxE_mHp3IiZdObb96m4XFF5eFjDWq7IKo=.292a92ed-8957-4ae2-a930-2c942d7f3cc0@github.com>
Message-ID: <2bAfQEf8_dpaTkD8XXiAZ911GhinAu7_GPN48V0oj30=.dd622fb6-1dfd-476a-86cc-35af2ed1a16b@github.com>

On Tue, 4 Oct 2022 11:44:26 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Hi,
> 
> This is only a refactoring where the usage of manual character buffers are replaced with output streams, leading to much simpler code.

This definitely seems simpler and cleaner, but raises the obvious question: why was it not done this way in the first place? Are there initialization issues/constraints with use of the stream classes?

I need to see if there is some historical info on the initial implementation here.

Thanks.

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

PR: https://git.openjdk.org/jdk/pull/10553

From dholmes at openjdk.org  Wed Oct  5 02:48:20 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 5 Oct 2022 02:48:20 GMT
Subject: RFR: 8294362: UL: Replace the internal usage of manual buffers
 with stringStream in LogSelection
In-Reply-To: <2bAfQEf8_dpaTkD8XXiAZ911GhinAu7_GPN48V0oj30=.dd622fb6-1dfd-476a-86cc-35af2ed1a16b@github.com>
References: <mUB0Ir5oWoGxE_mHp3IiZdObb96m4XFF5eFjDWq7IKo=.292a92ed-8957-4ae2-a930-2c942d7f3cc0@github.com>
 <2bAfQEf8_dpaTkD8XXiAZ911GhinAu7_GPN48V0oj30=.dd622fb6-1dfd-476a-86cc-35af2ed1a16b@github.com>
Message-ID: <OL78g6ZuEUoDv1rnU_yJdg3gJko4oIRNm8WsVad0rBo=.3fcf5f98-b176-4f71-83cf-96ded1a29e0f@github.com>

On Wed, 5 Oct 2022 02:00:39 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I need to see if there is some historical info on the initial implementation here.

Nope. Lets see if anyone else knows why the code may have originally been written the way it was.

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

PR: https://git.openjdk.org/jdk/pull/10553

From dholmes at openjdk.org  Wed Oct  5 04:14:53 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 5 Oct 2022 04:14:53 GMT
Subject: RFR: 8294759: Print actual lock/monitor ranking
In-Reply-To: <OWmG-86gxFSht-26qctihYkIdKz3f8kI86Lum7e8Lw8=.2330c15f-7d5e-4811-a78c-7742d761e650@github.com>
References: <OWmG-86gxFSht-26qctihYkIdKz3f8kI86Lum7e8Lw8=.2330c15f-7d5e-4811-a78c-7742d761e650@github.com>
Message-ID: <eKMrOT-LhUXW36WVUFglAQf0t1VYhd2neVsqLquukhc=.60df170e-94b1-4b9c-a638-d8639f5e0826@github.com>

On Tue, 4 Oct 2022 12:46:42 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> When relative lock ranks are changing, it is useful to see what are the final lock ranks are. It can be dumped as optional logging shortly after VM startup. 
> 
> Sample output:
> 
> 
> $ build/linux-x86_64-server-fastdebug/images/jdk/bin/java -Xlog:vmmutex
> [0.073s][info][vmmutex] VM Mutex/Monitor ranks: 
> [0.073s][info][vmmutex] 
> [0.073s][info][vmmutex] Rank "service-2":
> [0.073s][info][vmmutex]   Uncommit_lock
> [0.073s][info][vmmutex] 
> [0.073s][info][vmmutex] Rank "service-1":
> [0.073s][info][vmmutex]   FreeList_lock
> [0.073s][info][vmmutex]   MonitoringSupport_lock
> [0.073s][info][vmmutex] 
> [0.073s][info][vmmutex] Rank "service":
> [0.073s][info][vmmutex]   Service_lock
> [0.073s][info][vmmutex]   Notification_lock
> [0.073s][info][vmmutex] 
> [0.073s][info][vmmutex] Rank "stackwatermark-1":
> [0.073s][info][vmmutex]   JfrStacktrace_lock
> [0.073s][info][vmmutex] 
> [0.073s][info][vmmutex] Rank "tty-1":
> [0.073s][info][vmmutex]   SharedDecoder_lock
> [0.073s][info][vmmutex] 
> [0.073s][info][vmmutex] Rank "tty":
> [0.073s][info][vmmutex]   tty_lock
> [0.073s][info][vmmutex] 
> [0.073s][info][vmmutex] Rank "nosafepoint-3":
> [0.073s][info][vmmutex]   Metaspace_lock
> [0.073s][info][vmmutex]   JfrMsg_lock
> [0.073s][info][vmmutex]   ContinuationRelativize_lock
> [0.073s][info][vmmutex]   ThreadsSMRDelete_lock
> [0.073s][info][vmmutex]   CompiledMethod_lock
> [0.073s][info][vmmutex] 
> [0.073s][info][vmmutex] Rank "nosafepoint-2":
> [0.073s][info][vmmutex]   G1DetachedRefinementStats_lock
> [0.073s][info][vmmutex]   JmethodIdCreation_lock
> [0.073s][info][vmmutex]   CodeCache_lock
> [0.073s][info][vmmutex] 
> [0.073s][info][vmmutex] Rank "nosafepoint-1":
> [0.073s][info][vmmutex]   RootRegionScan_lock
> [0.073s][info][vmmutex]   RawMonitor_lock
> [0.073s][info][vmmutex]   MetaspaceCritical_lock
> [0.073s][info][vmmutex]   NonJavaThreadsList_lock
> [0.073s][info][vmmutex]   Zip_lock
> [0.073s][info][vmmutex]   InlineCacheBuffer_lock
> [0.073s][info][vmmutex]   VtableStubs_lock
> [0.073s][info][vmmutex] 
> [0.073s][info][vmmutex] Rank "nosafepoint":
> [0.073s][info][vmmutex]   STS_lock
> [0.073s][info][vmmutex]   CGC_lock
> [0.073s][info][vmmutex]   OldSets_lock
> [0.073s][info][vmmutex]   MarkStackFreeList_lock
> [0.073s][info][vmmutex]   MarkStackChunkList_lock
> [0.073s][info][vmmutex]   StringDedup_lock
> [0.073s][info][vmmutex]   StringDedupIntern_lock
> [0.073s][info][vmmutex]   Patching_lock
> [0.073s][info][vmmutex]   MonitorDeflation_lock
> [0.073s][info][vmmutex]   SymbolArena_lock
> [0.073s][info][vmmutex]   NonJavaThreadsListSync_lock
> [0.073s][info][vmmutex]   InitCompleted_lock
> [0.073s][info][vmmutex]   CompiledIC_lock
> [0.073s][info][vmmutex]   DirectivesStack_lock
> [0.073s][info][vmmutex]   EscapeBarrier_lock
> [0.073s][info][vmmutex]   JvmtiVTMSTransition_lock
> [0.073s][info][vmmutex]   JfrBuffer_lock
> [0.073s][info][vmmutex]   JfrThreadSampler_lock
> [0.073s][info][vmmutex]   DCmdFactory_lock
> [0.073s][info][vmmutex]   DumpTimeTable_lock
> [0.073s][info][vmmutex]   CDSLambda_lock
> [0.073s][info][vmmutex]   DumpRegion_lock
> [0.073s][info][vmmutex]   ClassListFile_lock
> [0.073s][info][vmmutex]   Bootclasspath_lock
> [0.073s][info][vmmutex] 
> [0.073s][info][vmmutex] Rank "safepoint-3":
> [0.073s][info][vmmutex]   PerfDataMemAlloc_lock
> [0.073s][info][vmmutex]   PerfDataManager_lock
> [0.073s][info][vmmutex]   VMOperation_lock
> [0.073s][info][vmmutex]   SystemDictionary_lock
> [0.073s][info][vmmutex] 
> [0.073s][info][vmmutex] Rank "safepoint-2":
> [0.073s][info][vmmutex]   Heap_lock
> [0.073s][info][vmmutex]   ClassInitError_lock
> [0.073s][info][vmmutex]   G1OldGCCount_lock
> [0.073s][info][vmmutex]   ParGCRareEvent_lock
> [0.073s][info][vmmutex]   OopMapCacheAlloc_lock
> [0.073s][info][vmmutex]   Module_lock
> [0.073s][info][vmmutex] 
> [0.073s][info][vmmutex] Rank "safepoint-1":
> [0.073s][info][vmmutex]   Threads_lock
> [0.073s][info][vmmutex]   Compile_lock
> [0.073s][info][vmmutex]   AdapterHandlerLibrary_lock
> [0.073s][info][vmmutex]   ClassLoaderDataGraph_lock
> [0.073s][info][vmmutex]   CompileTaskAlloc_lock
> [0.073s][info][vmmutex]   JNICritical_lock
> [0.073s][info][vmmutex]   JVMCI_lock
> [0.073s][info][vmmutex] 
> [0.073s][info][vmmutex] Rank "safepoint":
> [0.073s][info][vmmutex]   InvokeMethodTable_lock
> [0.073s][info][vmmutex]   SharedDictionary_lock
> [0.073s][info][vmmutex]   VMStatistic_lock
> [0.073s][info][vmmutex]   SignatureHandlerLibrary_lock
> [0.073s][info][vmmutex]   ExceptionCache_lock
> [0.073s][info][vmmutex]   FullGCALot_lock
> [0.073s][info][vmmutex]   BeforeExit_lock
> [0.073s][info][vmmutex]   RetData_lock
> [0.073s][info][vmmutex]   Terminator_lock
> [0.073s][info][vmmutex]   Notify_lock
> [0.073s][info][vmmutex]   Heap_lock
> [0.073s][info][vmmutex]   JfieldIdCreation_lock
> [0.073s][info][vmmutex]   MethodCompileQueue_lock
> [0.073s][info][vmmutex]   CompileStatistics_lock
> [0.073s][info][vmmutex]   MultiArray_lock
> [0.073s][info][vmmutex]   JvmtiThreadState_lock
> [0.073s][info][vmmutex]   Management_lock
> [0.073s][info][vmmutex]   ConcurrentGCBreakpoints_lock
> [0.073s][info][vmmutex]   MethodData_lock
> [0.073s][info][vmmutex]   TouchedMethodLog_lock
> [0.073s][info][vmmutex]   CompileThread_lock
> [0.073s][info][vmmutex]   PeriodicTask_lock
> [0.073s][info][vmmutex]   RedefineClasses_lock
> [0.073s][info][vmmutex]   Verify_lock
> [0.073s][info][vmmutex]   CodeHeapStateAnalytics_lock
> [0.073s][info][vmmutex]   ThreadIdTableCreate_lock
> [0.073s][info][vmmutex]   NMTQuery_lock
> [0.073s][info][vmmutex]   CDSClassFileStream_lock
> [0.073s][info][vmmutex]   LambdaFormInvokers_lock
> [0.073s][info][vmmutex]   JVMCIRuntime_lock
> 
> 
> Additional testing:
>  - [x] New test on Linux x86_64 {release,fastdebug,slowdebug}

Seems okay. One query.

Thanks.

src/hotspot/share/runtime/mutexLocker.cpp line 427:

> 425: 
> 426: void print_lock_ranks(outputStream* st) {
> 427:   st->print_cr("VM Mutex/Monitor ranks: ");

Do we want to clarify this is not the complete set of Mutexes in the VM?

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10556

From dholmes at openjdk.org  Wed Oct  5 05:18:23 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 5 Oct 2022 05:18:23 GMT
Subject: RFR: 8294772: Remove workaround in os::dll_address_to_library_name
In-Reply-To: <XxV07mEZMfIMNuve5mZDn7dQA8NzLrrXTULALA88G9Y=.1cd2c6ad-8880-4bc9-ae04-76a75e739c5d@github.com>
References: <XxV07mEZMfIMNuve5mZDn7dQA8NzLrrXTULALA88G9Y=.1cd2c6ad-8880-4bc9-ae04-76a75e739c5d@github.com>
Message-ID: <LymviHxuCsLYY3K_YyvR3C7yq3_CHVCP53tR-x55fBw=.b76c7f4e-8d2e-43b7-b6a2-4fbe20f0ba29@github.com>

On Tue, 4 Oct 2022 14:30:58 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> I ported the BSD implementation of this function. According to the comment this bug should be fixed, as the oldest glibc I can see us supporting is 2.12.x. I've made an attempt at finding the bug that the comment refers to on glibc's bug tracker but has been unsuccesful in this.
> 
> The second commit deletes what seems like an outdated comment (in os_bsd this refers to a code snippet right below the comment).

This looks good to me. Thanks for cleaning this up.

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10559

From rehn at openjdk.org  Wed Oct  5 06:07:32 2022
From: rehn at openjdk.org (Robbin Ehn)
Date: Wed, 5 Oct 2022 06:07:32 GMT
Subject: RFR: 8282900: runtime/stringtable/StringTableCleaningTest.java
 verify unavailable at this moment [v2]
In-Reply-To: <9QbUkXULbzjhFE2OTLKgLKsvGOH2Ofnd3g_UEBOAOkY=.457b1bd9-4b1c-412c-be68-3260a6558bbc@github.com>
References: <rB06qYn4ntJNAAokUKRsDjEei1uzh7IsM2HBzndbmLM=.fac54cf9-2fee-49bb-9666-3c22c158a184@github.com>
 <q4ZHyOQS5thuGOiWx9NLLIQb0WC9OdgxFK9IBV_SQJk=.2f89e1ec-371b-4729-92a2-dd7c81c68170@github.com>
 <BBl0JCg0IBeag9QlaUUk-UZaTFnmtw_CIac8iqg1u6c=.ed251e30-7c45-4f60-98b4-8883da86485e@github.com>
 <9QbUkXULbzjhFE2OTLKgLKsvGOH2Ofnd3g_UEBOAOkY=.457b1bd9-4b1c-412c-be68-3260a6558bbc@github.com>
Message-ID: <XZBN3BLZ7pwraN_Rf0DH5CXcnOaAjLLXhBkYpqgk0cQ=.fd020d5d-a1b3-480a-b143-5c979db6acb0@github.com>

On Wed, 5 Oct 2022 01:43:00 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Can you answer this query? Thanks

I thought did with:
> The exact code would in "StringTable::grow(...)" when calling "gt.pause(jt)".


  // Pauses for safepoint
  void pause(Thread* thread) {
    // This leaves internal state locked.
    this->thread_owns_resize_lock(thread);
    BucketsOperation::_cht->_resize_lock->unlock();     
    this->thread_owns_only_state_lock(thread);        
  }

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

PR: https://git.openjdk.org/jdk/pull/10527

From dholmes at openjdk.org  Wed Oct  5 07:04:45 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 5 Oct 2022 07:04:45 GMT
Subject: RFR: 8282900: runtime/stringtable/StringTableCleaningTest.java
 verify unavailable at this moment [v2]
In-Reply-To: <kxFARHbjp2RuG0KrQNvBEn4cBH4jAnzi60M0mgvSJHY=.14720867-2e9a-45bd-bca4-fdb6d1d29bf7@github.com>
References: <rB06qYn4ntJNAAokUKRsDjEei1uzh7IsM2HBzndbmLM=.fac54cf9-2fee-49bb-9666-3c22c158a184@github.com>
 <kxFARHbjp2RuG0KrQNvBEn4cBH4jAnzi60M0mgvSJHY=.14720867-2e9a-45bd-bca4-fdb6d1d29bf7@github.com>
Message-ID: <dxNxPnUvsoTr-9nqH1maylkH2XgYeoO3fj8qXJNR4C0=.2ae27f8f-56cc-4a98-944b-ba5d417f74af@github.com>

On Tue, 4 Oct 2022 11:26:01 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Hi, please consider:
>> 
>> verify() is called by GC in safepoint so it should use the corresponding scanning method.
>> verify_and_compare_entries() can wait for until there is no resize.
>> 
>> This makes these methods always succeed, passes t1-t6.
>
> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed review comments

Marked as reviewed by dholmes (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10527

From dholmes at openjdk.org  Wed Oct  5 07:04:45 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 5 Oct 2022 07:04:45 GMT
Subject: RFR: 8282900: runtime/stringtable/StringTableCleaningTest.java
 verify unavailable at this moment [v2]
In-Reply-To: <XZBN3BLZ7pwraN_Rf0DH5CXcnOaAjLLXhBkYpqgk0cQ=.fd020d5d-a1b3-480a-b143-5c979db6acb0@github.com>
References: <rB06qYn4ntJNAAokUKRsDjEei1uzh7IsM2HBzndbmLM=.fac54cf9-2fee-49bb-9666-3c22c158a184@github.com>
 <q4ZHyOQS5thuGOiWx9NLLIQb0WC9OdgxFK9IBV_SQJk=.2f89e1ec-371b-4729-92a2-dd7c81c68170@github.com>
 <BBl0JCg0IBeag9QlaUUk-UZaTFnmtw_CIac8iqg1u6c=.ed251e30-7c45-4f60-98b4-8883da86485e@github.com>
 <9QbUkXULbzjhFE2OTLKgLKsvGOH2Ofnd3g_UEBOAOkY=.457b1bd9-4b1c-412c-be68-3260a6558bbc@github.com>
 <XZBN3BLZ7pwraN_Rf0DH5CXcnOaAjLLXhBkYpqgk0cQ=.fd020d5d-a1b3-480a-b143-5c979db6acb0@github.com>
Message-ID: <b3n_jOyvGkNKueEN5AK8PYul5XUIsASsC0GK13s5gkY=.c129e0b2-0e20-49bd-a17d-2bd66820405c@github.com>

On Wed, 5 Oct 2022 06:01:12 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> I thought did with

Sorry I seem to have developed a selective reading disorder :(

Thanks for explaining.

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

PR: https://git.openjdk.org/jdk/pull/10527

From jsjolen at openjdk.org  Wed Oct  5 08:56:33 2022
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 5 Oct 2022 08:56:33 GMT
Subject: RFR: 8294362: UL: Replace the internal usage of manual buffers
 with stringStream in LogSelection
In-Reply-To: <2bAfQEf8_dpaTkD8XXiAZ911GhinAu7_GPN48V0oj30=.dd622fb6-1dfd-476a-86cc-35af2ed1a16b@github.com>
References: <mUB0Ir5oWoGxE_mHp3IiZdObb96m4XFF5eFjDWq7IKo=.292a92ed-8957-4ae2-a930-2c942d7f3cc0@github.com>
 <2bAfQEf8_dpaTkD8XXiAZ911GhinAu7_GPN48V0oj30=.dd622fb6-1dfd-476a-86cc-35af2ed1a16b@github.com>
Message-ID: <ukkMuYaucnIbQxplZ2F5SItt3SKlk0CYCtd8A3dV2s0=.211fa9e2-3efb-48c8-b3cd-bc44b695120f@github.com>

On Wed, 5 Oct 2022 02:00:39 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This definitely seems simpler and cleaner, but raises the obvious question: why was it not done this way in the first place? Are there initialization issues/constraints with use of the stream classes?
> 
> I need to see if there is some historical info on the initial implementation here.
> 
> Thanks.

A guess: The features stringStream depended on used to not be available pre-initialization.

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

PR: https://git.openjdk.org/jdk/pull/10553

From rehn at openjdk.org  Wed Oct  5 09:41:16 2022
From: rehn at openjdk.org (Robbin Ehn)
Date: Wed, 5 Oct 2022 09:41:16 GMT
Subject: RFR: 8282900: runtime/stringtable/StringTableCleaningTest.java
 verify unavailable at this moment [v2]
In-Reply-To: <kxFARHbjp2RuG0KrQNvBEn4cBH4jAnzi60M0mgvSJHY=.14720867-2e9a-45bd-bca4-fdb6d1d29bf7@github.com>
References: <rB06qYn4ntJNAAokUKRsDjEei1uzh7IsM2HBzndbmLM=.fac54cf9-2fee-49bb-9666-3c22c158a184@github.com>
 <kxFARHbjp2RuG0KrQNvBEn4cBH4jAnzi60M0mgvSJHY=.14720867-2e9a-45bd-bca4-fdb6d1d29bf7@github.com>
Message-ID: <GmvSUpJFqFnGgrfSDTVjCVogxOV-HxnvbuJuZT9Lqw8=.8209db20-5415-4ed1-876b-039ab23bac3a@github.com>

On Tue, 4 Oct 2022 11:26:01 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Hi, please consider:
>> 
>> verify() is called by GC in safepoint so it should use the corresponding scanning method.
>> verify_and_compare_entries() can wait for until there is no resize.
>> 
>> This makes these methods always succeed, passes t1-t6.
>
> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed review comments

Thanks David and Coleen!

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

PR: https://git.openjdk.org/jdk/pull/10527

From rrich at openjdk.org  Wed Oct  5 10:12:21 2022
From: rrich at openjdk.org (Richard Reingruber)
Date: Wed, 5 Oct 2022 10:12:21 GMT
Subject: RFR: 8289925: Shared code shouldn't reference the platform
 specific method frame::interpreter_frame_last_sp() [v5]
In-Reply-To: <ajPsCcqYGI_Nnz_dazduYGlJUMRPkbm7vYZLX_2NZBI=.ae53a301-68bd-4668-8ca9-f1b06386e872@github.com>
References: <ajPsCcqYGI_Nnz_dazduYGlJUMRPkbm7vYZLX_2NZBI=.ae53a301-68bd-4668-8ca9-f1b06386e872@github.com>
Message-ID: <JmNuyUfSV7I5enW2pBq-u9ff4hOJrpuThLxYk41WLOk=.bd0d7d5c-6bbe-4a1d-944e-3f04eecd0001@github.com>

> The method `frame::interpreter_frame_last_sp()` is a platform method in the sense that it is not declared in a shared header file. It is declared and defined on some platforms though (x86 and aarch64 I think).
> 
> `frame::interpreter_frame_last_sp()` existed on these platforms before vm continuations (aka loom). Shared code that is part of the vm continuations implementation references it. This breaks the platform abstraction.
> 
> Using unextended_sp is problematic too because there are no guarantees by the platform abstraction layer for it. In fact unextended_sp < sp is possible on ppc64 and aarch64.
> 
> This fix changes the callers of is_sp_in_continuation()
> 
> ```c++
> static inline bool is_sp_in_continuation(const ContinuationEntry* entry, intptr_t* const sp) {
>   return entry->entry_sp() > sp;
> }
> 
> 
> to pass the actual sp. This is correct because the following is true on all platforms:
> 
> ```c++
> a.sp() > E->entry_sp() > b.sp() > c.sp()
> 
> 
> where `a`, `b`, `c` are stack frames in call order and `E` is a ContinuationEntry. `a` is the caller frame of the continuation entry frame that corresponds to `E`.
> 
> is_sp_in_continuation() will then return true for `b.sp()` and `c.sp()` and false for `a.sp()`
> 
> Testing: hotspot_loom and jdk_loom on x86_64 and aarch64.

Richard Reingruber 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'
 - Remove `Unimplemented` definitions of interpreter_frame_last_sp
 - Only pass the actual sp when calling is_sp_in_continuation()
 - Merge branch 'master'
 - Merge branch 'master'
 - Remove platform dependent method interpreter_frame_last_sp() from shared code

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9411/files
  - new: https://git.openjdk.org/jdk/pull/9411/files/14c97290..f49ecf54

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9411&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9411&range=03-04

  Stats: 41961 lines in 1346 files changed: 21873 ins; 13281 del; 6807 mod
  Patch: https://git.openjdk.org/jdk/pull/9411.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9411/head:pull/9411

PR: https://git.openjdk.org/jdk/pull/9411

From rkennke at openjdk.org  Wed Oct  5 11:45:11 2022
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 5 Oct 2022 11:45:11 GMT
Subject: RFR: 8292082: Deprecate UseRTM* for removal
In-Reply-To: <pxSjfr1d-IgFGcs02zerw5imYdkr8Qfbr8PO4B2CHJE=.60a76ccb-08f8-45a5-9dde-e2af420c2332@github.com>
References: <pxSjfr1d-IgFGcs02zerw5imYdkr8Qfbr8PO4B2CHJE=.60a76ccb-08f8-45a5-9dde-e2af420c2332@github.com>
Message-ID: <goPgdsh8a4ExVW2zqxMln5K2rZWbefQen-rmPL6uNb8=.217b656d-7b74-41e7-8389-1bf19636db1b@github.com>

On Tue, 9 Aug 2022 15:59:21 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> HotSpot supports RTM (restricted transactional memory) to be used for locking and deoptimization. RTM has since been disabled in Intel processors due to security vulnerabilities [0] and IBM removed support for it since its Power 10 line. RTM adds unnecessarily to complexity and maintenance burden.
> 
> I would like to propose to deprecate the relevant flags for removal, and actually remove the flags and all related code in a later release, unless somebody comes up with a good reason and performance comparison to show that it's worth keeping.
> 
> [0] https://en.wikipedia.org/wiki/Transactional_Synchronization_Extensions#History_and_bugs
> 
> Testing:
>  - [x] runtime/CommandLine/VMDeprecatedOptions.java
>  - [x] tier1

Is there interest in getting rid of RTM locking, or should I close this PR as won't-fix at this point?

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

PR: https://git.openjdk.org/jdk/pull/9810

From dholmes at openjdk.org  Wed Oct  5 12:17:08 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 5 Oct 2022 12:17:08 GMT
Subject: RFR: 8292082: Deprecate UseRTM* for removal
In-Reply-To: <pxSjfr1d-IgFGcs02zerw5imYdkr8Qfbr8PO4B2CHJE=.60a76ccb-08f8-45a5-9dde-e2af420c2332@github.com>
References: <pxSjfr1d-IgFGcs02zerw5imYdkr8Qfbr8PO4B2CHJE=.60a76ccb-08f8-45a5-9dde-e2af420c2332@github.com>
Message-ID: <lxR86cG5-HyBR6SAI360EByb_bnDXSI9H4ssRj5JGkw=.e5f07b7f-049c-4ed2-bd29-2f57a10152e3@github.com>

On Tue, 9 Aug 2022 15:59:21 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> HotSpot supports RTM (restricted transactional memory) to be used for locking and deoptimization. RTM has since been disabled in Intel processors due to security vulnerabilities [0] and IBM removed support for it since its Power 10 line. RTM adds unnecessarily to complexity and maintenance burden.
> 
> I would like to propose to deprecate the relevant flags for removal, and actually remove the flags and all related code in a later release, unless somebody comes up with a good reason and performance comparison to show that it's worth keeping.
> 
> [0] https://en.wikipedia.org/wiki/Transactional_Synchronization_Extensions#History_and_bugs
> 
> Testing:
>  - [x] runtime/CommandLine/VMDeprecatedOptions.java
>  - [x] tier1

As this still appears to be an active and useful feature there needs to be a strong motivation for removing it.

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

PR: https://git.openjdk.org/jdk/pull/9810

From rehn at openjdk.org  Wed Oct  5 12:43:20 2022
From: rehn at openjdk.org (Robbin Ehn)
Date: Wed, 5 Oct 2022 12:43:20 GMT
Subject: RFR: 8294362: UL: Replace the internal usage of manual buffers
 with stringStream in LogSelection
In-Reply-To: <mUB0Ir5oWoGxE_mHp3IiZdObb96m4XFF5eFjDWq7IKo=.292a92ed-8957-4ae2-a930-2c942d7f3cc0@github.com>
References: <mUB0Ir5oWoGxE_mHp3IiZdObb96m4XFF5eFjDWq7IKo=.292a92ed-8957-4ae2-a930-2c942d7f3cc0@github.com>
Message-ID: <RZjiG5I9odFftkFoVFU4G0j740JMiv2hRkj77tvMCf8=.d8ad1b87-0690-4ac0-9459-048c065d65a2@github.com>

On Tue, 4 Oct 2022 11:44:26 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Hi,
> 
> This is only a refactoring where the usage of manual character buffers are replaced with output streams, leading to much simpler code.

Look good.

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

Marked as reviewed by rehn (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10553

From rehn at openjdk.org  Wed Oct  5 12:50:13 2022
From: rehn at openjdk.org (Robbin Ehn)
Date: Wed, 5 Oct 2022 12:50:13 GMT
Subject: Integrated: 8282900: runtime/stringtable/StringTableCleaningTest.java
 verify unavailable at this moment
In-Reply-To: <rB06qYn4ntJNAAokUKRsDjEei1uzh7IsM2HBzndbmLM=.fac54cf9-2fee-49bb-9666-3c22c158a184@github.com>
References: <rB06qYn4ntJNAAokUKRsDjEei1uzh7IsM2HBzndbmLM=.fac54cf9-2fee-49bb-9666-3c22c158a184@github.com>
Message-ID: <hiHk2e5KMleDojV6m3G6F7olD6jhswBMqAIFuYKD9X0=.2f1da4ee-6b73-49e5-9732-8938690bb284@github.com>

On Mon, 3 Oct 2022 06:30:40 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> Hi, please consider:
> 
> verify() is called by GC in safepoint so it should use the corresponding scanning method.
> verify_and_compare_entries() can wait for until there is no resize.
> 
> This makes these methods always succeed, passes t1-t6.

This pull request has now been integrated.

Changeset: bd90c4cf
Author:    Robbin Ehn <rehn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bd90c4cfa63ba2de26f7482ed5d1704f9be9629f
Stats:     9 lines in 1 file changed: 1 ins; 6 del; 2 mod

8282900: runtime/stringtable/StringTableCleaningTest.java verify unavailable at this moment

Reviewed-by: coleenp, dholmes

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

PR: https://git.openjdk.org/jdk/pull/10527

From rrich at openjdk.org  Wed Oct  5 14:15:30 2022
From: rrich at openjdk.org (Richard Reingruber)
Date: Wed, 5 Oct 2022 14:15:30 GMT
Subject: Integrated: 8289925: Shared code shouldn't reference the platform
 specific method frame::interpreter_frame_last_sp()
In-Reply-To: <ajPsCcqYGI_Nnz_dazduYGlJUMRPkbm7vYZLX_2NZBI=.ae53a301-68bd-4668-8ca9-f1b06386e872@github.com>
References: <ajPsCcqYGI_Nnz_dazduYGlJUMRPkbm7vYZLX_2NZBI=.ae53a301-68bd-4668-8ca9-f1b06386e872@github.com>
Message-ID: <tNk5WHqR6ZNZQHSO0IfifCkZ6SaU3ff5-LPYpWyj9G0=.4117a5b9-d8b0-4724-9ef2-02ff04a0d7de@github.com>

On Thu, 7 Jul 2022 16:02:19 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> The method `frame::interpreter_frame_last_sp()` is a platform method in the sense that it is not declared in a shared header file. It is declared and defined on some platforms though (x86 and aarch64 I think).
> 
> `frame::interpreter_frame_last_sp()` existed on these platforms before vm continuations (aka loom). Shared code that is part of the vm continuations implementation references it. This breaks the platform abstraction.
> 
> Using unextended_sp is problematic too because there are no guarantees by the platform abstraction layer for it. In fact unextended_sp < sp is possible on ppc64 and aarch64.
> 
> This fix changes the callers of is_sp_in_continuation()
> 
> ```c++
> static inline bool is_sp_in_continuation(const ContinuationEntry* entry, intptr_t* const sp) {
>   return entry->entry_sp() > sp;
> }
> 
> 
> to pass the actual sp. This is correct because the following is true on all platforms:
> 
> ```c++
> a.sp() > E->entry_sp() > b.sp() > c.sp()
> 
> 
> where `a`, `b`, `c` are stack frames in call order and `E` is a ContinuationEntry. `a` is the caller frame of the continuation entry frame that corresponds to `E`.
> 
> is_sp_in_continuation() will then return true for `b.sp()` and `c.sp()` and false for `a.sp()`
> 
> Testing: hotspot_loom and jdk_loom on x86_64 and aarch64.

This pull request has now been integrated.

Changeset: ee6c3917
Author:    Richard Reingruber <rrich at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ee6c39175bc47608282c52c575ce908399349e7c
Stats:     31 lines in 7 files changed: 5 ins; 22 del; 4 mod

8289925: Shared code shouldn't reference the platform specific method frame::interpreter_frame_last_sp()

Reviewed-by: eosterlund, dlong

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

PR: https://git.openjdk.org/jdk/pull/9411

From shade at openjdk.org  Wed Oct  5 16:02:20 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 5 Oct 2022 16:02:20 GMT
Subject: RFR: 8294759: Print actual lock/monitor ranking [v2]
In-Reply-To: <OWmG-86gxFSht-26qctihYkIdKz3f8kI86Lum7e8Lw8=.2330c15f-7d5e-4811-a78c-7742d761e650@github.com>
References: <OWmG-86gxFSht-26qctihYkIdKz3f8kI86Lum7e8Lw8=.2330c15f-7d5e-4811-a78c-7742d761e650@github.com>
Message-ID: <wieel5l8ojDy2bFWReSioEDe49hhDs77I1OL7olwZK8=.eafcddfd-dae0-454e-9b5c-4f68670ef757@github.com>

> When relative lock ranks are changing, it is useful to see what are the final lock ranks are. It can be dumped as optional logging shortly after VM startup. 
> 
> Sample output:
> 
> 
> $ build/linux-x86_64-server-fastdebug/images/jdk/bin/java -Xlog:vmmutex
> [0.073s][info][vmmutex] VM Mutex/Monitor ranks: 
> [0.073s][info][vmmutex] 
> [0.073s][info][vmmutex] Rank "service-2":
> [0.073s][info][vmmutex]   Uncommit_lock
> [0.073s][info][vmmutex] 
> [0.073s][info][vmmutex] Rank "service-1":
> [0.073s][info][vmmutex]   FreeList_lock
> [0.073s][info][vmmutex]   MonitoringSupport_lock
> [0.073s][info][vmmutex] 
> [0.073s][info][vmmutex] Rank "service":
> [0.073s][info][vmmutex]   Service_lock
> [0.073s][info][vmmutex]   Notification_lock
> [0.073s][info][vmmutex] 
> [0.073s][info][vmmutex] Rank "stackwatermark-1":
> [0.073s][info][vmmutex]   JfrStacktrace_lock
> [0.073s][info][vmmutex] 
> [0.073s][info][vmmutex] Rank "tty-1":
> [0.073s][info][vmmutex]   SharedDecoder_lock
> [0.073s][info][vmmutex] 
> [0.073s][info][vmmutex] Rank "tty":
> [0.073s][info][vmmutex]   tty_lock
> [0.073s][info][vmmutex] 
> [0.073s][info][vmmutex] Rank "nosafepoint-3":
> [0.073s][info][vmmutex]   Metaspace_lock
> [0.073s][info][vmmutex]   JfrMsg_lock
> [0.073s][info][vmmutex]   ContinuationRelativize_lock
> [0.073s][info][vmmutex]   ThreadsSMRDelete_lock
> [0.073s][info][vmmutex]   CompiledMethod_lock
> [0.073s][info][vmmutex] 
> [0.073s][info][vmmutex] Rank "nosafepoint-2":
> [0.073s][info][vmmutex]   G1DetachedRefinementStats_lock
> [0.073s][info][vmmutex]   JmethodIdCreation_lock
> [0.073s][info][vmmutex]   CodeCache_lock
> [0.073s][info][vmmutex] 
> [0.073s][info][vmmutex] Rank "nosafepoint-1":
> [0.073s][info][vmmutex]   RootRegionScan_lock
> [0.073s][info][vmmutex]   RawMonitor_lock
> [0.073s][info][vmmutex]   MetaspaceCritical_lock
> [0.073s][info][vmmutex]   NonJavaThreadsList_lock
> [0.073s][info][vmmutex]   Zip_lock
> [0.073s][info][vmmutex]   InlineCacheBuffer_lock
> [0.073s][info][vmmutex]   VtableStubs_lock
> [0.073s][info][vmmutex] 
> [0.073s][info][vmmutex] Rank "nosafepoint":
> [0.073s][info][vmmutex]   STS_lock
> [0.073s][info][vmmutex]   CGC_lock
> [0.073s][info][vmmutex]   OldSets_lock
> [0.073s][info][vmmutex]   MarkStackFreeList_lock
> [0.073s][info][vmmutex]   MarkStackChunkList_lock
> [0.073s][info][vmmutex]   StringDedup_lock
> [0.073s][info][vmmutex]   StringDedupIntern_lock
> [0.073s][info][vmmutex]   Patching_lock
> [0.073s][info][vmmutex]   MonitorDeflation_lock
> [0.073s][info][vmmutex]   SymbolArena_lock
> [0.073s][info][vmmutex]   NonJavaThreadsListSync_lock
> [0.073s][info][vmmutex]   InitCompleted_lock
> [0.073s][info][vmmutex]   CompiledIC_lock
> [0.073s][info][vmmutex]   DirectivesStack_lock
> [0.073s][info][vmmutex]   EscapeBarrier_lock
> [0.073s][info][vmmutex]   JvmtiVTMSTransition_lock
> [0.073s][info][vmmutex]   JfrBuffer_lock
> [0.073s][info][vmmutex]   JfrThreadSampler_lock
> [0.073s][info][vmmutex]   DCmdFactory_lock
> [0.073s][info][vmmutex]   DumpTimeTable_lock
> [0.073s][info][vmmutex]   CDSLambda_lock
> [0.073s][info][vmmutex]   DumpRegion_lock
> [0.073s][info][vmmutex]   ClassListFile_lock
> [0.073s][info][vmmutex]   Bootclasspath_lock
> [0.073s][info][vmmutex] 
> [0.073s][info][vmmutex] Rank "safepoint-3":
> [0.073s][info][vmmutex]   PerfDataMemAlloc_lock
> [0.073s][info][vmmutex]   PerfDataManager_lock
> [0.073s][info][vmmutex]   VMOperation_lock
> [0.073s][info][vmmutex]   SystemDictionary_lock
> [0.073s][info][vmmutex] 
> [0.073s][info][vmmutex] Rank "safepoint-2":
> [0.073s][info][vmmutex]   Heap_lock
> [0.073s][info][vmmutex]   ClassInitError_lock
> [0.073s][info][vmmutex]   G1OldGCCount_lock
> [0.073s][info][vmmutex]   ParGCRareEvent_lock
> [0.073s][info][vmmutex]   OopMapCacheAlloc_lock
> [0.073s][info][vmmutex]   Module_lock
> [0.073s][info][vmmutex] 
> [0.073s][info][vmmutex] Rank "safepoint-1":
> [0.073s][info][vmmutex]   Threads_lock
> [0.073s][info][vmmutex]   Compile_lock
> [0.073s][info][vmmutex]   AdapterHandlerLibrary_lock
> [0.073s][info][vmmutex]   ClassLoaderDataGraph_lock
> [0.073s][info][vmmutex]   CompileTaskAlloc_lock
> [0.073s][info][vmmutex]   JNICritical_lock
> [0.073s][info][vmmutex]   JVMCI_lock
> [0.073s][info][vmmutex] 
> [0.073s][info][vmmutex] Rank "safepoint":
> [0.073s][info][vmmutex]   InvokeMethodTable_lock
> [0.073s][info][vmmutex]   SharedDictionary_lock
> [0.073s][info][vmmutex]   VMStatistic_lock
> [0.073s][info][vmmutex]   SignatureHandlerLibrary_lock
> [0.073s][info][vmmutex]   ExceptionCache_lock
> [0.073s][info][vmmutex]   FullGCALot_lock
> [0.073s][info][vmmutex]   BeforeExit_lock
> [0.073s][info][vmmutex]   RetData_lock
> [0.073s][info][vmmutex]   Terminator_lock
> [0.073s][info][vmmutex]   Notify_lock
> [0.073s][info][vmmutex]   Heap_lock
> [0.073s][info][vmmutex]   JfieldIdCreation_lock
> [0.073s][info][vmmutex]   MethodCompileQueue_lock
> [0.073s][info][vmmutex]   CompileStatistics_lock
> [0.073s][info][vmmutex]   MultiArray_lock
> [0.073s][info][vmmutex]   JvmtiThreadState_lock
> [0.073s][info][vmmutex]   Management_lock
> [0.073s][info][vmmutex]   ConcurrentGCBreakpoints_lock
> [0.073s][info][vmmutex]   MethodData_lock
> [0.073s][info][vmmutex]   TouchedMethodLog_lock
> [0.073s][info][vmmutex]   CompileThread_lock
> [0.073s][info][vmmutex]   PeriodicTask_lock
> [0.073s][info][vmmutex]   RedefineClasses_lock
> [0.073s][info][vmmutex]   Verify_lock
> [0.073s][info][vmmutex]   CodeHeapStateAnalytics_lock
> [0.073s][info][vmmutex]   ThreadIdTableCreate_lock
> [0.073s][info][vmmutex]   NMTQuery_lock
> [0.073s][info][vmmutex]   CDSClassFileStream_lock
> [0.073s][info][vmmutex]   LambdaFormInvokers_lock
> [0.073s][info][vmmutex]   JVMCIRuntime_lock
> 
> 
> Additional testing:
>  - [x] New test on Linux x86_64 {release,fastdebug,slowdebug}

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10556/files
  - new: https://git.openjdk.org/jdk/pull/10556/files/161cf501..1a6655c6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10556&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10556&range=00-01

  Stats: 5 lines in 1 file changed: 2 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10556.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10556/head:pull/10556

PR: https://git.openjdk.org/jdk/pull/10556

From shade at openjdk.org  Wed Oct  5 16:02:22 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 5 Oct 2022 16:02:22 GMT
Subject: RFR: 8294759: Print actual lock/monitor ranking [v2]
In-Reply-To: <eKMrOT-LhUXW36WVUFglAQf0t1VYhd2neVsqLquukhc=.60df170e-94b1-4b9c-a638-d8639f5e0826@github.com>
References: <OWmG-86gxFSht-26qctihYkIdKz3f8kI86Lum7e8Lw8=.2330c15f-7d5e-4811-a78c-7742d761e650@github.com>
 <eKMrOT-LhUXW36WVUFglAQf0t1VYhd2neVsqLquukhc=.60df170e-94b1-4b9c-a638-d8639f5e0826@github.com>
Message-ID: <o8XLu6FehYAXvuw7H4_wSH3U7Rzra46HIuhh3PeWQbU=.f2942394-5f05-4def-b942-8c4658d55ff7@github.com>

On Wed, 5 Oct 2022 04:11:40 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Comments
>
> src/hotspot/share/runtime/mutexLocker.cpp line 427:
> 
>> 425: 
>> 426: void print_lock_ranks(outputStream* st) {
>> 427:   st->print_cr("VM Mutex/Monitor ranks: ");
> 
> Do we want to clarify this is not the complete set of Mutexes in the VM?

hs_err does not clarify this in the similar printout ("VM Mutex/Monitor currently owned by a thread: " in the method above), so it seems to be implied these are only the known mutexes. So, I left it as is.

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

PR: https://git.openjdk.org/jdk/pull/10556

From shade at openjdk.org  Wed Oct  5 16:14:44 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 5 Oct 2022 16:14:44 GMT
Subject: RFR: 8294759: Print actual lock/monitor ranking [v3]
In-Reply-To: <OWmG-86gxFSht-26qctihYkIdKz3f8kI86Lum7e8Lw8=.2330c15f-7d5e-4811-a78c-7742d761e650@github.com>
References: <OWmG-86gxFSht-26qctihYkIdKz3f8kI86Lum7e8Lw8=.2330c15f-7d5e-4811-a78c-7742d761e650@github.com>
Message-ID: <280S0zDZr4mWj8sTMWQJYO5V5T9TJ2Bxg8luMYojjYc=.097345b8-63bd-4e99-9125-b19dc051f413@github.com>

> When relative lock ranks are changing, it is useful to see what are the final lock ranks are. It can be dumped as optional logging shortly after VM startup. 
> 
> Sample output:
> 
> 
> $ build/linux-x86_64-server-fastdebug/images/jdk/bin/java -Xlog:vmmutex
> [0.073s][info][vmmutex] VM Mutex/Monitor ranks: 
> [0.073s][info][vmmutex] 
> [0.073s][info][vmmutex] Rank "service-2":
> [0.073s][info][vmmutex]   Uncommit_lock
> [0.073s][info][vmmutex] 
> [0.073s][info][vmmutex] Rank "service-1":
> [0.073s][info][vmmutex]   FreeList_lock
> [0.073s][info][vmmutex]   MonitoringSupport_lock
> [0.073s][info][vmmutex] 
> [0.073s][info][vmmutex] Rank "service":
> [0.073s][info][vmmutex]   Service_lock
> [0.073s][info][vmmutex]   Notification_lock
> [0.073s][info][vmmutex] 
> [0.073s][info][vmmutex] Rank "stackwatermark-1":
> [0.073s][info][vmmutex]   JfrStacktrace_lock
> [0.073s][info][vmmutex] 
> [0.073s][info][vmmutex] Rank "tty-1":
> [0.073s][info][vmmutex]   SharedDecoder_lock
> [0.073s][info][vmmutex] 
> [0.073s][info][vmmutex] Rank "tty":
> [0.073s][info][vmmutex]   tty_lock
> [0.073s][info][vmmutex] 
> [0.073s][info][vmmutex] Rank "nosafepoint-3":
> [0.073s][info][vmmutex]   Metaspace_lock
> [0.073s][info][vmmutex]   JfrMsg_lock
> [0.073s][info][vmmutex]   ContinuationRelativize_lock
> [0.073s][info][vmmutex]   ThreadsSMRDelete_lock
> [0.073s][info][vmmutex]   CompiledMethod_lock
> [0.073s][info][vmmutex] 
> [0.073s][info][vmmutex] Rank "nosafepoint-2":
> [0.073s][info][vmmutex]   G1DetachedRefinementStats_lock
> [0.073s][info][vmmutex]   JmethodIdCreation_lock
> [0.073s][info][vmmutex]   CodeCache_lock
> [0.073s][info][vmmutex] 
> [0.073s][info][vmmutex] Rank "nosafepoint-1":
> [0.073s][info][vmmutex]   RootRegionScan_lock
> [0.073s][info][vmmutex]   RawMonitor_lock
> [0.073s][info][vmmutex]   MetaspaceCritical_lock
> [0.073s][info][vmmutex]   NonJavaThreadsList_lock
> [0.073s][info][vmmutex]   Zip_lock
> [0.073s][info][vmmutex]   InlineCacheBuffer_lock
> [0.073s][info][vmmutex]   VtableStubs_lock
> [0.073s][info][vmmutex] 
> [0.073s][info][vmmutex] Rank "nosafepoint":
> [0.073s][info][vmmutex]   STS_lock
> [0.073s][info][vmmutex]   CGC_lock
> [0.073s][info][vmmutex]   OldSets_lock
> [0.073s][info][vmmutex]   MarkStackFreeList_lock
> [0.073s][info][vmmutex]   MarkStackChunkList_lock
> [0.073s][info][vmmutex]   StringDedup_lock
> [0.073s][info][vmmutex]   StringDedupIntern_lock
> [0.073s][info][vmmutex]   Patching_lock
> [0.073s][info][vmmutex]   MonitorDeflation_lock
> [0.073s][info][vmmutex]   SymbolArena_lock
> [0.073s][info][vmmutex]   NonJavaThreadsListSync_lock
> [0.073s][info][vmmutex]   InitCompleted_lock
> [0.073s][info][vmmutex]   CompiledIC_lock
> [0.073s][info][vmmutex]   DirectivesStack_lock
> [0.073s][info][vmmutex]   EscapeBarrier_lock
> [0.073s][info][vmmutex]   JvmtiVTMSTransition_lock
> [0.073s][info][vmmutex]   JfrBuffer_lock
> [0.073s][info][vmmutex]   JfrThreadSampler_lock
> [0.073s][info][vmmutex]   DCmdFactory_lock
> [0.073s][info][vmmutex]   DumpTimeTable_lock
> [0.073s][info][vmmutex]   CDSLambda_lock
> [0.073s][info][vmmutex]   DumpRegion_lock
> [0.073s][info][vmmutex]   ClassListFile_lock
> [0.073s][info][vmmutex]   Bootclasspath_lock
> [0.073s][info][vmmutex] 
> [0.073s][info][vmmutex] Rank "safepoint-3":
> [0.073s][info][vmmutex]   PerfDataMemAlloc_lock
> [0.073s][info][vmmutex]   PerfDataManager_lock
> [0.073s][info][vmmutex]   VMOperation_lock
> [0.073s][info][vmmutex]   SystemDictionary_lock
> [0.073s][info][vmmutex] 
> [0.073s][info][vmmutex] Rank "safepoint-2":
> [0.073s][info][vmmutex]   Heap_lock
> [0.073s][info][vmmutex]   ClassInitError_lock
> [0.073s][info][vmmutex]   G1OldGCCount_lock
> [0.073s][info][vmmutex]   ParGCRareEvent_lock
> [0.073s][info][vmmutex]   OopMapCacheAlloc_lock
> [0.073s][info][vmmutex]   Module_lock
> [0.073s][info][vmmutex] 
> [0.073s][info][vmmutex] Rank "safepoint-1":
> [0.073s][info][vmmutex]   Threads_lock
> [0.073s][info][vmmutex]   Compile_lock
> [0.073s][info][vmmutex]   AdapterHandlerLibrary_lock
> [0.073s][info][vmmutex]   ClassLoaderDataGraph_lock
> [0.073s][info][vmmutex]   CompileTaskAlloc_lock
> [0.073s][info][vmmutex]   JNICritical_lock
> [0.073s][info][vmmutex]   JVMCI_lock
> [0.073s][info][vmmutex] 
> [0.073s][info][vmmutex] Rank "safepoint":
> [0.073s][info][vmmutex]   InvokeMethodTable_lock
> [0.073s][info][vmmutex]   SharedDictionary_lock
> [0.073s][info][vmmutex]   VMStatistic_lock
> [0.073s][info][vmmutex]   SignatureHandlerLibrary_lock
> [0.073s][info][vmmutex]   ExceptionCache_lock
> [0.073s][info][vmmutex]   FullGCALot_lock
> [0.073s][info][vmmutex]   BeforeExit_lock
> [0.073s][info][vmmutex]   RetData_lock
> [0.073s][info][vmmutex]   Terminator_lock
> [0.073s][info][vmmutex]   Notify_lock
> [0.073s][info][vmmutex]   Heap_lock
> [0.073s][info][vmmutex]   JfieldIdCreation_lock
> [0.073s][info][vmmutex]   MethodCompileQueue_lock
> [0.073s][info][vmmutex]   CompileStatistics_lock
> [0.073s][info][vmmutex]   MultiArray_lock
> [0.073s][info][vmmutex]   JvmtiThreadState_lock
> [0.073s][info][vmmutex]   Management_lock
> [0.073s][info][vmmutex]   ConcurrentGCBreakpoints_lock
> [0.073s][info][vmmutex]   MethodData_lock
> [0.073s][info][vmmutex]   TouchedMethodLog_lock
> [0.073s][info][vmmutex]   CompileThread_lock
> [0.073s][info][vmmutex]   PeriodicTask_lock
> [0.073s][info][vmmutex]   RedefineClasses_lock
> [0.073s][info][vmmutex]   Verify_lock
> [0.073s][info][vmmutex]   CodeHeapStateAnalytics_lock
> [0.073s][info][vmmutex]   ThreadIdTableCreate_lock
> [0.073s][info][vmmutex]   NMTQuery_lock
> [0.073s][info][vmmutex]   CDSClassFileStream_lock
> [0.073s][info][vmmutex]   LambdaFormInvokers_lock
> [0.073s][info][vmmutex]   JVMCIRuntime_lock
> 
> 
> Additional testing:
>  - [x] New test on Linux x86_64 {release,fastdebug,slowdebug}

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  More comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10556/files
  - new: https://git.openjdk.org/jdk/pull/10556/files/1a6655c6..5aab4a75

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10556&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10556&range=01-02

  Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10556.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10556/head:pull/10556

PR: https://git.openjdk.org/jdk/pull/10556

From shade at openjdk.org  Wed Oct  5 16:14:45 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 5 Oct 2022 16:14:45 GMT
Subject: RFR: 8294759: Print actual lock/monitor ranking [v3]
In-Reply-To: <owyW4UuVRmQsk0N52Q2G850PPw_vthF_vCfCJOw-2Y4=.1d968544-d33a-4b53-8b36-506a4ce7fe9a@github.com>
References: <OWmG-86gxFSht-26qctihYkIdKz3f8kI86Lum7e8Lw8=.2330c15f-7d5e-4811-a78c-7742d761e650@github.com>
 <IVKtRZCD334u9fT64KZZ4M4u531zSm7Wkx4g__6S14g=.ef2e7590-5ca8-4716-81f2-113f4ddce069@github.com>
 <2cJQ_XYvvSMoqDDmu6tK6VFQUQ6PmFspKKSn88Gbw-w=.21f2e25e-9d64-44fa-8f8f-8aec324d00a0@github.com>
 <owyW4UuVRmQsk0N52Q2G850PPw_vthF_vCfCJOw-2Y4=.1d968544-d33a-4b53-8b36-506a4ce7fe9a@github.com>
Message-ID: <Uxu61AYgRjcsnSmqIT8dvH224WYqLge1SgfLvaAnQG8=.3173ba8c-2e6b-47bb-a616-22c90a3fd228@github.com>

On Tue, 4 Oct 2022 21:49:42 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Ah, I was being defensive about this: computing min/max without relying on the actual `Rank` definition. While `0` is plausibly the lowest rank, I don't really want to rely on `safepoint` being the last rank. This is debugging code, so we can spend some time on this. Makes sense?
>
> All the other code in this file thinks safepoint is the last rank (it's an invariant) and INT_MAX is a bit large even for debugging code.  I think safepoint would be better. I marked it as reviewed so am not really insistent., but it looked weird to me.

Yeah, I can now see the `Mutex` constructor asserts the rank is within (0...safepoint). But it still feels a bit fragile to rely on, so I left it as is. This debugging code, we better off overdoing stuff rather than misleading developers. I added a few comments, though!

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

PR: https://git.openjdk.org/jdk/pull/10556

From johan.sjolen at oracle.com  Wed Oct  5 16:15:21 2022
From: johan.sjolen at oracle.com (=?UTF-8?B?Sm9oYW4gU2rDtmzDqW4=?=)
Date: Wed, 5 Oct 2022 18:15:21 +0200
Subject: Proposal of Outputting Unified Logging to TCP socket
In-Reply-To: <b7b8a4524752e2ebc34f2d7930e68c7b@oss.nttdata.com>
References: <b7b8a4524752e2ebc34f2d7930e68c7b@oss.nttdata.com>
Message-ID: <6218e95d-57d9-fd05-ede9-9d01c7bf34e6@oracle.com>

On 2022-10-04 16:21, Koichi Sakata wrote:
> Hello,
> 
> I would like to propose outputting unified logging (UL) to the TCP 
> socket. I know that this has been discussed before [1]. However, 
> circumstances have changed. Asynchronous logging was added to UL. If we 
> output logs to TCP with async mode, we will be able to solve some issues 
> raised in the past discussion (e.g. lag of log() calls). So I will take 
> up this subject again.
> 
> This feature is useful, especially in the container environment. Take 
> Kubernetes for example, there are many containers. It is recommended 
> that containers send logs to standard output, but the mixture of Java 
> application logs and UL logs in stdout is not handy to parse or search 
> in a log aggregator like Elasticsearch. I believe that it's beneficial 
> to deal with each type of log individually.
> 
> When we have files of UL logs, we have another issue. That is where to 
> persist those files. As you know, we lose logs when pods are removed. I 
> would rather not use volumes like Persistent Volume because of the cost 
> of using volumes and the effort of managing files. When using the 
> volume, we need to determine the file size and the volume size and put 
> many log files of containers in it.
> 
> UL via TCP socket answers these issues. In the Kubernetes example, we 
> use a log forwarder like Fluent Bit, Filebeat or something as a 
> DaemonSet. It gets UL logs from the socket, gets application logs from 
> stdout, and sends each log to corresponding log aggregators. As a 
> result, we don't have UL log files and volumes to persist them anymore. 
> This is premised on asynchronous logging. So the lag will not be a 
> problem, I think.
> 
> For these reasons, I would like to propose outputting UL logs to TCP 
> inputs. It seems to be unnecessary for traditional java applications, 
> but it's of great use for applications in container environments. This 
> makes it easier to build and operate applications on Kubernetes. There 
> is also a bonus that this is os independent.
> 
> I will create a prototype of this proposal if it is worth trying.
> 
> By the way, there is a network stream class that is used to send node 
> information to Ideal Graph Visualizer via socket. I'm not sure whether 
> we can divert it or not for this new feature.
> 
> Best Regards,
> Koichi Sakata
> 
> [1] 
> https://mail.openjdk.org/pipermail/hotspot-runtime-dev/2020-November/043221.html 
> 

Hi Koichi Sokata,

Thank you for your suggestion. I think that you're right, UL is in a 
better position to accept TCP sockets as output devices now than it was 
previously thanks to the introduction of asynchronous logging. However, 
I am skeptical to the idea of adding these to UL. It creates a rather 
large attack vector for us, it also creates a maintenance burden and 
finally getting this right for everyone is probably close to impossible.

Please note that the Ideal Graph Visualizer is a debug tool, it is not 
meant for use in production. Therefore, its requirements are very 
different to UL, which needs to be robust.

My suggestion would be to use an external tool. The most basic of these 
would look like this:

Process 0:
$ run_tcp_server localhost 4040
Process 1:
$ mkfifo my.log
$ tail -f my.log | netcat localhost 4040
Process 2:
$ java -Xlog:disable -Xlog::my.log

Where the initial -Xlog:disable disables any default configuration which 
would output to stdout.

I am sure that there are more sophisticated tools which works 
essentially like this.

Best regards,
Johan Sj?l?n

From kvn at openjdk.org  Wed Oct  5 16:29:17 2022
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 5 Oct 2022 16:29:17 GMT
Subject: RFR: 8292082: Deprecate UseRTM* for removal
In-Reply-To: <goPgdsh8a4ExVW2zqxMln5K2rZWbefQen-rmPL6uNb8=.217b656d-7b74-41e7-8389-1bf19636db1b@github.com>
References: <pxSjfr1d-IgFGcs02zerw5imYdkr8Qfbr8PO4B2CHJE=.60a76ccb-08f8-45a5-9dde-e2af420c2332@github.com>
 <goPgdsh8a4ExVW2zqxMln5K2rZWbefQen-rmPL6uNb8=.217b656d-7b74-41e7-8389-1bf19636db1b@github.com>
Message-ID: <8iHwQuxxDk3yIiutiD8L7OD_lCdDkxiQpJNRPTwbzp8=.8549ee2b-39a3-409b-8dcc-5e1f5df6fdaa@github.com>

On Wed, 5 Oct 2022 11:41:46 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Is there interest in getting rid of RTM locking, or should I close this PR as won't-fix at this point?

Close PR.

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

PR: https://git.openjdk.org/jdk/pull/9810

From rkennke at openjdk.org  Wed Oct  5 16:43:24 2022
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 5 Oct 2022 16:43:24 GMT
Subject: RFR: 8292082: Deprecate UseRTM* for removal
In-Reply-To: <pxSjfr1d-IgFGcs02zerw5imYdkr8Qfbr8PO4B2CHJE=.60a76ccb-08f8-45a5-9dde-e2af420c2332@github.com>
References: <pxSjfr1d-IgFGcs02zerw5imYdkr8Qfbr8PO4B2CHJE=.60a76ccb-08f8-45a5-9dde-e2af420c2332@github.com>
Message-ID: <90DoIIUnU1W3qMXrCM2nmiHZKyQyamTOvFhp9A61D8g=.6b700db7-cff3-4a46-9137-6ba25eff27a4@github.com>

On Tue, 9 Aug 2022 15:59:21 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> HotSpot supports RTM (restricted transactional memory) to be used for locking and deoptimization. RTM has since been disabled in Intel processors due to security vulnerabilities [0] and IBM removed support for it since its Power 10 line. RTM adds unnecessarily to complexity and maintenance burden.
> 
> I would like to propose to deprecate the relevant flags for removal, and actually remove the flags and all related code in a later release, unless somebody comes up with a good reason and performance comparison to show that it's worth keeping.
> 
> [0] https://en.wikipedia.org/wiki/Transactional_Synchronization_Extensions#History_and_bugs
> 
> Testing:
>  - [x] runtime/CommandLine/VMDeprecatedOptions.java
>  - [x] tier1

Closing, will keep RTM locking for the time being.

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

PR: https://git.openjdk.org/jdk/pull/9810

From rkennke at openjdk.org  Wed Oct  5 16:43:25 2022
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 5 Oct 2022 16:43:25 GMT
Subject: Withdrawn: 8292082: Deprecate UseRTM* for removal
In-Reply-To: <pxSjfr1d-IgFGcs02zerw5imYdkr8Qfbr8PO4B2CHJE=.60a76ccb-08f8-45a5-9dde-e2af420c2332@github.com>
References: <pxSjfr1d-IgFGcs02zerw5imYdkr8Qfbr8PO4B2CHJE=.60a76ccb-08f8-45a5-9dde-e2af420c2332@github.com>
Message-ID: <t4KXwJEO39IcPZs2wuZL18_YfljdpC2-nYwrURXDu94=.7ccdd434-6a29-4689-a073-0a69d83fe254@github.com>

On Tue, 9 Aug 2022 15:59:21 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> HotSpot supports RTM (restricted transactional memory) to be used for locking and deoptimization. RTM has since been disabled in Intel processors due to security vulnerabilities [0] and IBM removed support for it since its Power 10 line. RTM adds unnecessarily to complexity and maintenance burden.
> 
> I would like to propose to deprecate the relevant flags for removal, and actually remove the flags and all related code in a later release, unless somebody comes up with a good reason and performance comparison to show that it's worth keeping.
> 
> [0] https://en.wikipedia.org/wiki/Transactional_Synchronization_Extensions#History_and_bugs
> 
> Testing:
>  - [x] runtime/CommandLine/VMDeprecatedOptions.java
>  - [x] tier1

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/9810

From iklam at openjdk.org  Wed Oct  5 16:45:16 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 5 Oct 2022 16:45:16 GMT
Subject: RFR: 8294751: Zero: Allow larger default heaps
In-Reply-To: <onIurPQPJzorzHjZNvhxPk12j0zySZeRR1rid9KW0Yg=.e42155f8-d8af-4496-b72b-350e1dbf8e09@github.com>
References: <onIurPQPJzorzHjZNvhxPk12j0zySZeRR1rid9KW0Yg=.e42155f8-d8af-4496-b72b-350e1dbf8e09@github.com>
Message-ID: <kftwqlAjrGBSwaZl7pzJKawOtkL-ao8afogSQyNgfAo=.01f133c0-359a-43f6-ac90-71af19dbf0fc@github.com>

On Tue, 4 Oct 2022 09:37:48 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Zero is currently defaulting to `MaxRAM=1G` on all machines. It is set in `compiler_globals.pd` under `#if !defined(COMPILER1) && !defined(COMPILER2) && !INCLUDE_JVMCI`.
> 
> Zero supports lots of GCs, and there is little sense to penalize it unnecessarily with too small heaps. After [JDK-8292847](https://bugs.openjdk.org/browse/JDK-8292847), this would allow G1 with reasonable heap size on most machines.
> 
> Motivational improvements, `SPECjvm2008:serial`:
> 
> 
> # Baseline, G1
> Serial.test  thrpt   10  1619.863 ? 16.694  ops/s
> 
> # Baseline, Serial
> Serial.test  thrpt   10  1094.438 ? 20.425  ops/s
> 
> # Patched, G1
> Serial.test  thrpt   10  1623.090 ? 17.553  ops/s
> 
> # Patched, Serial
> Serial.test  thrpt   10  1624.531 ? 15.792  ops/s  ; <---- matches G1 now, because young is not tiny
> 
> 
> Before:
> 
> 
> $ build/linux-x86_64-zero-release/jdk/bin/java -Xlog:gc -Xlog:gc+init Alloc.java
> [0.003s][info][gc     ] Using G1
> ...
> [0.005s][info][gc,init] Memory: 125G
> ...
> [0.005s][info][gc,init] Heap Region Size: 1M
> [0.005s][info][gc,init] Heap Min Capacity: 8M
> [0.005s][info][gc,init] Heap Initial Capacity: 16M
> [0.005s][info][gc,init] Heap Max Capacity: 256M
> 
> 
> After:
> 
> 
> $ build/linux-x86_64-zero-release/jdk/bin/java -Xlog:gc -Xlog:gc+init Alloc.java
> [0.003s][info][gc     ] Using G1
> ...
> [0.007s][info][gc,init] Memory: 125G
> ...
> [0.007s][info][gc,init] Heap Region Size: 16M
> [0.007s][info][gc,init] Heap Min Capacity: 16M
> [0.007s][info][gc,init] Heap Initial Capacity: 2016M
> [0.007s][info][gc,init] Heap Max Capacity: 30208M

Do we need to overhaul the other combinations as well? I don't see why we have to artificially limit the heap sizes. Here's the pd value for MaxRAM, which is defined identically for all platforms:

- no C2  = 1GB
- C2 on 32-bit = 4GB
- C2 on 64-bit = 128 GB

Also, if you want to do it for only ZERO for now, I think it's better to set the value inside compiler_globals_pd.hpp


#ifdef ZERO
define_pd_global(uint64_t,MaxRAM,                    128ULL*G);
#else 
define_pd_global(uint64_t,MaxRAM,                    1ULL*G);
#endif

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

PR: https://git.openjdk.org/jdk/pull/10552

From coleenp at openjdk.org  Wed Oct  5 17:47:08 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 5 Oct 2022 17:47:08 GMT
Subject: RFR: 8294759: Print actual lock/monitor ranking [v3]
In-Reply-To: <280S0zDZr4mWj8sTMWQJYO5V5T9TJ2Bxg8luMYojjYc=.097345b8-63bd-4e99-9125-b19dc051f413@github.com>
References: <OWmG-86gxFSht-26qctihYkIdKz3f8kI86Lum7e8Lw8=.2330c15f-7d5e-4811-a78c-7742d761e650@github.com>
 <280S0zDZr4mWj8sTMWQJYO5V5T9TJ2Bxg8luMYojjYc=.097345b8-63bd-4e99-9125-b19dc051f413@github.com>
Message-ID: <K6Vx5QJ8MDoXeajNnE8rKbFh3lknbWP80Mlv_kbo5TY=.76b5050d-715b-4403-a975-bb4ac56c3448@github.com>

On Wed, 5 Oct 2022 16:14:44 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> When relative lock ranks are changing, it is useful to see what are the final lock ranks are. It can be dumped as optional logging shortly after VM startup. 
>> 
>> Sample output:
>> 
>> 
>> $ build/linux-x86_64-server-fastdebug/images/jdk/bin/java -Xlog:vmmutex
>> [0.073s][info][vmmutex] VM Mutex/Monitor ranks: 
>> [0.073s][info][vmmutex] 
>> [0.073s][info][vmmutex] Rank "service-2":
>> [0.073s][info][vmmutex]   Uncommit_lock
>> [0.073s][info][vmmutex] 
>> [0.073s][info][vmmutex] Rank "service-1":
>> [0.073s][info][vmmutex]   FreeList_lock
>> [0.073s][info][vmmutex]   MonitoringSupport_lock
>> [0.073s][info][vmmutex] 
>> [0.073s][info][vmmutex] Rank "service":
>> [0.073s][info][vmmutex]   Service_lock
>> [0.073s][info][vmmutex]   Notification_lock
>> [0.073s][info][vmmutex] 
>> [0.073s][info][vmmutex] Rank "stackwatermark-1":
>> [0.073s][info][vmmutex]   JfrStacktrace_lock
>> [0.073s][info][vmmutex] 
>> [0.073s][info][vmmutex] Rank "tty-1":
>> [0.073s][info][vmmutex]   SharedDecoder_lock
>> [0.073s][info][vmmutex] 
>> [0.073s][info][vmmutex] Rank "tty":
>> [0.073s][info][vmmutex]   tty_lock
>> [0.073s][info][vmmutex] 
>> [0.073s][info][vmmutex] Rank "nosafepoint-3":
>> [0.073s][info][vmmutex]   Metaspace_lock
>> [0.073s][info][vmmutex]   JfrMsg_lock
>> [0.073s][info][vmmutex]   ContinuationRelativize_lock
>> [0.073s][info][vmmutex]   ThreadsSMRDelete_lock
>> [0.073s][info][vmmutex]   CompiledMethod_lock
>> [0.073s][info][vmmutex] 
>> [0.073s][info][vmmutex] Rank "nosafepoint-2":
>> [0.073s][info][vmmutex]   G1DetachedRefinementStats_lock
>> [0.073s][info][vmmutex]   JmethodIdCreation_lock
>> [0.073s][info][vmmutex]   CodeCache_lock
>> [0.073s][info][vmmutex] 
>> [0.073s][info][vmmutex] Rank "nosafepoint-1":
>> [0.073s][info][vmmutex]   RootRegionScan_lock
>> [0.073s][info][vmmutex]   RawMonitor_lock
>> [0.073s][info][vmmutex]   MetaspaceCritical_lock
>> [0.073s][info][vmmutex]   NonJavaThreadsList_lock
>> [0.073s][info][vmmutex]   Zip_lock
>> [0.073s][info][vmmutex]   InlineCacheBuffer_lock
>> [0.073s][info][vmmutex]   VtableStubs_lock
>> [0.073s][info][vmmutex] 
>> [0.073s][info][vmmutex] Rank "nosafepoint":
>> [0.073s][info][vmmutex]   STS_lock
>> [0.073s][info][vmmutex]   CGC_lock
>> [0.073s][info][vmmutex]   OldSets_lock
>> [0.073s][info][vmmutex]   MarkStackFreeList_lock
>> [0.073s][info][vmmutex]   MarkStackChunkList_lock
>> [0.073s][info][vmmutex]   StringDedup_lock
>> [0.073s][info][vmmutex]   StringDedupIntern_lock
>> [0.073s][info][vmmutex]   Patching_lock
>> [0.073s][info][vmmutex]   MonitorDeflation_lock
>> [0.073s][info][vmmutex]   SymbolArena_lock
>> [0.073s][info][vmmutex]   NonJavaThreadsListSync_lock
>> [0.073s][info][vmmutex]   InitCompleted_lock
>> [0.073s][info][vmmutex]   CompiledIC_lock
>> [0.073s][info][vmmutex]   DirectivesStack_lock
>> [0.073s][info][vmmutex]   EscapeBarrier_lock
>> [0.073s][info][vmmutex]   JvmtiVTMSTransition_lock
>> [0.073s][info][vmmutex]   JfrBuffer_lock
>> [0.073s][info][vmmutex]   JfrThreadSampler_lock
>> [0.073s][info][vmmutex]   DCmdFactory_lock
>> [0.073s][info][vmmutex]   DumpTimeTable_lock
>> [0.073s][info][vmmutex]   CDSLambda_lock
>> [0.073s][info][vmmutex]   DumpRegion_lock
>> [0.073s][info][vmmutex]   ClassListFile_lock
>> [0.073s][info][vmmutex]   Bootclasspath_lock
>> [0.073s][info][vmmutex] 
>> [0.073s][info][vmmutex] Rank "safepoint-3":
>> [0.073s][info][vmmutex]   PerfDataMemAlloc_lock
>> [0.073s][info][vmmutex]   PerfDataManager_lock
>> [0.073s][info][vmmutex]   VMOperation_lock
>> [0.073s][info][vmmutex]   SystemDictionary_lock
>> [0.073s][info][vmmutex] 
>> [0.073s][info][vmmutex] Rank "safepoint-2":
>> [0.073s][info][vmmutex]   Heap_lock
>> [0.073s][info][vmmutex]   ClassInitError_lock
>> [0.073s][info][vmmutex]   G1OldGCCount_lock
>> [0.073s][info][vmmutex]   ParGCRareEvent_lock
>> [0.073s][info][vmmutex]   OopMapCacheAlloc_lock
>> [0.073s][info][vmmutex]   Module_lock
>> [0.073s][info][vmmutex] 
>> [0.073s][info][vmmutex] Rank "safepoint-1":
>> [0.073s][info][vmmutex]   Threads_lock
>> [0.073s][info][vmmutex]   Compile_lock
>> [0.073s][info][vmmutex]   AdapterHandlerLibrary_lock
>> [0.073s][info][vmmutex]   ClassLoaderDataGraph_lock
>> [0.073s][info][vmmutex]   CompileTaskAlloc_lock
>> [0.073s][info][vmmutex]   JNICritical_lock
>> [0.073s][info][vmmutex]   JVMCI_lock
>> [0.073s][info][vmmutex] 
>> [0.073s][info][vmmutex] Rank "safepoint":
>> [0.073s][info][vmmutex]   InvokeMethodTable_lock
>> [0.073s][info][vmmutex]   SharedDictionary_lock
>> [0.073s][info][vmmutex]   VMStatistic_lock
>> [0.073s][info][vmmutex]   SignatureHandlerLibrary_lock
>> [0.073s][info][vmmutex]   ExceptionCache_lock
>> [0.073s][info][vmmutex]   FullGCALot_lock
>> [0.073s][info][vmmutex]   BeforeExit_lock
>> [0.073s][info][vmmutex]   RetData_lock
>> [0.073s][info][vmmutex]   Terminator_lock
>> [0.073s][info][vmmutex]   Notify_lock
>> [0.073s][info][vmmutex]   Heap_lock
>> [0.073s][info][vmmutex]   JfieldIdCreation_lock
>> [0.073s][info][vmmutex]   MethodCompileQueue_lock
>> [0.073s][info][vmmutex]   CompileStatistics_lock
>> [0.073s][info][vmmutex]   MultiArray_lock
>> [0.073s][info][vmmutex]   JvmtiThreadState_lock
>> [0.073s][info][vmmutex]   Management_lock
>> [0.073s][info][vmmutex]   ConcurrentGCBreakpoints_lock
>> [0.073s][info][vmmutex]   MethodData_lock
>> [0.073s][info][vmmutex]   TouchedMethodLog_lock
>> [0.073s][info][vmmutex]   CompileThread_lock
>> [0.073s][info][vmmutex]   PeriodicTask_lock
>> [0.073s][info][vmmutex]   RedefineClasses_lock
>> [0.073s][info][vmmutex]   Verify_lock
>> [0.073s][info][vmmutex]   CodeHeapStateAnalytics_lock
>> [0.073s][info][vmmutex]   ThreadIdTableCreate_lock
>> [0.073s][info][vmmutex]   NMTQuery_lock
>> [0.073s][info][vmmutex]   CDSClassFileStream_lock
>> [0.073s][info][vmmutex]   LambdaFormInvokers_lock
>> [0.073s][info][vmmutex]   JVMCIRuntime_lock
>> 
>> 
>> Additional testing:
>>  - [x] New test on Linux x86_64 {release,fastdebug,slowdebug}
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More comments

Marked as reviewed by coleenp (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10556

From coleenp at openjdk.org  Wed Oct  5 17:47:10 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 5 Oct 2022 17:47:10 GMT
Subject: RFR: 8294759: Print actual lock/monitor ranking [v3]
In-Reply-To: <o8XLu6FehYAXvuw7H4_wSH3U7Rzra46HIuhh3PeWQbU=.f2942394-5f05-4def-b942-8c4658d55ff7@github.com>
References: <OWmG-86gxFSht-26qctihYkIdKz3f8kI86Lum7e8Lw8=.2330c15f-7d5e-4811-a78c-7742d761e650@github.com>
 <eKMrOT-LhUXW36WVUFglAQf0t1VYhd2neVsqLquukhc=.60df170e-94b1-4b9c-a638-d8639f5e0826@github.com>
 <o8XLu6FehYAXvuw7H4_wSH3U7Rzra46HIuhh3PeWQbU=.f2942394-5f05-4def-b942-8c4658d55ff7@github.com>
Message-ID: <UwVPFKUemvAKP4MN7vqODwOzBS-nwYTYMFY_tgw0RJU=.d0fff308-46aa-4d46-acdb-99ebd45f1b81@github.com>

On Wed, 5 Oct 2022 15:59:09 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> src/hotspot/share/runtime/mutexLocker.cpp line 427:
>> 
>>> 425: 
>>> 426: void print_lock_ranks(outputStream* st) {
>>> 427:   st->print_cr("VM Mutex/Monitor ranks: ");
>> 
>> Do we want to clarify this is not the complete set of Mutexes in the VM?
>
> hs_err does not clarify this in the similar printout ("VM Mutex/Monitor currently owned by a thread: " in the method above), so it seems to be implied these are only the known mutexes. So, I left it as is.

it's a lot harder to get the full set of mutexes, which is unfortunate, but this is good.

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

PR: https://git.openjdk.org/jdk/pull/10556

From duke at openjdk.org  Wed Oct  5 21:51:49 2022
From: duke at openjdk.org (Matias Saavedra Silva)
Date: Wed, 5 Oct 2022 21:51:49 GMT
Subject: RFR: 8293061: Combine CDSOptions and AppCDSOptions test utility
 classes
Message-ID: <Wp-zm09bLBGsE8KsZzuN6UQeHuXDHmS_QQdZwPxE3KQ=.5591f902-289b-4afd-b7ab-a3c221e172a7@github.com>

AppCDSOptions class was moved into the CDSOptions class and relevant tests were updated. The updated tests pass. Verified with tier 1-4 tests.

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

Commit messages:
 - Fixed trailing whitespace
 - Fixed commenting
 - 8293061: Combine CDSOptions and AppCDSOptions test utility classes

Changes: https://git.openjdk.org/jdk/pull/10515/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10515&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293061
  Stats: 71 lines in 3 files changed: 13 ins; 42 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/10515.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10515/head:pull/10515

PR: https://git.openjdk.org/jdk/pull/10515

From dholmes at openjdk.org  Thu Oct  6 00:25:09 2022
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 6 Oct 2022 00:25:09 GMT
Subject: RFR: 8293061: Combine CDSOptions and AppCDSOptions test utility
 classes
In-Reply-To: <Wp-zm09bLBGsE8KsZzuN6UQeHuXDHmS_QQdZwPxE3KQ=.5591f902-289b-4afd-b7ab-a3c221e172a7@github.com>
References: <Wp-zm09bLBGsE8KsZzuN6UQeHuXDHmS_QQdZwPxE3KQ=.5591f902-289b-4afd-b7ab-a3c221e172a7@github.com>
Message-ID: <0EesctV3ZP4-Z3dqI3o85d_w6CngSwYIDGhMexxUL9I=.2d926011-b438-48f5-8454-189669ee3134@github.com>

On Fri, 30 Sep 2022 19:27:24 GMT, Matias Saavedra Silva <duke at openjdk.org> wrote:

> AppCDSOptions class was moved into the CDSOptions class and relevant tests were updated. The updated tests pass. Verified with tier 1-4 tests.

Code relocation looks accurate.

Thanks.

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10515

From dholmes at openjdk.org  Thu Oct  6 00:31:18 2022
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 6 Oct 2022 00:31:18 GMT
Subject: RFR: 8294759: Print actual lock/monitor ranking [v3]
In-Reply-To: <280S0zDZr4mWj8sTMWQJYO5V5T9TJ2Bxg8luMYojjYc=.097345b8-63bd-4e99-9125-b19dc051f413@github.com>
References: <OWmG-86gxFSht-26qctihYkIdKz3f8kI86Lum7e8Lw8=.2330c15f-7d5e-4811-a78c-7742d761e650@github.com>
 <280S0zDZr4mWj8sTMWQJYO5V5T9TJ2Bxg8luMYojjYc=.097345b8-63bd-4e99-9125-b19dc051f413@github.com>
Message-ID: <reEF-ZWBl5Ddh6tUEUAvxIHJ1mVForyRBej8Ci5MDAQ=.99d8e51a-f3ec-4ccc-8608-1aab5adfee53@github.com>

On Wed, 5 Oct 2022 16:14:44 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> When relative lock ranks are changing, it is useful to see what are the final lock ranks are. It can be dumped as optional logging shortly after VM startup. 
>> 
>> Sample output:
>> 
>> 
>> $ build/linux-x86_64-server-fastdebug/images/jdk/bin/java -Xlog:vmmutex
>> [0.073s][info][vmmutex] VM Mutex/Monitor ranks: 
>> [0.073s][info][vmmutex] 
>> [0.073s][info][vmmutex] Rank "service-2":
>> [0.073s][info][vmmutex]   Uncommit_lock
>> [0.073s][info][vmmutex] 
>> [0.073s][info][vmmutex] Rank "service-1":
>> [0.073s][info][vmmutex]   FreeList_lock
>> [0.073s][info][vmmutex]   MonitoringSupport_lock
>> [0.073s][info][vmmutex] 
>> [0.073s][info][vmmutex] Rank "service":
>> [0.073s][info][vmmutex]   Service_lock
>> [0.073s][info][vmmutex]   Notification_lock
>> [0.073s][info][vmmutex] 
>> [0.073s][info][vmmutex] Rank "stackwatermark-1":
>> [0.073s][info][vmmutex]   JfrStacktrace_lock
>> [0.073s][info][vmmutex] 
>> [0.073s][info][vmmutex] Rank "tty-1":
>> [0.073s][info][vmmutex]   SharedDecoder_lock
>> [0.073s][info][vmmutex] 
>> [0.073s][info][vmmutex] Rank "tty":
>> [0.073s][info][vmmutex]   tty_lock
>> [0.073s][info][vmmutex] 
>> [0.073s][info][vmmutex] Rank "nosafepoint-3":
>> [0.073s][info][vmmutex]   Metaspace_lock
>> [0.073s][info][vmmutex]   JfrMsg_lock
>> [0.073s][info][vmmutex]   ContinuationRelativize_lock
>> [0.073s][info][vmmutex]   ThreadsSMRDelete_lock
>> [0.073s][info][vmmutex]   CompiledMethod_lock
>> [0.073s][info][vmmutex] 
>> [0.073s][info][vmmutex] Rank "nosafepoint-2":
>> [0.073s][info][vmmutex]   G1DetachedRefinementStats_lock
>> [0.073s][info][vmmutex]   JmethodIdCreation_lock
>> [0.073s][info][vmmutex]   CodeCache_lock
>> [0.073s][info][vmmutex] 
>> [0.073s][info][vmmutex] Rank "nosafepoint-1":
>> [0.073s][info][vmmutex]   RootRegionScan_lock
>> [0.073s][info][vmmutex]   RawMonitor_lock
>> [0.073s][info][vmmutex]   MetaspaceCritical_lock
>> [0.073s][info][vmmutex]   NonJavaThreadsList_lock
>> [0.073s][info][vmmutex]   Zip_lock
>> [0.073s][info][vmmutex]   InlineCacheBuffer_lock
>> [0.073s][info][vmmutex]   VtableStubs_lock
>> [0.073s][info][vmmutex] 
>> [0.073s][info][vmmutex] Rank "nosafepoint":
>> [0.073s][info][vmmutex]   STS_lock
>> [0.073s][info][vmmutex]   CGC_lock
>> [0.073s][info][vmmutex]   OldSets_lock
>> [0.073s][info][vmmutex]   MarkStackFreeList_lock
>> [0.073s][info][vmmutex]   MarkStackChunkList_lock
>> [0.073s][info][vmmutex]   StringDedup_lock
>> [0.073s][info][vmmutex]   StringDedupIntern_lock
>> [0.073s][info][vmmutex]   Patching_lock
>> [0.073s][info][vmmutex]   MonitorDeflation_lock
>> [0.073s][info][vmmutex]   SymbolArena_lock
>> [0.073s][info][vmmutex]   NonJavaThreadsListSync_lock
>> [0.073s][info][vmmutex]   InitCompleted_lock
>> [0.073s][info][vmmutex]   CompiledIC_lock
>> [0.073s][info][vmmutex]   DirectivesStack_lock
>> [0.073s][info][vmmutex]   EscapeBarrier_lock
>> [0.073s][info][vmmutex]   JvmtiVTMSTransition_lock
>> [0.073s][info][vmmutex]   JfrBuffer_lock
>> [0.073s][info][vmmutex]   JfrThreadSampler_lock
>> [0.073s][info][vmmutex]   DCmdFactory_lock
>> [0.073s][info][vmmutex]   DumpTimeTable_lock
>> [0.073s][info][vmmutex]   CDSLambda_lock
>> [0.073s][info][vmmutex]   DumpRegion_lock
>> [0.073s][info][vmmutex]   ClassListFile_lock
>> [0.073s][info][vmmutex]   Bootclasspath_lock
>> [0.073s][info][vmmutex] 
>> [0.073s][info][vmmutex] Rank "safepoint-3":
>> [0.073s][info][vmmutex]   PerfDataMemAlloc_lock
>> [0.073s][info][vmmutex]   PerfDataManager_lock
>> [0.073s][info][vmmutex]   VMOperation_lock
>> [0.073s][info][vmmutex]   SystemDictionary_lock
>> [0.073s][info][vmmutex] 
>> [0.073s][info][vmmutex] Rank "safepoint-2":
>> [0.073s][info][vmmutex]   Heap_lock
>> [0.073s][info][vmmutex]   ClassInitError_lock
>> [0.073s][info][vmmutex]   G1OldGCCount_lock
>> [0.073s][info][vmmutex]   ParGCRareEvent_lock
>> [0.073s][info][vmmutex]   OopMapCacheAlloc_lock
>> [0.073s][info][vmmutex]   Module_lock
>> [0.073s][info][vmmutex] 
>> [0.073s][info][vmmutex] Rank "safepoint-1":
>> [0.073s][info][vmmutex]   Threads_lock
>> [0.073s][info][vmmutex]   Compile_lock
>> [0.073s][info][vmmutex]   AdapterHandlerLibrary_lock
>> [0.073s][info][vmmutex]   ClassLoaderDataGraph_lock
>> [0.073s][info][vmmutex]   CompileTaskAlloc_lock
>> [0.073s][info][vmmutex]   JNICritical_lock
>> [0.073s][info][vmmutex]   JVMCI_lock
>> [0.073s][info][vmmutex] 
>> [0.073s][info][vmmutex] Rank "safepoint":
>> [0.073s][info][vmmutex]   InvokeMethodTable_lock
>> [0.073s][info][vmmutex]   SharedDictionary_lock
>> [0.073s][info][vmmutex]   VMStatistic_lock
>> [0.073s][info][vmmutex]   SignatureHandlerLibrary_lock
>> [0.073s][info][vmmutex]   ExceptionCache_lock
>> [0.073s][info][vmmutex]   FullGCALot_lock
>> [0.073s][info][vmmutex]   BeforeExit_lock
>> [0.073s][info][vmmutex]   RetData_lock
>> [0.073s][info][vmmutex]   Terminator_lock
>> [0.073s][info][vmmutex]   Notify_lock
>> [0.073s][info][vmmutex]   Heap_lock
>> [0.073s][info][vmmutex]   JfieldIdCreation_lock
>> [0.073s][info][vmmutex]   MethodCompileQueue_lock
>> [0.073s][info][vmmutex]   CompileStatistics_lock
>> [0.073s][info][vmmutex]   MultiArray_lock
>> [0.073s][info][vmmutex]   JvmtiThreadState_lock
>> [0.073s][info][vmmutex]   Management_lock
>> [0.073s][info][vmmutex]   ConcurrentGCBreakpoints_lock
>> [0.073s][info][vmmutex]   MethodData_lock
>> [0.073s][info][vmmutex]   TouchedMethodLog_lock
>> [0.073s][info][vmmutex]   CompileThread_lock
>> [0.073s][info][vmmutex]   PeriodicTask_lock
>> [0.073s][info][vmmutex]   RedefineClasses_lock
>> [0.073s][info][vmmutex]   Verify_lock
>> [0.073s][info][vmmutex]   CodeHeapStateAnalytics_lock
>> [0.073s][info][vmmutex]   ThreadIdTableCreate_lock
>> [0.073s][info][vmmutex]   NMTQuery_lock
>> [0.073s][info][vmmutex]   CDSClassFileStream_lock
>> [0.073s][info][vmmutex]   LambdaFormInvokers_lock
>> [0.073s][info][vmmutex]   JVMCIRuntime_lock
>> 
>> 
>> Additional testing:
>>  - [x] New test on Linux x86_64 {release,fastdebug,slowdebug}
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More comments

Marked as reviewed by dholmes (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10556

From fyang at openjdk.org  Thu Oct  6 01:21:24 2022
From: fyang at openjdk.org (Fei Yang)
Date: Thu, 6 Oct 2022 01:21:24 GMT
Subject: RFR: 8294679: RISC-V: Misc crash dump improvements
In-Reply-To: <JKuHnCUYu-vBS0DBDx-aMiKiywWyxjM-fO6CN6_pSZ0=.073de068-79f8-48bd-bd1d-80bd7dbc0717@github.com>
References: <Z3nOQB1iSj9LJLM8jvbUP80OeJyxZOKZ87Dzm6hkpHU=.b8df2e3d-fea3-4cd2-a37d-f8618b03a975@github.com>
 <JKuHnCUYu-vBS0DBDx-aMiKiywWyxjM-fO6CN6_pSZ0=.073de068-79f8-48bd-bd1d-80bd7dbc0717@github.com>
Message-ID: <mcJp8C5QL9sxKS6_H5yqyYJAI0LUKKVnfTdTA8zF2ps=.e1ce3f95-f726-483c-8d15-dabf0f74b2d0@github.com>

On Tue, 4 Oct 2022 07:13:39 GMT, Feilong Jiang <fjiang at openjdk.org> wrote:

>> Issue https://bugs.openjdk.org/browse/JDK-8294160 only handles x86 & aarch64.
>> This adds handling for this case on RISC-V: When calling a bad address, we usually don't get a meaningful stack backtrace, but in many situations we can if we know where to find the caller information.
>> 
>> Testing: Tier1 tested on HiFive Unmatched board.
>
> LGTM

@feilongjiang @shipilev : Thanks for the review. Tier2-3 test is also clean.

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

PR: https://git.openjdk.org/jdk/pull/10512

From fyang at openjdk.org  Thu Oct  6 01:24:35 2022
From: fyang at openjdk.org (Fei Yang)
Date: Thu, 6 Oct 2022 01:24:35 GMT
Subject: Integrated: 8294679: RISC-V: Misc crash dump improvements
In-Reply-To: <Z3nOQB1iSj9LJLM8jvbUP80OeJyxZOKZ87Dzm6hkpHU=.b8df2e3d-fea3-4cd2-a37d-f8618b03a975@github.com>
References: <Z3nOQB1iSj9LJLM8jvbUP80OeJyxZOKZ87Dzm6hkpHU=.b8df2e3d-fea3-4cd2-a37d-f8618b03a975@github.com>
Message-ID: <j9KMwyYvLG3hX0Z7sKV9yBH7PiSWlyM3FtECmGcAuMM=.faed8660-9a15-4692-bd26-3cb3ca7a6012@github.com>

On Fri, 30 Sep 2022 14:41:05 GMT, Fei Yang <fyang at openjdk.org> wrote:

> Issue https://bugs.openjdk.org/browse/JDK-8294160 only handles x86 & aarch64.
> This adds handling for this case on RISC-V: When calling a bad address, we usually don't get a meaningful stack backtrace, but in many situations we can if we know where to find the caller information.
> 
> Testing: Tier1 tested on HiFive Unmatched board.

This pull request has now been integrated.

Changeset: 8f561159
Author:    Fei Yang <fyang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8f5611593a8085242d773bb8c7ee8b077a261e80
Stats:     8 lines in 1 file changed: 6 ins; 0 del; 2 mod

8294679: RISC-V: Misc crash dump improvements

Reviewed-by: fjiang, shade

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

PR: https://git.openjdk.org/jdk/pull/10512

From iklam at openjdk.org  Thu Oct  6 03:57:09 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 6 Oct 2022 03:57:09 GMT
Subject: RFR: 8293061: Combine CDSOptions and AppCDSOptions test utility
 classes
In-Reply-To: <Wp-zm09bLBGsE8KsZzuN6UQeHuXDHmS_QQdZwPxE3KQ=.5591f902-289b-4afd-b7ab-a3c221e172a7@github.com>
References: <Wp-zm09bLBGsE8KsZzuN6UQeHuXDHmS_QQdZwPxE3KQ=.5591f902-289b-4afd-b7ab-a3c221e172a7@github.com>
Message-ID: <XQNyHaEMWT5BH8R9MD7WuxvsKsLoHpXsEMusBlOyNHE=.8a9704ac-dbd3-424d-bb79-db1842403d06@github.com>

On Fri, 30 Sep 2022 19:27:24 GMT, Matias Saavedra Silva <duke at openjdk.org> wrote:

> AppCDSOptions class was moved into the CDSOptions class and relevant tests were updated. The updated tests pass. Verified with tier 1-4 tests.

LGTM

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

Marked as reviewed by iklam (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10515

From ccheung at openjdk.org  Thu Oct  6 05:35:20 2022
From: ccheung at openjdk.org (Calvin Cheung)
Date: Thu, 6 Oct 2022 05:35:20 GMT
Subject: RFR: 8293061: Combine CDSOptions and AppCDSOptions test utility
 classes
In-Reply-To: <Wp-zm09bLBGsE8KsZzuN6UQeHuXDHmS_QQdZwPxE3KQ=.5591f902-289b-4afd-b7ab-a3c221e172a7@github.com>
References: <Wp-zm09bLBGsE8KsZzuN6UQeHuXDHmS_QQdZwPxE3KQ=.5591f902-289b-4afd-b7ab-a3c221e172a7@github.com>
Message-ID: <x6mDjXyb7vS3TAQV2jSLap-g6z4BhsWyJjI562JsbRQ=.36dad9af-8918-4de3-88aa-1013dc4bb849@github.com>

On Fri, 30 Sep 2022 19:27:24 GMT, Matias Saavedra Silva <duke at openjdk.org> wrote:

> AppCDSOptions class was moved into the CDSOptions class and relevant tests were updated. The updated tests pass. Verified with tier 1-4 tests.

Thanks for fixing this. Looks good.

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

Marked as reviewed by ccheung (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10515

From dholmes at openjdk.org  Thu Oct  6 06:54:24 2022
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 6 Oct 2022 06:54:24 GMT
Subject: RFR: 8293806: JDK_JAVA_OPTIONS picked up twice if launcher
 re-executes it self
In-Reply-To: <o_7CQY9QGHSXKRvNGPndiAp6M8w_rjDztF30TMU4eqM=.499fd1ac-f0aa-4935-b971-44d67fea49fc@github.com>
References: <o_7CQY9QGHSXKRvNGPndiAp6M8w_rjDztF30TMU4eqM=.499fd1ac-f0aa-4935-b971-44d67fea49fc@github.com>
Message-ID: <xndg_YdJvyfaN6dM3UBlXbEWjghJi8nc2nQuPdO6nDg=.a20ceffd-d2dc-4cbc-8372-1e27749b6c04@github.com>

On Mon, 26 Sep 2022 18:15:17 GMT, Dmitry Samersoff <dsamersoff at openjdk.org> wrote:

> If the user has set LD_LIBRARY_PATH to use a particular libjvm.so, options from the JDK_JAVA_OPTIONS environment variable are picked up twice.
> 
> If an option cannot be accepted twice (e.g., -agentlib), the application fails to start.
> 
> The same happens on operating systems that doesn't support $RPATH/$ORIGIN and always have to set LD_LIBRARY_PATH and re-exec the launcher.
> 
> The fix adds one additional argument - orig_argv to JLI_Launch() and use it in on relaunch in execv() call.
> 
> All relevant jtreg tests are passed.

I'm still somewhat perplexed as the launcher appears to to try and deal with this as I said before "see JLI_AddArgsFromEnvVar and the use of the relaunch field". So something seems amiss here. If that logic is not supposed to deal with the current problem, then what exactly is it intended for?

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

PR: https://git.openjdk.org/jdk/pull/10430

From shade at openjdk.org  Thu Oct  6 07:59:27 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 6 Oct 2022 07:59:27 GMT
Subject: RFR: 8294759: Print actual lock/monitor ranking [v3]
In-Reply-To: <280S0zDZr4mWj8sTMWQJYO5V5T9TJ2Bxg8luMYojjYc=.097345b8-63bd-4e99-9125-b19dc051f413@github.com>
References: <OWmG-86gxFSht-26qctihYkIdKz3f8kI86Lum7e8Lw8=.2330c15f-7d5e-4811-a78c-7742d761e650@github.com>
 <280S0zDZr4mWj8sTMWQJYO5V5T9TJ2Bxg8luMYojjYc=.097345b8-63bd-4e99-9125-b19dc051f413@github.com>
Message-ID: <kHHverLSGzj9_g_kBqR8K7rk01FKV3NmdD2Eu7uWhUQ=.a418b8bd-0cfa-4e3e-8850-5e2778e79d65@github.com>

On Wed, 5 Oct 2022 16:14:44 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> When relative lock ranks are changing, it is useful to see what are the final lock ranks are. It can be dumped as optional logging shortly after VM startup. 
>> 
>> Sample output:
>> 
>> 
>> $ build/linux-x86_64-server-fastdebug/images/jdk/bin/java -Xlog:vmmutex
>> [0.073s][info][vmmutex] VM Mutex/Monitor ranks: 
>> [0.073s][info][vmmutex] 
>> [0.073s][info][vmmutex] Rank "service-2":
>> [0.073s][info][vmmutex]   Uncommit_lock
>> [0.073s][info][vmmutex] 
>> [0.073s][info][vmmutex] Rank "service-1":
>> [0.073s][info][vmmutex]   FreeList_lock
>> [0.073s][info][vmmutex]   MonitoringSupport_lock
>> [0.073s][info][vmmutex] 
>> [0.073s][info][vmmutex] Rank "service":
>> [0.073s][info][vmmutex]   Service_lock
>> [0.073s][info][vmmutex]   Notification_lock
>> [0.073s][info][vmmutex] 
>> [0.073s][info][vmmutex] Rank "stackwatermark-1":
>> [0.073s][info][vmmutex]   JfrStacktrace_lock
>> [0.073s][info][vmmutex] 
>> [0.073s][info][vmmutex] Rank "tty-1":
>> [0.073s][info][vmmutex]   SharedDecoder_lock
>> [0.073s][info][vmmutex] 
>> [0.073s][info][vmmutex] Rank "tty":
>> [0.073s][info][vmmutex]   tty_lock
>> [0.073s][info][vmmutex] 
>> [0.073s][info][vmmutex] Rank "nosafepoint-3":
>> [0.073s][info][vmmutex]   Metaspace_lock
>> [0.073s][info][vmmutex]   JfrMsg_lock
>> [0.073s][info][vmmutex]   ContinuationRelativize_lock
>> [0.073s][info][vmmutex]   ThreadsSMRDelete_lock
>> [0.073s][info][vmmutex]   CompiledMethod_lock
>> [0.073s][info][vmmutex] 
>> [0.073s][info][vmmutex] Rank "nosafepoint-2":
>> [0.073s][info][vmmutex]   G1DetachedRefinementStats_lock
>> [0.073s][info][vmmutex]   JmethodIdCreation_lock
>> [0.073s][info][vmmutex]   CodeCache_lock
>> [0.073s][info][vmmutex] 
>> [0.073s][info][vmmutex] Rank "nosafepoint-1":
>> [0.073s][info][vmmutex]   RootRegionScan_lock
>> [0.073s][info][vmmutex]   RawMonitor_lock
>> [0.073s][info][vmmutex]   MetaspaceCritical_lock
>> [0.073s][info][vmmutex]   NonJavaThreadsList_lock
>> [0.073s][info][vmmutex]   Zip_lock
>> [0.073s][info][vmmutex]   InlineCacheBuffer_lock
>> [0.073s][info][vmmutex]   VtableStubs_lock
>> [0.073s][info][vmmutex] 
>> [0.073s][info][vmmutex] Rank "nosafepoint":
>> [0.073s][info][vmmutex]   STS_lock
>> [0.073s][info][vmmutex]   CGC_lock
>> [0.073s][info][vmmutex]   OldSets_lock
>> [0.073s][info][vmmutex]   MarkStackFreeList_lock
>> [0.073s][info][vmmutex]   MarkStackChunkList_lock
>> [0.073s][info][vmmutex]   StringDedup_lock
>> [0.073s][info][vmmutex]   StringDedupIntern_lock
>> [0.073s][info][vmmutex]   Patching_lock
>> [0.073s][info][vmmutex]   MonitorDeflation_lock
>> [0.073s][info][vmmutex]   SymbolArena_lock
>> [0.073s][info][vmmutex]   NonJavaThreadsListSync_lock
>> [0.073s][info][vmmutex]   InitCompleted_lock
>> [0.073s][info][vmmutex]   CompiledIC_lock
>> [0.073s][info][vmmutex]   DirectivesStack_lock
>> [0.073s][info][vmmutex]   EscapeBarrier_lock
>> [0.073s][info][vmmutex]   JvmtiVTMSTransition_lock
>> [0.073s][info][vmmutex]   JfrBuffer_lock
>> [0.073s][info][vmmutex]   JfrThreadSampler_lock
>> [0.073s][info][vmmutex]   DCmdFactory_lock
>> [0.073s][info][vmmutex]   DumpTimeTable_lock
>> [0.073s][info][vmmutex]   CDSLambda_lock
>> [0.073s][info][vmmutex]   DumpRegion_lock
>> [0.073s][info][vmmutex]   ClassListFile_lock
>> [0.073s][info][vmmutex]   Bootclasspath_lock
>> [0.073s][info][vmmutex] 
>> [0.073s][info][vmmutex] Rank "safepoint-3":
>> [0.073s][info][vmmutex]   PerfDataMemAlloc_lock
>> [0.073s][info][vmmutex]   PerfDataManager_lock
>> [0.073s][info][vmmutex]   VMOperation_lock
>> [0.073s][info][vmmutex]   SystemDictionary_lock
>> [0.073s][info][vmmutex] 
>> [0.073s][info][vmmutex] Rank "safepoint-2":
>> [0.073s][info][vmmutex]   Heap_lock
>> [0.073s][info][vmmutex]   ClassInitError_lock
>> [0.073s][info][vmmutex]   G1OldGCCount_lock
>> [0.073s][info][vmmutex]   ParGCRareEvent_lock
>> [0.073s][info][vmmutex]   OopMapCacheAlloc_lock
>> [0.073s][info][vmmutex]   Module_lock
>> [0.073s][info][vmmutex] 
>> [0.073s][info][vmmutex] Rank "safepoint-1":
>> [0.073s][info][vmmutex]   Threads_lock
>> [0.073s][info][vmmutex]   Compile_lock
>> [0.073s][info][vmmutex]   AdapterHandlerLibrary_lock
>> [0.073s][info][vmmutex]   ClassLoaderDataGraph_lock
>> [0.073s][info][vmmutex]   CompileTaskAlloc_lock
>> [0.073s][info][vmmutex]   JNICritical_lock
>> [0.073s][info][vmmutex]   JVMCI_lock
>> [0.073s][info][vmmutex] 
>> [0.073s][info][vmmutex] Rank "safepoint":
>> [0.073s][info][vmmutex]   InvokeMethodTable_lock
>> [0.073s][info][vmmutex]   SharedDictionary_lock
>> [0.073s][info][vmmutex]   VMStatistic_lock
>> [0.073s][info][vmmutex]   SignatureHandlerLibrary_lock
>> [0.073s][info][vmmutex]   ExceptionCache_lock
>> [0.073s][info][vmmutex]   FullGCALot_lock
>> [0.073s][info][vmmutex]   BeforeExit_lock
>> [0.073s][info][vmmutex]   RetData_lock
>> [0.073s][info][vmmutex]   Terminator_lock
>> [0.073s][info][vmmutex]   Notify_lock
>> [0.073s][info][vmmutex]   Heap_lock
>> [0.073s][info][vmmutex]   JfieldIdCreation_lock
>> [0.073s][info][vmmutex]   MethodCompileQueue_lock
>> [0.073s][info][vmmutex]   CompileStatistics_lock
>> [0.073s][info][vmmutex]   MultiArray_lock
>> [0.073s][info][vmmutex]   JvmtiThreadState_lock
>> [0.073s][info][vmmutex]   Management_lock
>> [0.073s][info][vmmutex]   ConcurrentGCBreakpoints_lock
>> [0.073s][info][vmmutex]   MethodData_lock
>> [0.073s][info][vmmutex]   TouchedMethodLog_lock
>> [0.073s][info][vmmutex]   CompileThread_lock
>> [0.073s][info][vmmutex]   PeriodicTask_lock
>> [0.073s][info][vmmutex]   RedefineClasses_lock
>> [0.073s][info][vmmutex]   Verify_lock
>> [0.073s][info][vmmutex]   CodeHeapStateAnalytics_lock
>> [0.073s][info][vmmutex]   ThreadIdTableCreate_lock
>> [0.073s][info][vmmutex]   NMTQuery_lock
>> [0.073s][info][vmmutex]   CDSClassFileStream_lock
>> [0.073s][info][vmmutex]   LambdaFormInvokers_lock
>> [0.073s][info][vmmutex]   JVMCIRuntime_lock
>> 
>> 
>> Additional testing:
>>  - [x] New test on Linux x86_64 {release,fastdebug,slowdebug}
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More comments

Thank you!

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

PR: https://git.openjdk.org/jdk/pull/10556

From shade at openjdk.org  Thu Oct  6 08:00:55 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 6 Oct 2022 08:00:55 GMT
Subject: Integrated: 8294759: Print actual lock/monitor ranking
In-Reply-To: <OWmG-86gxFSht-26qctihYkIdKz3f8kI86Lum7e8Lw8=.2330c15f-7d5e-4811-a78c-7742d761e650@github.com>
References: <OWmG-86gxFSht-26qctihYkIdKz3f8kI86Lum7e8Lw8=.2330c15f-7d5e-4811-a78c-7742d761e650@github.com>
Message-ID: <uNiY-nhKS1H1CbwK7G594OnZa3QpfcP9rJM9NGNkiFA=.46d3980c-4c8f-49a8-be7b-3547582c64c7@github.com>

On Tue, 4 Oct 2022 12:46:42 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> When relative lock ranks are changing, it is useful to see what are the final lock ranks are. It can be dumped as optional logging shortly after VM startup. 
> 
> Sample output:
> 
> 
> $ build/linux-x86_64-server-fastdebug/images/jdk/bin/java -Xlog:vmmutex
> [0.073s][info][vmmutex] VM Mutex/Monitor ranks: 
> [0.073s][info][vmmutex] 
> [0.073s][info][vmmutex] Rank "service-2":
> [0.073s][info][vmmutex]   Uncommit_lock
> [0.073s][info][vmmutex] 
> [0.073s][info][vmmutex] Rank "service-1":
> [0.073s][info][vmmutex]   FreeList_lock
> [0.073s][info][vmmutex]   MonitoringSupport_lock
> [0.073s][info][vmmutex] 
> [0.073s][info][vmmutex] Rank "service":
> [0.073s][info][vmmutex]   Service_lock
> [0.073s][info][vmmutex]   Notification_lock
> [0.073s][info][vmmutex] 
> [0.073s][info][vmmutex] Rank "stackwatermark-1":
> [0.073s][info][vmmutex]   JfrStacktrace_lock
> [0.073s][info][vmmutex] 
> [0.073s][info][vmmutex] Rank "tty-1":
> [0.073s][info][vmmutex]   SharedDecoder_lock
> [0.073s][info][vmmutex] 
> [0.073s][info][vmmutex] Rank "tty":
> [0.073s][info][vmmutex]   tty_lock
> [0.073s][info][vmmutex] 
> [0.073s][info][vmmutex] Rank "nosafepoint-3":
> [0.073s][info][vmmutex]   Metaspace_lock
> [0.073s][info][vmmutex]   JfrMsg_lock
> [0.073s][info][vmmutex]   ContinuationRelativize_lock
> [0.073s][info][vmmutex]   ThreadsSMRDelete_lock
> [0.073s][info][vmmutex]   CompiledMethod_lock
> [0.073s][info][vmmutex] 
> [0.073s][info][vmmutex] Rank "nosafepoint-2":
> [0.073s][info][vmmutex]   G1DetachedRefinementStats_lock
> [0.073s][info][vmmutex]   JmethodIdCreation_lock
> [0.073s][info][vmmutex]   CodeCache_lock
> [0.073s][info][vmmutex] 
> [0.073s][info][vmmutex] Rank "nosafepoint-1":
> [0.073s][info][vmmutex]   RootRegionScan_lock
> [0.073s][info][vmmutex]   RawMonitor_lock
> [0.073s][info][vmmutex]   MetaspaceCritical_lock
> [0.073s][info][vmmutex]   NonJavaThreadsList_lock
> [0.073s][info][vmmutex]   Zip_lock
> [0.073s][info][vmmutex]   InlineCacheBuffer_lock
> [0.073s][info][vmmutex]   VtableStubs_lock
> [0.073s][info][vmmutex] 
> [0.073s][info][vmmutex] Rank "nosafepoint":
> [0.073s][info][vmmutex]   STS_lock
> [0.073s][info][vmmutex]   CGC_lock
> [0.073s][info][vmmutex]   OldSets_lock
> [0.073s][info][vmmutex]   MarkStackFreeList_lock
> [0.073s][info][vmmutex]   MarkStackChunkList_lock
> [0.073s][info][vmmutex]   StringDedup_lock
> [0.073s][info][vmmutex]   StringDedupIntern_lock
> [0.073s][info][vmmutex]   Patching_lock
> [0.073s][info][vmmutex]   MonitorDeflation_lock
> [0.073s][info][vmmutex]   SymbolArena_lock
> [0.073s][info][vmmutex]   NonJavaThreadsListSync_lock
> [0.073s][info][vmmutex]   InitCompleted_lock
> [0.073s][info][vmmutex]   CompiledIC_lock
> [0.073s][info][vmmutex]   DirectivesStack_lock
> [0.073s][info][vmmutex]   EscapeBarrier_lock
> [0.073s][info][vmmutex]   JvmtiVTMSTransition_lock
> [0.073s][info][vmmutex]   JfrBuffer_lock
> [0.073s][info][vmmutex]   JfrThreadSampler_lock
> [0.073s][info][vmmutex]   DCmdFactory_lock
> [0.073s][info][vmmutex]   DumpTimeTable_lock
> [0.073s][info][vmmutex]   CDSLambda_lock
> [0.073s][info][vmmutex]   DumpRegion_lock
> [0.073s][info][vmmutex]   ClassListFile_lock
> [0.073s][info][vmmutex]   Bootclasspath_lock
> [0.073s][info][vmmutex] 
> [0.073s][info][vmmutex] Rank "safepoint-3":
> [0.073s][info][vmmutex]   PerfDataMemAlloc_lock
> [0.073s][info][vmmutex]   PerfDataManager_lock
> [0.073s][info][vmmutex]   VMOperation_lock
> [0.073s][info][vmmutex]   SystemDictionary_lock
> [0.073s][info][vmmutex] 
> [0.073s][info][vmmutex] Rank "safepoint-2":
> [0.073s][info][vmmutex]   Heap_lock
> [0.073s][info][vmmutex]   ClassInitError_lock
> [0.073s][info][vmmutex]   G1OldGCCount_lock
> [0.073s][info][vmmutex]   ParGCRareEvent_lock
> [0.073s][info][vmmutex]   OopMapCacheAlloc_lock
> [0.073s][info][vmmutex]   Module_lock
> [0.073s][info][vmmutex] 
> [0.073s][info][vmmutex] Rank "safepoint-1":
> [0.073s][info][vmmutex]   Threads_lock
> [0.073s][info][vmmutex]   Compile_lock
> [0.073s][info][vmmutex]   AdapterHandlerLibrary_lock
> [0.073s][info][vmmutex]   ClassLoaderDataGraph_lock
> [0.073s][info][vmmutex]   CompileTaskAlloc_lock
> [0.073s][info][vmmutex]   JNICritical_lock
> [0.073s][info][vmmutex]   JVMCI_lock
> [0.073s][info][vmmutex] 
> [0.073s][info][vmmutex] Rank "safepoint":
> [0.073s][info][vmmutex]   InvokeMethodTable_lock
> [0.073s][info][vmmutex]   SharedDictionary_lock
> [0.073s][info][vmmutex]   VMStatistic_lock
> [0.073s][info][vmmutex]   SignatureHandlerLibrary_lock
> [0.073s][info][vmmutex]   ExceptionCache_lock
> [0.073s][info][vmmutex]   FullGCALot_lock
> [0.073s][info][vmmutex]   BeforeExit_lock
> [0.073s][info][vmmutex]   RetData_lock
> [0.073s][info][vmmutex]   Terminator_lock
> [0.073s][info][vmmutex]   Notify_lock
> [0.073s][info][vmmutex]   Heap_lock
> [0.073s][info][vmmutex]   JfieldIdCreation_lock
> [0.073s][info][vmmutex]   MethodCompileQueue_lock
> [0.073s][info][vmmutex]   CompileStatistics_lock
> [0.073s][info][vmmutex]   MultiArray_lock
> [0.073s][info][vmmutex]   JvmtiThreadState_lock
> [0.073s][info][vmmutex]   Management_lock
> [0.073s][info][vmmutex]   ConcurrentGCBreakpoints_lock
> [0.073s][info][vmmutex]   MethodData_lock
> [0.073s][info][vmmutex]   TouchedMethodLog_lock
> [0.073s][info][vmmutex]   CompileThread_lock
> [0.073s][info][vmmutex]   PeriodicTask_lock
> [0.073s][info][vmmutex]   RedefineClasses_lock
> [0.073s][info][vmmutex]   Verify_lock
> [0.073s][info][vmmutex]   CodeHeapStateAnalytics_lock
> [0.073s][info][vmmutex]   ThreadIdTableCreate_lock
> [0.073s][info][vmmutex]   NMTQuery_lock
> [0.073s][info][vmmutex]   CDSClassFileStream_lock
> [0.073s][info][vmmutex]   LambdaFormInvokers_lock
> [0.073s][info][vmmutex]   JVMCIRuntime_lock
> 
> 
> Additional testing:
>  - [x] New test on Linux x86_64 {release,fastdebug,slowdebug}

This pull request has now been integrated.

Changeset: e38ae8a6
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e38ae8a6510c8a83d65f8f39c276a0ad7572e26d
Stats:     104 lines in 4 files changed: 104 ins; 0 del; 0 mod

8294759: Print actual lock/monitor ranking

Reviewed-by: coleenp, dholmes

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

PR: https://git.openjdk.org/jdk/pull/10556

From shade at openjdk.org  Thu Oct  6 10:13:01 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 6 Oct 2022 10:13:01 GMT
Subject: RFR: 8294751: Zero: Allow larger default heaps [v2]
In-Reply-To: <onIurPQPJzorzHjZNvhxPk12j0zySZeRR1rid9KW0Yg=.e42155f8-d8af-4496-b72b-350e1dbf8e09@github.com>
References: <onIurPQPJzorzHjZNvhxPk12j0zySZeRR1rid9KW0Yg=.e42155f8-d8af-4496-b72b-350e1dbf8e09@github.com>
Message-ID: <MG-Wb8zUE0JI4L-owNCxUkP6qD5pDVRgFWhtjTcGv1A=.63c600bd-66cc-4836-9aee-7ed24ca7d781@github.com>

> Zero is currently defaulting to `MaxRAM=1G` on all machines. It is set in `compiler_globals.pd` under `#if !defined(COMPILER1) && !defined(COMPILER2) && !INCLUDE_JVMCI`.
> 
> Zero supports lots of GCs, and there is little sense to penalize it unnecessarily with too small heaps. After [JDK-8292847](https://bugs.openjdk.org/browse/JDK-8292847), this would allow G1 with reasonable heap size on most machines.
> 
> Motivational improvements, `SPECjvm2008:serial`:
> 
> 
> # Baseline, G1
> Serial.test  thrpt   10  1619.863 ? 16.694  ops/s
> 
> # Baseline, Serial
> Serial.test  thrpt   10  1094.438 ? 20.425  ops/s
> 
> # Patched, G1
> Serial.test  thrpt   10  1623.090 ? 17.553  ops/s
> 
> # Patched, Serial
> Serial.test  thrpt   10  1624.531 ? 15.792  ops/s  ; <---- matches G1 now, because young is not tiny
> 
> 
> Before:
> 
> 
> $ build/linux-x86_64-zero-release/jdk/bin/java -Xlog:gc -Xlog:gc+init Alloc.java
> [0.003s][info][gc     ] Using G1
> ...
> [0.005s][info][gc,init] Memory: 125G
> ...
> [0.005s][info][gc,init] Heap Region Size: 1M
> [0.005s][info][gc,init] Heap Min Capacity: 8M
> [0.005s][info][gc,init] Heap Initial Capacity: 16M
> [0.005s][info][gc,init] Heap Max Capacity: 256M
> 
> 
> After:
> 
> 
> $ build/linux-x86_64-zero-release/jdk/bin/java -Xlog:gc -Xlog:gc+init Alloc.java
> [0.003s][info][gc     ] Using G1
> ...
> [0.007s][info][gc,init] Memory: 125G
> ...
> [0.007s][info][gc,init] Heap Region Size: 16M
> [0.007s][info][gc,init] Heap Min Capacity: 16M
> [0.007s][info][gc,init] Heap Initial Capacity: 2016M
> [0.007s][info][gc,init] Heap Max Capacity: 30208M

Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Move to compiler_globals_pd.hpp
 - Merge branch 'master' into JDK-8294751-zero-larger-heaps
 - Fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10552/files
  - new: https://git.openjdk.org/jdk/pull/10552/files/d3d831e0..9d120795

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10552&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10552&range=00-01

  Stats: 1823 lines in 133 files changed: 919 ins; 447 del; 457 mod
  Patch: https://git.openjdk.org/jdk/pull/10552.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10552/head:pull/10552

PR: https://git.openjdk.org/jdk/pull/10552

From shade at openjdk.org  Thu Oct  6 10:13:03 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 6 Oct 2022 10:13:03 GMT
Subject: RFR: 8294751: Zero: Allow larger default heaps
In-Reply-To: <kftwqlAjrGBSwaZl7pzJKawOtkL-ao8afogSQyNgfAo=.01f133c0-359a-43f6-ac90-71af19dbf0fc@github.com>
References: <onIurPQPJzorzHjZNvhxPk12j0zySZeRR1rid9KW0Yg=.e42155f8-d8af-4496-b72b-350e1dbf8e09@github.com>
 <kftwqlAjrGBSwaZl7pzJKawOtkL-ao8afogSQyNgfAo=.01f133c0-359a-43f6-ac90-71af19dbf0fc@github.com>
Message-ID: <G-nPV0mvtCaSFqJMfuIQF8s7phlN9ckk3M32sv4f7Y4=.fad3b3e7-846d-4329-8cb0-a83ece573333@github.com>

On Wed, 5 Oct 2022 16:41:40 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Do we need to overhaul the other combinations as well? I don't see why we have to artificially limit the heap sizes. 

Probably. But as always with ergonomics, it might have unintended consequences.
 
> Also, if you want to do it for only ZERO for now, I think it's better to set the value inside compiler_globals_pd.hpp

Yeah, @tstuefe asked about this in the previous PR too. Let's move both flags to that `.hpp` then. See new commit.

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

PR: https://git.openjdk.org/jdk/pull/10552

From duke at openjdk.org  Thu Oct  6 15:07:38 2022
From: duke at openjdk.org (Matias Saavedra Silva)
Date: Thu, 6 Oct 2022 15:07:38 GMT
Subject: Integrated: 8293061: Combine CDSOptions and AppCDSOptions test utility
 classes
In-Reply-To: <Wp-zm09bLBGsE8KsZzuN6UQeHuXDHmS_QQdZwPxE3KQ=.5591f902-289b-4afd-b7ab-a3c221e172a7@github.com>
References: <Wp-zm09bLBGsE8KsZzuN6UQeHuXDHmS_QQdZwPxE3KQ=.5591f902-289b-4afd-b7ab-a3c221e172a7@github.com>
Message-ID: <6V7tbwUTLWyhCRprv6AP3WA8gHQEtflO17oZ_YkJPeg=.c22490b7-dae5-46c3-b32f-f16d514a699d@github.com>

On Fri, 30 Sep 2022 19:27:24 GMT, Matias Saavedra Silva <duke at openjdk.org> wrote:

> AppCDSOptions class was moved into the CDSOptions class and relevant tests were updated. The updated tests pass. Verified with tier 1-4 tests.

This pull request has now been integrated.

Changeset: f888aa95
Author:    Matias Saavedra Silva <matias.s.saavedra.silva at oracle.com>
Committer: Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f888aa953c1335f438ded22abf66b090e894684c
Stats:     71 lines in 3 files changed: 13 ins; 42 del; 16 mod

8293061: Combine CDSOptions and AppCDSOptions test utility classes

Reviewed-by: dholmes, iklam, ccheung

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

PR: https://git.openjdk.org/jdk/pull/10515

From iklam at openjdk.org  Thu Oct  6 15:49:29 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 6 Oct 2022 15:49:29 GMT
Subject: RFR: 8294751: Zero: Allow larger default heaps [v2]
In-Reply-To: <MG-Wb8zUE0JI4L-owNCxUkP6qD5pDVRgFWhtjTcGv1A=.63c600bd-66cc-4836-9aee-7ed24ca7d781@github.com>
References: <onIurPQPJzorzHjZNvhxPk12j0zySZeRR1rid9KW0Yg=.e42155f8-d8af-4496-b72b-350e1dbf8e09@github.com>
 <MG-Wb8zUE0JI4L-owNCxUkP6qD5pDVRgFWhtjTcGv1A=.63c600bd-66cc-4836-9aee-7ed24ca7d781@github.com>
Message-ID: <nNp7lFO9FOINn3lgk1qjKUA1k5eU8iaPXu7ZvxUT9Wk=.a7d64b4e-16bf-4cbf-b322-e9a996602482@github.com>

On Thu, 6 Oct 2022 10:13:01 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Zero is currently defaulting to `MaxRAM=1G` on all machines. It is set in `compiler_globals.pd` under `#if !defined(COMPILER1) && !defined(COMPILER2) && !INCLUDE_JVMCI`.
>> 
>> Zero supports lots of GCs, and there is little sense to penalize it unnecessarily with too small heaps. After [JDK-8292847](https://bugs.openjdk.org/browse/JDK-8292847), this would allow G1 with reasonable heap size on most machines.
>> 
>> Motivational improvements, `SPECjvm2008:serial`:
>> 
>> 
>> # Baseline, G1
>> Serial.test  thrpt   10  1619.863 ? 16.694  ops/s
>> 
>> # Baseline, Serial
>> Serial.test  thrpt   10  1094.438 ? 20.425  ops/s
>> 
>> # Patched, G1
>> Serial.test  thrpt   10  1623.090 ? 17.553  ops/s
>> 
>> # Patched, Serial
>> Serial.test  thrpt   10  1624.531 ? 15.792  ops/s  ; <---- matches G1 now, because young is not tiny
>> 
>> 
>> Before:
>> 
>> 
>> $ build/linux-x86_64-zero-release/jdk/bin/java -Xlog:gc -Xlog:gc+init Alloc.java
>> [0.003s][info][gc     ] Using G1
>> ...
>> [0.005s][info][gc,init] Memory: 125G
>> ...
>> [0.005s][info][gc,init] Heap Region Size: 1M
>> [0.005s][info][gc,init] Heap Min Capacity: 8M
>> [0.005s][info][gc,init] Heap Initial Capacity: 16M
>> [0.005s][info][gc,init] Heap Max Capacity: 256M
>> 
>> 
>> After:
>> 
>> 
>> $ build/linux-x86_64-zero-release/jdk/bin/java -Xlog:gc -Xlog:gc+init Alloc.java
>> [0.003s][info][gc     ] Using G1
>> ...
>> [0.007s][info][gc,init] Memory: 125G
>> ...
>> [0.007s][info][gc,init] Heap Region Size: 16M
>> [0.007s][info][gc,init] Heap Min Capacity: 16M
>> [0.007s][info][gc,init] Heap Initial Capacity: 2016M
>> [0.007s][info][gc,init] Heap Max Capacity: 30208M
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Move to compiler_globals_pd.hpp
>  - Merge branch 'master' into JDK-8294751-zero-larger-heaps
>  - Fix

Marked as reviewed by iklam (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10552

From duke at openjdk.org  Thu Oct  6 16:34:46 2022
From: duke at openjdk.org (Matias Saavedra Silva)
Date: Thu, 6 Oct 2022 16:34:46 GMT
Subject: RFR: 8294691: dynamicArchive/RelativePath.java is running other test
 case
Message-ID: <G2trpJ-VPkXWQk5498aMoaUf99pOcuMxZrTNgS1SS5k=.a7fa1746-8f2d-455d-806c-0c5be527c1f0@github.com>

Test case in RelativePath.java corrected. Verified with tier 1-4 tests.

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

Commit messages:
 - 8294691: dynamicArchive/RelativePath.java is running other test case

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

PR: https://git.openjdk.org/jdk/pull/10597

From iklam at openjdk.org  Thu Oct  6 18:35:21 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 6 Oct 2022 18:35:21 GMT
Subject: RFR: 8294691: dynamicArchive/RelativePath.java is running other
 test case
In-Reply-To: <G2trpJ-VPkXWQk5498aMoaUf99pOcuMxZrTNgS1SS5k=.a7fa1746-8f2d-455d-806c-0c5be527c1f0@github.com>
References: <G2trpJ-VPkXWQk5498aMoaUf99pOcuMxZrTNgS1SS5k=.a7fa1746-8f2d-455d-806c-0c5be527c1f0@github.com>
Message-ID: <IvEwdQHjsdZ0HPvH_NWa28nly70tXnhMqGun2kETZnk=.e2afedb0-0748-4403-b5ba-552518c6c567@github.com>

On Thu, 6 Oct 2022 15:35:50 GMT, Matias Saavedra Silva <duke at openjdk.org> wrote:

> Test case in RelativePath.java corrected. Verified with tier 1-4 tests.

Looks good, just a small nit.

test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/RelativePath.java line 66:

> 64:                     output.shouldContain("Written dynamic archive 0x");
> 65:             });
> 66: 

The new block also uses a relative path so it should be moved to under the `// relative path starting with "."` line.

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

Marked as reviewed by iklam (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10597

From ccheung at openjdk.org  Thu Oct  6 20:59:22 2022
From: ccheung at openjdk.org (Calvin Cheung)
Date: Thu, 6 Oct 2022 20:59:22 GMT
Subject: RFR: 8294691: dynamicArchive/RelativePath.java is running other
 test case
In-Reply-To: <G2trpJ-VPkXWQk5498aMoaUf99pOcuMxZrTNgS1SS5k=.a7fa1746-8f2d-455d-806c-0c5be527c1f0@github.com>
References: <G2trpJ-VPkXWQk5498aMoaUf99pOcuMxZrTNgS1SS5k=.a7fa1746-8f2d-455d-806c-0c5be527c1f0@github.com>
Message-ID: <PShBvErbToPeZ6oug-w8icQbLgI2Y0tM6ECgXmr2-Zs=.d8b53494-98a3-4960-8b6e-22adcd1afb78@github.com>

On Thu, 6 Oct 2022 15:35:50 GMT, Matias Saavedra Silva <duke at openjdk.org> wrote:

> Test case in RelativePath.java corrected. Verified with tier 1-4 tests.

Just one comment below.

test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/RelativePath.java line 61:

> 59:         dump(topArchiveName, "-Xlog:cds",
> 60:             "-Xlog:cds+dynamic=debug",
> 61:             "-cp", "." + File.separator + "hello.jar" + File.pathSeparator + appJar2,

For dumping archive, I think it's better not to use relative path as follows:
`"-cp", appJar + File.pathSeparator + appJar2,`

This test is for validating using relative path during runtime works while relative path wasn't used during dump time.

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

PR: https://git.openjdk.org/jdk/pull/10597

From jsjolen at openjdk.org  Fri Oct  7 11:49:46 2022
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Fri, 7 Oct 2022 11:49:46 GMT
Subject: RFR: 8294950: print_sys_devices_cpu_info doesn't use the provided
 buffer
Message-ID: <Jb7XWBhOiyGShVuh6zr6xvPsv-idy3rbI0pv9KbNKdI=.61d71a35-5809-4427-8358-d813ac534836@github.com>

Removes the 2 unused parameters from `print_sys_devices_cpu_info`

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

Commit messages:
 - Remove unused parameters

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

PR: https://git.openjdk.org/jdk/pull/10604

From dholmes at openjdk.org  Fri Oct  7 13:16:21 2022
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 7 Oct 2022 13:16:21 GMT
Subject: RFR: 8294950: print_sys_devices_cpu_info doesn't use the provided
 buffer
In-Reply-To: <Jb7XWBhOiyGShVuh6zr6xvPsv-idy3rbI0pv9KbNKdI=.61d71a35-5809-4427-8358-d813ac534836@github.com>
References: <Jb7XWBhOiyGShVuh6zr6xvPsv-idy3rbI0pv9KbNKdI=.61d71a35-5809-4427-8358-d813ac534836@github.com>
Message-ID: <M4VZ80JWpV-FyAq8E22VtY2TAjBfkbRIrwcCB6NgA7I=.72ad9d5e-4648-48a6-beda-f7d4e950d028@github.com>

On Fri, 7 Oct 2022 11:41:43 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Removes the 2 unused parameters from `print_sys_devices_cpu_info`

Wow! Dead code from day one - and I reviewed it! :(

Thanks for cleaning up.

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10604

From duke at openjdk.org  Fri Oct  7 20:28:35 2022
From: duke at openjdk.org (Matias Saavedra Silva)
Date: Fri, 7 Oct 2022 20:28:35 GMT
Subject: RFR: 8294691: dynamicArchive/RelativePath.java is running other
 test case [v2]
In-Reply-To: <G2trpJ-VPkXWQk5498aMoaUf99pOcuMxZrTNgS1SS5k=.a7fa1746-8f2d-455d-806c-0c5be527c1f0@github.com>
References: <G2trpJ-VPkXWQk5498aMoaUf99pOcuMxZrTNgS1SS5k=.a7fa1746-8f2d-455d-806c-0c5be527c1f0@github.com>
Message-ID: <42DqVSpKDf3TfkT9WqhUdSyvHabXnyO3ZxqdPjxbnkY=.d9ca1918-fdc1-47d8-a75d-6417eab15bed@github.com>

> Test case in RelativePath.java corrected. Verified with tier 1-4 tests.

Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:

  Changed dump time classpath

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10597/files
  - new: https://git.openjdk.org/jdk/pull/10597/files/3a92d84d..8d369399

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10597&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10597&range=00-01

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

PR: https://git.openjdk.org/jdk/pull/10597

From ccheung at openjdk.org  Fri Oct  7 20:39:37 2022
From: ccheung at openjdk.org (Calvin Cheung)
Date: Fri, 7 Oct 2022 20:39:37 GMT
Subject: RFR: 8294691: dynamicArchive/RelativePath.java is running other
 test case [v2]
In-Reply-To: <42DqVSpKDf3TfkT9WqhUdSyvHabXnyO3ZxqdPjxbnkY=.d9ca1918-fdc1-47d8-a75d-6417eab15bed@github.com>
References: <G2trpJ-VPkXWQk5498aMoaUf99pOcuMxZrTNgS1SS5k=.a7fa1746-8f2d-455d-806c-0c5be527c1f0@github.com>
 <42DqVSpKDf3TfkT9WqhUdSyvHabXnyO3ZxqdPjxbnkY=.d9ca1918-fdc1-47d8-a75d-6417eab15bed@github.com>
Message-ID: <LsKbpIyYqREeGSUSpiiaQwycqhM3ToKR6tGESOlnf2g=.8e04958d-4d60-4276-898d-f93931596cf3@github.com>

On Fri, 7 Oct 2022 20:28:35 GMT, Matias Saavedra Silva <duke at openjdk.org> wrote:

>> Test case in RelativePath.java corrected. Verified with tier 1-4 tests.
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changed dump time classpath

Update looks good. Thanks.

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

Marked as reviewed by ccheung (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10597

From dzhang at openjdk.org  Sat Oct  8 15:33:53 2022
From: dzhang at openjdk.org (Dingli Zhang)
Date: Sat, 8 Oct 2022 15:33:53 GMT
Subject: RFR: 8294623: gtests does not work with googletest release-1.12.0+
In-Reply-To: <GTSRMWikrMJP0xKZRchcdvyMTIA8QLo9Ghl0_bbIsd0=.953fc4ad-4f58-4cd2-b0df-9cd6d1784d21@github.com>
References: <GTSRMWikrMJP0xKZRchcdvyMTIA8QLo9Ghl0_bbIsd0=.953fc4ad-4f58-4cd2-b0df-9cd6d1784d21@github.com>
Message-ID: <B0icLmUNp-T8kpaICnegSVS_Ml_0l9BzVfM1adJSq6c=.69b03ff0-90cb-48f1-93d9-57a24d1c8f5a@github.com>

On Fri, 30 Sep 2022 08:38:29 GMT, Dingli Zhang <dzhang at openjdk.org> wrote:

> The scope of `GTEST_DECLARE_string_(internal_run_death_test)` has been changed in googletest 1.12.0 [1]. So we can see some new compiler errors as below:
> 
> 
> $ bash configure --with-gtest=/home/dingli/jdk-tools/googletest && make run-test TEST="gtest:all"
> 
> * For target hotspot_variant-server_libjvm_gtest_objs_gtestMain.o:
> In file included from /home/dingli/jdk-tools/googletest/googlemock/include/gmock/internal/gmock-port.h:57,
>                  from /home/dingli/jdk-tools/googletest/googlemock/include/gmock/internal/gmock-internal-utils.h:49,
>                  from /home/dingli/jdk-tools/googletest/googlemock/include/gmock/gmock-actions.h:145,
>                  from /home/dingli/jdk-tools/googletest/googlemock/include/gmock/gmock.h:56,
>                  from /home/dingli/jdk/test/hotspot/gtest/unittest.hpp:51,
>                  from /home/dingli/jdk/test/hotspot/gtest/gtestMain.cpp:39:

@dholmes-ora @tstuefe Hi, could anyone please help to take a look at this PR? Thanks in advance for your time!

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

PR: https://git.openjdk.org/jdk/pull/10503

From kbarrett at openjdk.org  Sun Oct  9 00:27:44 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sun, 9 Oct 2022 00:27:44 GMT
Subject: RFR: 8295012: Arena should not derive from CHeapObj<mtNone>
Message-ID: <Vi8c8J_dkW9vUkBsXGMT7WGG3IZBFV4yACs_akgKMgU=.35cda657-a697-42fb-b550-e940638080ec@github.com>

Please review this change to the `Arena` class.  Rather than deriving from
`CHeapObj<mtNone>` (which has the effect of preventing C-heap allocation for an
arena by asserting if such is attempted), instead have no allocation base
class so that `new Arena(...)` will fail to compile.

Testing: mach5 tier1

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

Commit messages:
 - remove base class from Arena

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

PR: https://git.openjdk.org/jdk/pull/10621

From kbarrett at openjdk.org  Sun Oct  9 01:46:16 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sun, 9 Oct 2022 01:46:16 GMT
Subject: RFR: 8294594: Fix cast-function-type warnings in signal handling
 code
In-Reply-To: <Fp96nMrtVhISqFOO67MmNGQPoKyUKV9jgPFtGkoTzt0=.3436f114-0877-4513-91f7-4b611ebd8c8b@github.com>
References: <Fp96nMrtVhISqFOO67MmNGQPoKyUKV9jgPFtGkoTzt0=.3436f114-0877-4513-91f7-4b611ebd8c8b@github.com>
Message-ID: <_vNpHQsYGB0Em5NjD1plwOpmcDcDIqf1T0i7gOj4nKs=.3a01519f-5f75-4805-8b9a-4230d1a31204@github.com>

On Thu, 29 Sep 2022 16:12:11 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> After [JDK-8294314](https://bugs.openjdk.org/browse/JDK-8294314), we would have signals_posix.cpp excluded with cast-function-type warning:

Changes requested by kbarrett (Reviewer).

test/hotspot/gtest/runtime/test_signals.cpp line 49:

> 47:   static void check_handlers() {
> 48:     struct sigaction act, old_SIGFPE_act, old_SIGILL_act;
> 49:     act.sa_handler = CAST_FROM_FN_PTR(sa_handler_t, sig_handler);

This is similarly wrong code that should be fixed instead of doing weird casting dances.  The problem here is that sig_handler has the wrong signature.  It should be just `void sig_handler(int)`.  Fix that and not casts needed.

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

PR: https://git.openjdk.org/jdk/pull/10494

From kbarrett at openjdk.org  Sun Oct  9 01:46:17 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sun, 9 Oct 2022 01:46:17 GMT
Subject: RFR: 8294594: Fix cast-function-type warnings in signal handling
 code
In-Reply-To: <t1X4oiPfM2ZDNQPceadU5bsr1Kg5VQWppWYjWVeHVHI=.14ae324c-b439-4b75-8c64-5c5e33e7d915@github.com>
References: <Fp96nMrtVhISqFOO67MmNGQPoKyUKV9jgPFtGkoTzt0=.3436f114-0877-4513-91f7-4b611ebd8c8b@github.com>
 <t1X4oiPfM2ZDNQPceadU5bsr1Kg5VQWppWYjWVeHVHI=.14ae324c-b439-4b75-8c64-5c5e33e7d915@github.com>
Message-ID: <I3ESJ8EIT8yXtevTGqeOQJVjgj9al7rqAMDVaD17LcE=.af674e89-edfe-4b84-aaa5-88ce92561a32@github.com>

On Fri, 30 Sep 2022 04:53:51 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> After [JDK-8294314](https://bugs.openjdk.org/browse/JDK-8294314), we would have signals_posix.cpp excluded with cast-function-type warning:
>
> src/hotspot/os/posix/signals_posix.cpp line 1727:
> 
>> 1725:   // Set up signal handler for suspend/resume
>> 1726:   act.sa_flags = SA_RESTART|SA_SIGINFO;
>> 1727:   act.sa_handler = CAST_FROM_FN_PTR(sa_handler_t, SR_handler);
> 
> The underlying cast in the macro seems a little odd for this situation but if it appeases the compiler then that is fine.

No, don't do this.  The code is just wrong, and should be fixed.

We have a struct sigaction.  We've set the sa_flags member to a value that
includes SA_SIGINFO.  That means the 3 argument sa_sigaction handler is
supposed to be invoked.

We're storing the SR_handler (cast to a value matching the type of the
sa_handler member of the sigaction). This is "working" purely by accident.
Apparently on all POSIX platforms we support, the sa_handler and sa_sigaction
occupy the same memory (being in a union, which is permitted by the spec).

The signature for SR_handler should be changed from
void SR_handler(int, siginfo_t*, ucontext_t*)
to
void SR_handler(int, siginfo_t*, void*)
and adjust the code to deal with the change to the type of the 3rd parameter.

Then we can just assign the sa_sigaction member to SR_handler without any casts.

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

PR: https://git.openjdk.org/jdk/pull/10494

From ccheung at openjdk.org  Sun Oct  9 02:35:11 2022
From: ccheung at openjdk.org (Calvin Cheung)
Date: Sun, 9 Oct 2022 02:35:11 GMT
Subject: RFR: 8279366: CDS should allow alternative locations for JAR files in
 classpath
Message-ID: <gjn5N9Lmavel1A8AHZFHxbp0J2l6XklY_-Pr-N04k7g=.dd8b5ed1-2c55-40cf-88e1-770e16c4c911@github.com>

Please review this RFE for allowing alternative locations for jar files in the app classpath during runtime.

During dump time, the longest common prefix of the app classpath will be stored in the CDS archive header. During runtime, existing checks of the app classpath will be performed first. Upon failure, the longest common prefix of the runtime app classpath will be computed and another check of the app classpath will be performed ignoring the longest common prefix.

Refer to the [bug report comment](https://bugs.openjdk.org/browse/JDK-8279366?focusedCommentId=14509536&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14509536) for an example.

Passed tiers 1 - 4 testing (including the new tests).

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

Commit messages:
 - remove trailing whitespace
 - 8279366: CDS should allow alternative locations for JAR files in classpath

Changes: https://git.openjdk.org/jdk/pull/10615/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10615&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8279366
  Stats: 510 lines in 9 files changed: 492 ins; 0 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/10615.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10615/head:pull/10615

PR: https://git.openjdk.org/jdk/pull/10615

From kbarrett at openjdk.org  Sun Oct  9 03:00:09 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sun, 9 Oct 2022 03:00:09 GMT
Subject: RFR: 8294594: Fix cast-function-type warnings in signal handling
 code
In-Reply-To: <_vNpHQsYGB0Em5NjD1plwOpmcDcDIqf1T0i7gOj4nKs=.3a01519f-5f75-4805-8b9a-4230d1a31204@github.com>
References: <Fp96nMrtVhISqFOO67MmNGQPoKyUKV9jgPFtGkoTzt0=.3436f114-0877-4513-91f7-4b611ebd8c8b@github.com>
 <_vNpHQsYGB0Em5NjD1plwOpmcDcDIqf1T0i7gOj4nKs=.3a01519f-5f75-4805-8b9a-4230d1a31204@github.com>
Message-ID: <jpL-bb0C1xWA3yIZaALPQCGpur2GSoUZx4lPhvTZrik=.d1b8ab36-653c-49a5-a531-4817ec0585df@github.com>

On Sun, 9 Oct 2022 01:43:26 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> After [JDK-8294314](https://bugs.openjdk.org/browse/JDK-8294314), we would have signals_posix.cpp excluded with cast-function-type warning:
>
> test/hotspot/gtest/runtime/test_signals.cpp line 49:
> 
>> 47:   static void check_handlers() {
>> 48:     struct sigaction act, old_SIGFPE_act, old_SIGILL_act;
>> 49:     act.sa_handler = CAST_FROM_FN_PTR(sa_handler_t, sig_handler);
> 
> This is similarly wrong code that should be fixed instead of doing weird casting dances.  The problem here is that sig_handler has the wrong signature.  It should be just `void sig_handler(int)`.  Fix that and not casts needed.

This one is even worse than the other.  Here we're installing a handler function taking 3 arguments in such a way that it will only be called with one.  Weee!

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

PR: https://git.openjdk.org/jdk/pull/10494

From kbarrett at openjdk.org  Sun Oct  9 03:02:07 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sun, 9 Oct 2022 03:02:07 GMT
Subject: RFR: 8295014: Remove unnecessary explicit casts to void* in
 CHeapObjBase
Message-ID: <UyIQedVM9M-bj2FAsbKw54-N7vpFj_kES9s2Vj_vBEU=.139f9d8d-4963-432a-a754-189ed33dcf83@github.com>

Please review this change to CHeapObjBase that removes unnecessary explicit
casts from char* to void*.

Testing: mach5 tier1

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

Commit messages:
 - remove unnecessary casts

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

PR: https://git.openjdk.org/jdk/pull/10623

From kbarrett at openjdk.org  Sun Oct  9 05:41:53 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sun, 9 Oct 2022 05:41:53 GMT
Subject: RFR: 8294594: Fix cast-function-type warnings in signal handling
 code
In-Reply-To: <Fp96nMrtVhISqFOO67MmNGQPoKyUKV9jgPFtGkoTzt0=.3436f114-0877-4513-91f7-4b611ebd8c8b@github.com>
References: <Fp96nMrtVhISqFOO67MmNGQPoKyUKV9jgPFtGkoTzt0=.3436f114-0877-4513-91f7-4b611ebd8c8b@github.com>
Message-ID: <iYezptZ6KPvk3Atzbvuhs-QRWd9uuS6WyrEq4MiOHGE=.94287867-eebd-494a-b97d-6d944c911edc@github.com>

On Thu, 29 Sep 2022 16:12:11 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> After [JDK-8294314](https://bugs.openjdk.org/browse/JDK-8294314), we would have signals_posix.cpp excluded with cast-function-type warning:

make/hotspot/lib/CompileJvm.gmk line 147:

> 145: # Now set up the actual compilation of the main hotspot native library
> 146: 
> 147: # TODO: Should merge once JDK-8294314 is in.

Left-over comment should be removed.

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

PR: https://git.openjdk.org/jdk/pull/10494

From jsjolen at openjdk.org  Sun Oct  9 16:06:52 2022
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Sun, 9 Oct 2022 16:06:52 GMT
Subject: RFR: 8295014: Remove unnecessary explicit casts to void* in
 CHeapObjBase
In-Reply-To: <UyIQedVM9M-bj2FAsbKw54-N7vpFj_kES9s2Vj_vBEU=.139f9d8d-4963-432a-a754-189ed33dcf83@github.com>
References: <UyIQedVM9M-bj2FAsbKw54-N7vpFj_kES9s2Vj_vBEU=.139f9d8d-4963-432a-a754-189ed33dcf83@github.com>
Message-ID: <L18m7x4xWmFx5G1_v9JnGgz9cEkisclWQppqjIRGqpw=.70c28cd2-289a-4a8f-b9a0-7905cd1f0845@github.com>

On Sun, 9 Oct 2022 02:52:37 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to CHeapObjBase that removes unnecessary explicit
> casts from char* to void*.
> 
> Testing: mach5 tier1

This looks good to me, thank you for the change.

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

Marked as reviewed by jsjolen (Author).

PR: https://git.openjdk.org/jdk/pull/10623

From dholmes at openjdk.org  Mon Oct 10 04:49:32 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 10 Oct 2022 04:49:32 GMT
Subject: RFR: 8294594: Fix cast-function-type warnings in signal handling
 code
In-Reply-To: <I3ESJ8EIT8yXtevTGqeOQJVjgj9al7rqAMDVaD17LcE=.af674e89-edfe-4b84-aaa5-88ce92561a32@github.com>
References: <Fp96nMrtVhISqFOO67MmNGQPoKyUKV9jgPFtGkoTzt0=.3436f114-0877-4513-91f7-4b611ebd8c8b@github.com>
 <t1X4oiPfM2ZDNQPceadU5bsr1Kg5VQWppWYjWVeHVHI=.14ae324c-b439-4b75-8c64-5c5e33e7d915@github.com>
 <I3ESJ8EIT8yXtevTGqeOQJVjgj9al7rqAMDVaD17LcE=.af674e89-edfe-4b84-aaa5-88ce92561a32@github.com>
Message-ID: <KVRtujr_dFUhRwCBFdRvoP9mAFrElYXxLIUvhHb2ws4=.d8188453-59de-413b-b07e-744407f61013@github.com>

On Sun, 9 Oct 2022 01:40:29 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> src/hotspot/os/posix/signals_posix.cpp line 1727:
>> 
>>> 1725:   // Set up signal handler for suspend/resume
>>> 1726:   act.sa_flags = SA_RESTART|SA_SIGINFO;
>>> 1727:   act.sa_handler = CAST_FROM_FN_PTR(sa_handler_t, SR_handler);
>> 
>> The underlying cast in the macro seems a little odd for this situation but if it appeases the compiler then that is fine.
>
> No, don't do this.  The code is just wrong, and should be fixed.
> 
> We have a struct sigaction.  We've set the sa_flags member to a value that
> includes SA_SIGINFO.  That means the 3 argument sa_sigaction handler is
> supposed to be invoked.
> 
> We're storing the SR_handler (cast to a value matching the type of the
> sa_handler member of the sigaction). This is "working" purely by accident.
> Apparently on all POSIX platforms we support, the sa_handler and sa_sigaction
> occupy the same memory (being in a union, which is permitted by the spec).
> 
> The signature for SR_handler should be changed from
> void SR_handler(int, siginfo_t*, ucontext_t*)
> to
> void SR_handler(int, siginfo_t*, void*)
> and adjust the code to deal with the change to the type of the 3rd parameter.
> 
> Then we can just assign the sa_sigaction member to SR_handler without any casts.

But this is how POSIX specifies it: `sigaction.sa_handler` is declared as `void(*) (int)` - so that is what we have to use when storing the handler address. But the handler itself has to be the three arg version because that is how it will be called.

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

PR: https://git.openjdk.org/jdk/pull/10494

From dholmes at openjdk.org  Mon Oct 10 04:49:32 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 10 Oct 2022 04:49:32 GMT
Subject: RFR: 8294594: Fix cast-function-type warnings in signal handling
 code
In-Reply-To: <KVRtujr_dFUhRwCBFdRvoP9mAFrElYXxLIUvhHb2ws4=.d8188453-59de-413b-b07e-744407f61013@github.com>
References: <Fp96nMrtVhISqFOO67MmNGQPoKyUKV9jgPFtGkoTzt0=.3436f114-0877-4513-91f7-4b611ebd8c8b@github.com>
 <t1X4oiPfM2ZDNQPceadU5bsr1Kg5VQWppWYjWVeHVHI=.14ae324c-b439-4b75-8c64-5c5e33e7d915@github.com>
 <I3ESJ8EIT8yXtevTGqeOQJVjgj9al7rqAMDVaD17LcE=.af674e89-edfe-4b84-aaa5-88ce92561a32@github.com>
 <KVRtujr_dFUhRwCBFdRvoP9mAFrElYXxLIUvhHb2ws4=.d8188453-59de-413b-b07e-744407f61013@github.com>
Message-ID: <5gHhzngXCdin5SaTRi41oVHEasuLPFxqGZDvRZqNPPc=.fa6cc437-0514-4990-ae6a-8e4b8b3016bb@github.com>

On Mon, 10 Oct 2022 04:43:03 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> No, don't do this.  The code is just wrong, and should be fixed.
>> 
>> We have a struct sigaction.  We've set the sa_flags member to a value that
>> includes SA_SIGINFO.  That means the 3 argument sa_sigaction handler is
>> supposed to be invoked.
>> 
>> We're storing the SR_handler (cast to a value matching the type of the
>> sa_handler member of the sigaction). This is "working" purely by accident.
>> Apparently on all POSIX platforms we support, the sa_handler and sa_sigaction
>> occupy the same memory (being in a union, which is permitted by the spec).
>> 
>> The signature for SR_handler should be changed from
>> void SR_handler(int, siginfo_t*, ucontext_t*)
>> to
>> void SR_handler(int, siginfo_t*, void*)
>> and adjust the code to deal with the change to the type of the 3rd parameter.
>> 
>> Then we can just assign the sa_sigaction member to SR_handler without any casts.
>
> But this is how POSIX specifies it: `sigaction.sa_handler` is declared as `void(*) (int)` - so that is what we have to use when storing the handler address. But the handler itself has to be the three arg version because that is how it will be called.

Oh! Sorry I wasn't reading the `sigaction` definition properly I missed it contains two "handler" slots and we are using the wrong one!

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

PR: https://git.openjdk.org/jdk/pull/10494

From dholmes at openjdk.org  Mon Oct 10 04:59:39 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 10 Oct 2022 04:59:39 GMT
Subject: RFR: 8294623: gtests does not work with googletest release-1.12.0+
In-Reply-To: <B0icLmUNp-T8kpaICnegSVS_Ml_0l9BzVfM1adJSq6c=.69b03ff0-90cb-48f1-93d9-57a24d1c8f5a@github.com>
References: <GTSRMWikrMJP0xKZRchcdvyMTIA8QLo9Ghl0_bbIsd0=.953fc4ad-4f58-4cd2-b0df-9cd6d1784d21@github.com>
 <B0icLmUNp-T8kpaICnegSVS_Ml_0l9BzVfM1adJSq6c=.69b03ff0-90cb-48f1-93d9-57a24d1c8f5a@github.com>
Message-ID: <TTmlUnjZua976e-yq4RhojkIqAKEYD0tmlsswuvD1h0=.4c60cc26-c813-4ce8-978f-7eaf2689c174@github.com>

On Sat, 8 Oct 2022 07:04:44 GMT, Dingli Zhang <dzhang at openjdk.org> wrote:

>> The scope of `GTEST_DECLARE_string_(internal_run_death_test)` has been changed in googletest 1.12.0 [1]. So we can see some new compiler errors as below:
>> 
>> 
>> $ bash configure --with-gtest=/home/dingli/jdk-tools/googletest && make run-test TEST="gtest:all"
>> 
>> * For target hotspot_variant-server_libjvm_gtest_objs_gtestMain.o:
>> In file included from /home/dingli/jdk-tools/googletest/googlemock/include/gmock/internal/gmock-port.h:57,
>>                  from /home/dingli/jdk-tools/googletest/googlemock/include/gmock/internal/gmock-internal-utils.h:49,
>>                  from /home/dingli/jdk-tools/googletest/googlemock/include/gmock/gmock-actions.h:145,
>>                  from /home/dingli/jdk-tools/googletest/googlemock/include/gmock/gmock.h:56,
>>                  from /home/dingli/jdk/test/hotspot/gtest/unittest.hpp:51,
>>                  from /home/dingli/jdk/test/hotspot/gtest/gtestMain.cpp:39:
>
> @dholmes-ora @tstuefe Hi, could anyone please help to take a look at this PR? Thanks in advance for your time!

@DingliZhang I've asked if anyone is familiar enough with googletest to review this, as I am not familiar with it.

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

PR: https://git.openjdk.org/jdk/pull/10503

From dholmes at openjdk.org  Mon Oct 10 05:06:51 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 10 Oct 2022 05:06:51 GMT
Subject: RFR: 8295012: Arena should not derive from CHeapObj<mtNone>
In-Reply-To: <Vi8c8J_dkW9vUkBsXGMT7WGG3IZBFV4yACs_akgKMgU=.35cda657-a697-42fb-b550-e940638080ec@github.com>
References: <Vi8c8J_dkW9vUkBsXGMT7WGG3IZBFV4yACs_akgKMgU=.35cda657-a697-42fb-b550-e940638080ec@github.com>
Message-ID: <tM33wVKktWNEFCeCUmRsZZ-8SwIapt2i00eh-z2wYj8=.d1cd0634-c013-4062-80ab-529a222e036d@github.com>

On Sun, 9 Oct 2022 00:21:18 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to the `Arena` class.  Rather than deriving from
> `CHeapObj<mtNone>` (which has the effect of preventing C-heap allocation for an
> arena by asserting if such is attempted), instead have no allocation base
> class so that `new Arena(...)` will fail to compile.
> 
> Testing: mach5 tier1

src/hotspot/share/memory/arena.hpp line 89:

> 87: //------------------------------Arena------------------------------------------
> 88: // Fast allocation of memory
> 89: class Arena {

The allocation base class tells the reader that `Arena` has special allocation constraints, by removing this it is not apparent there are any such constraints. Can we at least add a comment?

I confess I've forgotten how not having an allocation base class prevents use of `new Foo()` ??

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

PR: https://git.openjdk.org/jdk/pull/10621

From dholmes at openjdk.org  Mon Oct 10 05:07:54 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 10 Oct 2022 05:07:54 GMT
Subject: RFR: 8295014: Remove unnecessary explicit casts to void* in
 CHeapObjBase
In-Reply-To: <UyIQedVM9M-bj2FAsbKw54-N7vpFj_kES9s2Vj_vBEU=.139f9d8d-4963-432a-a754-189ed33dcf83@github.com>
References: <UyIQedVM9M-bj2FAsbKw54-N7vpFj_kES9s2Vj_vBEU=.139f9d8d-4963-432a-a754-189ed33dcf83@github.com>
Message-ID: <C3PlWYCodghZw4DGbv1RRP0nkVXpRjJp_OkIwG772wM=.cf6102ee-0ced-446a-830d-b1fc12d7da37@github.com>

On Sun, 9 Oct 2022 02:52:37 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to CHeapObjBase that removes unnecessary explicit
> casts from char* to void*.
> 
> Testing: mach5 tier1

Looks good - and cleaner! Thanks.

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10623

From iklam at openjdk.org  Mon Oct 10 06:00:51 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 10 Oct 2022 06:00:51 GMT
Subject: RFR: 8279366: CDS should allow alternative locations for JAR files
 in classpath
In-Reply-To: <gjn5N9Lmavel1A8AHZFHxbp0J2l6XklY_-Pr-N04k7g=.dd8b5ed1-2c55-40cf-88e1-770e16c4c911@github.com>
References: <gjn5N9Lmavel1A8AHZFHxbp0J2l6XklY_-Pr-N04k7g=.dd8b5ed1-2c55-40cf-88e1-770e16c4c911@github.com>
Message-ID: <rAreJqrssxr7i2L-75OXjAKwQgCK3ON69YKpwPL9qi8=.29d1ccf0-9907-4cc8-834f-c8bce637aaf7@github.com>

On Fri, 7 Oct 2022 22:59:09 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> Please review this RFE for allowing alternative locations for jar files in the app classpath during runtime.
> 
> During dump time, the longest common prefix of the app classpath will be stored in the CDS archive header. During runtime, existing checks of the app classpath will be performed first. Upon failure, the longest common prefix of the runtime app classpath will be computed and another check of the app classpath will be performed ignoring the longest common prefix.
> 
> Refer to the [bug report comment](https://bugs.openjdk.org/browse/JDK-8279366?focusedCommentId=14509536&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14509536) for an example.
> 
> Passed tiers 1 - 4 testing (including the new tests).

Changes requested by iklam (Reviewer).

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

> 259:   set_base_archive_name_size((unsigned int)base_archive_name_size);
> 260:   set_common_app_classpath_offset((unsigned int)common_app_classpath_offset);
> 261:   set_common_app_classpath_size((unsigned int)common_app_classpath_size);

I think there's no need to record the actual `common_app_classpath` string into the `FileMapHeader`. It should be enough to just store the length of the longest common path prefix. E.g., at runtime, the function `FileMapInfo::check_paths_ignoring_common_path` currently only uses `strlen(dumptime_prefix)`.

Also, `longest_common_app_classpath` can just return the length instead of the string.

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

> 893:   for (int i = 1; i < num_paths; i++) {
> 894:     chr = strrchr((char*)rp_array->at(i), *os::file_separator());
> 895:     size_t curr_len = chr != NULL ? chr - rp_array->at(i) + 1 : strlen(rp_array->at(i)) + 1;

If `chr == NULL`, it means we have a file name only, with no file separator. In this case, there will be no common prefix, so this function can return NULL immediately.

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

> 913:     *(lcp + j) = c;
> 914:   }
> 915: 

Need to check for this case as well:


rp[0] = "/x/a/Foo.jar"
rp[1] = "/x/aa/Bar.jar"


I think the current code will incorrectly return "/x/a"

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

> 940:     const char* runtime_path = rp_array->at(i)  + strlen(runtime_prefix);
> 941:     if (strcmp(dumptime_path, runtime_path) != 0) {
> 942:       mismatch = true;

Can this be simplified as `return false` so you don't need to maintain the `mismatch` variable?

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

> 1077:         mismatch = check_paths_ignoring_common_path(j, shared_app_paths_len, rp_array,
> 1078:                                                     (const char*)dumptime_prefix, runtime_prefix);
> 1079:       }

For completeness, we should allow empty prefixes. For example:

dump: `-cp foo.jar:x/bar.jar`
run: `-cp a/foo.jar:a/x/bar.jar`

or

dump: `-cp a/foo.jar:a/x/bar.jar`
run: `-cp foo.jar:x/bar.jar`

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

PR: https://git.openjdk.org/jdk/pull/10615

From dzhang at openjdk.org  Mon Oct 10 06:39:38 2022
From: dzhang at openjdk.org (Dingli Zhang)
Date: Mon, 10 Oct 2022 06:39:38 GMT
Subject: RFR: 8294623: gtests does not work with googletest release-1.12.0+
In-Reply-To: <B0icLmUNp-T8kpaICnegSVS_Ml_0l9BzVfM1adJSq6c=.69b03ff0-90cb-48f1-93d9-57a24d1c8f5a@github.com>
References: <GTSRMWikrMJP0xKZRchcdvyMTIA8QLo9Ghl0_bbIsd0=.953fc4ad-4f58-4cd2-b0df-9cd6d1784d21@github.com>
 <B0icLmUNp-T8kpaICnegSVS_Ml_0l9BzVfM1adJSq6c=.69b03ff0-90cb-48f1-93d9-57a24d1c8f5a@github.com>
Message-ID: <yCCwD379-NdX5QV_jfKs_gpzuvfz1CkcdTe2CdNJr-Q=.3fa72e71-b35a-4de8-84a2-066fdebbf811@github.com>

On Sat, 8 Oct 2022 07:04:44 GMT, Dingli Zhang <dzhang at openjdk.org> wrote:

>> The scope of `GTEST_DECLARE_string_(internal_run_death_test)` has been changed in googletest 1.12.0 [1]. So we can see some new compiler errors as below:
>> 
>> 
>> $ bash configure --with-gtest=/home/dingli/jdk-tools/googletest && make run-test TEST="gtest:all"
>> 
>> * For target hotspot_variant-server_libjvm_gtest_objs_gtestMain.o:
>> In file included from /home/dingli/jdk-tools/googletest/googlemock/include/gmock/internal/gmock-port.h:57,
>>                  from /home/dingli/jdk-tools/googletest/googlemock/include/gmock/internal/gmock-internal-utils.h:49,
>>                  from /home/dingli/jdk-tools/googletest/googlemock/include/gmock/gmock-actions.h:145,
>>                  from /home/dingli/jdk-tools/googletest/googlemock/include/gmock/gmock.h:56,
>>                  from /home/dingli/jdk/test/hotspot/gtest/unittest.hpp:51,
>>                  from /home/dingli/jdk/test/hotspot/gtest/gtestMain.cpp:39:
>
> @dholmes-ora @tstuefe Hi, could anyone please help to take a look at this PR? Thanks in advance for your time!

> @DingliZhang I've asked if anyone is familiar enough with googletest to review this, as I am not familiar with it.

Hi @dholmes-ora, thank you for your help!

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

PR: https://git.openjdk.org/jdk/pull/10503

From stefank at openjdk.org  Mon Oct 10 08:55:12 2022
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 10 Oct 2022 08:55:12 GMT
Subject: RFR: 8295012: Arena should not derive from CHeapObj<mtNone>
In-Reply-To: <Vi8c8J_dkW9vUkBsXGMT7WGG3IZBFV4yACs_akgKMgU=.35cda657-a697-42fb-b550-e940638080ec@github.com>
References: <Vi8c8J_dkW9vUkBsXGMT7WGG3IZBFV4yACs_akgKMgU=.35cda657-a697-42fb-b550-e940638080ec@github.com>
Message-ID: <hEw3XZtRzSiXSOfV9zJy2XvNBlM8D2FX0d7wHj_GC_I=.f623b42b-917e-4465-826a-4921af6863fe@github.com>

On Sun, 9 Oct 2022 00:21:18 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to the `Arena` class.  Rather than deriving from
> `CHeapObj<mtNone>` (which has the effect of preventing C-heap allocation for an
> arena by asserting if such is attempted), instead have no allocation base
> class so that `new Arena(...)` will fail to compile.
> 
> Testing: mach5 tier1

What's the reason for keeping the new/delete operators in Arena, instead of inheriting from the newly introduced CHeapObjBase class?

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

PR: https://git.openjdk.org/jdk/pull/10621

From stefank at openjdk.org  Mon Oct 10 08:55:13 2022
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 10 Oct 2022 08:55:13 GMT
Subject: RFR: 8295012: Arena should not derive from CHeapObj<mtNone>
In-Reply-To: <tM33wVKktWNEFCeCUmRsZZ-8SwIapt2i00eh-z2wYj8=.d1cd0634-c013-4062-80ab-529a222e036d@github.com>
References: <Vi8c8J_dkW9vUkBsXGMT7WGG3IZBFV4yACs_akgKMgU=.35cda657-a697-42fb-b550-e940638080ec@github.com>
 <tM33wVKktWNEFCeCUmRsZZ-8SwIapt2i00eh-z2wYj8=.d1cd0634-c013-4062-80ab-529a222e036d@github.com>
Message-ID: <CxdUCcjNOrMjla6lKyjXFih0qbALp2mde3qoCxk72Zw=.30b2af48-da80-4614-9063-87744cae1923@github.com>

On Mon, 10 Oct 2022 05:03:02 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Please review this change to the `Arena` class.  Rather than deriving from
>> `CHeapObj<mtNone>` (which has the effect of preventing C-heap allocation for an
>> arena by asserting if such is attempted), instead have no allocation base
>> class so that `new Arena(...)` will fail to compile.
>> 
>> Testing: mach5 tier1
>
> src/hotspot/share/memory/arena.hpp line 89:
> 
>> 87: //------------------------------Arena------------------------------------------
>> 88: // Fast allocation of memory
>> 89: class Arena {
> 
> The allocation base class tells the reader that `Arena` has special allocation constraints, by removing this it is not apparent there are any such constraints. Can we at least add a comment?
> 
> I confess I've forgotten how not having an allocation base class prevents use of `new Foo()` ??

We have a link-time check in debug builds that fails the build if someone tries to use the global new operators.

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

PR: https://git.openjdk.org/jdk/pull/10621

From stefank at openjdk.org  Mon Oct 10 08:56:01 2022
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 10 Oct 2022 08:56:01 GMT
Subject: RFR: 8295014: Remove unnecessary explicit casts to void* in
 CHeapObjBase
In-Reply-To: <UyIQedVM9M-bj2FAsbKw54-N7vpFj_kES9s2Vj_vBEU=.139f9d8d-4963-432a-a754-189ed33dcf83@github.com>
References: <UyIQedVM9M-bj2FAsbKw54-N7vpFj_kES9s2Vj_vBEU=.139f9d8d-4963-432a-a754-189ed33dcf83@github.com>
Message-ID: <iGafqYfh5VzzguvxIv5VCPATLQMr6Upk2AWTTN8DJL4=.cb49dcf9-ddcd-477f-a86e-4b9d3e955894@github.com>

On Sun, 9 Oct 2022 02:52:37 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to CHeapObjBase that removes unnecessary explicit
> casts from char* to void*.
> 
> Testing: mach5 tier1

Marked as reviewed by stefank (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10623

From aturbanov at openjdk.org  Mon Oct 10 10:35:01 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 10 Oct 2022 10:35:01 GMT
Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems
 [v3]
In-Reply-To: <6EJTmtCW0gnRRF6rQhE-uA2-l9Hz8q0CEOexDdFPtKs=.1bf44414-ffe9-4d4f-9105-eddd8f4130cf@github.com>
References: <pqUZH2ArAs3HzvROblncKitEBqbBLHVTUjgXvOzu3EQ=.7970acec-5eb8-4741-97d5-7d7d08f8a515@github.com>
 <6EJTmtCW0gnRRF6rQhE-uA2-l9Hz8q0CEOexDdFPtKs=.1bf44414-ffe9-4d4f-9105-eddd8f4130cf@github.com>
Message-ID: <Y85uuln2T09SqeRPceibPlJTK_D8axQNXgseWiY9UZo=.12d07524-8e08-4d1e-8bde-8fdf1f20c706@github.com>

On Wed, 18 May 2022 18:14:52 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this change to the cgroup v1 subsystem which makes it more resilient on some of the stranger systems. Unfortunately, I wasn't able to re-create a similar system as the reporter. The idea of using the longest substring match for the cgroupv1 file paths was based on the fact that on systemd systems processes run in separate scopes and the maven forked test runner might exhibit this property. For that it makes sense to use the common ancestor path. Nothing changes in the common cases where the `cgroup_path` matches `_root` and when the `_root` is `/` (container the former, host system the latter).
>> 
>> In addition, the code paths which are susceptible to throw NPE have been hardened to catch those situations. Should it happen in the future it makes more sense (to me) to not have accurate container detection in favor of continuing to keep running.
>> 
>> Finally, with the added unit-tests a bug was uncovered on the "substring" match case of cgroup paths in hotspot. `p` returned from `strstr` can never point to `_root` as it's used as the "needle" to find in "haystack" `cgroup_path` (not the other way round).
>> 
>> Testing:
>> - [x] Added unit tests
>> - [x] GHA
>> - [x] Container tests on cgroups v1 Linux. Continue to pass
>
> Severin Gehwolf has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Refactor hotspot gtest
>  - Separate into function. Fix comment.

test/jdk/jdk/internal/platform/cgroup/TestCgroupSubsystemFactory.java line 224:

> 222:             "1:name=systemd:/user.slice/user-1000.slice/user at 1000.service/apps.slice/apps-org.gnome.Terminal.slice/vte-spawn-3c00b338-5b65-439f-8e97-135e183d135d.scope\n" +
> 223:             "0::/user.slice/user-1000.slice/user at 1000.service/apps.slice/apps-org.gnome.Terminal.slice/vte-spawn-3c00b338-5b65-439f-8e97-135e183d135d.scope\n";
> 224:     private  String cgroupv1SelfPrefixContent = "9:memory:/user.slice/user-1000.slice/session-3.scope\n";

Let's remove one redundant space
Suggestion:

    private String cgroupv1SelfPrefixContent = "9:memory:/user.slice/user-1000.slice/session-3.scope\n";

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

PR: https://git.openjdk.org/jdk/pull/8629

From stefank at openjdk.org  Mon Oct 10 11:54:49 2022
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 10 Oct 2022 11:54:49 GMT
Subject: RFR: 8294950: print_sys_devices_cpu_info doesn't use the provided
 buffer
In-Reply-To: <Jb7XWBhOiyGShVuh6zr6xvPsv-idy3rbI0pv9KbNKdI=.61d71a35-5809-4427-8358-d813ac534836@github.com>
References: <Jb7XWBhOiyGShVuh6zr6xvPsv-idy3rbI0pv9KbNKdI=.61d71a35-5809-4427-8358-d813ac534836@github.com>
Message-ID: <AS7Vg4x8FsJZLEWUrwwTkAuiOvd9iiZwDMecIwXAftU=.f42e3266-694a-4079-8b9e-3b3d009e790f@github.com>

On Fri, 7 Oct 2022 11:41:43 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Removes the 2 unused parameters from `print_sys_devices_cpu_info`

Marked as reviewed by stefank (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10604

From shade at openjdk.org  Mon Oct 10 12:09:51 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 10 Oct 2022 12:09:51 GMT
Subject: RFR: 8294594: Fix cast-function-type warnings in signal handling
 code
In-Reply-To: <iYezptZ6KPvk3Atzbvuhs-QRWd9uuS6WyrEq4MiOHGE=.94287867-eebd-494a-b97d-6d944c911edc@github.com>
References: <Fp96nMrtVhISqFOO67MmNGQPoKyUKV9jgPFtGkoTzt0=.3436f114-0877-4513-91f7-4b611ebd8c8b@github.com>
 <iYezptZ6KPvk3Atzbvuhs-QRWd9uuS6WyrEq4MiOHGE=.94287867-eebd-494a-b97d-6d944c911edc@github.com>
Message-ID: <gw8Po8np2WcQ2_wRwJVx9lFeIbgl5ivTMaByaFHoJno=.f80c365c-29f4-4458-89cc-8f9a0e82e243@github.com>

On Sun, 9 Oct 2022 05:39:26 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> After [JDK-8294314](https://bugs.openjdk.org/browse/JDK-8294314), we would have signals_posix.cpp excluded with cast-function-type warning:
>
> make/hotspot/lib/CompileJvm.gmk line 147:
> 
>> 145: # Now set up the actual compilation of the main hotspot native library
>> 146: 
>> 147: # TODO: Should merge once JDK-8294314 is in.
> 
> Left-over comment should be removed.

I shall, once JDK-8294314 integrates. I am keeping those build changes to force a merge conflict.

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

PR: https://git.openjdk.org/jdk/pull/10494

From shade at openjdk.org  Mon Oct 10 12:29:51 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 10 Oct 2022 12:29:51 GMT
Subject: RFR: 8294751: Zero: Allow larger default heaps [v2]
In-Reply-To: <MG-Wb8zUE0JI4L-owNCxUkP6qD5pDVRgFWhtjTcGv1A=.63c600bd-66cc-4836-9aee-7ed24ca7d781@github.com>
References: <onIurPQPJzorzHjZNvhxPk12j0zySZeRR1rid9KW0Yg=.e42155f8-d8af-4496-b72b-350e1dbf8e09@github.com>
 <MG-Wb8zUE0JI4L-owNCxUkP6qD5pDVRgFWhtjTcGv1A=.63c600bd-66cc-4836-9aee-7ed24ca7d781@github.com>
Message-ID: <jfpEfvuDsG4PLbp4c60zGeIaDFhZRSnJjphNtcYkUUw=.345dc922-6c62-472f-94ea-bbf8d21d7caf@github.com>

On Thu, 6 Oct 2022 10:13:01 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Zero is currently defaulting to `MaxRAM=1G` on all machines. It is set in `compiler_globals.pd` under `#if !defined(COMPILER1) && !defined(COMPILER2) && !INCLUDE_JVMCI`.
>> 
>> Zero supports lots of GCs, and there is little sense to penalize it unnecessarily with too small heaps. After [JDK-8292847](https://bugs.openjdk.org/browse/JDK-8292847), this would allow G1 with reasonable heap size on most machines.
>> 
>> Motivational improvements, `SPECjvm2008:serial`:
>> 
>> 
>> # Baseline, G1
>> Serial.test  thrpt   10  1619.863 ? 16.694  ops/s
>> 
>> # Baseline, Serial
>> Serial.test  thrpt   10  1094.438 ? 20.425  ops/s
>> 
>> # Patched, G1
>> Serial.test  thrpt   10  1623.090 ? 17.553  ops/s
>> 
>> # Patched, Serial
>> Serial.test  thrpt   10  1624.531 ? 15.792  ops/s  ; <---- matches G1 now, because young is not tiny
>> 
>> 
>> Before:
>> 
>> 
>> $ build/linux-x86_64-zero-release/jdk/bin/java -Xlog:gc -Xlog:gc+init Alloc.java
>> [0.003s][info][gc     ] Using G1
>> ...
>> [0.005s][info][gc,init] Memory: 125G
>> ...
>> [0.005s][info][gc,init] Heap Region Size: 1M
>> [0.005s][info][gc,init] Heap Min Capacity: 8M
>> [0.005s][info][gc,init] Heap Initial Capacity: 16M
>> [0.005s][info][gc,init] Heap Max Capacity: 256M
>> 
>> 
>> After:
>> 
>> 
>> $ build/linux-x86_64-zero-release/jdk/bin/java -Xlog:gc -Xlog:gc+init Alloc.java
>> [0.003s][info][gc     ] Using G1
>> ...
>> [0.007s][info][gc,init] Memory: 125G
>> ...
>> [0.007s][info][gc,init] Heap Region Size: 16M
>> [0.007s][info][gc,init] Heap Min Capacity: 16M
>> [0.007s][info][gc,init] Heap Initial Capacity: 2016M
>> [0.007s][info][gc,init] Heap Max Capacity: 30208M
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Move to compiler_globals_pd.hpp
>  - Merge branch 'master' into JDK-8294751-zero-larger-heaps
>  - Fix

GHA re-run returned green. Yet, this PR checks report some failures. This is an infrastructure hiccup.

@tstuefe, the move of these checks to header definitions -- that is what you wanted to see, right?

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

PR: https://git.openjdk.org/jdk/pull/10552

From shade at openjdk.org  Mon Oct 10 12:32:39 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 10 Oct 2022 12:32:39 GMT
Subject: RFR: 8294594: Fix cast-function-type warnings in signal handling
 code [v2]
In-Reply-To: <Fp96nMrtVhISqFOO67MmNGQPoKyUKV9jgPFtGkoTzt0=.3436f114-0877-4513-91f7-4b611ebd8c8b@github.com>
References: <Fp96nMrtVhISqFOO67MmNGQPoKyUKV9jgPFtGkoTzt0=.3436f114-0877-4513-91f7-4b611ebd8c8b@github.com>
Message-ID: <f09OuHeDU7QluFW1PwmfzMJVSjBFg10Exs2m--0bNbQ=.682762a4-9af3-43e4-88df-37b21bd89e6c@github.com>

> After [JDK-8294314](https://bugs.openjdk.org/browse/JDK-8294314), we would have signals_posix.cpp excluded with cast-function-type warning:

Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - Naming
 - Redo using the proper signatures
 - Merge branch 'master' into JDK-8294594-warning-cast-function-type-signals
 - Fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10494/files
  - new: https://git.openjdk.org/jdk/pull/10494/files/2ca21e2a..c469e840

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10494&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10494&range=00-01

  Stats: 14704 lines in 421 files changed: 10039 ins; 3141 del; 1524 mod
  Patch: https://git.openjdk.org/jdk/pull/10494.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10494/head:pull/10494

PR: https://git.openjdk.org/jdk/pull/10494

From shade at openjdk.org  Mon Oct 10 12:32:41 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 10 Oct 2022 12:32:41 GMT
Subject: RFR: 8294594: Fix cast-function-type warnings in signal handling
 code [v2]
In-Reply-To: <I3ESJ8EIT8yXtevTGqeOQJVjgj9al7rqAMDVaD17LcE=.af674e89-edfe-4b84-aaa5-88ce92561a32@github.com>
References: <Fp96nMrtVhISqFOO67MmNGQPoKyUKV9jgPFtGkoTzt0=.3436f114-0877-4513-91f7-4b611ebd8c8b@github.com>
 <t1X4oiPfM2ZDNQPceadU5bsr1Kg5VQWppWYjWVeHVHI=.14ae324c-b439-4b75-8c64-5c5e33e7d915@github.com>
 <I3ESJ8EIT8yXtevTGqeOQJVjgj9al7rqAMDVaD17LcE=.af674e89-edfe-4b84-aaa5-88ce92561a32@github.com>
Message-ID: <fNhrkwJvEgI6KbtawXuiMs7N9hDaLThkaTYQmdRjzaI=.2512c593-209d-46a1-9c01-ef57bda747d4@github.com>

On Sun, 9 Oct 2022 01:40:29 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> src/hotspot/os/posix/signals_posix.cpp line 1727:
>> 
>>> 1725:   // Set up signal handler for suspend/resume
>>> 1726:   act.sa_flags = SA_RESTART|SA_SIGINFO;
>>> 1727:   act.sa_handler = CAST_FROM_FN_PTR(sa_handler_t, SR_handler);
>> 
>> The underlying cast in the macro seems a little odd for this situation but if it appeases the compiler then that is fine.
>
> No, don't do this.  The code is just wrong, and should be fixed.
> 
> We have a struct sigaction.  We've set the sa_flags member to a value that
> includes SA_SIGINFO.  That means the 3 argument sa_sigaction handler is
> supposed to be invoked.
> 
> We're storing the SR_handler (cast to a value matching the type of the
> sa_handler member of the sigaction). This is "working" purely by accident.
> Apparently on all POSIX platforms we support, the sa_handler and sa_sigaction
> occupy the same memory (being in a union, which is permitted by the spec).
> 
> The signature for SR_handler should be changed from
> void SR_handler(int, siginfo_t*, ucontext_t*)
> to
> void SR_handler(int, siginfo_t*, void*)
> and adjust the code to deal with the change to the type of the 3rd parameter.
> 
> Then we can just assign the sa_sigaction member to SR_handler without any casts.

This is an excellent catch, @kimbarrett! I think I missed it the same way David did: I completely missed there is `sa_handler` and `sa_sigaction`! Re-done this in new commits.

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

PR: https://git.openjdk.org/jdk/pull/10494

From shade at openjdk.org  Mon Oct 10 12:44:57 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 10 Oct 2022 12:44:57 GMT
Subject: RFR: 8294594: Fix cast-function-type warnings in signal handling
 code [v2]
In-Reply-To: <jpL-bb0C1xWA3yIZaALPQCGpur2GSoUZx4lPhvTZrik=.d1b8ab36-653c-49a5-a531-4817ec0585df@github.com>
References: <Fp96nMrtVhISqFOO67MmNGQPoKyUKV9jgPFtGkoTzt0=.3436f114-0877-4513-91f7-4b611ebd8c8b@github.com>
 <_vNpHQsYGB0Em5NjD1plwOpmcDcDIqf1T0i7gOj4nKs=.3a01519f-5f75-4805-8b9a-4230d1a31204@github.com>
 <jpL-bb0C1xWA3yIZaALPQCGpur2GSoUZx4lPhvTZrik=.d1b8ab36-653c-49a5-a531-4817ec0585df@github.com>
Message-ID: <9jSmtB93I6PqKwew8D1kiLHK-AR2DiSn1NbWlUBpivs=.72a241dc-9cb6-4d57-abaf-b49153e4a360@github.com>

On Sun, 9 Oct 2022 02:57:36 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> test/hotspot/gtest/runtime/test_signals.cpp line 49:
>> 
>>> 47:   static void check_handlers() {
>>> 48:     struct sigaction act, old_SIGFPE_act, old_SIGILL_act;
>>> 49:     act.sa_handler = CAST_FROM_FN_PTR(sa_handler_t, sig_handler);
>> 
>> This is similarly wrong code that should be fixed instead of doing weird casting dances.  The problem here is that sig_handler has the wrong signature.  It should be just `void sig_handler(int)`.  Fix that and not casts needed.
>
> This one is even worse than the other.  Here we're installing a handler function taking 3 arguments in such a way that it will only be called with one.  Weee!

:facepalm:

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

PR: https://git.openjdk.org/jdk/pull/10494

From jsjolen at openjdk.org  Mon Oct 10 13:33:22 2022
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 10 Oct 2022 13:33:22 GMT
Subject: RFR: 8295067: Remove virtual from ResourceObj::print_on
Message-ID: <1OgYiKFdbcNQxeH38V_DHqpc8ivA24MwKZ2OxpIrnZM=.9b9c796d-94c8-464d-96dd-970b0c854703@github.com>

We never use this method in any virtual manner. For example, we never iterate over `ResourceObj*` where the underlying types are different subclasses of `ResourceObj`. Removing `virtual` removes 8 bytes from each allocation (24 bytes -> 16 bytes) and also allows subclasses `print_on` to be non-`const`.

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

Commit messages:
 - No longer virtual

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

PR: https://git.openjdk.org/jdk/pull/10630

From mdoerr at openjdk.org  Mon Oct 10 14:37:15 2022
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 10 Oct 2022 14:37:15 GMT
Subject: RFR: 8295069: [PPC64] Performance regression after JDK-8290025
In-Reply-To: <OnRsJ6wxgFKb0mkUmTVScpm3-6gK6BYaFr58Tk5wzT8=.7fae15f8-5e08-459f-b5ee-5430703824a4@github.com>
References: <OnRsJ6wxgFKb0mkUmTVScpm3-6gK6BYaFr58Tk5wzT8=.7fae15f8-5e08-459f-b5ee-5430703824a4@github.com>
Message-ID: <qeojhPXeKIZxMA2WCtfIv3ro-0KtGWmlSE4b-euZ1SM=.9a57449d-1123-40a4-8f2a-6c2adc9b8c64@github.com>

On Mon, 10 Oct 2022 14:02:09 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> I have a proposal to mitigate the performance regression (see JBS issue) on PPC64 significantly. We get most of the performance back. Please review. May also be relevant for aarch64 which I haven't checked.
> I'm checking explicitly for GCs which are known to be safe. Maybe there is a better way to check this.

Changed to draft. Aarch64 seems to have a better solution. I should probably implement it the same way.

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

PR: https://git.openjdk.org/jdk/pull/10632

From ngasson at openjdk.org  Mon Oct 10 14:41:33 2022
From: ngasson at openjdk.org (Nick Gasson)
Date: Mon, 10 Oct 2022 14:41:33 GMT
Subject: RFR: 8295069: [PPC64] Performance regression after JDK-8290025
In-Reply-To: <OnRsJ6wxgFKb0mkUmTVScpm3-6gK6BYaFr58Tk5wzT8=.7fae15f8-5e08-459f-b5ee-5430703824a4@github.com>
References: <OnRsJ6wxgFKb0mkUmTVScpm3-6gK6BYaFr58Tk5wzT8=.7fae15f8-5e08-459f-b5ee-5430703824a4@github.com>
Message-ID: <DNuQFhUNo_82SjQ-NU-Fwek8Ppj9V8xdFpK0XPz2v6E=.fce4a678-0d12-4041-a44b-59330b5ab3e3@github.com>

On Mon, 10 Oct 2022 14:02:09 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> I have a proposal to mitigate the performance regression (see JBS issue) on PPC64 significantly. We get most of the performance back. Please review. May also be relevant for aarch64 which I haven't checked.
> I'm checking explicitly for GCs which are known to be safe. Maybe there is a better way to check this.

This was fixed for AArch64 in JDK-8290700 - maybe it's worth adopting the `NMethodPatchingType` enum used there?

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

PR: https://git.openjdk.org/jdk/pull/10632

From jsjolen at openjdk.org  Mon Oct 10 14:48:53 2022
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 10 Oct 2022 14:48:53 GMT
Subject: Withdrawn: 8295067: Remove virtual from ResourceObj::print_on
In-Reply-To: <1OgYiKFdbcNQxeH38V_DHqpc8ivA24MwKZ2OxpIrnZM=.9b9c796d-94c8-464d-96dd-970b0c854703@github.com>
References: <1OgYiKFdbcNQxeH38V_DHqpc8ivA24MwKZ2OxpIrnZM=.9b9c796d-94c8-464d-96dd-970b0c854703@github.com>
Message-ID: <Dm_5UpS-6GVNHdNkrmnDJiz3knPY56X7UDmVdEdKYbo=.dcf7f2be-3b84-4395-8fde-b26c4d2900ad@github.com>

On Mon, 10 Oct 2022 13:23:06 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> We never use this method in any virtual manner. For example, we never iterate over `ResourceObj*` where the underlying types are different subclasses of `ResourceObj`. Removing `virtual` removes 8 bytes from each allocation (24 bytes -> 16 bytes) and also allows subclasses `print_on` to be non-`const`.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/10630

From mdoerr at openjdk.org  Mon Oct 10 15:07:43 2022
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 10 Oct 2022 15:07:43 GMT
Subject: RFR: 8295069: [PPC64] Performance regression after JDK-8290025
 [v2]
In-Reply-To: <OnRsJ6wxgFKb0mkUmTVScpm3-6gK6BYaFr58Tk5wzT8=.7fae15f8-5e08-459f-b5ee-5430703824a4@github.com>
References: <OnRsJ6wxgFKb0mkUmTVScpm3-6gK6BYaFr58Tk5wzT8=.7fae15f8-5e08-459f-b5ee-5430703824a4@github.com>
Message-ID: <tIDXslMGKobJSMHDxn4c1FGMS3dm8brMpkbCs6bocJA=.12279b57-caea-4275-95a3-5338fa46b26f@github.com>

> I have a proposal to mitigate the performance regression (see JBS issue) on PPC64 significantly. We get most of the performance back. Please review. May also be relevant for aarch64 which I haven't checked.
> I'm checking explicitly for GCs which are known to be safe. Maybe there is a better way to check this.

Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:

  Implement like on aarch64.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10632/files
  - new: https://git.openjdk.org/jdk/pull/10632/files/7c19cb17..99d133ba

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10632&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10632&range=00-01

  Stats: 17 lines in 5 files changed: 13 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/10632.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10632/head:pull/10632

PR: https://git.openjdk.org/jdk/pull/10632

From mdoerr at openjdk.org  Mon Oct 10 15:07:43 2022
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 10 Oct 2022 15:07:43 GMT
Subject: RFR: 8295069: [PPC64] Performance regression after JDK-8290025
In-Reply-To: <OnRsJ6wxgFKb0mkUmTVScpm3-6gK6BYaFr58Tk5wzT8=.7fae15f8-5e08-459f-b5ee-5430703824a4@github.com>
References: <OnRsJ6wxgFKb0mkUmTVScpm3-6gK6BYaFr58Tk5wzT8=.7fae15f8-5e08-459f-b5ee-5430703824a4@github.com>
Message-ID: <ozXhPGGcN6HDYfEk5l_Xf_ENYEHFuXTZ_9kGZAyllXM=.968a5c92-87be-47c5-9c76-e9daf0935139@github.com>

On Mon, 10 Oct 2022 14:02:09 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> I have a proposal to mitigate the performance regression (see JBS issue) on PPC64 significantly. We get most of the performance back. Please review. May also be relevant for aarch64 which I haven't checked.
> I'm checking explicitly for GCs which are known to be safe. Maybe there is a better way to check this.

Thanks for the hint! We had already noticed and I was working on it in the meantime.

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

PR: https://git.openjdk.org/jdk/pull/10632

From mdoerr at openjdk.org  Mon Oct 10 15:12:51 2022
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 10 Oct 2022 15:12:51 GMT
Subject: RFR: 8295069: [PPC64] Performance regression after JDK-8290025
 [v2]
In-Reply-To: <tIDXslMGKobJSMHDxn4c1FGMS3dm8brMpkbCs6bocJA=.12279b57-caea-4275-95a3-5338fa46b26f@github.com>
References: <OnRsJ6wxgFKb0mkUmTVScpm3-6gK6BYaFr58Tk5wzT8=.7fae15f8-5e08-459f-b5ee-5430703824a4@github.com>
 <tIDXslMGKobJSMHDxn4c1FGMS3dm8brMpkbCs6bocJA=.12279b57-caea-4275-95a3-5338fa46b26f@github.com>
Message-ID: <ysGuTPpD2zUWFX8i90EFiVBXofatWiF46EGmiYsx-XM=.1f1a7bed-ba5c-4ea0-9c19-20cd9b5a451f@github.com>

On Mon, 10 Oct 2022 15:07:43 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> I have a proposal to mitigate the performance regression (see JBS issue) on PPC64 significantly. We get most of the performance back. Please review. Implemented like on aarch64, now.
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implement like on aarch64.

Note: `conc_instruction_and_data_patch` is for generational ZGC which is not yet in jdk master. PPC64 implementation will still work if we forget to update from `conc_data_patch`.

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

PR: https://git.openjdk.org/jdk/pull/10632

From aph at openjdk.org  Mon Oct 10 17:29:02 2022
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 10 Oct 2022 17:29:02 GMT
Subject: RFR: 8295069: [PPC64] Performance regression after JDK-8290025
 [v2]
In-Reply-To: <tIDXslMGKobJSMHDxn4c1FGMS3dm8brMpkbCs6bocJA=.12279b57-caea-4275-95a3-5338fa46b26f@github.com>
References: <OnRsJ6wxgFKb0mkUmTVScpm3-6gK6BYaFr58Tk5wzT8=.7fae15f8-5e08-459f-b5ee-5430703824a4@github.com>
 <tIDXslMGKobJSMHDxn4c1FGMS3dm8brMpkbCs6bocJA=.12279b57-caea-4275-95a3-5338fa46b26f@github.com>
Message-ID: <Lal8Or6BTGJ4E1OJPynWrs35ZkLjBi4j52MbAuHeaYQ=.309b763a-a894-402c-aed9-761fa9448d8a@github.com>

On Mon, 10 Oct 2022 15:07:43 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> I have a proposal to mitigate the performance regression (see JBS issue) on PPC64 significantly. We get most of the performance back. Please review. Implemented like on aarch64, now.
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implement like on aarch64.

Might it make sense for PPC to do what AArch64 does? We don't need any memory fence instructions on the fast path.

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

PR: https://git.openjdk.org/jdk/pull/10632

From iklam at openjdk.org  Mon Oct 10 17:29:03 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 10 Oct 2022 17:29:03 GMT
Subject: RFR: 8294772: Remove workaround in os::dll_address_to_library_name
In-Reply-To: <XxV07mEZMfIMNuve5mZDn7dQA8NzLrrXTULALA88G9Y=.1cd2c6ad-8880-4bc9-ae04-76a75e739c5d@github.com>
References: <XxV07mEZMfIMNuve5mZDn7dQA8NzLrrXTULALA88G9Y=.1cd2c6ad-8880-4bc9-ae04-76a75e739c5d@github.com>
Message-ID: <eLi9_-pDMQfQWO4ZBrfxmSxvsCfo1_JEcmKbCxwXoBE=.a4c54a85-e1d4-4a2b-99bd-47675b73d171@github.com>

On Tue, 4 Oct 2022 14:30:58 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> I ported the BSD implementation of this function. According to the comment this bug should be fixed, as the oldest glibc I can see us supporting is 2.12.x. I've made an attempt at finding the bug that the comment refers to on glibc's bug tracker but has been unsuccesful in this.
> 
> The second commit deletes what seems like an outdated comment (in os_bsd this refers to a code snippet right below the comment).

Looks good except for a nit on the comment.

src/hotspot/os/linux/os_linux.cpp line 1375:

> 1373: }
> 1374: 
> 1375: // Ported from BSD version

I think this comment is not necessary. In fact, the corresponding comment `// ported from solaris version` in os_bsd.cpp should probably be removed as well.

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

Marked as reviewed by iklam (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10559

From kbarrett at openjdk.org  Mon Oct 10 19:59:51 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 10 Oct 2022 19:59:51 GMT
Subject: RFR: 8294594: Fix cast-function-type warnings in signal handling
 code [v2]
In-Reply-To: <f09OuHeDU7QluFW1PwmfzMJVSjBFg10Exs2m--0bNbQ=.682762a4-9af3-43e4-88df-37b21bd89e6c@github.com>
References: <Fp96nMrtVhISqFOO67MmNGQPoKyUKV9jgPFtGkoTzt0=.3436f114-0877-4513-91f7-4b611ebd8c8b@github.com>
 <f09OuHeDU7QluFW1PwmfzMJVSjBFg10Exs2m--0bNbQ=.682762a4-9af3-43e4-88df-37b21bd89e6c@github.com>
Message-ID: <-rK8vM7SBOjsiYzFMMNmAtXNimDEmw6jyiYeRdXQOAk=.dcb5e445-1e7d-456a-9469-76f45e53a334@github.com>

On Mon, 10 Oct 2022 12:32:39 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> After [JDK-8294314](https://bugs.openjdk.org/browse/JDK-8294314), we would have signals_posix.cpp excluded with cast-function-type warning:
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Naming
>  - Redo using the proper signatures
>  - Merge branch 'master' into JDK-8294594-warning-cast-function-type-signals
>  - Fix

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10494

From mdoerr at openjdk.org  Mon Oct 10 21:00:49 2022
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 10 Oct 2022 21:00:49 GMT
Subject: RFR: 8295069: [PPC64] Performance regression after JDK-8290025
 [v2]
In-Reply-To: <Lal8Or6BTGJ4E1OJPynWrs35ZkLjBi4j52MbAuHeaYQ=.309b763a-a894-402c-aed9-761fa9448d8a@github.com>
References: <OnRsJ6wxgFKb0mkUmTVScpm3-6gK6BYaFr58Tk5wzT8=.7fae15f8-5e08-459f-b5ee-5430703824a4@github.com>
 <tIDXslMGKobJSMHDxn4c1FGMS3dm8brMpkbCs6bocJA=.12279b57-caea-4275-95a3-5338fa46b26f@github.com>
 <Lal8Or6BTGJ4E1OJPynWrs35ZkLjBi4j52MbAuHeaYQ=.309b763a-a894-402c-aed9-761fa9448d8a@github.com>
Message-ID: <LECAKm0RDLiAnZ09wBws3ii-eLHVOn1tBIru03hQQzA=.e278e0ae-afcd-4c9c-a6f6-cce80e7bd285@github.com>

On Mon, 10 Oct 2022 17:26:49 GMT, Andrew Haley <aph at openjdk.org> wrote:

> Might it make sense for PPC to do what AArch64 does? We don't need any memory fence instructions on the fast path.

We are actually doing what AArch64 does, now. AArch64 still uses `membar(__ LoadLoad)` for (non-generational) ZGC and ShenandoahGC, because they use `NMethodPatchingType::conc_data_patch`. Other GCs don't need any memory fence instructions. (See `BarrierSetAssembler::nmethod_entry_barrier`.) Exactly like on PPC64, now.
Note that the patching epoch implementation is protected by `NMethodPatchingType::conc_instruction_and_data_patch` and is hence not used at all in jdk master. (Only in generational ZGC which is not yet integrated into jdk master.)

It may make sense to implement the patching epoch code on PPC64 as well. We could evaluate it, but we should better do that with generational ZGC (like on AArch64).

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

PR: https://git.openjdk.org/jdk/pull/10632

From dholmes at openjdk.org  Mon Oct 10 21:43:33 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 10 Oct 2022 21:43:33 GMT
Subject: RFR: 8294623: gtests does not work with googletest release-1.12.0+
In-Reply-To: <yCCwD379-NdX5QV_jfKs_gpzuvfz1CkcdTe2CdNJr-Q=.3fa72e71-b35a-4de8-84a2-066fdebbf811@github.com>
References: <GTSRMWikrMJP0xKZRchcdvyMTIA8QLo9Ghl0_bbIsd0=.953fc4ad-4f58-4cd2-b0df-9cd6d1784d21@github.com>
 <B0icLmUNp-T8kpaICnegSVS_Ml_0l9BzVfM1adJSq6c=.69b03ff0-90cb-48f1-93d9-57a24d1c8f5a@github.com>
 <yCCwD379-NdX5QV_jfKs_gpzuvfz1CkcdTe2CdNJr-Q=.3fa72e71-b35a-4de8-84a2-066fdebbf811@github.com>
Message-ID: <PnX-7jUqsLxgE6zRImaXmkN5E4gbjxKhjqSfd7zuvr0=.e2b63301-58ce-4c89-a7bf-6531d35ce7e0@github.com>

On Mon, 10 Oct 2022 06:36:03 GMT, Dingli Zhang <dzhang at openjdk.org> wrote:

>> @dholmes-ora @tstuefe Hi, could anyone please help to take a look at this PR? Thanks in advance for your time!
>
>> @DingliZhang I've asked if anyone is familiar enough with googletest to review this, as I am not familiar with it.
> 
> Hi @dholmes-ora, thank you for your help!

@DingliZhang According to the building.md documentation:

The supported version of Google Test is 1.8.1, whose source code can be obtained:

 * by downloading and unpacking the source bundle from [here](https://github.com/google/googletest/releases/tag/release-1.8.1)
 * or by checking out `release-1.8.1` tag of `googletest` project: `git clone -b release-1.8.1 https://github.com/google/googletest`

I don't know how old version 1.8.1 is or whether we need to expand on the supported releases here. Maybe the build folk will have an opinion? @magicus or @erikj79 .

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

PR: https://git.openjdk.org/jdk/pull/10503

From mdoerr at openjdk.org  Mon Oct 10 22:14:12 2022
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 10 Oct 2022 22:14:12 GMT
Subject: RFR: 8295069: [PPC64] Performance regression after JDK-8290025
 [v3]
In-Reply-To: <OnRsJ6wxgFKb0mkUmTVScpm3-6gK6BYaFr58Tk5wzT8=.7fae15f8-5e08-459f-b5ee-5430703824a4@github.com>
References: <OnRsJ6wxgFKb0mkUmTVScpm3-6gK6BYaFr58Tk5wzT8=.7fae15f8-5e08-459f-b5ee-5430703824a4@github.com>
Message-ID: <f-5PPCuslv3d9xCB9SGXx92O85AQGIqks3Pt5_ss35g=.c353b2ce-a4c8-4dba-a034-9e88206a2ccd@github.com>

> I have a proposal to mitigate the performance regression (see JBS issue) on PPC64 significantly. We get most of the performance back. Please review. Implemented like on aarch64, now.

Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:

  Update Copyrigth years.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10632/files
  - new: https://git.openjdk.org/jdk/pull/10632/files/99d133ba..d9ea8790

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10632&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10632&range=01-02

  Stats: 8 lines in 4 files changed: 0 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/10632.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10632/head:pull/10632

PR: https://git.openjdk.org/jdk/pull/10632

From mdoerr at openjdk.org  Mon Oct 10 22:28:02 2022
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 10 Oct 2022 22:28:02 GMT
Subject: RFR: 8295069: [PPC64] Performance regression after JDK-8290025
 [v4]
In-Reply-To: <OnRsJ6wxgFKb0mkUmTVScpm3-6gK6BYaFr58Tk5wzT8=.7fae15f8-5e08-459f-b5ee-5430703824a4@github.com>
References: <OnRsJ6wxgFKb0mkUmTVScpm3-6gK6BYaFr58Tk5wzT8=.7fae15f8-5e08-459f-b5ee-5430703824a4@github.com>
Message-ID: <tQVcNhLFhiiMgK81JFfpzyi0Y_J0JRfPyepV-DJ6Z7k=.b2006694-a739-4dbc-abfa-75cddf555fa5@github.com>

> I have a proposal to mitigate the performance regression (see JBS issue) on PPC64 significantly. We get most of the performance back. Please review. Implemented like on aarch64, now.

Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:

  Use 64 bit load for _nmethod_disarm_value. (Makes a difference on Big Endian\!)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10632/files
  - new: https://git.openjdk.org/jdk/pull/10632/files/d9ea8790..08b86237

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10632&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10632&range=02-03

  Stats: 3 lines in 2 files changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10632.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10632/head:pull/10632

PR: https://git.openjdk.org/jdk/pull/10632

From kbarrett at openjdk.org  Mon Oct 10 23:40:53 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 10 Oct 2022 23:40:53 GMT
Subject: RFR: 8294623: gtests does not work with googletest release-1.12.0+
In-Reply-To: <PnX-7jUqsLxgE6zRImaXmkN5E4gbjxKhjqSfd7zuvr0=.e2b63301-58ce-4c89-a7bf-6531d35ce7e0@github.com>
References: <GTSRMWikrMJP0xKZRchcdvyMTIA8QLo9Ghl0_bbIsd0=.953fc4ad-4f58-4cd2-b0df-9cd6d1784d21@github.com>
 <B0icLmUNp-T8kpaICnegSVS_Ml_0l9BzVfM1adJSq6c=.69b03ff0-90cb-48f1-93d9-57a24d1c8f5a@github.com>
 <yCCwD379-NdX5QV_jfKs_gpzuvfz1CkcdTe2CdNJr-Q=.3fa72e71-b35a-4de8-84a2-066fdebbf811@github.com>
 <PnX-7jUqsLxgE6zRImaXmkN5E4gbjxKhjqSfd7zuvr0=.e2b63301-58ce-4c89-a7bf-6531d35ce7e0@github.com>
Message-ID: <rnL2waiVREMQtbRdF4kikhiEquNFofsBKE5Bdft9lCg=.8ef316ae-d37e-4d4e-8c83-7f04d2340139@github.com>

On Mon, 10 Oct 2022 21:40:20 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I don't know how old version 1.8.1 is or whether we need to expand on the supported releases here. Maybe the build folk will have an opinion? @magicus or @erikj79 .

I don't think we need to support multiple versions of googletest.  I don't see any benefit, and doing so incurs costs.  It might be that we should update to using a newer version, but that's a very different discussion.

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

PR: https://git.openjdk.org/jdk/pull/10503

From kbarrett at openjdk.org  Tue Oct 11 00:05:17 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 11 Oct 2022 00:05:17 GMT
Subject: RFR: 8295014: Remove unnecessary explicit casts to void* in
 CHeapObjBase
In-Reply-To: <L18m7x4xWmFx5G1_v9JnGgz9cEkisclWQppqjIRGqpw=.70c28cd2-289a-4a8f-b9a0-7905cd1f0845@github.com>
References: <UyIQedVM9M-bj2FAsbKw54-N7vpFj_kES9s2Vj_vBEU=.139f9d8d-4963-432a-a754-189ed33dcf83@github.com>
 <L18m7x4xWmFx5G1_v9JnGgz9cEkisclWQppqjIRGqpw=.70c28cd2-289a-4a8f-b9a0-7905cd1f0845@github.com>
Message-ID: <iYWWTG1UygMXbkvtRO_olLuepnBJHlOV4mm12Fl_muA=.5192d947-bdeb-4a8a-8890-3e0612b76231@github.com>

On Sun, 9 Oct 2022 16:04:33 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Please review this change to CHeapObjBase that removes unnecessary explicit
>> casts from char* to void*.
>> 
>> Testing: mach5 tier1
>
> This looks good to me, thank you for the change.

Thanks for reviews @jdksjolen , @dholmes-ora , and @stefank .

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

PR: https://git.openjdk.org/jdk/pull/10623

From kbarrett at openjdk.org  Tue Oct 11 00:21:24 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 11 Oct 2022 00:21:24 GMT
Subject: Integrated: 8295014: Remove unnecessary explicit casts to void* in
 CHeapObjBase
In-Reply-To: <UyIQedVM9M-bj2FAsbKw54-N7vpFj_kES9s2Vj_vBEU=.139f9d8d-4963-432a-a754-189ed33dcf83@github.com>
References: <UyIQedVM9M-bj2FAsbKw54-N7vpFj_kES9s2Vj_vBEU=.139f9d8d-4963-432a-a754-189ed33dcf83@github.com>
Message-ID: <Yda7glBBGZyd6FU3pNeLYGLsFX85TNXMC71nmgxSD_4=.10f64557-11db-4d40-a997-e72064da79ea@github.com>

On Sun, 9 Oct 2022 02:52:37 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to CHeapObjBase that removes unnecessary explicit
> casts from char* to void*.
> 
> Testing: mach5 tier1

This pull request has now been integrated.

Changeset: e6c33e62
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e6c33e62b5d746f1a45202a6ddc3ded8f933752e
Stats:     8 lines in 1 file changed: 0 ins; 0 del; 8 mod

8295014: Remove unnecessary explicit casts to void* in CHeapObjBase

Reviewed-by: jsjolen, dholmes, stefank

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

PR: https://git.openjdk.org/jdk/pull/10623

From kbarrett at openjdk.org  Tue Oct 11 00:25:44 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 11 Oct 2022 00:25:44 GMT
Subject: RFR: 8295012: Arena should not derive from CHeapObj<mtNone>
In-Reply-To: <hEw3XZtRzSiXSOfV9zJy2XvNBlM8D2FX0d7wHj_GC_I=.f623b42b-917e-4465-826a-4921af6863fe@github.com>
References: <Vi8c8J_dkW9vUkBsXGMT7WGG3IZBFV4yACs_akgKMgU=.35cda657-a697-42fb-b550-e940638080ec@github.com>
 <hEw3XZtRzSiXSOfV9zJy2XvNBlM8D2FX0d7wHj_GC_I=.f623b42b-917e-4465-826a-4921af6863fe@github.com>
Message-ID: <ZW2rP3zes7Y5nLohOXliXBM0o-imjFKoUfEPdjQjfzY=.3050347e-fab1-478a-97b2-d853652d01be@github.com>

On Mon, 10 Oct 2022 08:52:51 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> What's the reason for keeping the new/delete operators in Arena, instead of inheriting from the newly introduced CHeapObjBase class?

No good reason.  I just forgot about them.  I will make that change.

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

PR: https://git.openjdk.org/jdk/pull/10621

From dholmes at openjdk.org  Tue Oct 11 01:51:20 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 11 Oct 2022 01:51:20 GMT
Subject: RFR: 8294594: Fix cast-function-type warnings in signal handling
 code [v2]
In-Reply-To: <f09OuHeDU7QluFW1PwmfzMJVSjBFg10Exs2m--0bNbQ=.682762a4-9af3-43e4-88df-37b21bd89e6c@github.com>
References: <Fp96nMrtVhISqFOO67MmNGQPoKyUKV9jgPFtGkoTzt0=.3436f114-0877-4513-91f7-4b611ebd8c8b@github.com>
 <f09OuHeDU7QluFW1PwmfzMJVSjBFg10Exs2m--0bNbQ=.682762a4-9af3-43e4-88df-37b21bd89e6c@github.com>
Message-ID: <VKINUWO-QctcaSiPS-qsrBVsepqtihEDqJFKNBJrXa0=.d0e02d97-c30c-40a9-9d99-b9b0a1c92e89@github.com>

On Mon, 10 Oct 2022 12:32:39 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> After [JDK-8294314](https://bugs.openjdk.org/browse/JDK-8294314), we would have signals_posix.cpp excluded with cast-function-type warning:
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Naming
>  - Redo using the proper signatures
>  - Merge branch 'master' into JDK-8294594-warning-cast-function-type-signals
>  - Fix

Fix looks good as far as it goes (can't believe I didn't see what was going on here!) - but `os::signal` is still broken as it uses `sa_handler` instead of `sa_sigaction`.

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

Changes requested by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10494

From iklam at openjdk.org  Tue Oct 11 02:20:17 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 11 Oct 2022 02:20:17 GMT
Subject: RFR: 8295102: Always load @lambda-form-invoker lines from default
 classlist
Message-ID: <8P6vyzEAJpw7qVfgAo3unZKcanLD6q1Xu11lCap9xVo=.ab0719a4-0764-44cf-9f3c-c59879a1ddec@github.com>

The `@lambda-form-invoker` lines in the default classlist (`$JAVA_HOME/lib/classlist`) control what lambda-form invoker methods are added to these classes that are generated during a CDS dump ([see here](https://github.com/iklam/jdk/blob/5aa997b001367141a6a2d2e69649d41b46199ab4/src/hotspot/share/cds/lambdaFormInvokers.cpp#L230)):

- `java.lang.invoke.Invokers$Holder`
- `java.lang.invoke.DirectMethodHandle$Holder`
- `java.lang.invoke.DelegatingMethodHandle$Holder`
- `java.lang.invoke.LambdaForm$Holder`

The list of these invoker methods is generated as part of the [JDK build process](https://github.com/iklam/jdk/blob/1996f649a3a30b7ac4b547a762417f807f5fa414/make/GenerateLinkOptData.gmk#L64). They are used for invoking MethodHandles of commonly-used types, so that we can avoid generating custom LambdaForm classes.

When a CDS archive is created with a non-default classlist, (e.g., `-XX:SharedClassListFile=foo.classlist`), such a classlist may not contain all the `@lambda-form-invoker` lines as in the default classlist. As a result, at runtime, more custom LambdaForm classes may be generated than necessary.

The solution is to always load the `@lambda-form-invoker` lines from the default classlist, to make sure the CDS image has all the commonly-used invoker methods.

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

Commit messages:
 - fixed build
 - 8295102: Always load @lambda-form-invoker lines from default classlist

Changes: https://git.openjdk.org/jdk/pull/10639/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10639&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295102
  Stats: 263 lines in 7 files changed: 224 ins; 34 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/10639.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10639/head:pull/10639

PR: https://git.openjdk.org/jdk/pull/10639

From dholmes at openjdk.org  Tue Oct 11 03:25:21 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 11 Oct 2022 03:25:21 GMT
Subject: RFR: 8295102: Always load @lambda-form-invoker lines from default
 classlist
In-Reply-To: <8P6vyzEAJpw7qVfgAo3unZKcanLD6q1Xu11lCap9xVo=.ab0719a4-0764-44cf-9f3c-c59879a1ddec@github.com>
References: <8P6vyzEAJpw7qVfgAo3unZKcanLD6q1Xu11lCap9xVo=.ab0719a4-0764-44cf-9f3c-c59879a1ddec@github.com>
Message-ID: <bOgbh7yM6_IHckURnMPeXTdnyMln8uMpAhtSACa7DRM=.c89ea131-0d1c-4c1a-8f57-3120cd051846@github.com>

On Mon, 10 Oct 2022 22:18:33 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> The `@lambda-form-invoker` lines in the default classlist (`$JAVA_HOME/lib/classlist`) control what lambda-form invoker methods are added to these classes that are generated during a CDS dump ([see here](https://github.com/iklam/jdk/blob/5aa997b001367141a6a2d2e69649d41b46199ab4/src/hotspot/share/cds/lambdaFormInvokers.cpp#L230)):
> 
> - `java.lang.invoke.Invokers$Holder`
> - `java.lang.invoke.DirectMethodHandle$Holder`
> - `java.lang.invoke.DelegatingMethodHandle$Holder`
> - `java.lang.invoke.LambdaForm$Holder`
> 
> The list of these invoker methods is generated as part of the [JDK build process](https://github.com/iklam/jdk/blob/1996f649a3a30b7ac4b547a762417f807f5fa414/make/GenerateLinkOptData.gmk#L64). They are used for invoking MethodHandles of commonly-used types, so that we can avoid generating custom LambdaForm classes.
> 
> When a CDS archive is created with a non-default classlist, (e.g., `-XX:SharedClassListFile=foo.classlist`), such a classlist may not contain all the `@lambda-form-invoker` lines as in the default classlist. As a result, at runtime, more custom LambdaForm classes may be generated than necessary.
> 
> The solution is to always load the `@lambda-form-invoker` lines from the default classlist, to make sure the CDS image has all the commonly-used invoker methods.

Seems to me this is edging towards a scheme where the user-defined classlist is to be used to augment the default one, rather than being a complete replacement. Either the classlist should be the one-true-source for the classes to include in the archive, or else you need a way to express that you want to use it in union with the default list (to some extent), but not just (seemingly arbitrarily) decide that a special subset of classes should always be included even if missing from the classlist.

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

PR: https://git.openjdk.org/jdk/pull/10639

From iklam at openjdk.org  Tue Oct 11 03:40:00 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 11 Oct 2022 03:40:00 GMT
Subject: RFR: 8295102: Always load @lambda-form-invoker lines from default
 classlist [v2]
In-Reply-To: <8P6vyzEAJpw7qVfgAo3unZKcanLD6q1Xu11lCap9xVo=.ab0719a4-0764-44cf-9f3c-c59879a1ddec@github.com>
References: <8P6vyzEAJpw7qVfgAo3unZKcanLD6q1Xu11lCap9xVo=.ab0719a4-0764-44cf-9f3c-c59879a1ddec@github.com>
Message-ID: <xPV-ArnX4doFubXMdMRPzdTWFwMFrEuQG8MtBgztyHM=.b601224c-7cf2-410f-a0ef-3924aa5bbd16@github.com>

> The `@lambda-form-invoker` lines in the default classlist (`$JAVA_HOME/lib/classlist`) control what lambda-form invoker methods are added to these classes that are generated during a CDS dump ([see here](https://github.com/iklam/jdk/blob/5aa997b001367141a6a2d2e69649d41b46199ab4/src/hotspot/share/cds/lambdaFormInvokers.cpp#L230)):
> 
> - `java.lang.invoke.Invokers$Holder`
> - `java.lang.invoke.DirectMethodHandle$Holder`
> - `java.lang.invoke.DelegatingMethodHandle$Holder`
> - `java.lang.invoke.LambdaForm$Holder`
> 
> The list of these invoker methods is generated as part of the [JDK build process](https://github.com/iklam/jdk/blob/1996f649a3a30b7ac4b547a762417f807f5fa414/make/GenerateLinkOptData.gmk#L64). They are used for invoking MethodHandles of commonly-used types, so that we can avoid generating custom LambdaForm classes.
> 
> When a CDS archive is created with a non-default classlist, (e.g., `-XX:SharedClassListFile=foo.classlist`), such a classlist may not contain all the `@lambda-form-invoker` lines as in the default classlist. As a result, at runtime, more custom LambdaForm classes may be generated than necessary.
> 
> The solution is to always load the `@lambda-form-invoker` lines from the default classlist, to make sure the CDS image has all the commonly-used invoker methods.

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  Fixed open/test/hotspot/jtreg:hotspot_appcds_dynamic tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10639/files
  - new: https://git.openjdk.org/jdk/pull/10639/files/2fd5057e..54d9e240

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10639&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10639&range=00-01

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

PR: https://git.openjdk.org/jdk/pull/10639

From kbarrett at openjdk.org  Tue Oct 11 05:17:40 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 11 Oct 2022 05:17:40 GMT
Subject: RFR: 8295012: Arena should not derive from CHeapObj<mtNone> [v2]
In-Reply-To: <Vi8c8J_dkW9vUkBsXGMT7WGG3IZBFV4yACs_akgKMgU=.35cda657-a697-42fb-b550-e940638080ec@github.com>
References: <Vi8c8J_dkW9vUkBsXGMT7WGG3IZBFV4yACs_akgKMgU=.35cda657-a697-42fb-b550-e940638080ec@github.com>
Message-ID: <xmxHDx6edRDIxFE9tqwlf2xGhipiMTjlLHkTVeomwmA=.6ae115e6-8713-42b4-870c-9c44fe99ec41@github.com>

> Please review this change to the `Arena` class.  Rather than deriving from
> `CHeapObj<mtNone>` (which has the effect of preventing C-heap allocation for an
> arena by asserting if such is attempted), instead have no allocation base
> class so that `new Arena(...)` will fail to compile.
> 
> Testing: mach5 tier1

Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:

  Arena derives from CHeapObjBase

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10621/files
  - new: https://git.openjdk.org/jdk/pull/10621/files/1e64a3cd..828541f5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10621&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10621&range=00-01

  Stats: 33 lines in 2 files changed: 0 ins; 32 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10621.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10621/head:pull/10621

PR: https://git.openjdk.org/jdk/pull/10621

From iklam at openjdk.org  Tue Oct 11 06:15:44 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 11 Oct 2022 06:15:44 GMT
Subject: RFR: 8295102: Always load @lambda-form-invoker lines from default
 classlist
In-Reply-To: <bOgbh7yM6_IHckURnMPeXTdnyMln8uMpAhtSACa7DRM=.c89ea131-0d1c-4c1a-8f57-3120cd051846@github.com>
References: <8P6vyzEAJpw7qVfgAo3unZKcanLD6q1Xu11lCap9xVo=.ab0719a4-0764-44cf-9f3c-c59879a1ddec@github.com>
 <bOgbh7yM6_IHckURnMPeXTdnyMln8uMpAhtSACa7DRM=.c89ea131-0d1c-4c1a-8f57-3120cd051846@github.com>
Message-ID: <L0czXxN9B7uzr-MNeIjvc0QHF6HxMrx9e90Jxxtqhwc=.2a5b0f1d-d572-4e5d-b656-536392bca1d9@github.com>

On Tue, 11 Oct 2022 03:23:01 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Seems to me this is edging towards a scheme where the user-defined classlist is to be used to augment the default one, rather than being a complete replacement. Either the classlist should be the one-true-source for the classes to include in the archive, or else you need a way to express that you want to use it in union with the default list (to some extent), but not just (seemingly arbitrarily) decide that a special subset of classes should always be included even if missing from the classlist.

This PR doesn't add extra classes into the archive. It just adds methods to the four Holder classes listed in the PR's description. In fact, these 4 classes (as stored in the JDK's module image) are generated at JDK build time to contain commonly used invoker methods. See GenerateLinkOptData.gmk.

The intention of the `@lambda-form-invoker` lines in the classlist is to add extra invoker methods into these holder classes (according to the app's profile) to avoid runtime generation of LambdaForm classes. Therefore, when dumping the archive, these 4 classes are regenerated and populated with methods specified by the `@lambda-form-invoker` lines.

However, the application's profile may use only a small number of invoker methods. As a result, if we just depend on the app's profile, the regenerated Holder classes, which are stored in the CDS archive, will be missing some invoker methods that are in JDK's module image.

These missing methods cause the following problems

- Excessive LambdaForm classes may be generated at runtime if the app executes code outside of its profile
- It will cause complication in future CDS optimizations (e.g., [JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336)) 

The default classlist (also generated by GenerateLinkOptData.gmk) contains the `@lambda-form-invoker` lines to regenerate the exact same set of methods as in the JDK's module image (this is checked by the new test case). By always loading these lines, we can guarantee that when a Holder class is stored in the CDS archive, it will not be missing any of the methods that are in the modules image.

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

PR: https://git.openjdk.org/jdk/pull/10639

From iklam at openjdk.org  Tue Oct 11 06:15:44 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 11 Oct 2022 06:15:44 GMT
Subject: RFR: 8295102: Always load @lambda-form-invoker lines from default
 classlist [v2]
In-Reply-To: <xPV-ArnX4doFubXMdMRPzdTWFwMFrEuQG8MtBgztyHM=.b601224c-7cf2-410f-a0ef-3924aa5bbd16@github.com>
References: <8P6vyzEAJpw7qVfgAo3unZKcanLD6q1Xu11lCap9xVo=.ab0719a4-0764-44cf-9f3c-c59879a1ddec@github.com>
 <xPV-ArnX4doFubXMdMRPzdTWFwMFrEuQG8MtBgztyHM=.b601224c-7cf2-410f-a0ef-3924aa5bbd16@github.com>
Message-ID: <-sM3NHMCAqk4OCeUrhD3WSkFQc0rd7_qKMuvBitTYBk=.a8abdcd1-f695-425c-a2e4-c588606254b5@github.com>

On Tue, 11 Oct 2022 03:40:00 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> The `@lambda-form-invoker` lines in the default classlist (`$JAVA_HOME/lib/classlist`) control what lambda-form invoker methods are added to these classes that are generated during a CDS dump ([see here](https://github.com/iklam/jdk/blob/5aa997b001367141a6a2d2e69649d41b46199ab4/src/hotspot/share/cds/lambdaFormInvokers.cpp#L230)):
>> 
>> - `java.lang.invoke.Invokers$Holder`
>> - `java.lang.invoke.DirectMethodHandle$Holder`
>> - `java.lang.invoke.DelegatingMethodHandle$Holder`
>> - `java.lang.invoke.LambdaForm$Holder`
>> 
>> The list of these invoker methods is generated as part of the [JDK build process](https://github.com/iklam/jdk/blob/1996f649a3a30b7ac4b547a762417f807f5fa414/make/GenerateLinkOptData.gmk#L64). They are used for invoking MethodHandles of commonly-used types, so that we can avoid generating custom LambdaForm classes.
>> 
>> When a CDS archive is created with a non-default classlist, (e.g., `-XX:SharedClassListFile=foo.classlist`), such a classlist may not contain all the `@lambda-form-invoker` lines as in the default classlist. As a result, at runtime, more custom LambdaForm classes may be generated than necessary.
>> 
>> The solution is to always load the `@lambda-form-invoker` lines from the default classlist, to make sure the CDS image has all the commonly-used invoker methods.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed open/test/hotspot/jtreg:hotspot_appcds_dynamic tests

More background info:

- https://wiki.openjdk.org/display/HotSpot/Support+for+pre-generated+java.lang.invoke+classes+in+CDS+archive
- https://bugs.openjdk.org/browse/JDK-8247536

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

PR: https://git.openjdk.org/jdk/pull/10639

From dholmes at openjdk.org  Tue Oct 11 06:30:24 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 11 Oct 2022 06:30:24 GMT
Subject: RFR: 8295102: Always load @lambda-form-invoker lines from default
 classlist [v2]
In-Reply-To: <xPV-ArnX4doFubXMdMRPzdTWFwMFrEuQG8MtBgztyHM=.b601224c-7cf2-410f-a0ef-3924aa5bbd16@github.com>
References: <8P6vyzEAJpw7qVfgAo3unZKcanLD6q1Xu11lCap9xVo=.ab0719a4-0764-44cf-9f3c-c59879a1ddec@github.com>
 <xPV-ArnX4doFubXMdMRPzdTWFwMFrEuQG8MtBgztyHM=.b601224c-7cf2-410f-a0ef-3924aa5bbd16@github.com>
Message-ID: <WwaWMaHboW-7s6A8kgdIbLIj-4bKTQhiEx05iGTq5FI=.7fd143b5-3755-4774-a7f6-098fd931a0c3@github.com>

On Tue, 11 Oct 2022 03:40:00 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> The `@lambda-form-invoker` lines in the default classlist (`$JAVA_HOME/lib/classlist`) control what lambda-form invoker methods are added to these classes that are generated during a CDS dump ([see here](https://github.com/iklam/jdk/blob/5aa997b001367141a6a2d2e69649d41b46199ab4/src/hotspot/share/cds/lambdaFormInvokers.cpp#L230)):
>> 
>> - `java.lang.invoke.Invokers$Holder`
>> - `java.lang.invoke.DirectMethodHandle$Holder`
>> - `java.lang.invoke.DelegatingMethodHandle$Holder`
>> - `java.lang.invoke.LambdaForm$Holder`
>> 
>> The list of these invoker methods is generated as part of the [JDK build process](https://github.com/iklam/jdk/blob/1996f649a3a30b7ac4b547a762417f807f5fa414/make/GenerateLinkOptData.gmk#L64). They are used for invoking MethodHandles of commonly-used types, so that we can avoid generating custom LambdaForm classes.
>> 
>> When a CDS archive is created with a non-default classlist, (e.g., `-XX:SharedClassListFile=foo.classlist`), such a classlist may not contain all the `@lambda-form-invoker` lines as in the default classlist. As a result, at runtime, more custom LambdaForm classes may be generated than necessary.
>> 
>> The solution is to always load the `@lambda-form-invoker` lines from the default classlist, to make sure the CDS image has all the commonly-used invoker methods.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed open/test/hotspot/jtreg:hotspot_appcds_dynamic tests

Sorry this was an aspect of archive generation that I was not aware of - and I still don't really grok the full picture here.

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

PR: https://git.openjdk.org/jdk/pull/10639

From kbarrett at openjdk.org  Tue Oct 11 07:48:31 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 11 Oct 2022 07:48:31 GMT
Subject: RFR: 8294594: Fix cast-function-type warnings in signal handling
 code [v2]
In-Reply-To: <VKINUWO-QctcaSiPS-qsrBVsepqtihEDqJFKNBJrXa0=.d0e02d97-c30c-40a9-9d99-b9b0a1c92e89@github.com>
References: <Fp96nMrtVhISqFOO67MmNGQPoKyUKV9jgPFtGkoTzt0=.3436f114-0877-4513-91f7-4b611ebd8c8b@github.com>
 <f09OuHeDU7QluFW1PwmfzMJVSjBFg10Exs2m--0bNbQ=.682762a4-9af3-43e4-88df-37b21bd89e6c@github.com>
 <VKINUWO-QctcaSiPS-qsrBVsepqtihEDqJFKNBJrXa0=.d0e02d97-c30c-40a9-9d99-b9b0a1c92e89@github.com>
Message-ID: <5c7KNhNgs7Fg2ZNwr6X72zfqytPBvq5n_Vr8AvrX30o=.659b507d-f75f-4490-b5ea-6c6f50b15374@github.com>

On Tue, 11 Oct 2022 01:47:45 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Fix looks good as far as it goes (can't believe I didn't see what was going on here!) - but `os::signal` is still broken as it uses `sa_handler` instead of `sa_sigaction`.

Yikes!  I think this change should proceed as is, and `os::signal` should be looked at as a new issue.  That looks messy :(

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

PR: https://git.openjdk.org/jdk/pull/10494

From shade at openjdk.org  Tue Oct 11 08:13:24 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 11 Oct 2022 08:13:24 GMT
Subject: RFR: 8294594: Fix cast-function-type warnings in signal handling
 code [v2]
In-Reply-To: <5c7KNhNgs7Fg2ZNwr6X72zfqytPBvq5n_Vr8AvrX30o=.659b507d-f75f-4490-b5ea-6c6f50b15374@github.com>
References: <Fp96nMrtVhISqFOO67MmNGQPoKyUKV9jgPFtGkoTzt0=.3436f114-0877-4513-91f7-4b611ebd8c8b@github.com>
 <f09OuHeDU7QluFW1PwmfzMJVSjBFg10Exs2m--0bNbQ=.682762a4-9af3-43e4-88df-37b21bd89e6c@github.com>
 <VKINUWO-QctcaSiPS-qsrBVsepqtihEDqJFKNBJrXa0=.d0e02d97-c30c-40a9-9d99-b9b0a1c92e89@github.com>
 <5c7KNhNgs7Fg2ZNwr6X72zfqytPBvq5n_Vr8AvrX30o=.659b507d-f75f-4490-b5ea-6c6f50b15374@github.com>
Message-ID: <NGvQZdueqf_R_0CXHQRGZhiEESfdokg1yeqnutgKFXo=.ed4c4aad-c9aa-4330-a1b7-232240eb9d14@github.com>

On Tue, 11 Oct 2022 07:44:30 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> > Fix looks good as far as it goes (can't believe I didn't see what was going on here!) - but `os::signal` is still broken as it uses `sa_handler` instead of `sa_sigaction`.
> 
> Yikes! I think this change should proceed as is, and `os::signal` should be looked at as a new issue. That looks messy :(

There is no rush, because we are waiting for another build system change to drop. 

Why can't we do the same thing we did for `SR_handler` in `SR_initialize`?


@@ -864,7 +864,7 @@ void* os::signal(int signal_number, void* handler) {
   remove_error_signals_from_set(&(sigAct.sa_mask));
 
   sigAct.sa_flags   = SA_RESTART|SA_SIGINFO;
-  sigAct.sa_handler = CAST_TO_FN_PTR(sa_handler_t, handler);
+  sigAct.sa_sigaction = CAST_TO_FN_PTR(sa_sigaction_t, handler);
 
   if (sigaction(signal_number, &sigAct, &oldSigAct)) {
     // -1 means registration failed


It matches what we should do for `SIG_INFO` flag, and as Kim said, it is still likely yields the same code as `sa_handler` and `sa_sigaction` are probably the same on currently supported systems.

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

PR: https://git.openjdk.org/jdk/pull/10494

From kbarrett at openjdk.org  Tue Oct 11 08:31:46 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 11 Oct 2022 08:31:46 GMT
Subject: RFR: 8294594: Fix cast-function-type warnings in signal handling
 code [v2]
In-Reply-To: <NGvQZdueqf_R_0CXHQRGZhiEESfdokg1yeqnutgKFXo=.ed4c4aad-c9aa-4330-a1b7-232240eb9d14@github.com>
References: <Fp96nMrtVhISqFOO67MmNGQPoKyUKV9jgPFtGkoTzt0=.3436f114-0877-4513-91f7-4b611ebd8c8b@github.com>
 <f09OuHeDU7QluFW1PwmfzMJVSjBFg10Exs2m--0bNbQ=.682762a4-9af3-43e4-88df-37b21bd89e6c@github.com>
 <VKINUWO-QctcaSiPS-qsrBVsepqtihEDqJFKNBJrXa0=.d0e02d97-c30c-40a9-9d99-b9b0a1c92e89@github.com>
 <5c7KNhNgs7Fg2ZNwr6X72zfqytPBvq5n_Vr8AvrX30o=.659b507d-f75f-4490-b5ea-6c6f50b15374@github.com>
 <NGvQZdueqf_R_0CXHQRGZhiEESfdokg1yeqnutgKFXo=.ed4c4aad-c9aa-4330-a1b7-232240eb9d14@github.com>
Message-ID: <7DnCphTnvHF8WA3ki9dLidoxEe64MRWZZpx9u9rIfSY=.6333dff8-ef6a-4aec-8e53-2e14e89b8be4@github.com>

On Tue, 11 Oct 2022 08:11:02 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> > > Fix looks good as far as it goes (can't believe I didn't see what was going on here!) - but `os::signal` is still broken as it uses `sa_handler` instead of `sa_sigaction`.
> > 
> > 
> > Yikes! I think this change should proceed as is, and `os::signal` should be looked at as a new issue. That looks messy :(
> 
> There is no rush, because we are waiting for another build system change to drop.
> 
> Why can't we do the same thing we did for `SR_handler` in `SR_initialize`?
> 
> ```
> @@ -864,7 +864,7 @@ void* os::signal(int signal_number, void* handler) {
>    remove_error_signals_from_set(&(sigAct.sa_mask));
>  
>    sigAct.sa_flags   = SA_RESTART|SA_SIGINFO;
> -  sigAct.sa_handler = CAST_TO_FN_PTR(sa_handler_t, handler);
> +  sigAct.sa_sigaction = CAST_TO_FN_PTR(sa_sigaction_t, handler);
>  
>    if (sigaction(signal_number, &sigAct, &oldSigAct)) {
>      // -1 means registration failed
> ```
> 
> It matches what we should do for `SIG_INFO` flag, and as Kim said, it is still likely yields the same code as `sa_handler` and `sa_sigaction` are probably the same on currently supported systems.

For POSIX we expect the handler argument for os::signal to be a sigaction handler (taking 3 arguments).  For Windows we expect os::signal to take a 1 argument handler, since Windows seemingly doesn't support the sigaction stuff.  How is that a portability layer?

So all of the calls are going to need their handler functions examined.  In at least one use (in os_windows), the UserHandler function takes 3 arguments though only uses one, and is called with only one.

Looking at where os::signal is called, it's not clear it needs to be in os, and given the inconsistent expectations it probably shouldn't be.  All calls are in posix-specific or windows-specific files.  I'd suggest removing os::signal entirely, and having windows code use ::signal and posix code use ::sigaction.  Maybe with some convenience wrappers around each, but those wrappers are windows-specific or posix-specific and never the twain shall meet.

That all seems to me like it would be better to separate from this change, keeping this one nice and simple.

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

PR: https://git.openjdk.org/jdk/pull/10494

From shade at openjdk.org  Tue Oct 11 08:40:24 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 11 Oct 2022 08:40:24 GMT
Subject: RFR: 8294594: Fix cast-function-type warnings in signal handling
 code [v2]
In-Reply-To: <7DnCphTnvHF8WA3ki9dLidoxEe64MRWZZpx9u9rIfSY=.6333dff8-ef6a-4aec-8e53-2e14e89b8be4@github.com>
References: <Fp96nMrtVhISqFOO67MmNGQPoKyUKV9jgPFtGkoTzt0=.3436f114-0877-4513-91f7-4b611ebd8c8b@github.com>
 <f09OuHeDU7QluFW1PwmfzMJVSjBFg10Exs2m--0bNbQ=.682762a4-9af3-43e4-88df-37b21bd89e6c@github.com>
 <VKINUWO-QctcaSiPS-qsrBVsepqtihEDqJFKNBJrXa0=.d0e02d97-c30c-40a9-9d99-b9b0a1c92e89@github.com>
 <5c7KNhNgs7Fg2ZNwr6X72zfqytPBvq5n_Vr8AvrX30o=.659b507d-f75f-4490-b5ea-6c6f50b15374@github.com>
 <NGvQZdueqf_R_0CXHQRGZhiEESfdokg1yeqnutgKFXo=.ed4c4aad-c9aa-4330-a1b7-232240eb9d14@github.com>
 <7DnCphTnvHF8WA3ki9dLidoxEe64MRWZZpx9u9rIfSY=.6333dff8-ef6a-4aec-8e53-2e14e89b8be4@github.com>
Message-ID: <JgXGBX5vNzKs2x1uHC0caBx2mvyfjPwNxAibAc3FCtA=.125ef708-513c-46fb-a2f5-6a9c4d9b703f@github.com>

On Tue, 11 Oct 2022 08:28:48 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> For POSIX we expect the handler argument for os::signal to be a sigaction handler (taking 3 arguments). For Windows we expect os::signal to take a 1 argument handler, since Windows seemingly doesn't support the sigaction stuff. How is that a portability layer?

D'oh.

> That all seems to me like it would be better to separate from this change, keeping this one nice and simple.

Agreed.

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

PR: https://git.openjdk.org/jdk/pull/10494

From kbarrett at openjdk.org  Tue Oct 11 08:58:23 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 11 Oct 2022 08:58:23 GMT
Subject: RFR: 8294594: Fix cast-function-type warnings in signal handling
 code [v2]
In-Reply-To: <JgXGBX5vNzKs2x1uHC0caBx2mvyfjPwNxAibAc3FCtA=.125ef708-513c-46fb-a2f5-6a9c4d9b703f@github.com>
References: <Fp96nMrtVhISqFOO67MmNGQPoKyUKV9jgPFtGkoTzt0=.3436f114-0877-4513-91f7-4b611ebd8c8b@github.com>
 <f09OuHeDU7QluFW1PwmfzMJVSjBFg10Exs2m--0bNbQ=.682762a4-9af3-43e4-88df-37b21bd89e6c@github.com>
 <VKINUWO-QctcaSiPS-qsrBVsepqtihEDqJFKNBJrXa0=.d0e02d97-c30c-40a9-9d99-b9b0a1c92e89@github.com>
 <5c7KNhNgs7Fg2ZNwr6X72zfqytPBvq5n_Vr8AvrX30o=.659b507d-f75f-4490-b5ea-6c6f50b15374@github.com>
 <NGvQZdueqf_R_0CXHQRGZhiEESfdokg1yeqnutgKFXo=.ed4c4aad-c9aa-4330-a1b7-232240eb9d14@github.com>
 <7DnCphTnvHF8WA3ki9dLidoxEe64MRWZZpx9u9rIfSY=.6333dff8-ef6a-4aec-8e53-2e14e89b8be4@github.com>
 <JgXGBX5vNzKs2x1uHC0caBx2mvyfjPwNxAibAc3FCtA=.125ef708-513c-46fb-a2f5-6a9c4d9b703f@github.com>
Message-ID: <iRIbXyZEMCfifFjBA5mbpnqGWiNnjOone8Z81u2v_FM=.89c46b19-08e1-4458-9460-3d53c48e7ecb@github.com>

On Tue, 11 Oct 2022 08:37:59 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> > For POSIX we expect the handler argument for os::signal to be a sigaction handler (taking 3 arguments). For Windows we expect os::signal to take a 1 argument handler, since Windows seemingly doesn't support the sigaction stuff. How is that a portability layer?

I'll file a bug report for this.

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

PR: https://git.openjdk.org/jdk/pull/10494

From stefank at openjdk.org  Tue Oct 11 09:06:24 2022
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 11 Oct 2022 09:06:24 GMT
Subject: RFR: 8295012: Arena should not derive from CHeapObj<mtNone> [v2]
In-Reply-To: <xmxHDx6edRDIxFE9tqwlf2xGhipiMTjlLHkTVeomwmA=.6ae115e6-8713-42b4-870c-9c44fe99ec41@github.com>
References: <Vi8c8J_dkW9vUkBsXGMT7WGG3IZBFV4yACs_akgKMgU=.35cda657-a697-42fb-b550-e940638080ec@github.com>
 <xmxHDx6edRDIxFE9tqwlf2xGhipiMTjlLHkTVeomwmA=.6ae115e6-8713-42b4-870c-9c44fe99ec41@github.com>
Message-ID: <aSM1_ktl6q1YVRqFqFQQYKzKU1y1w0j1UyOAnl2Idww=.822ae766-716f-4d91-b569-2c4c238ffbad@github.com>

On Tue, 11 Oct 2022 05:17:40 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to the `Arena` class.  Rather than deriving from
>> `CHeapObj<mtNone>` (which has the effect of preventing C-heap allocation for an
>> arena by asserting if such is attempted), instead have no allocation base
>> class so that `new Arena(...)` will fail to compile.
>> 
>> Testing: mach5 tier1
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Arena derives from CHeapObjBase

Marked as reviewed by stefank (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10621

From aph at openjdk.org  Tue Oct 11 09:07:26 2022
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 11 Oct 2022 09:07:26 GMT
Subject: RFR: 8295069: [PPC64] Performance regression after JDK-8290025
 [v2]
In-Reply-To: <LECAKm0RDLiAnZ09wBws3ii-eLHVOn1tBIru03hQQzA=.e278e0ae-afcd-4c9c-a6f6-cce80e7bd285@github.com>
References: <OnRsJ6wxgFKb0mkUmTVScpm3-6gK6BYaFr58Tk5wzT8=.7fae15f8-5e08-459f-b5ee-5430703824a4@github.com>
 <tIDXslMGKobJSMHDxn4c1FGMS3dm8brMpkbCs6bocJA=.12279b57-caea-4275-95a3-5338fa46b26f@github.com>
 <Lal8Or6BTGJ4E1OJPynWrs35ZkLjBi4j52MbAuHeaYQ=.309b763a-a894-402c-aed9-761fa9448d8a@github.com>
 <LECAKm0RDLiAnZ09wBws3ii-eLHVOn1tBIru03hQQzA=.e278e0ae-afcd-4c9c-a6f6-cce80e7bd285@github.com>
Message-ID: <r1j7l9UUzid7O66f-GoOgDigA33YcuBKgLMFSVYOsOI=.1d6e5cdf-b46a-4d6a-90fd-da4d3f8170e8@github.com>

On Mon, 10 Oct 2022 20:58:33 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> > Might it make sense for PPC to do what AArch64 does? We don't need any memory fence instructions on the fast path.
> 
> We are actually doing what AArch64 does, now. AArch64 still uses `membar(__ LoadLoad)` for (non-generational) ZGC and ShenandoahGC, because they use `NMethodPatchingType::conc_data_patch`. Other GCs don't need any memory fence instructions. 

Ah, okay. On AArch64 we only issue a `LoadLoad` for `conc_data_patch` so I think we're good.

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

PR: https://git.openjdk.org/jdk/pull/10632

From kbarrett at openjdk.org  Tue Oct 11 09:16:33 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 11 Oct 2022 09:16:33 GMT
Subject: RFR: 8294594: Fix cast-function-type warnings in signal handling
 code [v2]
In-Reply-To: <iRIbXyZEMCfifFjBA5mbpnqGWiNnjOone8Z81u2v_FM=.89c46b19-08e1-4458-9460-3d53c48e7ecb@github.com>
References: <Fp96nMrtVhISqFOO67MmNGQPoKyUKV9jgPFtGkoTzt0=.3436f114-0877-4513-91f7-4b611ebd8c8b@github.com>
 <f09OuHeDU7QluFW1PwmfzMJVSjBFg10Exs2m--0bNbQ=.682762a4-9af3-43e4-88df-37b21bd89e6c@github.com>
 <VKINUWO-QctcaSiPS-qsrBVsepqtihEDqJFKNBJrXa0=.d0e02d97-c30c-40a9-9d99-b9b0a1c92e89@github.com>
 <5c7KNhNgs7Fg2ZNwr6X72zfqytPBvq5n_Vr8AvrX30o=.659b507d-f75f-4490-b5ea-6c6f50b15374@github.com>
 <NGvQZdueqf_R_0CXHQRGZhiEESfdokg1yeqnutgKFXo=.ed4c4aad-c9aa-4330-a1b7-232240eb9d14@github.com>
 <7DnCphTnvHF8WA3ki9dLidoxEe64MRWZZpx9u9rIfSY=.6333dff8-ef6a-4aec-8e53-2e14e89b8be4@github.com>
 <JgXGBX5vNzKs2x1uHC0caBx2mvyfjPwNxAibAc3FCtA=.125ef708-513c-46fb-a2f5-6a9c4d9b703f@github.com>
 <iRIbXyZEMCfifFjBA5mbpnqGWiNnjOone8Z81u2v_FM=.89c46b19-08e1-4458-9460-3d53c48e7ecb@github.com>
Message-ID: <Smx5R78KX2yKKXaoVgTJpS1mEaDVLGMv2KO462Enlpc=.c7f4b7a7-ad23-4353-9d00-1fa9e25afebd@github.com>

On Tue, 11 Oct 2022 08:54:42 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> > > For POSIX we expect the handler argument for os::signal to be a sigaction handler (taking 3 arguments). For Windows we expect os::signal to take a 1 argument handler, since Windows seemingly doesn't support the sigaction stuff. How is that a portability layer?
> 
> I'll file a bug report for this.

https://bugs.openjdk.org/browse/JDK-8295125

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

PR: https://git.openjdk.org/jdk/pull/10494

From rrich at openjdk.org  Tue Oct 11 09:58:53 2022
From: rrich at openjdk.org (Richard Reingruber)
Date: Tue, 11 Oct 2022 09:58:53 GMT
Subject: RFR: 8295069: [PPC64] Performance regression after JDK-8290025
 [v4]
In-Reply-To: <tQVcNhLFhiiMgK81JFfpzyi0Y_J0JRfPyepV-DJ6Z7k=.b2006694-a739-4dbc-abfa-75cddf555fa5@github.com>
References: <OnRsJ6wxgFKb0mkUmTVScpm3-6gK6BYaFr58Tk5wzT8=.7fae15f8-5e08-459f-b5ee-5430703824a4@github.com>
 <tQVcNhLFhiiMgK81JFfpzyi0Y_J0JRfPyepV-DJ6Z7k=.b2006694-a739-4dbc-abfa-75cddf555fa5@github.com>
Message-ID: <iXxpxe-D1Irv1sI8eEW3wX3HHW3A0oFuLN5HC6EWTSg=.dffca6c3-18fe-4536-aaaa-f70936a97f83@github.com>

On Mon, 10 Oct 2022 22:28:02 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> I have a proposal to mitigate the performance regression (see JBS issue) on PPC64 significantly. We get most of the performance back. Please review. Implemented like on aarch64, now. Also use 64 bit load for `uint64_t _nmethod_disarm_value` (not relevant for Little Endian).
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use 64 bit load for _nmethod_disarm_value. (Makes a difference on Big Endian\!)

Changes look good!
Thanks, Richard.

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

Marked as reviewed by rrich (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10632

From mdoerr at openjdk.org  Tue Oct 11 10:14:30 2022
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 11 Oct 2022 10:14:30 GMT
Subject: RFR: 8295069: [PPC64] Performance regression after JDK-8290025
 [v4]
In-Reply-To: <tQVcNhLFhiiMgK81JFfpzyi0Y_J0JRfPyepV-DJ6Z7k=.b2006694-a739-4dbc-abfa-75cddf555fa5@github.com>
References: <OnRsJ6wxgFKb0mkUmTVScpm3-6gK6BYaFr58Tk5wzT8=.7fae15f8-5e08-459f-b5ee-5430703824a4@github.com>
 <tQVcNhLFhiiMgK81JFfpzyi0Y_J0JRfPyepV-DJ6Z7k=.b2006694-a739-4dbc-abfa-75cddf555fa5@github.com>
Message-ID: <8tzBoN0RtyIW9miMSZC2OL7bjYfmnpV7cv27O6nG6aM=.7fb95192-8269-43bc-b100-05fbb5c7952f@github.com>

On Mon, 10 Oct 2022 22:28:02 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> I have a proposal to mitigate the performance regression (see JBS issue) on PPC64 significantly. We get most of the performance back. Please review. Implemented like on aarch64, now. Also use 64 bit load for `uint64_t _nmethod_disarm_value` (not relevant for Little Endian).
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use 64 bit load for _nmethod_disarm_value. (Makes a difference on Big Endian\!)

Thanks for reviewing!
Note: I have tested the new code on Big Endian linux as well. My latest commit avoids hitting the C++ barrier code unnecessarily often.

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

PR: https://git.openjdk.org/jdk/pull/10632

From jsjolen at openjdk.org  Tue Oct 11 10:31:29 2022
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 11 Oct 2022 10:31:29 GMT
Subject: RFR: 8294772: Remove workaround in os::dll_address_to_library_name
 [v2]
In-Reply-To: <XxV07mEZMfIMNuve5mZDn7dQA8NzLrrXTULALA88G9Y=.1cd2c6ad-8880-4bc9-ae04-76a75e739c5d@github.com>
References: <XxV07mEZMfIMNuve5mZDn7dQA8NzLrrXTULALA88G9Y=.1cd2c6ad-8880-4bc9-ae04-76a75e739c5d@github.com>
Message-ID: <2rEQy56A_hMk4hT3OkGHljyJufVc0xvm3n72rrAf1DY=.7d21ed2a-4187-46ce-a03b-0aed88561990@github.com>

> I ported the BSD implementation of this function. According to the comment this bug should be fixed, as the oldest glibc I can see us supporting is 2.12.x. I've made an attempt at finding the bug that the comment refers to on glibc's bug tracker but has been unsuccesful in this.
> 
> The second commit deletes what seems like an outdated comment (in os_bsd this refers to a code snippet right below the comment).

Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:

  Delete comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10559/files
  - new: https://git.openjdk.org/jdk/pull/10559/files/7ae05ca1..36dcb7d3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10559&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10559&range=00-01

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

PR: https://git.openjdk.org/jdk/pull/10559

From jsjolen at openjdk.org  Tue Oct 11 10:31:31 2022
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 11 Oct 2022 10:31:31 GMT
Subject: RFR: 8294772: Remove workaround in os::dll_address_to_library_name
 [v2]
In-Reply-To: <eLi9_-pDMQfQWO4ZBrfxmSxvsCfo1_JEcmKbCxwXoBE=.a4c54a85-e1d4-4a2b-99bd-47675b73d171@github.com>
References: <XxV07mEZMfIMNuve5mZDn7dQA8NzLrrXTULALA88G9Y=.1cd2c6ad-8880-4bc9-ae04-76a75e739c5d@github.com>
 <eLi9_-pDMQfQWO4ZBrfxmSxvsCfo1_JEcmKbCxwXoBE=.a4c54a85-e1d4-4a2b-99bd-47675b73d171@github.com>
Message-ID: <Zhfra3gaUYg8L7GFAS8OCkNEZoXVAHeZeg0yM8vXqqI=.806a095f-2aae-4103-b99c-c8d50b3f79ad@github.com>

On Mon, 10 Oct 2022 17:24:54 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Delete comments
>
> src/hotspot/os/linux/os_linux.cpp line 1375:
> 
>> 1373: }
>> 1374: 
>> 1375: // Ported from BSD version
> 
> I think this comment is not necessary. In fact, the corresponding comment `// ported from solaris version` in os_bsd.cpp should probably be removed as well.

Sounds good, removed them.

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

PR: https://git.openjdk.org/jdk/pull/10559

From sakatakui at oss.nttdata.com  Tue Oct 11 11:27:04 2022
From: sakatakui at oss.nttdata.com (Koichi Sakata)
Date: Tue, 11 Oct 2022 20:27:04 +0900
Subject: Proposal of Outputting Unified Logging to TCP socket
In-Reply-To: <6218e95d-57d9-fd05-ede9-9d01c7bf34e6@oracle.com>
References: <b7b8a4524752e2ebc34f2d7930e68c7b@oss.nttdata.com>
 <6218e95d-57d9-fd05-ede9-9d01c7bf34e6@oracle.com>
Message-ID: <6f99e5a6fd760baa27867cbe56319c5c@oss.nttdata.com>

Hello Johan,

Thank you for reading the entire proposal! I'm sorry for late reply.

I understand that it might create a large attack vector, but that might 
be the same for Log4j2 and Logback because they have the TCP 
implementation, I think. I can see that maintenance costs will increase 
if we have this feature.

> My suggestion would be to use an external tool. The most basic of
> these would look like this:
> 
> Process 0:
> $ run_tcp_server localhost 4040
> Process 1:
> $ mkfifo my.log
> $ tail -f my.log | netcat localhost 4040
> Process 2:
> $ java -Xlog:disable -Xlog::my.log

Thank you for your suggestion. That's useful for me!

Regards,
Koichi Sakata

On 06-10-2022 01:15 AM, Johan Sj?l?n wrote:
> On 2022-10-04 16:21, Koichi Sakata wrote:
>> Hello,
>> 
>> I would like to propose outputting unified logging (UL) to the TCP 
>> socket. I know that this has been discussed before [1]. However, 
>> circumstances have changed. Asynchronous logging was added to UL. If 
>> we output logs to TCP with async mode, we will be able to solve some 
>> issues raised in the past discussion (e.g. lag of log() calls). So I 
>> will take up this subject again.
>> 
>> This feature is useful, especially in the container environment. Take 
>> Kubernetes for example, there are many containers. It is recommended 
>> that containers send logs to standard output, but the mixture of Java 
>> application logs and UL logs in stdout is not handy to parse or search 
>> in a log aggregator like Elasticsearch. I believe that it's beneficial 
>> to deal with each type of log individually.
>> 
>> When we have files of UL logs, we have another issue. That is where to 
>> persist those files. As you know, we lose logs when pods are removed. 
>> I would rather not use volumes like Persistent Volume because of the 
>> cost of using volumes and the effort of managing files. When using the 
>> volume, we need to determine the file size and the volume size and put 
>> many log files of containers in it.
>> 
>> UL via TCP socket answers these issues. In the Kubernetes example, we 
>> use a log forwarder like Fluent Bit, Filebeat or something as a 
>> DaemonSet. It gets UL logs from the socket, gets application logs from 
>> stdout, and sends each log to corresponding log aggregators. As a 
>> result, we don't have UL log files and volumes to persist them 
>> anymore. This is premised on asynchronous logging. So the lag will not 
>> be a problem, I think.
>> 
>> For these reasons, I would like to propose outputting UL logs to TCP 
>> inputs. It seems to be unnecessary for traditional java applications, 
>> but it's of great use for applications in container environments. This 
>> makes it easier to build and operate applications on Kubernetes. There 
>> is also a bonus that this is os independent.
>> 
>> I will create a prototype of this proposal if it is worth trying.
>> 
>> By the way, there is a network stream class that is used to send node 
>> information to Ideal Graph Visualizer via socket. I'm not sure whether 
>> we can divert it or not for this new feature.
>> 
>> Best Regards,
>> Koichi Sakata
>> 
>> [1] 
>> https://mail.openjdk.org/pipermail/hotspot-runtime-dev/2020-November/043221.html
> 
> Hi Koichi Sokata,
> 
> Thank you for your suggestion. I think that you're right, UL is in a
> better position to accept TCP sockets as output devices now than it
> was previously thanks to the introduction of asynchronous logging.
> However, I am skeptical to the idea of adding these to UL. It creates
> a rather large attack vector for us, it also creates a maintenance
> burden and finally getting this right for everyone is probably close
> to impossible.
> 
> Please note that the Ideal Graph Visualizer is a debug tool, it is not
> meant for use in production. Therefore, its requirements are very
> different to UL, which needs to be robust.
> 
> My suggestion would be to use an external tool. The most basic of
> these would look like this:
> 
> Process 0:
> $ run_tcp_server localhost 4040
> Process 1:
> $ mkfifo my.log
> $ tail -f my.log | netcat localhost 4040
> Process 2:
> $ java -Xlog:disable -Xlog::my.log
> 
> Where the initial -Xlog:disable disables any default configuration
> which would output to stdout.
> 
> I am sure that there are more sophisticated tools which works
> essentially like this.
> 
> Best regards,
> Johan Sj?l?n

From rkennke at openjdk.org  Tue Oct 11 12:27:23 2022
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 11 Oct 2022 12:27:23 GMT
Subject: RFR: 8294751: Zero: Allow larger default heaps [v2]
In-Reply-To: <MG-Wb8zUE0JI4L-owNCxUkP6qD5pDVRgFWhtjTcGv1A=.63c600bd-66cc-4836-9aee-7ed24ca7d781@github.com>
References: <onIurPQPJzorzHjZNvhxPk12j0zySZeRR1rid9KW0Yg=.e42155f8-d8af-4496-b72b-350e1dbf8e09@github.com>
 <MG-Wb8zUE0JI4L-owNCxUkP6qD5pDVRgFWhtjTcGv1A=.63c600bd-66cc-4836-9aee-7ed24ca7d781@github.com>
Message-ID: <UPVAM5LNdSFumP7gs6amgfdS0Q86Lpl83nWGkpGYOQA=.663fdc0d-ad7c-48c2-b199-f6bb415a8a58@github.com>

On Thu, 6 Oct 2022 10:13:01 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Zero is currently defaulting to `MaxRAM=1G` on all machines. It is set in `compiler_globals.pd` under `#if !defined(COMPILER1) && !defined(COMPILER2) && !INCLUDE_JVMCI`.
>> 
>> Zero supports lots of GCs, and there is little sense to penalize it unnecessarily with too small heaps. After [JDK-8292847](https://bugs.openjdk.org/browse/JDK-8292847), this would allow G1 with reasonable heap size on most machines.
>> 
>> Motivational improvements, `SPECjvm2008:serial`:
>> 
>> 
>> # Baseline, G1
>> Serial.test  thrpt   10  1619.863 ? 16.694  ops/s
>> 
>> # Baseline, Serial
>> Serial.test  thrpt   10  1094.438 ? 20.425  ops/s
>> 
>> # Patched, G1
>> Serial.test  thrpt   10  1623.090 ? 17.553  ops/s
>> 
>> # Patched, Serial
>> Serial.test  thrpt   10  1624.531 ? 15.792  ops/s  ; <---- matches G1 now, because young is not tiny
>> 
>> 
>> Before:
>> 
>> 
>> $ build/linux-x86_64-zero-release/jdk/bin/java -Xlog:gc -Xlog:gc+init Alloc.java
>> [0.003s][info][gc     ] Using G1
>> ...
>> [0.005s][info][gc,init] Memory: 125G
>> ...
>> [0.005s][info][gc,init] Heap Region Size: 1M
>> [0.005s][info][gc,init] Heap Min Capacity: 8M
>> [0.005s][info][gc,init] Heap Initial Capacity: 16M
>> [0.005s][info][gc,init] Heap Max Capacity: 256M
>> 
>> 
>> After:
>> 
>> 
>> $ build/linux-x86_64-zero-release/jdk/bin/java -Xlog:gc -Xlog:gc+init Alloc.java
>> [0.003s][info][gc     ] Using G1
>> ...
>> [0.007s][info][gc,init] Memory: 125G
>> ...
>> [0.007s][info][gc,init] Heap Region Size: 16M
>> [0.007s][info][gc,init] Heap Min Capacity: 16M
>> [0.007s][info][gc,init] Heap Initial Capacity: 2016M
>> [0.007s][info][gc,init] Heap Max Capacity: 30208M
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Move to compiler_globals_pd.hpp
>  - Merge branch 'master' into JDK-8294751-zero-larger-heaps
>  - Fix

Seems reasonable and patch looks good!

Thanks,
Roman

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

Marked as reviewed by rkennke (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10552

From shade at openjdk.org  Tue Oct 11 12:31:23 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 11 Oct 2022 12:31:23 GMT
Subject: RFR: 8294751: Zero: Allow larger default heaps [v2]
In-Reply-To: <MG-Wb8zUE0JI4L-owNCxUkP6qD5pDVRgFWhtjTcGv1A=.63c600bd-66cc-4836-9aee-7ed24ca7d781@github.com>
References: <onIurPQPJzorzHjZNvhxPk12j0zySZeRR1rid9KW0Yg=.e42155f8-d8af-4496-b72b-350e1dbf8e09@github.com>
 <MG-Wb8zUE0JI4L-owNCxUkP6qD5pDVRgFWhtjTcGv1A=.63c600bd-66cc-4836-9aee-7ed24ca7d781@github.com>
Message-ID: <SipR_SLNEwTh8jt7eZlJZE2ZyglDG4ddUZhPBc4CmnE=.59e0894e-26fa-4e9b-bab2-eba448fd4bcf@github.com>

On Thu, 6 Oct 2022 10:13:01 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Zero is currently defaulting to `MaxRAM=1G` on all machines. It is set in `compiler_globals.pd` under `#if !defined(COMPILER1) && !defined(COMPILER2) && !INCLUDE_JVMCI`.
>> 
>> Zero supports lots of GCs, and there is little sense to penalize it unnecessarily with too small heaps. After [JDK-8292847](https://bugs.openjdk.org/browse/JDK-8292847), this would allow G1 with reasonable heap size on most machines.
>> 
>> Motivational improvements, `SPECjvm2008:serial`:
>> 
>> 
>> # Baseline, G1
>> Serial.test  thrpt   10  1619.863 ? 16.694  ops/s
>> 
>> # Baseline, Serial
>> Serial.test  thrpt   10  1094.438 ? 20.425  ops/s
>> 
>> # Patched, G1
>> Serial.test  thrpt   10  1623.090 ? 17.553  ops/s
>> 
>> # Patched, Serial
>> Serial.test  thrpt   10  1624.531 ? 15.792  ops/s  ; <---- matches G1 now, because young is not tiny
>> 
>> 
>> Before:
>> 
>> 
>> $ build/linux-x86_64-zero-release/jdk/bin/java -Xlog:gc -Xlog:gc+init Alloc.java
>> [0.003s][info][gc     ] Using G1
>> ...
>> [0.005s][info][gc,init] Memory: 125G
>> ...
>> [0.005s][info][gc,init] Heap Region Size: 1M
>> [0.005s][info][gc,init] Heap Min Capacity: 8M
>> [0.005s][info][gc,init] Heap Initial Capacity: 16M
>> [0.005s][info][gc,init] Heap Max Capacity: 256M
>> 
>> 
>> After:
>> 
>> 
>> $ build/linux-x86_64-zero-release/jdk/bin/java -Xlog:gc -Xlog:gc+init Alloc.java
>> [0.003s][info][gc     ] Using G1
>> ...
>> [0.007s][info][gc,init] Memory: 125G
>> ...
>> [0.007s][info][gc,init] Heap Region Size: 16M
>> [0.007s][info][gc,init] Heap Min Capacity: 16M
>> [0.007s][info][gc,init] Heap Initial Capacity: 2016M
>> [0.007s][info][gc,init] Heap Max Capacity: 30208M
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Move to compiler_globals_pd.hpp
>  - Merge branch 'master' into JDK-8294751-zero-larger-heaps
>  - Fix

Thanks!

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

PR: https://git.openjdk.org/jdk/pull/10552

From shade at openjdk.org  Tue Oct 11 12:33:32 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 11 Oct 2022 12:33:32 GMT
Subject: Integrated: 8294751: Zero: Allow larger default heaps
In-Reply-To: <onIurPQPJzorzHjZNvhxPk12j0zySZeRR1rid9KW0Yg=.e42155f8-d8af-4496-b72b-350e1dbf8e09@github.com>
References: <onIurPQPJzorzHjZNvhxPk12j0zySZeRR1rid9KW0Yg=.e42155f8-d8af-4496-b72b-350e1dbf8e09@github.com>
Message-ID: <YTeI7ta0D8dIEfIPyCC2akVTly_f0QLkVtE1e18t6MU=.100ae4cd-324a-4122-9883-fc33258ff614@github.com>

On Tue, 4 Oct 2022 09:37:48 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Zero is currently defaulting to `MaxRAM=1G` on all machines. It is set in `compiler_globals.pd` under `#if !defined(COMPILER1) && !defined(COMPILER2) && !INCLUDE_JVMCI`.
> 
> Zero supports lots of GCs, and there is little sense to penalize it unnecessarily with too small heaps. After [JDK-8292847](https://bugs.openjdk.org/browse/JDK-8292847), this would allow G1 with reasonable heap size on most machines.
> 
> Motivational improvements, `SPECjvm2008:serial`:
> 
> 
> # Baseline, G1
> Serial.test  thrpt   10  1619.863 ? 16.694  ops/s
> 
> # Baseline, Serial
> Serial.test  thrpt   10  1094.438 ? 20.425  ops/s
> 
> # Patched, G1
> Serial.test  thrpt   10  1623.090 ? 17.553  ops/s
> 
> # Patched, Serial
> Serial.test  thrpt   10  1624.531 ? 15.792  ops/s  ; <---- matches G1 now, because young is not tiny
> 
> 
> Before:
> 
> 
> $ build/linux-x86_64-zero-release/jdk/bin/java -Xlog:gc -Xlog:gc+init Alloc.java
> [0.003s][info][gc     ] Using G1
> ...
> [0.005s][info][gc,init] Memory: 125G
> ...
> [0.005s][info][gc,init] Heap Region Size: 1M
> [0.005s][info][gc,init] Heap Min Capacity: 8M
> [0.005s][info][gc,init] Heap Initial Capacity: 16M
> [0.005s][info][gc,init] Heap Max Capacity: 256M
> 
> 
> After:
> 
> 
> $ build/linux-x86_64-zero-release/jdk/bin/java -Xlog:gc -Xlog:gc+init Alloc.java
> [0.003s][info][gc     ] Using G1
> ...
> [0.007s][info][gc,init] Memory: 125G
> ...
> [0.007s][info][gc,init] Heap Region Size: 16M
> [0.007s][info][gc,init] Heap Min Capacity: 16M
> [0.007s][info][gc,init] Heap Initial Capacity: 2016M
> [0.007s][info][gc,init] Heap Max Capacity: 30208M

This pull request has now been integrated.

Changeset: 3ebe5ad2
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3ebe5ad2d7771ccf7710350b749d780fef91e40c
Stats:     13 lines in 2 files changed: 7 ins; 6 del; 0 mod

8294751: Zero: Allow larger default heaps

Reviewed-by: iklam, rkennke

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

PR: https://git.openjdk.org/jdk/pull/10552

From dholmes at openjdk.org  Tue Oct 11 13:12:13 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 11 Oct 2022 13:12:13 GMT
Subject: RFR: 8294594: Fix cast-function-type warnings in signal handling
 code [v2]
In-Reply-To: <f09OuHeDU7QluFW1PwmfzMJVSjBFg10Exs2m--0bNbQ=.682762a4-9af3-43e4-88df-37b21bd89e6c@github.com>
References: <Fp96nMrtVhISqFOO67MmNGQPoKyUKV9jgPFtGkoTzt0=.3436f114-0877-4513-91f7-4b611ebd8c8b@github.com>
 <f09OuHeDU7QluFW1PwmfzMJVSjBFg10Exs2m--0bNbQ=.682762a4-9af3-43e4-88df-37b21bd89e6c@github.com>
Message-ID: <7zK0uy01g7MNXeNK-40g97ir_PCUCKUkSoto8jxEIgA=.da3eb364-3f42-47dd-ab02-960a710a4c0f@github.com>

On Mon, 10 Oct 2022 12:32:39 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> After [JDK-8294314](https://bugs.openjdk.org/browse/JDK-8294314), we would have signals_posix.cpp excluded with cast-function-type warning:
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Naming
>  - Redo using the proper signatures
>  - Merge branch 'master' into JDK-8294594-warning-cast-function-type-signals
>  - Fix

Okay I agree it makes no sense to have `os::signal` as shared code because you can't use it in a platform independent manner.

I can take that new bug (thanks @kimbarrett ) unless @shipilev  really wants it? :)

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

PR: https://git.openjdk.org/jdk/pull/10494

From shade at openjdk.org  Tue Oct 11 13:12:13 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 11 Oct 2022 13:12:13 GMT
Subject: RFR: 8294594: Fix cast-function-type warnings in signal handling
 code [v2]
In-Reply-To: <JgXGBX5vNzKs2x1uHC0caBx2mvyfjPwNxAibAc3FCtA=.125ef708-513c-46fb-a2f5-6a9c4d9b703f@github.com>
References: <Fp96nMrtVhISqFOO67MmNGQPoKyUKV9jgPFtGkoTzt0=.3436f114-0877-4513-91f7-4b611ebd8c8b@github.com>
 <f09OuHeDU7QluFW1PwmfzMJVSjBFg10Exs2m--0bNbQ=.682762a4-9af3-43e4-88df-37b21bd89e6c@github.com>
 <VKINUWO-QctcaSiPS-qsrBVsepqtihEDqJFKNBJrXa0=.d0e02d97-c30c-40a9-9d99-b9b0a1c92e89@github.com>
 <5c7KNhNgs7Fg2ZNwr6X72zfqytPBvq5n_Vr8AvrX30o=.659b507d-f75f-4490-b5ea-6c6f50b15374@github.com>
 <NGvQZdueqf_R_0CXHQRGZhiEESfdokg1yeqnutgKFXo=.ed4c4aad-c9aa-4330-a1b7-232240eb9d14@github.com>
 <7DnCphTnvHF8WA3ki9dLidoxEe64MRWZZpx9u9rIfSY=.6333dff8-ef6a-4aec-8e53-2e14e89b8be4@github.com>
 <JgXGBX5vNzKs2x1uHC0caBx2mvyfjPwNxAibAc3FCtA=.125ef708-513c-46fb-a2f5-6a9c4d9b703f@github.com>
Message-ID: <9k-Cf-C0Ny8c81LyOQakF-rlew2c3nC5mVHnEgL8YQE=.19689a5d-ed54-486d-a683-d60a05f9fe37@github.com>

On Tue, 11 Oct 2022 08:37:59 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>>> > > Fix looks good as far as it goes (can't believe I didn't see what was going on here!) - but `os::signal` is still broken as it uses `sa_handler` instead of `sa_sigaction`.
>>> > 
>>> > 
>>> > Yikes! I think this change should proceed as is, and `os::signal` should be looked at as a new issue. That looks messy :(
>>> 
>>> There is no rush, because we are waiting for another build system change to drop.
>>> 
>>> Why can't we do the same thing we did for `SR_handler` in `SR_initialize`?
>>> 
>>> ```
>>> @@ -864,7 +864,7 @@ void* os::signal(int signal_number, void* handler) {
>>>    remove_error_signals_from_set(&(sigAct.sa_mask));
>>>  
>>>    sigAct.sa_flags   = SA_RESTART|SA_SIGINFO;
>>> -  sigAct.sa_handler = CAST_TO_FN_PTR(sa_handler_t, handler);
>>> +  sigAct.sa_sigaction = CAST_TO_FN_PTR(sa_sigaction_t, handler);
>>>  
>>>    if (sigaction(signal_number, &sigAct, &oldSigAct)) {
>>>      // -1 means registration failed
>>> ```
>>> 
>>> It matches what we should do for `SIG_INFO` flag, and as Kim said, it is still likely yields the same code as `sa_handler` and `sa_sigaction` are probably the same on currently supported systems.
>> 
>> For POSIX we expect the handler argument for os::signal to be a sigaction handler (taking 3 arguments).  For Windows we expect os::signal to take a 1 argument handler, since Windows seemingly doesn't support the sigaction stuff.  How is that a portability layer?
>> 
>> So all of the calls are going to need their handler functions examined.  In at least one use (in os_windows), the UserHandler function takes 3 arguments though only uses one, and is called with only one.
>> 
>> Looking at where os::signal is called, it's not clear it needs to be in os, and given the inconsistent expectations it probably shouldn't be.  All calls are in posix-specific or windows-specific files.  I'd suggest removing os::signal entirely, and having windows code use ::signal and posix code use ::sigaction.  Maybe with some convenience wrappers around each, but those wrappers are windows-specific or posix-specific and never the twain shall meet.
>> 
>> That all seems to me like it would be better to separate from this change, keeping this one nice and simple.
>
>> For POSIX we expect the handler argument for os::signal to be a sigaction handler (taking 3 arguments). For Windows we expect os::signal to take a 1 argument handler, since Windows seemingly doesn't support the sigaction stuff. How is that a portability layer?
> 
> D'oh.
> 
>> That all seems to me like it would be better to separate from this change, keeping this one nice and simple.
> 
> Agreed.

> ...unless @shipilev really wants it? :)

No, I do NOT want it :) I'll be happy to test it, though.

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

PR: https://git.openjdk.org/jdk/pull/10494

From lucy at openjdk.org  Tue Oct 11 13:39:36 2022
From: lucy at openjdk.org (Lutz Schmidt)
Date: Tue, 11 Oct 2022 13:39:36 GMT
Subject: RFR: 8295069: [PPC64] Performance regression after JDK-8290025
 [v4]
In-Reply-To: <tQVcNhLFhiiMgK81JFfpzyi0Y_J0JRfPyepV-DJ6Z7k=.b2006694-a739-4dbc-abfa-75cddf555fa5@github.com>
References: <OnRsJ6wxgFKb0mkUmTVScpm3-6gK6BYaFr58Tk5wzT8=.7fae15f8-5e08-459f-b5ee-5430703824a4@github.com>
 <tQVcNhLFhiiMgK81JFfpzyi0Y_J0JRfPyepV-DJ6Z7k=.b2006694-a739-4dbc-abfa-75cddf555fa5@github.com>
Message-ID: <nd2rBAKoxn3rRv6VtXC5k2D0lPvBvmOww5zbnA7fses=.74178ab0-40cd-45da-b854-cdc3f7c2b3e5@github.com>

On Mon, 10 Oct 2022 22:28:02 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> I have a proposal to mitigate the performance regression (see JBS issue) on PPC64 significantly. We get most of the performance back. Please review. Implemented like on aarch64, now. Also use 64 bit load for `uint64_t _nmethod_disarm_value` (not relevant for Little Endian).
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use 64 bit load for _nmethod_disarm_value. (Makes a difference on Big Endian\!)

Changes look good to me.

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

Marked as reviewed by lucy (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10632

From mdoerr at openjdk.org  Tue Oct 11 13:39:37 2022
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 11 Oct 2022 13:39:37 GMT
Subject: RFR: 8295069: [PPC64] Performance regression after JDK-8290025
 [v4]
In-Reply-To: <tQVcNhLFhiiMgK81JFfpzyi0Y_J0JRfPyepV-DJ6Z7k=.b2006694-a739-4dbc-abfa-75cddf555fa5@github.com>
References: <OnRsJ6wxgFKb0mkUmTVScpm3-6gK6BYaFr58Tk5wzT8=.7fae15f8-5e08-459f-b5ee-5430703824a4@github.com>
 <tQVcNhLFhiiMgK81JFfpzyi0Y_J0JRfPyepV-DJ6Z7k=.b2006694-a739-4dbc-abfa-75cddf555fa5@github.com>
Message-ID: <p5wJGDw06KA9zhJsl-su5sr1vN-5YCU8hO-4vACxyIw=.7a3c1413-4b2c-4e60-a23e-4669d07c8e3d@github.com>

On Mon, 10 Oct 2022 22:28:02 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> I have a proposal to mitigate the performance regression (see JBS issue) on PPC64 significantly. We get most of the performance back. Please review. Implemented like on aarch64, now. Also use 64 bit load for `uint64_t _nmethod_disarm_value` (not relevant for Little Endian).
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use 64 bit load for _nmethod_disarm_value. (Makes a difference on Big Endian\!)

Thanks for the review!

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

PR: https://git.openjdk.org/jdk/pull/10632

From iklam at openjdk.org  Tue Oct 11 15:04:31 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 11 Oct 2022 15:04:31 GMT
Subject: RFR: 8294772: Remove workaround in os::dll_address_to_library_name
 [v2]
In-Reply-To: <2rEQy56A_hMk4hT3OkGHljyJufVc0xvm3n72rrAf1DY=.7d21ed2a-4187-46ce-a03b-0aed88561990@github.com>
References: <XxV07mEZMfIMNuve5mZDn7dQA8NzLrrXTULALA88G9Y=.1cd2c6ad-8880-4bc9-ae04-76a75e739c5d@github.com>
 <2rEQy56A_hMk4hT3OkGHljyJufVc0xvm3n72rrAf1DY=.7d21ed2a-4187-46ce-a03b-0aed88561990@github.com>
Message-ID: <AyctZqGNNQNjRuz53VaCBMTbMLBbkRogmBPg5aratTM=.d4a5cb49-8783-419b-9e3c-302fe4eaa6a9@github.com>

On Tue, 11 Oct 2022 10:31:29 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> I ported the BSD implementation of this function. According to the comment this bug should be fixed, as the oldest glibc I can see us supporting is 2.12.x. I've made an attempt at finding the bug that the comment refers to on glibc's bug tracker but has been unsuccesful in this.
>> 
>> The second commit deletes what seems like an outdated comment (in os_bsd this refers to a code snippet right below the comment).
>
> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Delete comments

What kind of testing have you done? I saw that the GitHub Actions included only jcheck.

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

PR: https://git.openjdk.org/jdk/pull/10559

From ihse at openjdk.org  Tue Oct 11 16:07:20 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 11 Oct 2022 16:07:20 GMT
Subject: RFR: 8294623: gtests does not work with googletest release-1.12.0+
In-Reply-To: <GTSRMWikrMJP0xKZRchcdvyMTIA8QLo9Ghl0_bbIsd0=.953fc4ad-4f58-4cd2-b0df-9cd6d1784d21@github.com>
References: <GTSRMWikrMJP0xKZRchcdvyMTIA8QLo9Ghl0_bbIsd0=.953fc4ad-4f58-4cd2-b0df-9cd6d1784d21@github.com>
Message-ID: <0cu3MhxOIKOJHsWVc-SYd9Yk5hD7hz-aD1ttlAWWkRg=.dfc4faa4-5ab8-41f6-a5e8-93251fc0548e@github.com>

On Fri, 30 Sep 2022 08:38:29 GMT, Dingli Zhang <dzhang at openjdk.org> wrote:

> The scope of `GTEST_DECLARE_string_(internal_run_death_test)` has been changed in googletest 1.12.0 [1]. So we can see some new compiler errors as below:
> 
> 
> $ bash configure --with-gtest=/home/dingli/jdk-tools/googletest && make run-test TEST="gtest:all"
> 
> * For target hotspot_variant-server_libjvm_gtest_objs_gtestMain.o:
> In file included from /home/dingli/jdk-tools/googletest/googlemock/include/gmock/internal/gmock-port.h:57,
>                  from /home/dingli/jdk-tools/googletest/googlemock/include/gmock/internal/gmock-internal-utils.h:49,
>                  from /home/dingli/jdk-tools/googletest/googlemock/include/gmock/gmock-actions.h:145,
>                  from /home/dingli/jdk-tools/googletest/googlemock/include/gmock/gmock.h:56,
>                  from /home/dingli/jdk/test/hotspot/gtest/unittest.hpp:51,
>                  from /home/dingli/jdk/test/hotspot/gtest/gtestMain.cpp:39:

We only support a specific version of gtest. The `building.md` file clearly states:


The supported version of Google Test is 1.8.1


I fully agree with you @kimbarrett. There is no need to support multiple versions of gtest. If 1.8.1 is old, we might consider upgrading, but that is a different discussion. I recommend closing this PR.

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

PR: https://git.openjdk.org/jdk/pull/10503

From jrose at openjdk.org  Tue Oct 11 16:35:18 2022
From: jrose at openjdk.org (John R Rose)
Date: Tue, 11 Oct 2022 16:35:18 GMT
Subject: RFR: 8294623: gtests does not work with googletest release-1.12.0+
In-Reply-To: <GTSRMWikrMJP0xKZRchcdvyMTIA8QLo9Ghl0_bbIsd0=.953fc4ad-4f58-4cd2-b0df-9cd6d1784d21@github.com>
References: <GTSRMWikrMJP0xKZRchcdvyMTIA8QLo9Ghl0_bbIsd0=.953fc4ad-4f58-4cd2-b0df-9cd6d1784d21@github.com>
Message-ID: <OrOnX-4cTfjXAJJHepHkcc2kY0Do2ybjAnz3yzPZ7N4=.cbec2502-9d61-4e0a-8b4b-c0e1cd38cb18@github.com>

On Fri, 30 Sep 2022 08:38:29 GMT, Dingli Zhang <dzhang at openjdk.org> wrote:

> The scope of `GTEST_DECLARE_string_(internal_run_death_test)` has been changed in googletest 1.12.0 [1]. So we can see some new compiler errors as below:
> 
> 
> $ bash configure --with-gtest=/home/dingli/jdk-tools/googletest && make run-test TEST="gtest:all"
> 
> * For target hotspot_variant-server_libjvm_gtest_objs_gtestMain.o:
> In file included from /home/dingli/jdk-tools/googletest/googlemock/include/gmock/internal/gmock-port.h:57,
>                  from /home/dingli/jdk-tools/googletest/googlemock/include/gmock/internal/gmock-internal-utils.h:49,
>                  from /home/dingli/jdk-tools/googletest/googlemock/include/gmock/gmock-actions.h:145,
>                  from /home/dingli/jdk-tools/googletest/googlemock/include/gmock/gmock.h:56,
>                  from /home/dingli/jdk/test/hotspot/gtest/unittest.hpp:51,
>                  from /home/dingli/jdk/test/hotspot/gtest/gtestMain.cpp:39:

In `doc/building.md` it clearly states:

> The supported version of Google Test is 1.8.1, whose source code can be obtained?

The bug report does not say why 1.8.1 was not attempted or was not possible to use.  So this bug report is incomplete until we have sufficient reason to consider an upgrade (which is likely ot be a global upgrade) to a newer gtest.

Until sufficient evidence shows a reason to change, let's stick to our strategy of supporting a particular version of gtest, 1.8.1 at present.

Question to @DingliZhang: Is there a change to the documentation that would help people find and implement the directive to use 1.8.1?  And (of course) is there some reason 1.8.1 was impossible for you to use?

Or is all of this just a move to improve convenience for developers?  If it's a convenience move, it's too expensive, since supporting two versions of gtest is harder than supporting one.  That's why I'm looking for a possible documentation fix, to guide developers a little better.  Perhaps the `Gtest` section in `doc/testing.md` should cross-link to the section quoted above in `doc/building.md`

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

PR: https://git.openjdk.org/jdk/pull/10503

From mdoerr at openjdk.org  Tue Oct 11 19:25:59 2022
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 11 Oct 2022 19:25:59 GMT
Subject: Integrated: 8295069: [PPC64] Performance regression after JDK-8290025
In-Reply-To: <OnRsJ6wxgFKb0mkUmTVScpm3-6gK6BYaFr58Tk5wzT8=.7fae15f8-5e08-459f-b5ee-5430703824a4@github.com>
References: <OnRsJ6wxgFKb0mkUmTVScpm3-6gK6BYaFr58Tk5wzT8=.7fae15f8-5e08-459f-b5ee-5430703824a4@github.com>
Message-ID: <rWQn5vHDmnJ9moH221VCBw8G2Bymgeuim8VAEZ0D7gM=.35f8d1dc-4f30-4ece-8956-c071ae0a6c31@github.com>

On Mon, 10 Oct 2022 14:02:09 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> I have a proposal to mitigate the performance regression (see JBS issue) on PPC64 significantly. We get most of the performance back. Please review. Implemented like on aarch64, now. Also use 64 bit load for `uint64_t _nmethod_disarm_value` (not relevant for Little Endian).

This pull request has now been integrated.

Changeset: 945950d8
Author:    Martin Doerr <mdoerr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/945950d863ebe984e099d83f967adce71892bb95
Stats:     36 lines in 5 files changed: 20 ins; 1 del; 15 mod

8295069: [PPC64] Performance regression after JDK-8290025

Reviewed-by: rrich, lucy

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

PR: https://git.openjdk.org/jdk/pull/10632

From dholmes at openjdk.org  Tue Oct 11 21:20:03 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 11 Oct 2022 21:20:03 GMT
Subject: RFR: 8294594: Fix cast-function-type warnings in signal handling
 code [v2]
In-Reply-To: <f09OuHeDU7QluFW1PwmfzMJVSjBFg10Exs2m--0bNbQ=.682762a4-9af3-43e4-88df-37b21bd89e6c@github.com>
References: <Fp96nMrtVhISqFOO67MmNGQPoKyUKV9jgPFtGkoTzt0=.3436f114-0877-4513-91f7-4b611ebd8c8b@github.com>
 <f09OuHeDU7QluFW1PwmfzMJVSjBFg10Exs2m--0bNbQ=.682762a4-9af3-43e4-88df-37b21bd89e6c@github.com>
Message-ID: <7QKz3KHYBdzXj3wdQT9PsvKO689fN2orAqHJvYdl5OA=.baa36d64-5587-461a-8edd-f929c6923580@github.com>

On Mon, 10 Oct 2022 12:32:39 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> After [JDK-8294314](https://bugs.openjdk.org/browse/JDK-8294314), we would have signals_posix.cpp excluded with cast-function-type warning:
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Naming
>  - Redo using the proper signatures
>  - Merge branch 'master' into JDK-8294594-warning-cast-function-type-signals
>  - Fix

So this is okay to go in in current form, as per discussions. os::signal will be handled separately.

Thanks.

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10494

From david.holmes at oracle.com  Tue Oct 11 23:34:35 2022
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 12 Oct 2022 09:34:35 +1000
Subject: Proposal of Outputting Unified Logging to TCP socket
In-Reply-To: <6218e95d-57d9-fd05-ede9-9d01c7bf34e6@oracle.com>
References: <b7b8a4524752e2ebc34f2d7930e68c7b@oss.nttdata.com>
 <6218e95d-57d9-fd05-ede9-9d01c7bf34e6@oracle.com>
Message-ID: <60c0bc9f-68f5-c977-6e8e-6cde01002a07@oracle.com>

I second Johan's suggestion of files backed by sockets here. I think 
this has been raised before and the view was that we keep UL focused on 
"files" and then let the files map to other kinds of output devices 
rather than trying to support them all directly in UL.

Thanks,
David

On 6/10/2022 2:15 am, Johan Sj?l?n wrote:
> On 2022-10-04 16:21, Koichi Sakata wrote:
>> Hello,
>>
>> I would like to propose outputting unified logging (UL) to the TCP 
>> socket. I know that this has been discussed before [1]. However, 
>> circumstances have changed. Asynchronous logging was added to UL. If 
>> we output logs to TCP with async mode, we will be able to solve some 
>> issues raised in the past discussion (e.g. lag of log() calls). So I 
>> will take up this subject again.
>>
>> This feature is useful, especially in the container environment. Take 
>> Kubernetes for example, there are many containers. It is recommended 
>> that containers send logs to standard output, but the mixture of Java 
>> application logs and UL logs in stdout is not handy to parse or search 
>> in a log aggregator like Elasticsearch. I believe that it's beneficial 
>> to deal with each type of log individually.
>>
>> When we have files of UL logs, we have another issue. That is where to 
>> persist those files. As you know, we lose logs when pods are removed. 
>> I would rather not use volumes like Persistent Volume because of the 
>> cost of using volumes and the effort of managing files. When using the 
>> volume, we need to determine the file size and the volume size and put 
>> many log files of containers in it.
>>
>> UL via TCP socket answers these issues. In the Kubernetes example, we 
>> use a log forwarder like Fluent Bit, Filebeat or something as a 
>> DaemonSet. It gets UL logs from the socket, gets application logs from 
>> stdout, and sends each log to corresponding log aggregators. As a 
>> result, we don't have UL log files and volumes to persist them 
>> anymore. This is premised on asynchronous logging. So the lag will not 
>> be a problem, I think.
>>
>> For these reasons, I would like to propose outputting UL logs to TCP 
>> inputs. It seems to be unnecessary for traditional java applications, 
>> but it's of great use for applications in container environments. This 
>> makes it easier to build and operate applications on Kubernetes. There 
>> is also a bonus that this is os independent.
>>
>> I will create a prototype of this proposal if it is worth trying.
>>
>> By the way, there is a network stream class that is used to send node 
>> information to Ideal Graph Visualizer via socket. I'm not sure whether 
>> we can divert it or not for this new feature.
>>
>> Best Regards,
>> Koichi Sakata
>>
>> [1] 
>> https://mail.openjdk.org/pipermail/hotspot-runtime-dev/2020-November/043221.html
> 
> Hi Koichi Sokata,
> 
> Thank you for your suggestion. I think that you're right, UL is in a 
> better position to accept TCP sockets as output devices now than it was 
> previously thanks to the introduction of asynchronous logging. However, 
> I am skeptical to the idea of adding these to UL. It creates a rather 
> large attack vector for us, it also creates a maintenance burden and 
> finally getting this right for everyone is probably close to impossible.
> 
> Please note that the Ideal Graph Visualizer is a debug tool, it is not 
> meant for use in production. Therefore, its requirements are very 
> different to UL, which needs to be robust.
> 
> My suggestion would be to use an external tool. The most basic of these 
> would look like this:
> 
> Process 0:
> $ run_tcp_server localhost 4040
> Process 1:
> $ mkfifo my.log
> $ tail -f my.log | netcat localhost 4040
> Process 2:
> $ java -Xlog:disable -Xlog::my.log
> 
> Where the initial -Xlog:disable disables any default configuration which 
> would output to stdout.
> 
> I am sure that there are more sophisticated tools which works 
> essentially like this.
> 
> Best regards,
> Johan Sj?l?n

From ccheung at openjdk.org  Tue Oct 11 23:37:07 2022
From: ccheung at openjdk.org (Calvin Cheung)
Date: Tue, 11 Oct 2022 23:37:07 GMT
Subject: RFR: 8295102: Always load @lambda-form-invoker lines from default
 classlist [v2]
In-Reply-To: <xPV-ArnX4doFubXMdMRPzdTWFwMFrEuQG8MtBgztyHM=.b601224c-7cf2-410f-a0ef-3924aa5bbd16@github.com>
References: <8P6vyzEAJpw7qVfgAo3unZKcanLD6q1Xu11lCap9xVo=.ab0719a4-0764-44cf-9f3c-c59879a1ddec@github.com>
 <xPV-ArnX4doFubXMdMRPzdTWFwMFrEuQG8MtBgztyHM=.b601224c-7cf2-410f-a0ef-3924aa5bbd16@github.com>
Message-ID: <G2yCvu6-CKuxajskRhy9KGQGr0LK5fceS8_qaNDGsi0=.385b6f98-5180-400c-9767-dee1e080029e@github.com>

On Tue, 11 Oct 2022 03:40:00 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> The `@lambda-form-invoker` lines in the default classlist (`$JAVA_HOME/lib/classlist`) control what lambda-form invoker methods are added to these classes that are generated during a CDS dump ([see here](https://github.com/iklam/jdk/blob/5aa997b001367141a6a2d2e69649d41b46199ab4/src/hotspot/share/cds/lambdaFormInvokers.cpp#L230)):
>> 
>> - `java.lang.invoke.Invokers$Holder`
>> - `java.lang.invoke.DirectMethodHandle$Holder`
>> - `java.lang.invoke.DelegatingMethodHandle$Holder`
>> - `java.lang.invoke.LambdaForm$Holder`
>> 
>> The list of these invoker methods is generated as part of the [JDK build process](https://github.com/iklam/jdk/blob/1996f649a3a30b7ac4b547a762417f807f5fa414/make/GenerateLinkOptData.gmk#L64). They are used for invoking MethodHandles of commonly-used types, so that we can avoid generating custom LambdaForm classes.
>> 
>> When a CDS archive is created with a non-default classlist, (e.g., `-XX:SharedClassListFile=foo.classlist`), such a classlist may not contain all the `@lambda-form-invoker` lines as in the default classlist. As a result, at runtime, more custom LambdaForm classes may be generated than necessary.
>> 
>> The solution is to always load the `@lambda-form-invoker` lines from the default classlist, to make sure the CDS image has all the commonly-used invoker methods.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed open/test/hotspot/jtreg:hotspot_appcds_dynamic tests

test/hotspot/jtreg/runtime/cds/appcds/TestCommon.java line 775:

> 773:                                        + ", a=<none>"
> 774:                                        + ", b=" + b[max]);
> 775:         }

Should these checks be done before the "for" loop at line 756? Otherwise, could one of the array be indexed out-out-bound?

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

PR: https://git.openjdk.org/jdk/pull/10639

From dholmes at openjdk.org  Tue Oct 11 23:54:05 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 11 Oct 2022 23:54:05 GMT
Subject: RFR: 8295012: Arena should not derive from CHeapObj<mtNone> [v2]
In-Reply-To: <xmxHDx6edRDIxFE9tqwlf2xGhipiMTjlLHkTVeomwmA=.6ae115e6-8713-42b4-870c-9c44fe99ec41@github.com>
References: <Vi8c8J_dkW9vUkBsXGMT7WGG3IZBFV4yACs_akgKMgU=.35cda657-a697-42fb-b550-e940638080ec@github.com>
 <xmxHDx6edRDIxFE9tqwlf2xGhipiMTjlLHkTVeomwmA=.6ae115e6-8713-42b4-870c-9c44fe99ec41@github.com>
Message-ID: <ZMNux8MS4mnZWIv-CoZWtRiKBtRZYSgO5sXakuu78iY=.ee5473e2-2880-480f-a44d-c454a10523b4@github.com>

On Tue, 11 Oct 2022 05:17:40 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to the `Arena` class.  Rather than deriving from
>> `CHeapObj<mtNone>` (which has the effect of preventing C-heap allocation for an
>> arena by asserting if such is attempted), instead have no allocation base
>> class so that `new Arena(...)` will fail to compile.
>> 
>> Testing: mach5 tier1
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Arena derives from CHeapObjBase

LGTM!

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10621

From iklam at openjdk.org  Wed Oct 12 00:31:15 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 12 Oct 2022 00:31:15 GMT
Subject: RFR: 8295102: Always load @lambda-form-invoker lines from default
 classlist [v3]
In-Reply-To: <8P6vyzEAJpw7qVfgAo3unZKcanLD6q1Xu11lCap9xVo=.ab0719a4-0764-44cf-9f3c-c59879a1ddec@github.com>
References: <8P6vyzEAJpw7qVfgAo3unZKcanLD6q1Xu11lCap9xVo=.ab0719a4-0764-44cf-9f3c-c59879a1ddec@github.com>
Message-ID: <qhFs4C9MrLgZMvSFIYxnMeCcONaVAHnXpFTSIqv6nNg=.ab549c96-e714-49db-9903-0132c216f83c@github.com>

> The `@lambda-form-invoker` lines in the default classlist (`$JAVA_HOME/lib/classlist`) control what lambda-form invoker methods are added to these classes that are generated during a CDS dump ([see here](https://github.com/iklam/jdk/blob/5aa997b001367141a6a2d2e69649d41b46199ab4/src/hotspot/share/cds/lambdaFormInvokers.cpp#L230)):
> 
> - `java.lang.invoke.Invokers$Holder`
> - `java.lang.invoke.DirectMethodHandle$Holder`
> - `java.lang.invoke.DelegatingMethodHandle$Holder`
> - `java.lang.invoke.LambdaForm$Holder`
> 
> The list of these invoker methods is generated as part of the [JDK build process](https://github.com/iklam/jdk/blob/1996f649a3a30b7ac4b547a762417f807f5fa414/make/GenerateLinkOptData.gmk#L64). They are used for invoking MethodHandles of commonly-used types, so that we can avoid generating custom LambdaForm classes.
> 
> When a CDS archive is created with a non-default classlist, (e.g., `-XX:SharedClassListFile=foo.classlist`), such a classlist may not contain all the `@lambda-form-invoker` lines as in the default classlist. As a result, at runtime, more custom LambdaForm classes may be generated than necessary.
> 
> The solution is to always load the `@lambda-form-invoker` lines from the default classlist, to make sure the CDS image has all the commonly-used invoker methods.

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  @calvinccheung comment: fixed bug in TestCommon.linesMustMatch

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10639/files
  - new: https://git.openjdk.org/jdk/pull/10639/files/54d9e240..2e6af772

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10639&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10639&range=01-02

  Stats: 13 lines in 1 file changed: 4 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/10639.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10639/head:pull/10639

PR: https://git.openjdk.org/jdk/pull/10639

From iklam at openjdk.org  Wed Oct 12 00:33:06 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 12 Oct 2022 00:33:06 GMT
Subject: RFR: 8295102: Always load @lambda-form-invoker lines from default
 classlist [v2]
In-Reply-To: <G2yCvu6-CKuxajskRhy9KGQGr0LK5fceS8_qaNDGsi0=.385b6f98-5180-400c-9767-dee1e080029e@github.com>
References: <8P6vyzEAJpw7qVfgAo3unZKcanLD6q1Xu11lCap9xVo=.ab0719a4-0764-44cf-9f3c-c59879a1ddec@github.com>
 <xPV-ArnX4doFubXMdMRPzdTWFwMFrEuQG8MtBgztyHM=.b601224c-7cf2-410f-a0ef-3924aa5bbd16@github.com>
 <G2yCvu6-CKuxajskRhy9KGQGr0LK5fceS8_qaNDGsi0=.385b6f98-5180-400c-9767-dee1e080029e@github.com>
Message-ID: <jCJI6CaYlfqqXsnhAAGB9GLmiexBXRCf1ADmnrpAsTc=.163eb2ec-ede6-4d46-abd3-61b415136abb@github.com>

On Tue, 11 Oct 2022 23:30:51 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed open/test/hotspot/jtreg:hotspot_appcds_dynamic tests
>
> test/hotspot/jtreg/runtime/cds/appcds/TestCommon.java line 775:
> 
>> 773:                                        + ", a=<none>"
>> 774:                                        + ", b=" + b[max]);
>> 775:         }
> 
> Should these checks be done before the "for" loop at line 756? Otherwise, could one of the array be indexed out-out-bound?

Thanks for finding the bug. I have fixed it in version [2e6af77](https://github.com/openjdk/jdk/pull/10639/commits/2e6af772766dff3432a11b436924185e1b270626). I also tested locally with this code:


String[] a = {"1", "2"}, b = {"1"};
TestCommon.linesMustMatch(a, b);


which correctly produces this error:


java.lang.RuntimeException: Output mismatch on line 1: a=2, b=<none>

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

PR: https://git.openjdk.org/jdk/pull/10639

From kbarrett at openjdk.org  Wed Oct 12 01:15:52 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 12 Oct 2022 01:15:52 GMT
Subject: RFR: 8295124: Atomic::add to pointer type may return wrong value
Message-ID: <8MVHNI6FliDXtf6MFWwrL9cj3o_VaM98dPj_TuRgkWI=.83b5aee8-f553-48fa-9d86-80d5d54a5a5e@github.com>

Please review this change to the handling of Atomic pointer arithmetic. When
the value being modified is a pointer `P*`, the type of the value in the
destination passed to the platform operation is `const char*`, so a pointer
type whose pointee is size 1. This allows the platform operation to just treat
the arithmetic as a simple byte adjustment.

To demonstrate the problem described in the bug (possible incorrect result for
Atomic pointer arithmetic) and show that it is now fixed, this change also
includes some gtests for Atomic operations, including pointer arithmetic which
fails before the change and succeeds after.

Testing: mach5 tier1-3

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

Commit messages:
 - shared conversion of pointer type
 - add more gtests of Atomic

Changes: https://git.openjdk.org/jdk/pull/10667/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10667&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295124
  Stats: 161 lines in 2 files changed: 146 ins; 3 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/10667.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10667/head:pull/10667

PR: https://git.openjdk.org/jdk/pull/10667

From dzhang at openjdk.org  Wed Oct 12 01:52:33 2022
From: dzhang at openjdk.org (Dingli Zhang)
Date: Wed, 12 Oct 2022 01:52:33 GMT
Subject: RFR: 8294623: gtests does not work with googletest release-1.12.0+
In-Reply-To: <rnL2waiVREMQtbRdF4kikhiEquNFofsBKE5Bdft9lCg=.8ef316ae-d37e-4d4e-8c83-7f04d2340139@github.com>
References: <GTSRMWikrMJP0xKZRchcdvyMTIA8QLo9Ghl0_bbIsd0=.953fc4ad-4f58-4cd2-b0df-9cd6d1784d21@github.com>
 <B0icLmUNp-T8kpaICnegSVS_Ml_0l9BzVfM1adJSq6c=.69b03ff0-90cb-48f1-93d9-57a24d1c8f5a@github.com>
 <yCCwD379-NdX5QV_jfKs_gpzuvfz1CkcdTe2CdNJr-Q=.3fa72e71-b35a-4de8-84a2-066fdebbf811@github.com>
 <PnX-7jUqsLxgE6zRImaXmkN5E4gbjxKhjqSfd7zuvr0=.e2b63301-58ce-4c89-a7bf-6531d35ce7e0@github.com>
 <rnL2waiVREMQtbRdF4kikhiEquNFofsBKE5Bdft9lCg=.8ef316ae-d37e-4d4e-8c83-7f04d2340139@github.com>
Message-ID: <FdhypWEEk6NuM_Gr2tHGMaP5wPWPkO_2EVrky_j7BlY=.5d32b1b3-9006-4d5f-9c37-eee82d3b3391@github.com>

On Mon, 10 Oct 2022 23:36:38 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> @DingliZhang According to the building.md documentation:
>> 
>> The supported version of Google Test is 1.8.1, whose source code can be obtained:
>> 
>>  * by downloading and unpacking the source bundle from [here](https://github.com/google/googletest/releases/tag/release-1.8.1)
>>  * or by checking out `release-1.8.1` tag of `googletest` project: `git clone -b release-1.8.1 https://github.com/google/googletest`
>> 
>> I don't know how old version 1.8.1 is or whether we need to expand on the supported releases here. Maybe the build folk will have an opinion? @magicus or @erikj79 .
>
>> I don't know how old version 1.8.1 is or whether we need to expand on the supported releases here. Maybe the build folk will have an opinion? @magicus or @erikj79 .
> 
> I don't think we need to support multiple versions of googletest.  I don't see any benefit, and doing so incurs costs.  It might be that we should update to using a newer version, but that's a very different discussion.

@kimbarrett @magicus @rose00 Thanks for review!

I apologize for the incomplete error report due to an oversight on my part. At first I misread `Gtest` section in `doc/building.md `, only read `Gtest` section in `doc/testing.md` and used version 1.10.0 of `Gtest`. When I found out that there was a newer version of googletest I made an attempt and found the problem.

I later found out that the `doc/building.md` pointed out the supported versions of gtest and thought it would be a convenient move for developers to support latest versions of gtest.

I think it is a good idea:
> Perhaps the Gtest section in doc/testing.md should cross-link to the section quoted above in doc/building.md

Thank you all for helping me in your busy schedule! I will close this PR.

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

PR: https://git.openjdk.org/jdk/pull/10503

From dzhang at openjdk.org  Wed Oct 12 01:52:34 2022
From: dzhang at openjdk.org (Dingli Zhang)
Date: Wed, 12 Oct 2022 01:52:34 GMT
Subject: Withdrawn: 8294623: gtests does not work with googletest
 release-1.12.0+
In-Reply-To: <GTSRMWikrMJP0xKZRchcdvyMTIA8QLo9Ghl0_bbIsd0=.953fc4ad-4f58-4cd2-b0df-9cd6d1784d21@github.com>
References: <GTSRMWikrMJP0xKZRchcdvyMTIA8QLo9Ghl0_bbIsd0=.953fc4ad-4f58-4cd2-b0df-9cd6d1784d21@github.com>
Message-ID: <OBI16l55X7PEJwXdasM5BjGLTo3C2NTaLkgxGT5coro=.ec112a77-a2c4-4042-b583-11c9f39f7435@github.com>

On Fri, 30 Sep 2022 08:38:29 GMT, Dingli Zhang <dzhang at openjdk.org> wrote:

> The scope of `GTEST_DECLARE_string_(internal_run_death_test)` has been changed in googletest 1.12.0 [1]. So we can see some new compiler errors as below:
> 
> 
> $ bash configure --with-gtest=/home/dingli/jdk-tools/googletest && make run-test TEST="gtest:all"
> 
> * For target hotspot_variant-server_libjvm_gtest_objs_gtestMain.o:
> In file included from /home/dingli/jdk-tools/googletest/googlemock/include/gmock/internal/gmock-port.h:57,
>                  from /home/dingli/jdk-tools/googletest/googlemock/include/gmock/internal/gmock-internal-utils.h:49,
>                  from /home/dingli/jdk-tools/googletest/googlemock/include/gmock/gmock-actions.h:145,
>                  from /home/dingli/jdk-tools/googletest/googlemock/include/gmock/gmock.h:56,
>                  from /home/dingli/jdk/test/hotspot/gtest/unittest.hpp:51,
>                  from /home/dingli/jdk/test/hotspot/gtest/gtestMain.cpp:39:

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/10503

From kbarrett at openjdk.org  Wed Oct 12 02:00:52 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 12 Oct 2022 02:00:52 GMT
Subject: RFR: 8295012: Arena should not derive from CHeapObj<mtNone> [v3]
In-Reply-To: <Vi8c8J_dkW9vUkBsXGMT7WGG3IZBFV4yACs_akgKMgU=.35cda657-a697-42fb-b550-e940638080ec@github.com>
References: <Vi8c8J_dkW9vUkBsXGMT7WGG3IZBFV4yACs_akgKMgU=.35cda657-a697-42fb-b550-e940638080ec@github.com>
Message-ID: <WLfZWUf5F0PRY9trGFo2SAbEow5VXrUDYZYlwmaBZ_w=.243f288c-05d0-4cab-b4af-0d989310147b@github.com>

> Please review this change to the `Arena` class.  Rather than deriving from
> `CHeapObj<mtNone>` (which has the effect of preventing C-heap allocation for an
> arena by asserting if such is attempted), instead have no allocation base
> class so that `new Arena(...)` will fail to compile.
> 
> Testing: mach5 tier1

Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Merge branch 'master' into arena-base
 - Arena derives from CHeapObjBase
 - remove base class from Arena

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10621/files
  - new: https://git.openjdk.org/jdk/pull/10621/files/828541f5..817072dd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10621&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10621&range=01-02

  Stats: 5303 lines in 121 files changed: 3625 ins; 818 del; 860 mod
  Patch: https://git.openjdk.org/jdk/pull/10621.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10621/head:pull/10621

PR: https://git.openjdk.org/jdk/pull/10621

From kbarrett at openjdk.org  Wed Oct 12 02:00:53 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 12 Oct 2022 02:00:53 GMT
Subject: RFR: 8295012: Arena should not derive from CHeapObj<mtNone> [v2]
In-Reply-To: <aSM1_ktl6q1YVRqFqFQQYKzKU1y1w0j1UyOAnl2Idww=.822ae766-716f-4d91-b569-2c4c238ffbad@github.com>
References: <Vi8c8J_dkW9vUkBsXGMT7WGG3IZBFV4yACs_akgKMgU=.35cda657-a697-42fb-b550-e940638080ec@github.com>
 <xmxHDx6edRDIxFE9tqwlf2xGhipiMTjlLHkTVeomwmA=.6ae115e6-8713-42b4-870c-9c44fe99ec41@github.com>
 <aSM1_ktl6q1YVRqFqFQQYKzKU1y1w0j1UyOAnl2Idww=.822ae766-716f-4d91-b569-2c4c238ffbad@github.com>
Message-ID: <WLKeyBtRslrBsvpQuBKUGdOFng79X1_SrVa3UURLjDY=.84b70232-f2a9-4c54-9bc8-12133d5b254d@github.com>

On Tue, 11 Oct 2022 09:04:01 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Arena derives from CHeapObjBase
>
> Marked as reviewed by stefank (Reviewer).

Thanks @stefank and @dholmes-ora  for reviews.

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

PR: https://git.openjdk.org/jdk/pull/10621

From kbarrett at openjdk.org  Wed Oct 12 02:00:54 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 12 Oct 2022 02:00:54 GMT
Subject: Integrated: 8295012: Arena should not derive from CHeapObj<mtNone>
In-Reply-To: <Vi8c8J_dkW9vUkBsXGMT7WGG3IZBFV4yACs_akgKMgU=.35cda657-a697-42fb-b550-e940638080ec@github.com>
References: <Vi8c8J_dkW9vUkBsXGMT7WGG3IZBFV4yACs_akgKMgU=.35cda657-a697-42fb-b550-e940638080ec@github.com>
Message-ID: <b8BdNGbNhrDZTnQEpNamptCPpctssOjQP3OtiGcqE8U=.62c48f9b-b8a6-4bd2-9d9d-01fcd6f2e9ab@github.com>

On Sun, 9 Oct 2022 00:21:18 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to the `Arena` class.  Rather than deriving from
> `CHeapObj<mtNone>` (which has the effect of preventing C-heap allocation for an
> arena by asserting if such is attempted), instead have no allocation base
> class so that `new Arena(...)` will fail to compile.
> 
> Testing: mach5 tier1

This pull request has now been integrated.

Changeset: 5ad126f4
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5ad126f44662d81d2d065b215ed967c0b983f9c9
Stats:     33 lines in 2 files changed: 0 ins; 32 del; 1 mod

8295012: Arena should not derive from CHeapObj<mtNone>

Reviewed-by: stefank, dholmes

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

PR: https://git.openjdk.org/jdk/pull/10621

From iklam at openjdk.org  Wed Oct 12 02:29:08 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 12 Oct 2022 02:29:08 GMT
Subject: RFR: 8294623: gtests does not work with googletest release-1.12.0+
In-Reply-To: <GTSRMWikrMJP0xKZRchcdvyMTIA8QLo9Ghl0_bbIsd0=.953fc4ad-4f58-4cd2-b0df-9cd6d1784d21@github.com>
References: <GTSRMWikrMJP0xKZRchcdvyMTIA8QLo9Ghl0_bbIsd0=.953fc4ad-4f58-4cd2-b0df-9cd6d1784d21@github.com>
Message-ID: <es_tmCXJP-vQWHfcZWwswR7p-2RRCB618C_9ZhxdwEs=.fc00f731-ec6e-491b-b9b3-20ef60a6e2e7@github.com>

On Fri, 30 Sep 2022 08:38:29 GMT, Dingli Zhang <dzhang at openjdk.org> wrote:

> The scope of `GTEST_DECLARE_string_(internal_run_death_test)` has been changed in googletest 1.12.0 [1]. So we can see some new compiler errors as below:
> 
> 
> $ bash configure --with-gtest=/home/dingli/jdk-tools/googletest && make run-test TEST="gtest:all"
> 
> * For target hotspot_variant-server_libjvm_gtest_objs_gtestMain.o:
> In file included from /home/dingli/jdk-tools/googletest/googlemock/include/gmock/internal/gmock-port.h:57,
>                  from /home/dingli/jdk-tools/googletest/googlemock/include/gmock/internal/gmock-internal-utils.h:49,
>                  from /home/dingli/jdk-tools/googletest/googlemock/include/gmock/gmock-actions.h:145,
>                  from /home/dingli/jdk-tools/googletest/googlemock/include/gmock/gmock.h:56,
>                  from /home/dingli/jdk/test/hotspot/gtest/unittest.hpp:51,
>                  from /home/dingli/jdk/test/hotspot/gtest/gtestMain.cpp:39:

It would be good if we can detect the version of the googletest and report an error if it's not 1.8.1. However, in https://github.com/google/googletest/archive/refs/tags/release-1.8.1.tar.gz, I couldn't find any file that contains the version information. The only file that contains some sort of version number doesn't have the right version:


./googlemock/configure.ac:        [1.8.0]


Maybe `make doctor` can print out some hints about 1.8.1 if it finds that the gtest build has failed?

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

PR: https://git.openjdk.org/jdk/pull/10503

From ihse at openjdk.org  Wed Oct 12 06:23:21 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 12 Oct 2022 06:23:21 GMT
Subject: RFR: 8294623: gtests does not work with googletest release-1.12.0+
In-Reply-To: <es_tmCXJP-vQWHfcZWwswR7p-2RRCB618C_9ZhxdwEs=.fc00f731-ec6e-491b-b9b3-20ef60a6e2e7@github.com>
References: <GTSRMWikrMJP0xKZRchcdvyMTIA8QLo9Ghl0_bbIsd0=.953fc4ad-4f58-4cd2-b0df-9cd6d1784d21@github.com>
 <es_tmCXJP-vQWHfcZWwswR7p-2RRCB618C_9ZhxdwEs=.fc00f731-ec6e-491b-b9b3-20ef60a6e2e7@github.com>
Message-ID: <vrtaGV_T-gCjzx_c-4LKN3e7h48_h38pxOkgA75sllo=.f0931915-dace-4607-86a0-914dab94a294@github.com>

On Wed, 12 Oct 2022 02:25:18 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> The scope of `GTEST_DECLARE_string_(internal_run_death_test)` has been changed in googletest 1.12.0 [1]. So we can see some new compiler errors as below:
>> 
>> 
>> $ bash configure --with-gtest=/home/dingli/jdk-tools/googletest && make run-test TEST="gtest:all"
>> 
>> * For target hotspot_variant-server_libjvm_gtest_objs_gtestMain.o:
>> In file included from /home/dingli/jdk-tools/googletest/googlemock/include/gmock/internal/gmock-port.h:57,
>>                  from /home/dingli/jdk-tools/googletest/googlemock/include/gmock/internal/gmock-internal-utils.h:49,
>>                  from /home/dingli/jdk-tools/googletest/googlemock/include/gmock/gmock-actions.h:145,
>>                  from /home/dingli/jdk-tools/googletest/googlemock/include/gmock/gmock.h:56,
>>                  from /home/dingli/jdk/test/hotspot/gtest/unittest.hpp:51,
>>                  from /home/dingli/jdk/test/hotspot/gtest/gtestMain.cpp:39:
>
> It would be good if we can detect the version of the googletest and report an error if it's not 1.8.1. However, in https://github.com/google/googletest/archive/refs/tags/release-1.8.1.tar.gz, I couldn't find any file that contains the version information. The only file that contains some sort of version number doesn't have the right version:
> 
> 
> ./googlemock/configure.ac:        [1.8.0]
> 
> 
> Maybe `make doctor` can print out some hints about 1.8.1 if it finds that the gtest build has failed?

@iklam I agree that ideally `configure` should complain if you have the wrong version of gtest. But as you say, this is not easy to determine. :-( That was why I skipped this when we added gtest as a prerequisite. But maybe I could do like an SHA256 of the source files and check if it matches..? Hm...

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

PR: https://git.openjdk.org/jdk/pull/10503

From jsjolen at openjdk.org  Wed Oct 12 07:15:14 2022
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 12 Oct 2022 07:15:14 GMT
Subject: Integrated: 8294950: print_sys_devices_cpu_info doesn't use the
 provided buffer
In-Reply-To: <Jb7XWBhOiyGShVuh6zr6xvPsv-idy3rbI0pv9KbNKdI=.61d71a35-5809-4427-8358-d813ac534836@github.com>
References: <Jb7XWBhOiyGShVuh6zr6xvPsv-idy3rbI0pv9KbNKdI=.61d71a35-5809-4427-8358-d813ac534836@github.com>
Message-ID: <j3aq7QVlEpjLxpm9DaJnUEE9gpC8JI7LO__h5oi9_R0=.ef1e06fc-719e-480a-9bfb-0e100bdfe167@github.com>

On Fri, 7 Oct 2022 11:41:43 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Removes the 2 unused parameters from `print_sys_devices_cpu_info`

This pull request has now been integrated.

Changeset: 16e0c599
Author:    Johan Sj?len <jsjolen at openjdk.org>
Committer: Stefan Karlsson <stefank at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/16e0c5994acc57d8c157c852c77801f3a791f6c6
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8294950: print_sys_devices_cpu_info doesn't use the provided buffer

Reviewed-by: dholmes, stefank

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

PR: https://git.openjdk.org/jdk/pull/10604

From redestad at openjdk.org  Wed Oct 12 09:42:09 2022
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 12 Oct 2022 09:42:09 GMT
Subject: RFR: 8295102: Always load @lambda-form-invoker lines from default
 classlist [v3]
In-Reply-To: <qhFs4C9MrLgZMvSFIYxnMeCcONaVAHnXpFTSIqv6nNg=.ab549c96-e714-49db-9903-0132c216f83c@github.com>
References: <8P6vyzEAJpw7qVfgAo3unZKcanLD6q1Xu11lCap9xVo=.ab0719a4-0764-44cf-9f3c-c59879a1ddec@github.com>
 <qhFs4C9MrLgZMvSFIYxnMeCcONaVAHnXpFTSIqv6nNg=.ab549c96-e714-49db-9903-0132c216f83c@github.com>
Message-ID: <qP4NUs7lC_7qnJZnVFMn1eye6m6jLr8HpMNEmSSaL_c=.50543380-64bd-470a-86e6-57c9f37a0a6f@github.com>

On Wed, 12 Oct 2022 00:31:15 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> The `@lambda-form-invoker` lines in the default classlist (`$JAVA_HOME/lib/classlist`) control what lambda-form invoker methods are added to these classes that are generated during a CDS dump ([see here](https://github.com/iklam/jdk/blob/5aa997b001367141a6a2d2e69649d41b46199ab4/src/hotspot/share/cds/lambdaFormInvokers.cpp#L230)):
>> 
>> - `java.lang.invoke.Invokers$Holder`
>> - `java.lang.invoke.DirectMethodHandle$Holder`
>> - `java.lang.invoke.DelegatingMethodHandle$Holder`
>> - `java.lang.invoke.LambdaForm$Holder`
>> 
>> The list of these invoker methods is generated as part of the [JDK build process](https://github.com/iklam/jdk/blob/1996f649a3a30b7ac4b547a762417f807f5fa414/make/GenerateLinkOptData.gmk#L64). They are used for invoking MethodHandles of commonly-used types, so that we can avoid generating custom LambdaForm classes.
>> 
>> When a CDS archive is created with a non-default classlist, (e.g., `-XX:SharedClassListFile=foo.classlist`), such a classlist may not contain all the `@lambda-form-invoker` lines as in the default classlist. As a result, at runtime, more custom LambdaForm classes may be generated than necessary.
>> 
>> The solution is to always load the `@lambda-form-invoker` lines from the default classlist, to make sure the CDS image has all the commonly-used invoker methods.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @calvinccheung comment: fixed bug in TestCommon.linesMustMatch

This patch ensures that the methods in the LF holder classes _at least_ contain the set of methods as generated by jlink at build, which seems to me to be reasonable to hold as an invariant to avoid surprises at runtime. (Does resolving a LF from a holder does trigger emitting a `@lambda-form-invoker` line when generating the classlist?)

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

Marked as reviewed by redestad (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10639

From iklam at openjdk.org  Wed Oct 12 16:23:07 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 12 Oct 2022 16:23:07 GMT
Subject: RFR: 8294772: Remove workaround in os::dll_address_to_library_name
 [v2]
In-Reply-To: <AyctZqGNNQNjRuz53VaCBMTbMLBbkRogmBPg5aratTM=.d4a5cb49-8783-419b-9e3c-302fe4eaa6a9@github.com>
References: <XxV07mEZMfIMNuve5mZDn7dQA8NzLrrXTULALA88G9Y=.1cd2c6ad-8880-4bc9-ae04-76a75e739c5d@github.com>
 <2rEQy56A_hMk4hT3OkGHljyJufVc0xvm3n72rrAf1DY=.7d21ed2a-4187-46ce-a03b-0aed88561990@github.com>
 <AyctZqGNNQNjRuz53VaCBMTbMLBbkRogmBPg5aratTM=.d4a5cb49-8783-419b-9e3c-302fe4eaa6a9@github.com>
Message-ID: <x3ayVe40kXNzJ7IXPXhxSYqUrr0mXhPNOhdDhR6zaYY=.447f2314-5734-4f10-ae63-657235167545@github.com>

On Tue, 11 Oct 2022 15:01:52 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> What kind of testing have you done? I saw that the GitHub Actions included only jcheck.

@jdksjolen has run tiers 1-3 and builds-tier-5 in our CI. This PR is ready to be integrated.

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

PR: https://git.openjdk.org/jdk/pull/10559

From jsjolen at openjdk.org  Wed Oct 12 16:26:33 2022
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 12 Oct 2022 16:26:33 GMT
Subject: Integrated: 8294772: Remove workaround in
 os::dll_address_to_library_name
In-Reply-To: <XxV07mEZMfIMNuve5mZDn7dQA8NzLrrXTULALA88G9Y=.1cd2c6ad-8880-4bc9-ae04-76a75e739c5d@github.com>
References: <XxV07mEZMfIMNuve5mZDn7dQA8NzLrrXTULALA88G9Y=.1cd2c6ad-8880-4bc9-ae04-76a75e739c5d@github.com>
Message-ID: <ILs0ySndaR9vNqDRfrW12t793mtkmeiSTTKLmfbY0T0=.c5c5b87f-e130-4597-9bf3-78c780b7638f@github.com>

On Tue, 4 Oct 2022 14:30:58 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> I ported the BSD implementation of this function. According to the comment this bug should be fixed, as the oldest glibc I can see us supporting is 2.12.x. I've made an attempt at finding the bug that the comment refers to on glibc's bug tracker but has been unsuccesful in this.
> 
> The second commit deletes what seems like an outdated comment (in os_bsd this refers to a code snippet right below the comment).

This pull request has now been integrated.

Changeset: 5699041a
Author:    Johan Sj?len <jsjolen at openjdk.org>
Committer: Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5699041adb64f41c90090fd68494430ecf8660d4
Stats:     72 lines in 2 files changed: 0 ins; 69 del; 3 mod

8294772: Remove workaround in os::dll_address_to_library_name

Reviewed-by: dholmes, iklam

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

PR: https://git.openjdk.org/jdk/pull/10559

From ccheung at openjdk.org  Wed Oct 12 17:09:25 2022
From: ccheung at openjdk.org (Calvin Cheung)
Date: Wed, 12 Oct 2022 17:09:25 GMT
Subject: RFR: 8295102: Always load @lambda-form-invoker lines from default
 classlist [v3]
In-Reply-To: <qhFs4C9MrLgZMvSFIYxnMeCcONaVAHnXpFTSIqv6nNg=.ab549c96-e714-49db-9903-0132c216f83c@github.com>
References: <8P6vyzEAJpw7qVfgAo3unZKcanLD6q1Xu11lCap9xVo=.ab0719a4-0764-44cf-9f3c-c59879a1ddec@github.com>
 <qhFs4C9MrLgZMvSFIYxnMeCcONaVAHnXpFTSIqv6nNg=.ab549c96-e714-49db-9903-0132c216f83c@github.com>
Message-ID: <fPtpFapvZRHnQwcKkfWZrP_jVEEeh8RLAK3hB8sB7Pw=.349076f3-4aad-4f23-b2cc-af788b72c993@github.com>

On Wed, 12 Oct 2022 00:31:15 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> The `@lambda-form-invoker` lines in the default classlist (`$JAVA_HOME/lib/classlist`) control what lambda-form invoker methods are added to these classes that are generated during a CDS dump ([see here](https://github.com/iklam/jdk/blob/5aa997b001367141a6a2d2e69649d41b46199ab4/src/hotspot/share/cds/lambdaFormInvokers.cpp#L230)):
>> 
>> - `java.lang.invoke.Invokers$Holder`
>> - `java.lang.invoke.DirectMethodHandle$Holder`
>> - `java.lang.invoke.DelegatingMethodHandle$Holder`
>> - `java.lang.invoke.LambdaForm$Holder`
>> 
>> The list of these invoker methods is generated as part of the [JDK build process](https://github.com/iklam/jdk/blob/1996f649a3a30b7ac4b547a762417f807f5fa414/make/GenerateLinkOptData.gmk#L64). They are used for invoking MethodHandles of commonly-used types, so that we can avoid generating custom LambdaForm classes.
>> 
>> When a CDS archive is created with a non-default classlist, (e.g., `-XX:SharedClassListFile=foo.classlist`), such a classlist may not contain all the `@lambda-form-invoker` lines as in the default classlist. As a result, at runtime, more custom LambdaForm classes may be generated than necessary.
>> 
>> The solution is to always load the `@lambda-form-invoker` lines from the default classlist, to make sure the CDS image has all the commonly-used invoker methods.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @calvinccheung comment: fixed bug in TestCommon.linesMustMatch

Updates look good. Thanks.

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

Marked as reviewed by ccheung (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10639

From iklam at openjdk.org  Wed Oct 12 17:12:15 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 12 Oct 2022 17:12:15 GMT
Subject: RFR: 8295102: Always load @lambda-form-invoker lines from default
 classlist [v3]
In-Reply-To: <qP4NUs7lC_7qnJZnVFMn1eye6m6jLr8HpMNEmSSaL_c=.50543380-64bd-470a-86e6-57c9f37a0a6f@github.com>
References: <8P6vyzEAJpw7qVfgAo3unZKcanLD6q1Xu11lCap9xVo=.ab0719a4-0764-44cf-9f3c-c59879a1ddec@github.com>
 <qhFs4C9MrLgZMvSFIYxnMeCcONaVAHnXpFTSIqv6nNg=.ab549c96-e714-49db-9903-0132c216f83c@github.com>
 <qP4NUs7lC_7qnJZnVFMn1eye6m6jLr8HpMNEmSSaL_c=.50543380-64bd-470a-86e6-57c9f37a0a6f@github.com>
Message-ID: <T-MSZ0Hb8DBxC8GJoOnhgvYE8HDiBt0thij6ffbzd-A=.94a4d111-d6c1-4e71-9af1-39ba7d0a9b8e@github.com>

On Wed, 12 Oct 2022 09:38:18 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This patch ensures that the methods in the LF holder classes _at least_ contain the set of methods as generated by jlink at build, which seems to me to be reasonable to hold as an invariant to avoid surprises at runtime. (Does resolving a LF from a holder does trigger emitting a `@lambda-form-invoker` line when generating the classlist?)

The  `@lambda-form-invoker` lines are generated in MethodHandleStatics.java::traceLambdaForm() when LambdaForms are being resolved:

https://github.com/openjdk/jdk/blob/5699041adb64f41c90090fd68494430ecf8660d4/src/java.base/share/classes/java/lang/invoke/MethodHandleStatics.java#L122-L131

This is the same place where GenerateLinkOptData.gmk gathers information for generating the Holder classes for the JDK's module image.

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

PR: https://git.openjdk.org/jdk/pull/10639

From iklam at openjdk.org  Wed Oct 12 19:49:35 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 12 Oct 2022 19:49:35 GMT
Subject: RFR: 8295102: Always load @lambda-form-invoker lines from default
 classlist [v4]
In-Reply-To: <8P6vyzEAJpw7qVfgAo3unZKcanLD6q1Xu11lCap9xVo=.ab0719a4-0764-44cf-9f3c-c59879a1ddec@github.com>
References: <8P6vyzEAJpw7qVfgAo3unZKcanLD6q1Xu11lCap9xVo=.ab0719a4-0764-44cf-9f3c-c59879a1ddec@github.com>
Message-ID: <pJiEQXQeaN3BawftlterCqJhziHzi6_vsGvCbuJNS2c=.0cc4605f-2dfa-4a58-9406-027335824ed4@github.com>

> The `@lambda-form-invoker` lines in the default classlist (`$JAVA_HOME/lib/classlist`) control what lambda-form invoker methods are added to these classes that are generated during a CDS dump ([see here](https://github.com/iklam/jdk/blob/5aa997b001367141a6a2d2e69649d41b46199ab4/src/hotspot/share/cds/lambdaFormInvokers.cpp#L230)):
> 
> - `java.lang.invoke.Invokers$Holder`
> - `java.lang.invoke.DirectMethodHandle$Holder`
> - `java.lang.invoke.DelegatingMethodHandle$Holder`
> - `java.lang.invoke.LambdaForm$Holder`
> 
> The list of these invoker methods is generated as part of the [JDK build process](https://github.com/iklam/jdk/blob/1996f649a3a30b7ac4b547a762417f807f5fa414/make/GenerateLinkOptData.gmk#L64). They are used for invoking MethodHandles of commonly-used types, so that we can avoid generating custom LambdaForm classes.
> 
> When a CDS archive is created with a non-default classlist, (e.g., `-XX:SharedClassListFile=foo.classlist`), such a classlist may not contain all the `@lambda-form-invoker` lines as in the default classlist. As a result, at runtime, more custom LambdaForm classes may be generated than necessary.
> 
> The solution is to always load the `@lambda-form-invoker` lines from the default classlist, to make sure the CDS image has all the commonly-used invoker methods.

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  rewrote test to write output to a file instead of stdout, so it will not be affected by -Xlog options

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10639/files
  - new: https://git.openjdk.org/jdk/pull/10639/files/2e6af772..fada121b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10639&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10639&range=02-03

  Stats: 88 lines in 3 files changed: 38 ins; 30 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/10639.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10639/head:pull/10639

PR: https://git.openjdk.org/jdk/pull/10639

From kbarrett at openjdk.org  Wed Oct 12 20:38:10 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 12 Oct 2022 20:38:10 GMT
Subject: RFR: 8295124: Atomic::add to pointer type may return wrong value
 [v2]
In-Reply-To: <8MVHNI6FliDXtf6MFWwrL9cj3o_VaM98dPj_TuRgkWI=.83b5aee8-f553-48fa-9d86-80d5d54a5a5e@github.com>
References: <8MVHNI6FliDXtf6MFWwrL9cj3o_VaM98dPj_TuRgkWI=.83b5aee8-f553-48fa-9d86-80d5d54a5a5e@github.com>
Message-ID: <pLyuIraAHIPX4fT5YJG14TSjcoETKZbazFG8EBq3YjI=.3ad05410-1860-4a92-8ae7-a28599f80e26@github.com>

> Please review this change to the handling of Atomic pointer arithmetic. When
> the value being modified is a pointer `P*`, the type of the value in the
> destination passed to the platform operation is `const char*`, so a pointer
> type whose pointee is size 1. This allows the platform operation to just treat
> the arithmetic as a simple byte adjustment.
> 
> To demonstrate the problem described in the bug (possible incorrect result for
> Atomic pointer arithmetic) and show that it is now fixed, this change also
> includes some gtests for Atomic operations, including pointer arithmetic which
> fails before the change and succeeds after.
> 
> Testing: mach5 tier1-3

Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:

  conditionalize 64bit tests on 64bit platform

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10667/files
  - new: https://git.openjdk.org/jdk/pull/10667/files/9dbb07a6..e44e81cd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10667&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10667&range=00-01

  Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10667.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10667/head:pull/10667

PR: https://git.openjdk.org/jdk/pull/10667

From ccheung at openjdk.org  Wed Oct 12 21:05:09 2022
From: ccheung at openjdk.org (Calvin Cheung)
Date: Wed, 12 Oct 2022 21:05:09 GMT
Subject: RFR: 8295102: Always load @lambda-form-invoker lines from default
 classlist [v4]
In-Reply-To: <pJiEQXQeaN3BawftlterCqJhziHzi6_vsGvCbuJNS2c=.0cc4605f-2dfa-4a58-9406-027335824ed4@github.com>
References: <8P6vyzEAJpw7qVfgAo3unZKcanLD6q1Xu11lCap9xVo=.ab0719a4-0764-44cf-9f3c-c59879a1ddec@github.com>
 <pJiEQXQeaN3BawftlterCqJhziHzi6_vsGvCbuJNS2c=.0cc4605f-2dfa-4a58-9406-027335824ed4@github.com>
Message-ID: <_Yh-oeIHbRmaGXPENxJkeWqaYVf3d6jwIjPlwfYb24k=.d619abf0-eaff-498f-b1c6-540b72b86ab8@github.com>

On Wed, 12 Oct 2022 19:49:35 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> The `@lambda-form-invoker` lines in the default classlist (`$JAVA_HOME/lib/classlist`) control what lambda-form invoker methods are added to these classes that are generated during a CDS dump ([see here](https://github.com/iklam/jdk/blob/5aa997b001367141a6a2d2e69649d41b46199ab4/src/hotspot/share/cds/lambdaFormInvokers.cpp#L230)):
>> 
>> - `java.lang.invoke.Invokers$Holder`
>> - `java.lang.invoke.DirectMethodHandle$Holder`
>> - `java.lang.invoke.DelegatingMethodHandle$Holder`
>> - `java.lang.invoke.LambdaForm$Holder`
>> 
>> The list of these invoker methods is generated as part of the [JDK build process](https://github.com/iklam/jdk/blob/1996f649a3a30b7ac4b547a762417f807f5fa414/make/GenerateLinkOptData.gmk#L64). They are used for invoking MethodHandles of commonly-used types, so that we can avoid generating custom LambdaForm classes.
>> 
>> When a CDS archive is created with a non-default classlist, (e.g., `-XX:SharedClassListFile=foo.classlist`), such a classlist may not contain all the `@lambda-form-invoker` lines as in the default classlist. As a result, at runtime, more custom LambdaForm classes may be generated than necessary.
>> 
>> The solution is to always load the `@lambda-form-invoker` lines from the default classlist, to make sure the CDS image has all the commonly-used invoker methods.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rewrote test to write output to a file instead of stdout, so it will not be affected by -Xlog options

Test changes look good.

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

Marked as reviewed by ccheung (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10639

From iklam at openjdk.org  Thu Oct 13 00:04:45 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 13 Oct 2022 00:04:45 GMT
Subject: RFR: 8295102: Always load @lambda-form-invoker lines from default
 classlist [v4]
In-Reply-To: <_Yh-oeIHbRmaGXPENxJkeWqaYVf3d6jwIjPlwfYb24k=.d619abf0-eaff-498f-b1c6-540b72b86ab8@github.com>
References: <8P6vyzEAJpw7qVfgAo3unZKcanLD6q1Xu11lCap9xVo=.ab0719a4-0764-44cf-9f3c-c59879a1ddec@github.com>
 <pJiEQXQeaN3BawftlterCqJhziHzi6_vsGvCbuJNS2c=.0cc4605f-2dfa-4a58-9406-027335824ed4@github.com>
 <_Yh-oeIHbRmaGXPENxJkeWqaYVf3d6jwIjPlwfYb24k=.d619abf0-eaff-498f-b1c6-540b72b86ab8@github.com>
Message-ID: <cz9CC_JA0lbWjIKvWVPTFfqvI7brNKtpyp3i8WX7SoY=.3a704fe4-8254-47db-a32f-074c58a52641@github.com>

On Wed, 12 Oct 2022 21:01:31 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   rewrote test to write output to a file instead of stdout, so it will not be affected by -Xlog options
>
> Test changes look good.

Thanks to @calvinccheung and @cl4es for the review.

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

PR: https://git.openjdk.org/jdk/pull/10639

From iklam at openjdk.org  Thu Oct 13 00:04:48 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 13 Oct 2022 00:04:48 GMT
Subject: Integrated: 8295102: Always load @lambda-form-invoker lines from
 default classlist
In-Reply-To: <8P6vyzEAJpw7qVfgAo3unZKcanLD6q1Xu11lCap9xVo=.ab0719a4-0764-44cf-9f3c-c59879a1ddec@github.com>
References: <8P6vyzEAJpw7qVfgAo3unZKcanLD6q1Xu11lCap9xVo=.ab0719a4-0764-44cf-9f3c-c59879a1ddec@github.com>
Message-ID: <DtEDuFE17mYM5LLevX_Pg2AnrzrAt3V3jPaZYCWK6uw=.2d7031aa-de98-49d6-9053-1ed713bfbf3f@github.com>

On Mon, 10 Oct 2022 22:18:33 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> The `@lambda-form-invoker` lines in the default classlist (`$JAVA_HOME/lib/classlist`) control what lambda-form invoker methods are added to these classes that are generated during a CDS dump ([see here](https://github.com/iklam/jdk/blob/5aa997b001367141a6a2d2e69649d41b46199ab4/src/hotspot/share/cds/lambdaFormInvokers.cpp#L230)):
> 
> - `java.lang.invoke.Invokers$Holder`
> - `java.lang.invoke.DirectMethodHandle$Holder`
> - `java.lang.invoke.DelegatingMethodHandle$Holder`
> - `java.lang.invoke.LambdaForm$Holder`
> 
> The list of these invoker methods is generated as part of the [JDK build process](https://github.com/iklam/jdk/blob/1996f649a3a30b7ac4b547a762417f807f5fa414/make/GenerateLinkOptData.gmk#L64). They are used for invoking MethodHandles of commonly-used types, so that we can avoid generating custom LambdaForm classes.
> 
> When a CDS archive is created with a non-default classlist, (e.g., `-XX:SharedClassListFile=foo.classlist`), such a classlist may not contain all the `@lambda-form-invoker` lines as in the default classlist. As a result, at runtime, more custom LambdaForm classes may be generated than necessary.
> 
> The solution is to always load the `@lambda-form-invoker` lines from the default classlist, to make sure the CDS image has all the commonly-used invoker methods.

This pull request has now been integrated.

Changeset: 90fb9a08
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/90fb9a085bbaa9d1928a1cec9f00098b80577721
Stats:     276 lines in 7 files changed: 237 ins; 34 del; 5 mod

8295102: Always load @lambda-form-invoker lines from default classlist

Reviewed-by: redestad, ccheung

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

PR: https://git.openjdk.org/jdk/pull/10639

From iklam at openjdk.org  Thu Oct 13 03:54:42 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 13 Oct 2022 03:54:42 GMT
Subject: RFR: 8286431: Do not use resource array in posix mmap_attach_shared()
Message-ID: <ilMQJwSkR-8ZsXHtlFKIXyvKf63185rovLf5l28KBnc=.8cf85ba9-93d3-4ba5-bdda-7de280f1583b@github.com>

Please review this small clean up

perfMemory_posix.cpp uses a lot of explicit C heap alloc/free because the function may be called during early VM bootstrap, before ResourceMark can be used.

However, we have a single odd use of resource allocation in this file. It's supposed to work with Java exceptions. However, the code actually makes an explicitly exception check, so there's no need to do the resource alloc at all.

Also, there's no need to close the fd in case of exception.

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

Commit messages:
 - 8286431: Do not use resource array in posix mmap_attach_shared()

Changes: https://git.openjdk.org/jdk/pull/10686/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10686&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8286431
  Stats: 18 lines in 1 file changed: 1 ins; 13 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/10686.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10686/head:pull/10686

PR: https://git.openjdk.org/jdk/pull/10686

From ccheung at openjdk.org  Thu Oct 13 04:43:08 2022
From: ccheung at openjdk.org (Calvin Cheung)
Date: Thu, 13 Oct 2022 04:43:08 GMT
Subject: RFR: 8293291: Simplify relocation of native pointers in archive
 heap [v2]
In-Reply-To: <0hxng3R-ZFzWmXuotoVt2KTcYWahCgsxGjACmYxt9LE=.729cd1aa-cd1c-45f7-b7d2-0dabc1d7d05b@github.com>
References: <ElL_R-ZOAf6qfTzAypZPN0G5VrE9yLMuMznOJNauYFA=.85a3978c-c93a-4848-923f-92631a5c840e@github.com>
 <0hxng3R-ZFzWmXuotoVt2KTcYWahCgsxGjACmYxt9LE=.729cd1aa-cd1c-45f7-b7d2-0dabc1d7d05b@github.com>
Message-ID: <whp6L322hbdvzS2wNb_YU503KRNAt9FCMUfn6mfJgvo=.b875b75d-3556-4887-b5ae-c79f5bd23bfa@github.com>

On Mon, 19 Sep 2022 18:34:50 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Some objects in the archive heap contain native pointers. E.g., archived `java.lang.Class` objects contain a pointer to its `Klass*`.
>> 
>> At runtime, if the archived metadata are mapped at an alternative address, all of the `Klass*` pointers must be relocated. Instead of doing this in an ad-hoc way, this PR uses a bitmap, `FileMapRegion::ptrmap_view()`, to track the position of all the native pointers.
>> 
>> This PR is done in preparation for supporting new types of archived heap objects that have native pointers. E.g., `java.lang.invoke.ResolvedMethodName` has a pointer to a `Method*`.
>> 
>> 
>> Notes for reviewers:
>> 
>> - At dump time, the native pointers are remembered in `HeapShared::mark_native_pointers()`.
>> - At runtime, the native pointers are patched in `ArchiveHeapLoader::patch_native_pointers()`.
>> - The ad-hoc relocation code has been removed from javaClasses.cpp and systemDictionaryShared.cpp
>> - Many of the changes are for renaming from "oopmaps" to "bitmaps": the old code handled only a single type of pointers (oop references). The new code handles two types of bitmaps ("oopmap" is for oop references, "ptrmap" is for native pointers).
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @calvinccheung comments

Updates look good.

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

Marked as reviewed by ccheung (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10296

From dholmes at openjdk.org  Thu Oct 13 06:47:32 2022
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 13 Oct 2022 06:47:32 GMT
Subject: RFR: 8286431: Do not use resource array in posix
 mmap_attach_shared()
In-Reply-To: <ilMQJwSkR-8ZsXHtlFKIXyvKf63185rovLf5l28KBnc=.8cf85ba9-93d3-4ba5-bdda-7de280f1583b@github.com>
References: <ilMQJwSkR-8ZsXHtlFKIXyvKf63185rovLf5l28KBnc=.8cf85ba9-93d3-4ba5-bdda-7de280f1583b@github.com>
Message-ID: <RJqS3zsAyHFZ3ceu1Bc_0QQBr0IfVCZyCD_Cxm-tNFE=.f955d5c2-242b-4e0a-b6cd-d6b90ff3f2b9@github.com>

On Thu, 13 Oct 2022 03:48:03 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Please review this small clean up
> 
> perfMemory_posix.cpp uses a lot of explicit C heap alloc/free because the function may be called during early VM bootstrap, before ResourceMark can be used.
> 
> However, we have a single odd use of resource allocation in this file. It's supposed to work with Java exceptions. However, the code actually makes an explicitly exception check, so there's no need to do the resource alloc at all.
> 
> Also, there's no need to close the fd in case of exception.

One issue below and a suggestion.

I'm assuming we used the CHECK macro at one stage - hence the use of the RM etc.

src/hotspot/os/posix/perfMemory_posix.cpp line 1200:

> 1198:   char* filename = get_sharedmem_filename(dirname, vmid, nspid);
> 1199: 
> 1200:   // Handle the exception explicitly so we can free the strings.

Suggestion:
// We don't use CHECK as we need to free the strings even if an exception occurred.

src/hotspot/os/posix/perfMemory_posix.cpp line 1218:

> 1216:   if (fd == OS_ERR) {
> 1217:     return;
> 1218:   }

I think you still need this for the case where the file is insecure - no exception is thrown in that case.

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

Changes requested by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10686

From luhenry at openjdk.org  Thu Oct 13 07:56:52 2022
From: luhenry at openjdk.org (Ludovic Henry)
Date: Thu, 13 Oct 2022 07:56:52 GMT
Subject: RFR: 8295264: Fix PaX check on RISC-V
Message-ID: <Djj2_7ZL0rARimJOIpy07-jWSo-xfBbWreb9G0GjOjc=.14dcc827-4735-4136-ac26-391c3175dfa1@github.com>

On Linux RISC-V, PROT_WRITE doesn't imply PROT_READ [1]

The fix is to pass PROT_READ|PROT_WRITE. That matches all other calls to mmap in hotspot.

[1] https://lkml.org/lkml/2022/9/8/1066

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

Commit messages:
 - 8295264: Fix PaX check on RISC-V

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

PR: https://git.openjdk.org/jdk/pull/10690

From coleenp at openjdk.org  Thu Oct 13 17:15:47 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 13 Oct 2022 17:15:47 GMT
Subject: RFR: 8295278: Add parallel class loading tests
Message-ID: <SgIeM9-sAxxUNWtS7pvU-S5WK0oQ2DduUP7nZFmzNy0=.b9a3d6ba-73fd-43a3-98be-e179af406dd7@github.com>

I moved the ParallelLoad test to a subdirectory, and created a new one called CallLoadClass that calls loadClass directly and then waits on the ClassLoader object, while another thread calls forName() to go through the SystemDictionary resolution.

I also made dedicated tests out of the bugs reported in
[JDK-4699981](https://bugs.openjdk.org/browse/JDK-4699981) ClassCircularityError thrown without reason during class loading and
[JDK-4670071](https://bugs.openjdk.org/browse/JDK-4670071) java.lang.ClassLoader.loadClassInternal(String) is too restrictive

Tested with tier1 on Oracle platforms. These tests are run in tier1.

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

Commit messages:
 - 8295278: Add parallel class loading tests

Changes: https://git.openjdk.org/jdk/pull/10587/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10587&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295278
  Stats: 737 lines in 23 files changed: 735 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10587.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10587/head:pull/10587

PR: https://git.openjdk.org/jdk/pull/10587

From iklam at openjdk.org  Thu Oct 13 18:56:31 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 13 Oct 2022 18:56:31 GMT
Subject: Integrated: 8295295: CDS ArchivedEnumTest fails with
 StaticProperty::JAVA_LOCALE_USE_OLD_ISO_CODES
Message-ID: <aA3upqsbCbzKn0nlmHxOK3uWLpoYCQsZMACRNvnsBYI=.9f3f9a47-bd90-46b3-802b-1dfe9aae8f06@github.com>

Please review this trivial change to fix a tier2 failure:

The field `jdk.internal.util.StaticProperty::JAVA_LOCALE_USE_OLD_ISO_CODES` was added recently in [JDK-8295232](https://bugs.openjdk.org/browse/JDK-8295232). We need to add this field to the exception rules in cdsHeapVerifier.cpp, similar to the existing entry for `StaticProperty::FILE_ENCODING`

For more information about the exception rules, please see 
https://github.com/openjdk/jdk/blob/4224d45132b98e4f7bb7a96b696692d2f0bf645e/src/hotspot/share/cds/cdsHeapVerifier.cpp#L40-L83

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

Commit messages:
 - 8295295: CDS ArchivedEnumTest fails with StaticProperty::JAVA_LOCALE_USE_OLD_ISO_CODES

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

PR: https://git.openjdk.org/jdk/pull/10702

From ccheung at openjdk.org  Thu Oct 13 18:56:32 2022
From: ccheung at openjdk.org (Calvin Cheung)
Date: Thu, 13 Oct 2022 18:56:32 GMT
Subject: Integrated: 8295295: CDS ArchivedEnumTest fails with
 StaticProperty::JAVA_LOCALE_USE_OLD_ISO_CODES
In-Reply-To: <aA3upqsbCbzKn0nlmHxOK3uWLpoYCQsZMACRNvnsBYI=.9f3f9a47-bd90-46b3-802b-1dfe9aae8f06@github.com>
References: <aA3upqsbCbzKn0nlmHxOK3uWLpoYCQsZMACRNvnsBYI=.9f3f9a47-bd90-46b3-802b-1dfe9aae8f06@github.com>
Message-ID: <eX3T4iQJH-YF5KYz68iOmkw9hUg6wKEOE8CuYqY4gDw=.5d14490a-93c2-477e-a40d-31c160db134d@github.com>

On Thu, 13 Oct 2022 18:32:18 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Please review this trivial change to fix a tier2 failure:
> 
> The field `jdk.internal.util.StaticProperty::JAVA_LOCALE_USE_OLD_ISO_CODES` was added recently in [JDK-8295232](https://bugs.openjdk.org/browse/JDK-8295232). We need to add this field to the exception rules in cdsHeapVerifier.cpp, similar to the existing entry for `StaticProperty::FILE_ENCODING`
> 
> For more information about the exception rules, please see 
> https://github.com/openjdk/jdk/blob/4224d45132b98e4f7bb7a96b696692d2f0bf645e/src/hotspot/share/cds/cdsHeapVerifier.cpp#L40-L83

LGTM

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

Marked as reviewed by ccheung (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10702

From iklam at openjdk.org  Thu Oct 13 18:56:33 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 13 Oct 2022 18:56:33 GMT
Subject: Integrated: 8295295: CDS ArchivedEnumTest fails with
 StaticProperty::JAVA_LOCALE_USE_OLD_ISO_CODES
In-Reply-To: <eX3T4iQJH-YF5KYz68iOmkw9hUg6wKEOE8CuYqY4gDw=.5d14490a-93c2-477e-a40d-31c160db134d@github.com>
References: <aA3upqsbCbzKn0nlmHxOK3uWLpoYCQsZMACRNvnsBYI=.9f3f9a47-bd90-46b3-802b-1dfe9aae8f06@github.com>
 <eX3T4iQJH-YF5KYz68iOmkw9hUg6wKEOE8CuYqY4gDw=.5d14490a-93c2-477e-a40d-31c160db134d@github.com>
Message-ID: <3gts8Jf61zjwhq7z_QwDlBoO_0cTUu8_J1LfcVPSUyQ=.83146568-0ab6-4aac-8f33-e8f8359e0037@github.com>

On Thu, 13 Oct 2022 18:36:54 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Please review this trivial change to fix a tier2 failure:
>> 
>> The field `jdk.internal.util.StaticProperty::JAVA_LOCALE_USE_OLD_ISO_CODES` was added recently in [JDK-8295232](https://bugs.openjdk.org/browse/JDK-8295232). We need to add this field to the exception rules in cdsHeapVerifier.cpp, similar to the existing entry for `StaticProperty::FILE_ENCODING`
>> 
>> For more information about the exception rules, please see 
>> https://github.com/openjdk/jdk/blob/4224d45132b98e4f7bb7a96b696692d2f0bf645e/src/hotspot/share/cds/cdsHeapVerifier.cpp#L40-L83
>
> LGTM

Thanks to @calvinccheung for the review.

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

PR: https://git.openjdk.org/jdk/pull/10702

From iklam at openjdk.org  Thu Oct 13 18:56:34 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 13 Oct 2022 18:56:34 GMT
Subject: Integrated: 8295295: CDS ArchivedEnumTest fails with
 StaticProperty::JAVA_LOCALE_USE_OLD_ISO_CODES
In-Reply-To: <aA3upqsbCbzKn0nlmHxOK3uWLpoYCQsZMACRNvnsBYI=.9f3f9a47-bd90-46b3-802b-1dfe9aae8f06@github.com>
References: <aA3upqsbCbzKn0nlmHxOK3uWLpoYCQsZMACRNvnsBYI=.9f3f9a47-bd90-46b3-802b-1dfe9aae8f06@github.com>
Message-ID: <dgDBQVeJi3UERVuRA-OqhPOF44R4F6JTHzSp8o0upjs=.1f9302ac-61fa-4d7c-874e-646f6c5e24ad@github.com>

On Thu, 13 Oct 2022 18:32:18 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Please review this trivial change to fix a tier2 failure:
> 
> The field `jdk.internal.util.StaticProperty::JAVA_LOCALE_USE_OLD_ISO_CODES` was added recently in [JDK-8295232](https://bugs.openjdk.org/browse/JDK-8295232). We need to add this field to the exception rules in cdsHeapVerifier.cpp, similar to the existing entry for `StaticProperty::FILE_ENCODING`
> 
> For more information about the exception rules, please see 
> https://github.com/openjdk/jdk/blob/4224d45132b98e4f7bb7a96b696692d2f0bf645e/src/hotspot/share/cds/cdsHeapVerifier.cpp#L40-L83

This pull request has now been integrated.

Changeset: f5f8df11
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f5f8df11ce146f8b33963eea4de6ccf9d2373ff3
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8295295: CDS ArchivedEnumTest fails with StaticProperty::JAVA_LOCALE_USE_OLD_ISO_CODES

Reviewed-by: ccheung

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

PR: https://git.openjdk.org/jdk/pull/10702

From iklam at openjdk.org  Thu Oct 13 19:57:04 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 13 Oct 2022 19:57:04 GMT
Subject: RFR: 8286431: Do not use resource array in posix
 mmap_attach_shared() [v2]
In-Reply-To: <ilMQJwSkR-8ZsXHtlFKIXyvKf63185rovLf5l28KBnc=.8cf85ba9-93d3-4ba5-bdda-7de280f1583b@github.com>
References: <ilMQJwSkR-8ZsXHtlFKIXyvKf63185rovLf5l28KBnc=.8cf85ba9-93d3-4ba5-bdda-7de280f1583b@github.com>
Message-ID: <NxfDFaKfwF3VckkQaIHw3rkgDQfcT3d4WAwB--lVqyQ=.31494c92-7e8e-4eb1-87a8-5faeb9d2beda@github.com>

> Please review this small clean up
> 
> perfMemory_posix.cpp uses a lot of explicit C heap alloc/free because the function may be called during early VM bootstrap, before ResourceMark can be used.
> 
> However, we have a single odd use of resource allocation in this file. It's supposed to work with Java exceptions. However, the code actually makes an explicitly exception check, so there's no need to do the resource alloc at all.
> 
> Also, there's no need to close the fd in case of exception.

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  @dholmes-ora comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10686/files
  - new: https://git.openjdk.org/jdk/pull/10686/files/f77cc07b..6e99ca65

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10686&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10686&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10686.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10686/head:pull/10686

PR: https://git.openjdk.org/jdk/pull/10686

From iklam at openjdk.org  Thu Oct 13 19:57:05 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 13 Oct 2022 19:57:05 GMT
Subject: RFR: 8286431: Do not use resource array in posix
 mmap_attach_shared() [v2]
In-Reply-To: <RJqS3zsAyHFZ3ceu1Bc_0QQBr0IfVCZyCD_Cxm-tNFE=.f955d5c2-242b-4e0a-b6cd-d6b90ff3f2b9@github.com>
References: <ilMQJwSkR-8ZsXHtlFKIXyvKf63185rovLf5l28KBnc=.8cf85ba9-93d3-4ba5-bdda-7de280f1583b@github.com>
 <RJqS3zsAyHFZ3ceu1Bc_0QQBr0IfVCZyCD_Cxm-tNFE=.f955d5c2-242b-4e0a-b6cd-d6b90ff3f2b9@github.com>
Message-ID: <a3j0De-pnFRbQ7oCr0gLFjaRcbCzoi5dAtf7V5-o7dU=.5c8715f8-9537-4bc8-9823-231bbb2c3487@github.com>

On Thu, 13 Oct 2022 06:38:00 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @dholmes-ora comments
>
> src/hotspot/os/posix/perfMemory_posix.cpp line 1200:
> 
>> 1198:   char* filename = get_sharedmem_filename(dirname, vmid, nspid);
>> 1199: 
>> 1200:   // Handle the exception explicitly so we can free the strings.
> 
> Suggestion:
> // We don't use CHECK as we need to free the strings even if an exception occurred.

Fixed.

> src/hotspot/os/posix/perfMemory_posix.cpp line 1218:
> 
>> 1216:   if (fd == OS_ERR) {
>> 1217:     return;
>> 1218:   }
> 
> I think you still need this for the case where the file is insecure - no exception is thrown in that case.

Fixed.

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

PR: https://git.openjdk.org/jdk/pull/10686

From iklam at openjdk.org  Thu Oct 13 20:41:27 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 13 Oct 2022 20:41:27 GMT
Subject: RFR: 8293291: Simplify relocation of native pointers in archive
 heap [v3]
In-Reply-To: <ElL_R-ZOAf6qfTzAypZPN0G5VrE9yLMuMznOJNauYFA=.85a3978c-c93a-4848-923f-92631a5c840e@github.com>
References: <ElL_R-ZOAf6qfTzAypZPN0G5VrE9yLMuMznOJNauYFA=.85a3978c-c93a-4848-923f-92631a5c840e@github.com>
Message-ID: <abGfx7kGb0DNlLqKlrIDSR-wJyo9deKIvUSq_ZvWMsw=.d0653909-e248-4d3b-bd5f-bb0f8e533f2e@github.com>

> Some objects in the archive heap contain native pointers. E.g., archived `java.lang.Class` objects contain a pointer to its `Klass*`.
> 
> At runtime, if the archived metadata are mapped at an alternative address, all of the `Klass*` pointers must be relocated. Instead of doing this in an ad-hoc way, this PR uses a bitmap, `FileMapRegion::ptrmap_view()`, to track the position of all the native pointers.
> 
> This PR is done in preparation for supporting new types of archived heap objects that have native pointers. E.g., `java.lang.invoke.ResolvedMethodName` has a pointer to a `Method*`.
> 
> 
> Notes for reviewers:
> 
> - At dump time, the native pointers are remembered in `HeapShared::mark_native_pointers()`.
> - At runtime, the native pointers are patched in `ArchiveHeapLoader::patch_native_pointers()`.
> - The ad-hoc relocation code has been removed from javaClasses.cpp and systemDictionaryShared.cpp
> - Many of the changes are for renaming from "oopmaps" to "bitmaps": the old code handled only a single type of pointers (oop references). The new code handles two types of bitmaps ("oopmap" is for oop references, "ptrmap" is for native pointers).

Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:

 - Merge branch 'master' into 8293291-simplify-archive-heap-native-ptr-relocation
 - Merge branch 'master' into 8293291-simplify-archive-heap-native-ptr-relocation
 - @calvinccheung comments
 - clean up
 - 8293291: Simplify relocation of native pointers in archive heap

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10296/files
  - new: https://git.openjdk.org/jdk/pull/10296/files/24b905b3..d2e969bb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10296&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10296&range=01-02

  Stats: 52901 lines in 1551 files changed: 30195 ins; 14800 del; 7906 mod
  Patch: https://git.openjdk.org/jdk/pull/10296.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10296/head:pull/10296

PR: https://git.openjdk.org/jdk/pull/10296

From vlivanov at openjdk.org  Thu Oct 13 20:48:55 2022
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Thu, 13 Oct 2022 20:48:55 GMT
Subject: RFR: 8295294: Misc cleanups in runtime/InvocationTests
Message-ID: <1pwynQSe-Dc7BNRO3Q1CzUrQRbuNda3VSBz9dhD21fA=.a67db81b-6e64-47ef-a683-7add61bcc5eb@github.com>

Address the following problems in runtime/InvocationTests:
  - Test case tracing output is omitted;
  - Stand-alone test case executors are broken.

Testing: manual

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

Commit messages:
 - fix output in --noexecute mode
 - 8295294: Misc cleanups in runtime/InvocationTests

Changes: https://git.openjdk.org/jdk/pull/10701/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10701&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295294
  Stats: 42 lines in 2 files changed: 10 ins; 16 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/10701.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10701/head:pull/10701

PR: https://git.openjdk.org/jdk/pull/10701

From vlivanov at openjdk.org  Thu Oct 13 22:22:00 2022
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Thu, 13 Oct 2022 22:22:00 GMT
Subject: RFR: 8295278: Add parallel class loading tests
In-Reply-To: <SgIeM9-sAxxUNWtS7pvU-S5WK0oQ2DduUP7nZFmzNy0=.b9a3d6ba-73fd-43a3-98be-e179af406dd7@github.com>
References: <SgIeM9-sAxxUNWtS7pvU-S5WK0oQ2DduUP7nZFmzNy0=.b9a3d6ba-73fd-43a3-98be-e179af406dd7@github.com>
Message-ID: <yXLBeGMv2PB8czy9ToRojxsGGfKdvK0yn4SjcA64V3U=.ad4b4910-a33f-487a-8131-bf79243077c0@github.com>

On Wed, 5 Oct 2022 22:53:48 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> I moved the ParallelLoad test to a subdirectory, and created a new one called CallLoadClass that calls loadClass directly and then waits on the ClassLoader object, while another thread calls forName() to go through the SystemDictionary resolution.
> 
> I also made dedicated tests out of the bugs reported in
> [JDK-4699981](https://bugs.openjdk.org/browse/JDK-4699981) ClassCircularityError thrown without reason during class loading and
> [JDK-4670071](https://bugs.openjdk.org/browse/JDK-4670071) java.lang.ClassLoader.loadClassInternal(String) is too restrictive
> 
> Tested with tier1 on Oracle platforms. These tests are run in tier1.

Looks good.

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

Marked as reviewed by vlivanov (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10587

From dholmes at openjdk.org  Thu Oct 13 23:42:04 2022
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 13 Oct 2022 23:42:04 GMT
Subject: RFR: 8286431: Do not use resource array in posix
 mmap_attach_shared() [v2]
In-Reply-To: <NxfDFaKfwF3VckkQaIHw3rkgDQfcT3d4WAwB--lVqyQ=.31494c92-7e8e-4eb1-87a8-5faeb9d2beda@github.com>
References: <ilMQJwSkR-8ZsXHtlFKIXyvKf63185rovLf5l28KBnc=.8cf85ba9-93d3-4ba5-bdda-7de280f1583b@github.com>
 <NxfDFaKfwF3VckkQaIHw3rkgDQfcT3d4WAwB--lVqyQ=.31494c92-7e8e-4eb1-87a8-5faeb9d2beda@github.com>
Message-ID: <56J8jT541QqmorVIXY5q_hVcDoa4N_sMS2RzbUKpV-0=.40b2b6a3-a4a6-4789-8d9d-7600df99d85d@github.com>

On Thu, 13 Oct 2022 19:57:04 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Please review this small clean up
>> 
>> perfMemory_posix.cpp uses a lot of explicit C heap alloc/free because the function may be called during early VM bootstrap, before ResourceMark can be used.
>> 
>> However, we have a single odd use of resource allocation in this file. It's supposed to work with Java exceptions. However, the code actually makes an explicitly exception check, so there's no need to do the resource alloc at all.
>> 
>> Also, there's no need to close the fd in case of exception.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @dholmes-ora comments

Looks good. Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10686

From ccheung at openjdk.org  Fri Oct 14 03:39:15 2022
From: ccheung at openjdk.org (Calvin Cheung)
Date: Fri, 14 Oct 2022 03:39:15 GMT
Subject: RFR: 8295278: Add parallel class loading tests
In-Reply-To: <SgIeM9-sAxxUNWtS7pvU-S5WK0oQ2DduUP7nZFmzNy0=.b9a3d6ba-73fd-43a3-98be-e179af406dd7@github.com>
References: <SgIeM9-sAxxUNWtS7pvU-S5WK0oQ2DduUP7nZFmzNy0=.b9a3d6ba-73fd-43a3-98be-e179af406dd7@github.com>
Message-ID: <FK_ebMmP1xpDwphyLosMTYZwO6vYo40mfSVhZODSQhA=.69d54931-8b40-4dab-924c-057ebb439865@github.com>

On Wed, 5 Oct 2022 22:53:48 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> I moved the ParallelLoad test to a subdirectory, and created a new one called CallLoadClass that calls loadClass directly and then waits on the ClassLoader object, while another thread calls forName() to go through the SystemDictionary resolution.
> 
> I also made dedicated tests out of the bugs reported in
> [JDK-4699981](https://bugs.openjdk.org/browse/JDK-4699981) ClassCircularityError thrown without reason during class loading and
> [JDK-4670071](https://bugs.openjdk.org/browse/JDK-4670071) java.lang.ClassLoader.loadClassInternal(String) is too restrictive
> 
> Tested with tier1 on Oracle platforms. These tests are run in tier1.

I looked at mostly the tests under CallLoadClass and have one comment. Thanks.

test/hotspot/jtreg/runtime/ParallelLoad/CallLoadClass/ClassLoadingThread.java line 68:

> 66:             } else {
> 67:                 success = true;
> 68:             }

Should `success` be set to `false` in this case?

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

PR: https://git.openjdk.org/jdk/pull/10587

From dholmes at openjdk.org  Fri Oct 14 04:33:00 2022
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 14 Oct 2022 04:33:00 GMT
Subject: RFR: 8295294: Misc cleanups in runtime/InvocationTests
In-Reply-To: <1pwynQSe-Dc7BNRO3Q1CzUrQRbuNda3VSBz9dhD21fA=.a67db81b-6e64-47ef-a683-7add61bcc5eb@github.com>
References: <1pwynQSe-Dc7BNRO3Q1CzUrQRbuNda3VSBz9dhD21fA=.a67db81b-6e64-47ef-a683-7add61bcc5eb@github.com>
Message-ID: <0Rkxzo3fVjTi3Peh4LlvgO6J44uwN1sMwbRlXRJgBTI=.89fcd1ca-516a-438a-a6c0-71fe9ca642c2@github.com>

On Thu, 13 Oct 2022 18:17:42 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> Address the following problems in runtime/InvocationTests:
>   - Test case tracing output is omitted;
>   - Stand-alone test case executors are broken.
> 
> Testing: manual

All looks reasonable. Thanks.

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10701

From coleenp at openjdk.org  Fri Oct 14 12:37:23 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 14 Oct 2022 12:37:23 GMT
Subject: RFR: 8295278: Add parallel class loading tests [v2]
In-Reply-To: <SgIeM9-sAxxUNWtS7pvU-S5WK0oQ2DduUP7nZFmzNy0=.b9a3d6ba-73fd-43a3-98be-e179af406dd7@github.com>
References: <SgIeM9-sAxxUNWtS7pvU-S5WK0oQ2DduUP7nZFmzNy0=.b9a3d6ba-73fd-43a3-98be-e179af406dd7@github.com>
Message-ID: <PUB5CW5MfpwL9Ov8kvBxja919xQqKpzbfcOhJ1Z7-Sg=.c2c0b252-0dbc-402f-bc0b-c5e8b55ae6fb@github.com>

> I moved the ParallelLoad test to a subdirectory, and created a new one called CallLoadClass that calls loadClass directly and then waits on the ClassLoader object, while another thread calls forName() to go through the SystemDictionary resolution.
> 
> I also made dedicated tests out of the bugs reported in
> [JDK-4699981](https://bugs.openjdk.org/browse/JDK-4699981) ClassCircularityError thrown without reason during class loading and
> [JDK-4670071](https://bugs.openjdk.org/browse/JDK-4670071) java.lang.ClassLoader.loadClassInternal(String) is too restrictive
> 
> Tested with tier1 on Oracle platforms. These tests are run in tier1.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Fix success test for loadClass case.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10587/files
  - new: https://git.openjdk.org/jdk/pull/10587/files/abab0205..796c7b45

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10587&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10587&range=00-01

  Stats: 5 lines in 1 file changed: 0 ins; 4 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10587.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10587/head:pull/10587

PR: https://git.openjdk.org/jdk/pull/10587

From coleenp at openjdk.org  Fri Oct 14 12:37:24 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 14 Oct 2022 12:37:24 GMT
Subject: RFR: 8295278: Add parallel class loading tests
In-Reply-To: <SgIeM9-sAxxUNWtS7pvU-S5WK0oQ2DduUP7nZFmzNy0=.b9a3d6ba-73fd-43a3-98be-e179af406dd7@github.com>
References: <SgIeM9-sAxxUNWtS7pvU-S5WK0oQ2DduUP7nZFmzNy0=.b9a3d6ba-73fd-43a3-98be-e179af406dd7@github.com>
Message-ID: <b7NfYQob2TC1B_ei_dfQfni38wiWQHpXxzM_d162HVI=.13dc8f08-fc61-4b42-bfaf-b5ceea66ca27@github.com>

On Wed, 5 Oct 2022 22:53:48 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> I moved the ParallelLoad test to a subdirectory, and created a new one called CallLoadClass that calls loadClass directly and then waits on the ClassLoader object, while another thread calls forName() to go through the SystemDictionary resolution.
> 
> I also made dedicated tests out of the bugs reported in
> [JDK-4699981](https://bugs.openjdk.org/browse/JDK-4699981) ClassCircularityError thrown without reason during class loading and
> [JDK-4670071](https://bugs.openjdk.org/browse/JDK-4670071) java.lang.ClassLoader.loadClassInternal(String) is too restrictive
> 
> Tested with tier1 on Oracle platforms. These tests are run in tier1.

Thanks for reviewing, Vladimir and Calvin.

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

PR: https://git.openjdk.org/jdk/pull/10587

From coleenp at openjdk.org  Fri Oct 14 12:37:24 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 14 Oct 2022 12:37:24 GMT
Subject: RFR: 8295278: Add parallel class loading tests [v2]
In-Reply-To: <FK_ebMmP1xpDwphyLosMTYZwO6vYo40mfSVhZODSQhA=.69d54931-8b40-4dab-924c-057ebb439865@github.com>
References: <SgIeM9-sAxxUNWtS7pvU-S5WK0oQ2DduUP7nZFmzNy0=.b9a3d6ba-73fd-43a3-98be-e179af406dd7@github.com>
 <FK_ebMmP1xpDwphyLosMTYZwO6vYo40mfSVhZODSQhA=.69d54931-8b40-4dab-924c-057ebb439865@github.com>
Message-ID: <5-0Np6Z4GjfiIrCEhylXpz72KOOK3euyV36cHUdVPhM=.7a6289a3-71be-4170-aeda-370ffffc3cc0@github.com>

On Fri, 14 Oct 2022 03:33:08 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix success test for loadClass case.
>
> test/hotspot/jtreg/runtime/ParallelLoad/CallLoadClass/ClassLoadingThread.java line 68:
> 
>> 66:             } else {
>> 67:                 success = true;
>> 68:             }
> 
> Should `success` be set to `false` in this case?

Yes, you're right, it should be false.  We expect LinkageError in this case.

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

PR: https://git.openjdk.org/jdk/pull/10587

From jsjolen at openjdk.org  Fri Oct 14 12:45:09 2022
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Fri, 14 Oct 2022 12:45:09 GMT
Subject: RFR: 8294362: UL: Replace the internal usage of manual buffers
 with stringStream in LogSelection
In-Reply-To: <OL78g6ZuEUoDv1rnU_yJdg3gJko4oIRNm8WsVad0rBo=.3fcf5f98-b176-4f71-83cf-96ded1a29e0f@github.com>
References: <mUB0Ir5oWoGxE_mHp3IiZdObb96m4XFF5eFjDWq7IKo=.292a92ed-8957-4ae2-a930-2c942d7f3cc0@github.com>
 <2bAfQEf8_dpaTkD8XXiAZ911GhinAu7_GPN48V0oj30=.dd622fb6-1dfd-476a-86cc-35af2ed1a16b@github.com>
 <OL78g6ZuEUoDv1rnU_yJdg3gJko4oIRNm8WsVad0rBo=.3fcf5f98-b176-4f71-83cf-96ded1a29e0f@github.com>
Message-ID: <npn7rbZTY0OkcWjdlsc-Vy974vZneCJLrGUsyMAigQ4=.78ad0c7a-8abb-4966-9acf-bfeba49af9f6@github.com>

On Wed, 5 Oct 2022 02:44:34 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > I need to see if there is some historical info on the initial implementation here.
> 
> Nope. Lets see if anyone else knows why the code may have originally been written the way it was.

We're not seeing anyone wanting to chime in on this :-). The reasoning might simply be: "Because it happened to be written that way."

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

PR: https://git.openjdk.org/jdk/pull/10553

From ccheung at openjdk.org  Fri Oct 14 15:54:06 2022
From: ccheung at openjdk.org (Calvin Cheung)
Date: Fri, 14 Oct 2022 15:54:06 GMT
Subject: RFR: 8295278: Add parallel class loading tests [v2]
In-Reply-To: <PUB5CW5MfpwL9Ov8kvBxja919xQqKpzbfcOhJ1Z7-Sg=.c2c0b252-0dbc-402f-bc0b-c5e8b55ae6fb@github.com>
References: <SgIeM9-sAxxUNWtS7pvU-S5WK0oQ2DduUP7nZFmzNy0=.b9a3d6ba-73fd-43a3-98be-e179af406dd7@github.com>
 <PUB5CW5MfpwL9Ov8kvBxja919xQqKpzbfcOhJ1Z7-Sg=.c2c0b252-0dbc-402f-bc0b-c5e8b55ae6fb@github.com>
Message-ID: <_ZXb93KyNexdZLN2OEU2izQO9Cd5fSzT-GnEru8Cw7I=.f5589e11-5f13-41c8-9fa2-5767d2515b75@github.com>

On Fri, 14 Oct 2022 12:37:23 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I moved the ParallelLoad test to a subdirectory, and created a new one called CallLoadClass that calls loadClass directly and then waits on the ClassLoader object, while another thread calls forName() to go through the SystemDictionary resolution.
>> 
>> I also made dedicated tests out of the bugs reported in
>> [JDK-4699981](https://bugs.openjdk.org/browse/JDK-4699981) ClassCircularityError thrown without reason during class loading and
>> [JDK-4670071](https://bugs.openjdk.org/browse/JDK-4670071) java.lang.ClassLoader.loadClassInternal(String) is too restrictive
>> 
>> Tested with tier1 on Oracle platforms. These tests are run in tier1.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix success test for loadClass case.

Updates look good. Thanks.

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

Marked as reviewed by ccheung (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10587

From ccheung at openjdk.org  Fri Oct 14 16:51:10 2022
From: ccheung at openjdk.org (Calvin Cheung)
Date: Fri, 14 Oct 2022 16:51:10 GMT
Subject: RFR: 8279366: CDS should allow alternative locations for JAR files
 in classpath [v2]
In-Reply-To: <gjn5N9Lmavel1A8AHZFHxbp0J2l6XklY_-Pr-N04k7g=.dd8b5ed1-2c55-40cf-88e1-770e16c4c911@github.com>
References: <gjn5N9Lmavel1A8AHZFHxbp0J2l6XklY_-Pr-N04k7g=.dd8b5ed1-2c55-40cf-88e1-770e16c4c911@github.com>
Message-ID: <vE4QFnE0HK7b-rn5jcY1uK3x7Cv62luelsIgLhFEA5o=.3bf5a547-bc67-418b-8639-c7d0117f3860@github.com>

> Please review this RFE for allowing alternative locations for jar files in the app classpath during runtime.
> 
> During dump time, the longest common prefix of the app classpath will be stored in the CDS archive header. During runtime, existing checks of the app classpath will be performed first. Upon failure, the longest common prefix of the runtime app classpath will be computed and another check of the app classpath will be performed ignoring the longest common prefix.
> 
> Refer to the [bug report comment](https://bugs.openjdk.org/browse/JDK-8279366?focusedCommentId=14509536&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14509536) for an example.
> 
> Passed tiers 1 - 4 testing (including the new tests).

Calvin Cheung 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 four additional commits since the last revision:

 - not storing the common app path string in the archive header
 - Merge branch 'master' into 8279366-longest-common-prefix
 - remove trailing whitespace
 - 8279366: CDS should allow alternative locations for JAR files in classpath

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10615/files
  - new: https://git.openjdk.org/jdk/pull/10615/files/a8db37da..d572c2e0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10615&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10615&range=00-01

  Stats: 46187 lines in 1070 files changed: 27780 ins; 13496 del; 4911 mod
  Patch: https://git.openjdk.org/jdk/pull/10615.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10615/head:pull/10615

PR: https://git.openjdk.org/jdk/pull/10615

From ccheung at openjdk.org  Fri Oct 14 16:57:26 2022
From: ccheung at openjdk.org (Calvin Cheung)
Date: Fri, 14 Oct 2022 16:57:26 GMT
Subject: RFR: 8279366: CDS should allow alternative locations for JAR files
 in classpath [v2]
In-Reply-To: <rAreJqrssxr7i2L-75OXjAKwQgCK3ON69YKpwPL9qi8=.29d1ccf0-9907-4cc8-834f-c8bce637aaf7@github.com>
References: <gjn5N9Lmavel1A8AHZFHxbp0J2l6XklY_-Pr-N04k7g=.dd8b5ed1-2c55-40cf-88e1-770e16c4c911@github.com>
 <rAreJqrssxr7i2L-75OXjAKwQgCK3ON69YKpwPL9qi8=.29d1ccf0-9907-4cc8-834f-c8bce637aaf7@github.com>
Message-ID: <UBAdNtWwhA9auhvaT-fT7xtXfcGBx07VLToFdFpVEnA=.fb8f1110-1b14-4766-a682-f33bdb7ee73e@github.com>

On Mon, 10 Oct 2022 05:23:39 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Calvin Cheung 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 four additional commits since the last revision:
>> 
>>  - not storing the common app path string in the archive header
>>  - Merge branch 'master' into 8279366-longest-common-prefix
>>  - remove trailing whitespace
>>  - 8279366: CDS should allow alternative locations for JAR files in classpath
>
> src/hotspot/share/cds/filemap.cpp line 261:
> 
>> 259:   set_base_archive_name_size((unsigned int)base_archive_name_size);
>> 260:   set_common_app_classpath_offset((unsigned int)common_app_classpath_offset);
>> 261:   set_common_app_classpath_size((unsigned int)common_app_classpath_size);
> 
> I think there's no need to record the actual `common_app_classpath` string into the `FileMapHeader`. It should be enough to just store the length of the longest common path prefix. E.g., at runtime, the function `FileMapInfo::check_paths_ignoring_common_path` currently only uses `strlen(dumptime_prefix)`.
> 
> Also, `longest_common_app_classpath` can just return the length instead of the string.

I've made the change. The changeset is smaller now.

> src/hotspot/share/cds/filemap.cpp line 895:
> 
>> 893:   for (int i = 1; i < num_paths; i++) {
>> 894:     chr = strrchr((char*)rp_array->at(i), *os::file_separator());
>> 895:     size_t curr_len = chr != NULL ? chr - rp_array->at(i) + 1 : strlen(rp_array->at(i)) + 1;
> 
> If `chr == NULL`, it means we have a file name only, with no file separator. In this case, there will be no common prefix, so this function can return NULL immediately.

Right. I don't need to use strrchr in my updated change.

> src/hotspot/share/cds/filemap.cpp line 915:
> 
>> 913:     *(lcp + j) = c;
>> 914:   }
>> 915: 
> 
> Need to check for this case as well:
> 
> 
> rp[0] = "/x/a/Foo.jar"
> rp[1] = "/x/aa/Bar.jar"
> 
> 
> I think the current code will incorrectly return "/x/a"

Fixed. I rewrote the function. It now returns the length.
I also added some test cases to test the above and refactored some code in the test cases.

> src/hotspot/share/cds/filemap.cpp line 942:
> 
>> 940:     const char* runtime_path = rp_array->at(i)  + strlen(runtime_prefix);
>> 941:     if (strcmp(dumptime_path, runtime_path) != 0) {
>> 942:       mismatch = true;
> 
> Can this be simplified as `return false` so you don't need to maintain the `mismatch` variable?

Fixed.

> src/hotspot/share/cds/filemap.cpp line 1079:
> 
>> 1077:         mismatch = check_paths_ignoring_common_path(j, shared_app_paths_len, rp_array,
>> 1078:                                                     (const char*)dumptime_prefix, runtime_prefix);
>> 1079:       }
> 
> For completeness, we should allow empty prefixes. For example:
> 
> dump: `-cp foo.jar:x/bar.jar`
> run: `-cp a/foo.jar:a/x/bar.jar`
> 
> or
> 
> dump: `-cp a/foo.jar:a/x/bar.jar`
> run: `-cp foo.jar:x/bar.jar`

My updated change doesn't have the condition check anymore.

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

PR: https://git.openjdk.org/jdk/pull/10615

From vlivanov at openjdk.org  Fri Oct 14 17:49:29 2022
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Fri, 14 Oct 2022 17:49:29 GMT
Subject: RFR: 8295294: Misc cleanups in runtime/InvocationTests
In-Reply-To: <1pwynQSe-Dc7BNRO3Q1CzUrQRbuNda3VSBz9dhD21fA=.a67db81b-6e64-47ef-a683-7add61bcc5eb@github.com>
References: <1pwynQSe-Dc7BNRO3Q1CzUrQRbuNda3VSBz9dhD21fA=.a67db81b-6e64-47ef-a683-7add61bcc5eb@github.com>
Message-ID: <tTLPxVHeQZdPy8jl4fqws_0pWlTNPR9o4rZyRPGT1EY=.292b6191-0d74-4096-a40a-721bdf634dde@github.com>

On Thu, 13 Oct 2022 18:17:42 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> Address the following problems in runtime/InvocationTests:
>   - Test case tracing output is omitted;
>   - Stand-alone test case executors are broken.
> 
> Testing: manual

Thanks for the review, David.

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

PR: https://git.openjdk.org/jdk/pull/10701

From vlivanov at openjdk.org  Fri Oct 14 17:49:29 2022
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Fri, 14 Oct 2022 17:49:29 GMT
Subject: Integrated: 8295294: Misc cleanups in runtime/InvocationTests
In-Reply-To: <1pwynQSe-Dc7BNRO3Q1CzUrQRbuNda3VSBz9dhD21fA=.a67db81b-6e64-47ef-a683-7add61bcc5eb@github.com>
References: <1pwynQSe-Dc7BNRO3Q1CzUrQRbuNda3VSBz9dhD21fA=.a67db81b-6e64-47ef-a683-7add61bcc5eb@github.com>
Message-ID: <CbSZBnzsrfeQYvIlhzpBFacibqJKBINRxW1EWLVkAYY=.27eea612-0910-445b-9035-8a54c41ac3d8@github.com>

On Thu, 13 Oct 2022 18:17:42 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> Address the following problems in runtime/InvocationTests:
>   - Test case tracing output is omitted;
>   - Stand-alone test case executors are broken.
> 
> Testing: manual

This pull request has now been integrated.

Changeset: 8487c56f
Author:    Vladimir Ivanov <vlivanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8487c56f7ea224169d9d42efda9efb824266289f
Stats:     42 lines in 2 files changed: 10 ins; 16 del; 16 mod

8295294: Misc cleanups in runtime/InvocationTests

Reviewed-by: dholmes

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

PR: https://git.openjdk.org/jdk/pull/10701

From aturbanov at openjdk.org  Fri Oct 14 19:14:23 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Fri, 14 Oct 2022 19:14:23 GMT
Subject: RFR: 8295278: Add parallel class loading tests [v2]
In-Reply-To: <PUB5CW5MfpwL9Ov8kvBxja919xQqKpzbfcOhJ1Z7-Sg=.c2c0b252-0dbc-402f-bc0b-c5e8b55ae6fb@github.com>
References: <SgIeM9-sAxxUNWtS7pvU-S5WK0oQ2DduUP7nZFmzNy0=.b9a3d6ba-73fd-43a3-98be-e179af406dd7@github.com>
 <PUB5CW5MfpwL9Ov8kvBxja919xQqKpzbfcOhJ1Z7-Sg=.c2c0b252-0dbc-402f-bc0b-c5e8b55ae6fb@github.com>
Message-ID: <dCMO2z_PFLyNAm6YEfWU41VNAukWjyNTax9iHCI83qk=.b47f111b-00b4-438b-8035-f77a592fb308@github.com>

On Fri, 14 Oct 2022 12:37:23 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I moved the ParallelLoad test to a subdirectory, and created a new one called CallLoadClass that calls loadClass directly and then waits on the ClassLoader object, while another thread calls forName() to go through the SystemDictionary resolution.
>> 
>> I also made dedicated tests out of the bugs reported in
>> [JDK-4699981](https://bugs.openjdk.org/browse/JDK-4699981) ClassCircularityError thrown without reason during class loading and
>> [JDK-4670071](https://bugs.openjdk.org/browse/JDK-4670071) java.lang.ClassLoader.loadClassInternal(String) is too restrictive
>> 
>> Tested with tier1 on Oracle platforms. These tests are run in tier1.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix success test for loadClass case.

test/hotspot/jtreg/runtime/ParallelLoad/SuperWait/test-classes/A.java line 25:

> 23: 
> 24: // A extends B in other Class loader.
> 25: public class A  extends B {

Suggestion:

public class A extends B {

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

PR: https://git.openjdk.org/jdk/pull/10587

From coleenp at openjdk.org  Sat Oct 15 01:33:37 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Sat, 15 Oct 2022 01:33:37 GMT
Subject: RFR: 8295278: Add parallel class loading tests [v3]
In-Reply-To: <SgIeM9-sAxxUNWtS7pvU-S5WK0oQ2DduUP7nZFmzNy0=.b9a3d6ba-73fd-43a3-98be-e179af406dd7@github.com>
References: <SgIeM9-sAxxUNWtS7pvU-S5WK0oQ2DduUP7nZFmzNy0=.b9a3d6ba-73fd-43a3-98be-e179af406dd7@github.com>
Message-ID: <N0EJgEpX1CoKl3V6qdUrX8MxXt7hD5_J_8-XAAb5a-w=.9e571fc6-974b-410c-bb08-5839e94a1176@github.com>

> I moved the ParallelLoad test to a subdirectory, and created a new one called CallLoadClass that calls loadClass directly and then waits on the ClassLoader object, while another thread calls forName() to go through the SystemDictionary resolution.
> 
> I also made dedicated tests out of the bugs reported in
> [JDK-4699981](https://bugs.openjdk.org/browse/JDK-4699981) ClassCircularityError thrown without reason during class loading and
> [JDK-4670071](https://bugs.openjdk.org/browse/JDK-4670071) java.lang.ClassLoader.loadClassInternal(String) is too restrictive
> 
> Tested with tier1 on Oracle platforms. These tests are run in tier1.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Update test/hotspot/jtreg/runtime/ParallelLoad/SuperWait/test-classes/A.java
  
  Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10587/files
  - new: https://git.openjdk.org/jdk/pull/10587/files/796c7b45..44892f2b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10587&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10587&range=01-02

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

PR: https://git.openjdk.org/jdk/pull/10587

From dcubed at openjdk.org  Sat Oct 15 14:47:32 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Sat, 15 Oct 2022 14:47:32 GMT
Subject: RFR: 8295379: ProblemList java/lang/Float/Binary16Conversion.java in
 Xcomp mode on x64
Message-ID: <SJFRzF38jWtRYd3G45jQ6C05fEg0gBdgrNpva7xVuHQ=.0fb514db-988d-4300-88af-cbb2efb5bd0c@github.com>

A trivial fix to ProblemList a couple of tests in -Xcomp mode on generic-x64:

[JDK-8295379](https://bugs.openjdk.org/browse/JDK-8295379) ProblemList java/lang/Float/Binary16Conversion.java in Xcomp mode on x64
[JDK-8295380](https://bugs.openjdk.org/browse/JDK-8295380) ProblemList gc/cslocker/TestCSLocker.java in Xcomp mode on x64

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

Commit messages:
 - 8295380: ProblemList gc/cslocker/TestCSLocker.java in Xcomp mode on x64
 - 8295379: ProblemList java/lang/Float/Binary16Conversion.java in Xcomp mode on x64

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

PR: https://git.openjdk.org/jdk/pull/10719

From alanb at openjdk.org  Sat Oct 15 14:47:32 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 15 Oct 2022 14:47:32 GMT
Subject: RFR: 8295379: ProblemList java/lang/Float/Binary16Conversion.java
 in Xcomp mode on x64
In-Reply-To: <SJFRzF38jWtRYd3G45jQ6C05fEg0gBdgrNpva7xVuHQ=.0fb514db-988d-4300-88af-cbb2efb5bd0c@github.com>
References: <SJFRzF38jWtRYd3G45jQ6C05fEg0gBdgrNpva7xVuHQ=.0fb514db-988d-4300-88af-cbb2efb5bd0c@github.com>
Message-ID: <tOFi0DgZeaf05iHougXRu9keiPuFyDepBgd2AGN1WMY=.4a02f571-cd34-499d-acc4-8c0bce0a4bec@github.com>

On Sat, 15 Oct 2022 14:29:18 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList a couple of tests in -Xcomp mode on generic-x64:
> 
> [JDK-8295379](https://bugs.openjdk.org/browse/JDK-8295379) ProblemList java/lang/Float/Binary16Conversion.java in Xcomp mode on x64
> [JDK-8295380](https://bugs.openjdk.org/browse/JDK-8295380) ProblemList gc/cslocker/TestCSLocker.java in Xcomp mode on x64

Marked as reviewed by alanb (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10719

From dcubed at openjdk.org  Sat Oct 15 14:47:32 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Sat, 15 Oct 2022 14:47:32 GMT
Subject: RFR: 8295379: ProblemList java/lang/Float/Binary16Conversion.java
 in Xcomp mode on x64
In-Reply-To: <tOFi0DgZeaf05iHougXRu9keiPuFyDepBgd2AGN1WMY=.4a02f571-cd34-499d-acc4-8c0bce0a4bec@github.com>
References: <SJFRzF38jWtRYd3G45jQ6C05fEg0gBdgrNpva7xVuHQ=.0fb514db-988d-4300-88af-cbb2efb5bd0c@github.com>
 <tOFi0DgZeaf05iHougXRu9keiPuFyDepBgd2AGN1WMY=.4a02f571-cd34-499d-acc4-8c0bce0a4bec@github.com>
Message-ID: <f52O5Y1eQ4zCRQgP6yh8sT3Ie3Zbz_Uqs0wuRMVHZQQ=.6958325c-e749-4ad7-86af-0d7ae8668ff2@github.com>

On Sat, 15 Oct 2022 14:31:29 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> A trivial fix to ProblemList a couple of tests in -Xcomp mode on generic-x64:
>> 
>> [JDK-8295379](https://bugs.openjdk.org/browse/JDK-8295379) ProblemList java/lang/Float/Binary16Conversion.java in Xcomp mode on x64
>> [JDK-8295380](https://bugs.openjdk.org/browse/JDK-8295380) ProblemList gc/cslocker/TestCSLocker.java in Xcomp mode on x64
>
> Marked as reviewed by alanb (Reviewer).

@AlanBateman - Thanks for the fast review, especially for a Saturday!

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

PR: https://git.openjdk.org/jdk/pull/10719

From dcubed at openjdk.org  Sat Oct 15 14:55:05 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Sat, 15 Oct 2022 14:55:05 GMT
Subject: Integrated: 8295379: ProblemList
 java/lang/Float/Binary16Conversion.java in Xcomp mode on x64
In-Reply-To: <SJFRzF38jWtRYd3G45jQ6C05fEg0gBdgrNpva7xVuHQ=.0fb514db-988d-4300-88af-cbb2efb5bd0c@github.com>
References: <SJFRzF38jWtRYd3G45jQ6C05fEg0gBdgrNpva7xVuHQ=.0fb514db-988d-4300-88af-cbb2efb5bd0c@github.com>
Message-ID: <Mv0YT42iLcGoELHqwuc0QL_I8FKmlQ-ck8VJ7-mO7go=.9abeb394-5b15-498d-96bd-7daf089bb37e@github.com>

On Sat, 15 Oct 2022 14:29:18 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList a couple of tests in -Xcomp mode on generic-x64:
> 
> [JDK-8295379](https://bugs.openjdk.org/browse/JDK-8295379) ProblemList java/lang/Float/Binary16Conversion.java in Xcomp mode on x64
> [JDK-8295380](https://bugs.openjdk.org/browse/JDK-8295380) ProblemList gc/cslocker/TestCSLocker.java in Xcomp mode on x64

This pull request has now been integrated.

Changeset: e7d0ab22
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e7d0ab227ff86bb65abf7fbeb135ce657454200b
Stats:     2 lines in 2 files changed: 1 ins; 0 del; 1 mod

8295379: ProblemList java/lang/Float/Binary16Conversion.java in Xcomp mode on x64
8295380: ProblemList gc/cslocker/TestCSLocker.java in Xcomp mode on x64

Reviewed-by: alanb

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

PR: https://git.openjdk.org/jdk/pull/10719

From dholmes at openjdk.org  Mon Oct 17 02:23:56 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 17 Oct 2022 02:23:56 GMT
Subject: RFR: 8294362: UL: Replace the internal usage of manual buffers
 with stringStream in LogSelection
In-Reply-To: <npn7rbZTY0OkcWjdlsc-Vy974vZneCJLrGUsyMAigQ4=.78ad0c7a-8abb-4966-9acf-bfeba49af9f6@github.com>
References: <mUB0Ir5oWoGxE_mHp3IiZdObb96m4XFF5eFjDWq7IKo=.292a92ed-8957-4ae2-a930-2c942d7f3cc0@github.com>
 <2bAfQEf8_dpaTkD8XXiAZ911GhinAu7_GPN48V0oj30=.dd622fb6-1dfd-476a-86cc-35af2ed1a16b@github.com>
 <OL78g6ZuEUoDv1rnU_yJdg3gJko4oIRNm8WsVad0rBo=.3fcf5f98-b176-4f71-83cf-96ded1a29e0f@github.com>
 <npn7rbZTY0OkcWjdlsc-Vy974vZneCJLrGUsyMAigQ4=.78ad0c7a-8abb-4966-9acf-bfeba49af9f6@github.com>
Message-ID: <ihMJDofYQFFtJaKIm0qLCXtLXwpWFwbbLbeIqugajJM=.1ebafef0-31c2-4026-b469-4282fbc79bcf@github.com>

On Fri, 14 Oct 2022 12:42:38 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> We're not seeing anyone wanting to chime in on this

No, unfortunately the committers who have been very active in this code most recently have not commented on it.

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

PR: https://git.openjdk.org/jdk/pull/10553

From yadongwang at openjdk.org  Mon Oct 17 02:36:53 2022
From: yadongwang at openjdk.org (Yadong Wang)
Date: Mon, 17 Oct 2022 02:36:53 GMT
Subject: RFR: 8295264: Fix PaX check on RISC-V
In-Reply-To: <Djj2_7ZL0rARimJOIpy07-jWSo-xfBbWreb9G0GjOjc=.14dcc827-4735-4136-ac26-391c3175dfa1@github.com>
References: <Djj2_7ZL0rARimJOIpy07-jWSo-xfBbWreb9G0GjOjc=.14dcc827-4735-4136-ac26-391c3175dfa1@github.com>
Message-ID: <X5v2zyf53TVKtZWE_oxVZSpIlPvP6RtWjQhFj98f-Lc=.9e8c2ce9-af33-4813-95b8-426b932e4bf3@github.com>

On Thu, 13 Oct 2022 07:49:55 GMT, Ludovic Henry <luhenry at openjdk.org> wrote:

> On Linux RISC-V, PROT_WRITE doesn't imply PROT_READ [1]
> 
> The fix is to pass PROT_READ|PROT_WRITE. That matches all other calls to mmap in hotspot.
> 
> [1] https://lkml.org/lkml/2022/9/8/1066

>From riscv's point of view, it's fine. (not a reviewer)

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

Marked as reviewed by yadongwang (Author).

PR: https://git.openjdk.org/jdk/pull/10690

From shade at openjdk.org  Mon Oct 17 07:52:29 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 17 Oct 2022 07:52:29 GMT
Subject: RFR: 8295395: Linux Alpha Zero builds fail after JDK-8292591
Message-ID: <U05zrRnWpH_7WCWay3v_GfxCwVAV6ehjUaow2cv1U3U=.a4d42dec-d458-45ec-9633-8552ca6f3aef@github.com>

See bug for details. We can just add the fallback definition in the relevant block.

Additional testing:
 - [x] Linux Alpha Zero fastdebug build (now passes)

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

Commit messages:
 - Fix

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

PR: https://git.openjdk.org/jdk/pull/10721

From stuefe at openjdk.org  Mon Oct 17 08:08:47 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 17 Oct 2022 08:08:47 GMT
Subject: RFR: 8295395: Linux Alpha Zero builds fail after JDK-8292591
In-Reply-To: <U05zrRnWpH_7WCWay3v_GfxCwVAV6ehjUaow2cv1U3U=.a4d42dec-d458-45ec-9633-8552ca6f3aef@github.com>
References: <U05zrRnWpH_7WCWay3v_GfxCwVAV6ehjUaow2cv1U3U=.a4d42dec-d458-45ec-9633-8552ca6f3aef@github.com>
Message-ID: <nItjtvGLfdr6Xlp69ZH9cJfCG5ev54UAaa-q2mpdJuM=.d4c8c154-c778-4093-bf97-cc1ab7f64a73@github.com>

On Mon, 17 Oct 2022 07:44:55 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See bug for details. We can just add the fallback definition in the relevant block.
> 
> Additional testing:
>  - [x] Linux Alpha Zero fastdebug build (now passes)

Is membarrier on alpha not 517?

https://github.com/torvalds/linux/blob/master/arch/alpha/kernel/syscalls/syscall.tbl#L448

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

PR: https://git.openjdk.org/jdk/pull/10721

From fyang at openjdk.org  Mon Oct 17 08:21:03 2022
From: fyang at openjdk.org (Fei Yang)
Date: Mon, 17 Oct 2022 08:21:03 GMT
Subject: RFR: 8295264: Fix PaX check on RISC-V
In-Reply-To: <Djj2_7ZL0rARimJOIpy07-jWSo-xfBbWreb9G0GjOjc=.14dcc827-4735-4136-ac26-391c3175dfa1@github.com>
References: <Djj2_7ZL0rARimJOIpy07-jWSo-xfBbWreb9G0GjOjc=.14dcc827-4735-4136-ac26-391c3175dfa1@github.com>
Message-ID: <hVRHJAf-iDHz85_S1BcsVI3KQ3qo0BgSTLOmKb3Wbdc=.71972128-8f19-4a9a-a118-08f8b45e0058@github.com>

On Thu, 13 Oct 2022 07:49:55 GMT, Ludovic Henry <luhenry at openjdk.org> wrote:

> On Linux RISC-V, PROT_WRITE doesn't imply PROT_READ [1]
> 
> The fix is to pass PROT_READ|PROT_WRITE. That matches all other calls to mmap in hotspot.
> 
> [1] https://lkml.org/lkml/2022/9/8/1066

I see the LKML link mentions this: "Just remove the check altogether and let PROT_WRITE imply PROT_READ as is the case on other architectures.". Is this change still necessary then? Thanks.

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

PR: https://git.openjdk.org/jdk/pull/10690

From luhenry at openjdk.org  Mon Oct 17 08:33:38 2022
From: luhenry at openjdk.org (Ludovic Henry)
Date: Mon, 17 Oct 2022 08:33:38 GMT
Subject: RFR: 8295264: Fix PaX check on RISC-V
In-Reply-To: <hVRHJAf-iDHz85_S1BcsVI3KQ3qo0BgSTLOmKb3Wbdc=.71972128-8f19-4a9a-a118-08f8b45e0058@github.com>
References: <Djj2_7ZL0rARimJOIpy07-jWSo-xfBbWreb9G0GjOjc=.14dcc827-4735-4136-ac26-391c3175dfa1@github.com>
 <hVRHJAf-iDHz85_S1BcsVI3KQ3qo0BgSTLOmKb3Wbdc=.71972128-8f19-4a9a-a118-08f8b45e0058@github.com>
Message-ID: <cYF39Po2RJvKm4Q6uL_RNFqe3C36sRpz970cyqK1xhc=.a5b3bcaf-7484-4667-a0b1-b745584ba9a0@github.com>

On Mon, 17 Oct 2022 08:17:28 GMT, Fei Yang <fyang at openjdk.org> wrote:

> I see the LKML link mentions this: "Just remove the check altogether and let PROT_WRITE imply PROT_READ as is the case on other architectures.". Is this change still necessary then? Thanks.

That would be necessary for any older version of Linux. Also, it allows it to match all other calls to `::mmap` in hotspot.

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

PR: https://git.openjdk.org/jdk/pull/10690

From stuefe at openjdk.org  Mon Oct 17 08:58:10 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 17 Oct 2022 08:58:10 GMT
Subject: RFR: 8293873: Centralize the initialization of UL
In-Reply-To: <t5OgHgQ5ROZvw4tQgIGnF8skH6kMX-b56BF34bbVcJQ=.39d1abb3-7d08-4c45-95ec-772389f5ecdf@github.com>
References: <dtoar0JxoD5Fukir-9tE3mivhVRXuO7-Ckg0N5t9ZdU=.ad9b3ba9-ccf8-4591-af97-dda12a10d9dc@github.com>
 <64dBk9q9MnvwD6Zh4FTp8ASWNhBCKUwEO8bfA2vwYf8=.888197a2-3d6e-4407-81e7-267546c747dc@github.com>
 <54gu66M3RMXXgSJ59A4PK9MJSZl3edv1zm_CprRdWgU=.e6451425-3b77-4598-ad77-f27a61bcb255@github.com>
 <t5OgHgQ5ROZvw4tQgIGnF8skH6kMX-b56BF34bbVcJQ=.39d1abb3-7d08-4c45-95ec-772389f5ecdf@github.com>
Message-ID: <41II87IdPFlqA9LxVZEo-cY4sRokbRYc5OMiFepD3qo=.2820229e-8698-4975-afe1-2f2f3f297e80@github.com>

On Mon, 26 Sep 2022 07:43:10 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > So the time where (a) holds has lengthened, and the time that (b) holds has been shortened.
> 
> I'm surprised that @tstuefe does not object to this. Having some form of UL available during early initialization was a definite requirement from some people, so this seems a backward step in terms of functionality.

I did have vacation :-)

I'll take a look.

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

PR: https://git.openjdk.org/jdk/pull/10307

From fyang at openjdk.org  Mon Oct 17 08:58:57 2022
From: fyang at openjdk.org (Fei Yang)
Date: Mon, 17 Oct 2022 08:58:57 GMT
Subject: RFR: 8295264: Fix PaX check on RISC-V
In-Reply-To: <Djj2_7ZL0rARimJOIpy07-jWSo-xfBbWreb9G0GjOjc=.14dcc827-4735-4136-ac26-391c3175dfa1@github.com>
References: <Djj2_7ZL0rARimJOIpy07-jWSo-xfBbWreb9G0GjOjc=.14dcc827-4735-4136-ac26-391c3175dfa1@github.com>
Message-ID: <u5XpRpBUB2evOgOan6ZTCAGmBcQND6Q3avmxWZOlK_4=.4baed605-4dce-49ea-bd6c-0d663d44e72d@github.com>

On Thu, 13 Oct 2022 07:49:55 GMT, Ludovic Henry <luhenry at openjdk.org> wrote:

> On Linux RISC-V, PROT_WRITE doesn't imply PROT_READ [1]
> 
> The fix is to pass PROT_READ|PROT_WRITE. That matches all other calls to mmap in hotspot.
> 
> [1] https://lkml.org/lkml/2022/9/8/1066

Marked as reviewed by fyang (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10690

From fyang at openjdk.org  Mon Oct 17 08:58:58 2022
From: fyang at openjdk.org (Fei Yang)
Date: Mon, 17 Oct 2022 08:58:58 GMT
Subject: RFR: 8295264: Fix PaX check on RISC-V
In-Reply-To: <cYF39Po2RJvKm4Q6uL_RNFqe3C36sRpz970cyqK1xhc=.a5b3bcaf-7484-4667-a0b1-b745584ba9a0@github.com>
References: <Djj2_7ZL0rARimJOIpy07-jWSo-xfBbWreb9G0GjOjc=.14dcc827-4735-4136-ac26-391c3175dfa1@github.com>
 <hVRHJAf-iDHz85_S1BcsVI3KQ3qo0BgSTLOmKb3Wbdc=.71972128-8f19-4a9a-a118-08f8b45e0058@github.com>
 <cYF39Po2RJvKm4Q6uL_RNFqe3C36sRpz970cyqK1xhc=.a5b3bcaf-7484-4667-a0b1-b745584ba9a0@github.com>
Message-ID: <2sn7qvdjRGplXIJ_9kBuV8XYa9skNNgN1wxEi0hefNI=.7f9243dd-813c-4a17-82d7-ec6336f9d57a@github.com>

On Mon, 17 Oct 2022 08:30:20 GMT, Ludovic Henry <luhenry at openjdk.org> wrote:

> > I see the LKML link mentions this: "Just remove the check altogether and let PROT_WRITE imply PROT_READ as is the case on other architectures.". Is this change still necessary then? Thanks.
> 
> That would be necessary for any older version of Linux. Also, it allows it to match all other calls to `::mmap` in hotspot.

That makes sence to me. Changes looks good to me.

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

PR: https://git.openjdk.org/jdk/pull/10690

From stuefe at openjdk.org  Mon Oct 17 09:11:46 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 17 Oct 2022 09:11:46 GMT
Subject: RFR: 8293873: Centralize the initialization of UL [v2]
In-Reply-To: <x5NoG1WoM-W7-_Cg_P6kqMJJE0E_tv2KxJaBvjRuxUY=.fe7852b8-c68d-478a-9568-eec0a8d1da6e@github.com>
References: <dtoar0JxoD5Fukir-9tE3mivhVRXuO7-Ckg0N5t9ZdU=.ad9b3ba9-ccf8-4591-af97-dda12a10d9dc@github.com>
 <x5NoG1WoM-W7-_Cg_P6kqMJJE0E_tv2KxJaBvjRuxUY=.fe7852b8-c68d-478a-9568-eec0a8d1da6e@github.com>
Message-ID: <1bRP4067zQU0C_NEuhfHgaNtyEjVH7yqt27MWhZ_0ZA=.fe1fde49-86db-4600-84d0-311af6266033@github.com>

On Fri, 23 Sep 2022 10:38:21 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi,
>> 
>> May I please have a review of this change? It moves around some of the initialization code of UL to one place (namely `LogConfiguration::initialize`). It does not change how UL works after VM start up, and it should not change how UL works after VM shut down, but it might change how UL works before VM start up. I don't believe that this causes any breakage.
>> 
>> Tier 2 and 3 tests are currently running, all green so far.
>> 
>> Some more context is available at https://bugs.openjdk.org/browse/JDK-8293873
>
> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright years

All good.

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

Marked as reviewed by stuefe (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10307

From stuefe at openjdk.org  Mon Oct 17 09:15:25 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 17 Oct 2022 09:15:25 GMT
Subject: RFR: 8293873: Centralize the initialization of UL
In-Reply-To: <41II87IdPFlqA9LxVZEo-cY4sRokbRYc5OMiFepD3qo=.2820229e-8698-4975-afe1-2f2f3f297e80@github.com>
References: <dtoar0JxoD5Fukir-9tE3mivhVRXuO7-Ckg0N5t9ZdU=.ad9b3ba9-ccf8-4591-af97-dda12a10d9dc@github.com>
 <64dBk9q9MnvwD6Zh4FTp8ASWNhBCKUwEO8bfA2vwYf8=.888197a2-3d6e-4407-81e7-267546c747dc@github.com>
 <54gu66M3RMXXgSJ59A4PK9MJSZl3edv1zm_CprRdWgU=.e6451425-3b77-4598-ad77-f27a61bcb255@github.com>
 <t5OgHgQ5ROZvw4tQgIGnF8skH6kMX-b56BF34bbVcJQ=.39d1abb3-7d08-4c45-95ec-772389f5ecdf@github.com>
 <41II87IdPFlqA9LxVZEo-cY4sRokbRYc5OMiFepD3qo=.2820229e-8698-4975-afe1-2f2f3f297e80@github.com>
Message-ID: <O1OqoHrrS-TLbMkCF7C1Nda0_fWi-Lr24xP9PNkZP4I=.e4e474b3-1b2a-4546-ae19-8c8010380b9e@github.com>

On Mon, 17 Oct 2022 08:54:27 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> > > So the time where (a) holds has lengthened, and the time that (b) holds has been shortened.
> > 
> > 
> > I'm surprised that @tstuefe does not object to this. Having some form of UL available during early initialization was a definite requirement from some people, so this seems a backward step in terms of functionality.

The change is a good simplification and does not change the fact that UL is quite unusable during early initialization. The important time span (c) does not change. I did not even know about the limited logging option (b).

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

PR: https://git.openjdk.org/jdk/pull/10307

From shade at openjdk.org  Mon Oct 17 09:58:58 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 17 Oct 2022 09:58:58 GMT
Subject: RFR: 8295395: Linux Alpha Zero builds fail after JDK-8292591
In-Reply-To: <nItjtvGLfdr6Xlp69ZH9cJfCG5ev54UAaa-q2mpdJuM=.d4c8c154-c778-4093-bf97-cc1ab7f64a73@github.com>
References: <U05zrRnWpH_7WCWay3v_GfxCwVAV6ehjUaow2cv1U3U=.a4d42dec-d458-45ec-9633-8552ca6f3aef@github.com>
 <nItjtvGLfdr6Xlp69ZH9cJfCG5ev54UAaa-q2mpdJuM=.d4c8c154-c778-4093-bf97-cc1ab7f64a73@github.com>
Message-ID: <KftpBFU65xi4uFrP1cWEOhAGSn6C9y5LBC3Odtm0sC8=.765ad665-8fb7-4812-a7c1-9f851565c022@github.com>

On Mon, 17 Oct 2022 08:05:30 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Is membarrier on alpha not 517?
> 
> https://github.com/torvalds/linux/blob/master/arch/alpha/kernel/syscalls/syscall.tbl#L448

Ha. The direct test shows it is indeed `517` when cross-compiled with modern GCC:


# sudo chroot /chroots/alpha
# cat test.c 
#include <syscall.h>
#include <stdio.h>

void main() {
  printf("%d\n", __NR_membarrier);
}
# gcc test.c 
# ./a.out 
517


So I was looking at `/usr/alpha-linux-gnu/include/asm-generic/unistd.h`, which defines the arch-specific syscalls:


#define __NR_membarrier 283
__SYSCALL(__NR_membarrier, sys_membarrier)


...but there is also a definition in `/usr/alpha-linux-gnu/include/asm/unistd_32.h`:


440:#define __NR_membarrier 517


I guess we should trust `517` here.

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

PR: https://git.openjdk.org/jdk/pull/10721

From dsamersoff at openjdk.org  Mon Oct 17 12:28:45 2022
From: dsamersoff at openjdk.org (Dmitry Samersoff)
Date: Mon, 17 Oct 2022 12:28:45 GMT
Subject: RFR: 8293806: JDK_JAVA_OPTIONS picked up twice if launcher
 re-executes it self
In-Reply-To: <o_7CQY9QGHSXKRvNGPndiAp6M8w_rjDztF30TMU4eqM=.499fd1ac-f0aa-4935-b971-44d67fea49fc@github.com>
References: <o_7CQY9QGHSXKRvNGPndiAp6M8w_rjDztF30TMU4eqM=.499fd1ac-f0aa-4935-b971-44d67fea49fc@github.com>
Message-ID: <kfZsCRtve4_RB2DKhwA09oKGUNWhODifKi_A1FbVrCc=.b5385e3d-755d-4d08-8cbe-af5a7de307f4@github.com>

On Mon, 26 Sep 2022 18:15:17 GMT, Dmitry Samersoff <dsamersoff at openjdk.org> wrote:

> If the user has set LD_LIBRARY_PATH to use a particular libjvm.so, options from the JDK_JAVA_OPTIONS environment variable are picked up twice.
> 
> If an option cannot be accepted twice (e.g., -agentlib), the application fails to start.
> 
> The same happens on operating systems that doesn't support $RPATH/$ORIGIN and always have to set LD_LIBRARY_PATH and re-exec the launcher.
> 
> The fix adds one additional argument - orig_argv to JLI_Launch() and use it in on relaunch in execv() call.
> 
> All relevant jtreg tests are passed.

```JNIEXPORT void JNICALL
JLI_InitArgProcessing(jboolean hasJavaArgs, jboolean disableArgFile) {
    // No expansion for relaunch
    if (argsCount != 1) {
        relaunch = JNI_TRUE;
        stopExpansion = JNI_TRUE;
        argsCount = 1;
    } else {

The code, that set relaunch variable (see above) doesn't really work.

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

PR: https://git.openjdk.org/jdk/pull/10430

From coleenp at openjdk.org  Mon Oct 17 12:35:26 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 17 Oct 2022 12:35:26 GMT
Subject: RFR: 8295278: Add parallel class loading tests [v3]
In-Reply-To: <N0EJgEpX1CoKl3V6qdUrX8MxXt7hD5_J_8-XAAb5a-w=.9e571fc6-974b-410c-bb08-5839e94a1176@github.com>
References: <SgIeM9-sAxxUNWtS7pvU-S5WK0oQ2DduUP7nZFmzNy0=.b9a3d6ba-73fd-43a3-98be-e179af406dd7@github.com>
 <N0EJgEpX1CoKl3V6qdUrX8MxXt7hD5_J_8-XAAb5a-w=.9e571fc6-974b-410c-bb08-5839e94a1176@github.com>
Message-ID: <AmKlkMXBrshmzO0i4DwpxX7qsIhoGIXHA7tZm9zM3uA=.caed3314-7435-4cad-bc25-a1982d15965d@github.com>

On Sat, 15 Oct 2022 01:33:37 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I moved the ParallelLoad test to a subdirectory, and created a new one called CallLoadClass that calls loadClass directly and then waits on the ClassLoader object, while another thread calls forName() to go through the SystemDictionary resolution.
>> 
>> I also made dedicated tests out of the bugs reported in
>> [JDK-4699981](https://bugs.openjdk.org/browse/JDK-4699981) ClassCircularityError thrown without reason during class loading and
>> [JDK-4670071](https://bugs.openjdk.org/browse/JDK-4670071) java.lang.ClassLoader.loadClassInternal(String) is too restrictive
>> 
>> Tested with tier1 on Oracle platforms. These tests are run in tier1.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/hotspot/jtreg/runtime/ParallelLoad/SuperWait/test-classes/A.java
>   
>   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

Thank you Vladimir and Calvin for the reviews, and @turbanoff for the suggestion to remove the unneeded space.

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

PR: https://git.openjdk.org/jdk/pull/10587

From coleenp at openjdk.org  Mon Oct 17 12:35:26 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 17 Oct 2022 12:35:26 GMT
Subject: Integrated: 8295278: Add parallel class loading tests
In-Reply-To: <SgIeM9-sAxxUNWtS7pvU-S5WK0oQ2DduUP7nZFmzNy0=.b9a3d6ba-73fd-43a3-98be-e179af406dd7@github.com>
References: <SgIeM9-sAxxUNWtS7pvU-S5WK0oQ2DduUP7nZFmzNy0=.b9a3d6ba-73fd-43a3-98be-e179af406dd7@github.com>
Message-ID: <pcMP4INiLW1XSkhMPvwuRnyNAch62wYOebcCM2AltcU=.0fb7d259-859f-4225-ae7f-822ea96b0fd9@github.com>

On Wed, 5 Oct 2022 22:53:48 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> I moved the ParallelLoad test to a subdirectory, and created a new one called CallLoadClass that calls loadClass directly and then waits on the ClassLoader object, while another thread calls forName() to go through the SystemDictionary resolution.
> 
> I also made dedicated tests out of the bugs reported in
> [JDK-4699981](https://bugs.openjdk.org/browse/JDK-4699981) ClassCircularityError thrown without reason during class loading and
> [JDK-4670071](https://bugs.openjdk.org/browse/JDK-4670071) java.lang.ClassLoader.loadClassInternal(String) is too restrictive
> 
> Tested with tier1 on Oracle platforms. These tests are run in tier1.

This pull request has now been integrated.

Changeset: 5d273b9f
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5d273b9f040a9884e2ae5b0f1409a3f9075c51c9
Stats:     733 lines in 23 files changed: 731 ins; 0 del; 2 mod

8295278: Add parallel class loading tests

Reviewed-by: vlivanov, ccheung

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

PR: https://git.openjdk.org/jdk/pull/10587

From coleenp at openjdk.org  Mon Oct 17 12:43:45 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 17 Oct 2022 12:43:45 GMT
Subject: RFR: 8295029: runtime/cds/appcds/LotsOfClasses.java fail with jfx
Message-ID: <Q9zXbTPMiOsu-e3Wd2EsBAC7a6cwoxyn0a_ATFyMJT0=.a4978796-143b-4ed3-9c76-b3c4dce3629c@github.com>

This removes the can-resize parameter for ClassLoaderData dictionaries. They can all resize now that the shared dictionaries are moved to the CompactHashtable. This also removes an unused/untested development option to disallow resizing.
Tested with tiers1-4 and tested with the failing test case. It can't be added because it requires outside code or simulated because it would be an expensive test to generate all those class files.  There's an existing test for resizing.

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

Commit messages:
 - 8295029: runtime/cds/appcds/LotsOfClasses.java fail with jfx

Changes: https://git.openjdk.org/jdk/pull/10708/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10708&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295029
  Stats: 19 lines in 4 files changed: 0 ins; 12 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/10708.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10708/head:pull/10708

PR: https://git.openjdk.org/jdk/pull/10708

From lzhai at openjdk.org  Mon Oct 17 12:43:45 2022
From: lzhai at openjdk.org (Leslie Zhai)
Date: Mon, 17 Oct 2022 12:43:45 GMT
Subject: RFR: 8295029: runtime/cds/appcds/LotsOfClasses.java fail with jfx
In-Reply-To: <Q9zXbTPMiOsu-e3Wd2EsBAC7a6cwoxyn0a_ATFyMJT0=.a4978796-143b-4ed3-9c76-b3c4dce3629c@github.com>
References: <Q9zXbTPMiOsu-e3Wd2EsBAC7a6cwoxyn0a_ATFyMJT0=.a4978796-143b-4ed3-9c76-b3c4dce3629c@github.com>
Message-ID: <GH9MoC5jCr3741VXH6PWGcKchTQk9ANYPLjEfd0a7M8=.ff1fd49b-4b28-489e-9d9d-ba973f0d51be@github.com>

On Fri, 14 Oct 2022 02:27:01 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This removes the can-resize parameter for ClassLoaderData dictionaries. They can all resize now that the shared dictionaries are moved to the CompactHashtable. This also removes an unused/untested development option to disallow resizing.
> Tested with tiers1-4 and tested with the failing test case. It can't be added because it requires outside code or simulated because it would be an expensive test to generate all those class files.  There's an existing test for resizing.

> I still have to write a test case.

Yes, the testcase needs to simulate a large number of (about 60189 - 49191) classes just like import javafx modular.

Thanks,
Leslie Zhai

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

PR: https://git.openjdk.org/jdk/pull/10708

From shade at openjdk.org  Mon Oct 17 13:26:40 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 17 Oct 2022 13:26:40 GMT
Subject: RFR: 8295395: Linux Alpha Zero builds fail after JDK-8292591 [v2]
In-Reply-To: <U05zrRnWpH_7WCWay3v_GfxCwVAV6ehjUaow2cv1U3U=.a4d42dec-d458-45ec-9633-8552ca6f3aef@github.com>
References: <U05zrRnWpH_7WCWay3v_GfxCwVAV6ehjUaow2cv1U3U=.a4d42dec-d458-45ec-9633-8552ca6f3aef@github.com>
Message-ID: <OKVTy09Wx6zqF3hN2N025U5CRu83pUjqWa61xQNdCdk=.b3736a4c-bb20-463d-ae2a-7142a1f5d792@github.com>

> See bug for details. We can just add the fallback definition in the relevant block.
> 
> Additional testing:
>  - [x] Linux Alpha Zero fastdebug build (now passes)

Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Use 517
 - Merge branch 'master' into JDK-8295395-alpha-gcc6
 - Fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10721/files
  - new: https://git.openjdk.org/jdk/pull/10721/files/941afd2a..24eb5fb0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10721&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10721&range=00-01

  Stats: 225 lines in 14 files changed: 180 ins; 16 del; 29 mod
  Patch: https://git.openjdk.org/jdk/pull/10721.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10721/head:pull/10721

PR: https://git.openjdk.org/jdk/pull/10721

From mbaesken at openjdk.org  Mon Oct 17 13:28:25 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 17 Oct 2022 13:28:25 GMT
Subject: RFR: JDK-8295412 : support latest VS2022 MSC_VER in
 abstract_vm_version.cpp
Message-ID: <2fCXFv9XHrDnz6y9X7MKpOweXWDbOpjpkBFB87LfEdE=.949d476d-7168-4abc-b5ff-7aefcb45e689@github.com>

Currently the latest VS2022 versions are not supported when checking _MSC_VER in abstract_vm_version.cpp, that should be improved.
See
https://learn.microsoft.com/en-us/cpp/preprocessor/predefined-macros?view=msvc-170
https://learn.microsoft.com/de-de/visualstudio/install/visual-studio-build-numbers-and-release-dates?view=vs-2022
Visual Studio 2022 version 17.3 1933
Visual Studio 2022 version 17.2 1932

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

Commit messages:
 - JDK-8295412

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

PR: https://git.openjdk.org/jdk/pull/10727

From shade at openjdk.org  Mon Oct 17 13:40:23 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 17 Oct 2022 13:40:23 GMT
Subject: RFR: 8294594: Fix cast-function-type warnings in signal handling
 code [v3]
In-Reply-To: <Fp96nMrtVhISqFOO67MmNGQPoKyUKV9jgPFtGkoTzt0=.3436f114-0877-4513-91f7-4b611ebd8c8b@github.com>
References: <Fp96nMrtVhISqFOO67MmNGQPoKyUKV9jgPFtGkoTzt0=.3436f114-0877-4513-91f7-4b611ebd8c8b@github.com>
Message-ID: <wOwAcasbkjXaIE6ke1Yp7cMRXdjbqo2sJspN_CeNm3k=.63b98484-ac36-46de-9887-d2f9e4bb6ede@github.com>

> After [JDK-8294314](https://bugs.openjdk.org/browse/JDK-8294314), we would have signals_posix.cpp excluded with cast-function-type warning:

Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:

 - Merge branch 'master' into JDK-8294594-warning-cast-function-type-signals
 - Naming
 - Redo using the proper signatures
 - Merge branch 'master' into JDK-8294594-warning-cast-function-type-signals
 - Fix

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

Changes: https://git.openjdk.org/jdk/pull/10494/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10494&range=02
  Stats: 10 lines in 4 files changed: 0 ins; 2 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/10494.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10494/head:pull/10494

PR: https://git.openjdk.org/jdk/pull/10494

From shade at openjdk.org  Mon Oct 17 13:46:48 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 17 Oct 2022 13:46:48 GMT
Subject: RFR: 8294594: Fix cast-function-type warnings in signal handling
 code [v3]
In-Reply-To: <wOwAcasbkjXaIE6ke1Yp7cMRXdjbqo2sJspN_CeNm3k=.63b98484-ac36-46de-9887-d2f9e4bb6ede@github.com>
References: <Fp96nMrtVhISqFOO67MmNGQPoKyUKV9jgPFtGkoTzt0=.3436f114-0877-4513-91f7-4b611ebd8c8b@github.com>
 <wOwAcasbkjXaIE6ke1Yp7cMRXdjbqo2sJspN_CeNm3k=.63b98484-ac36-46de-9887-d2f9e4bb6ede@github.com>
Message-ID: <VFPpswrGh6Ime5XRVhjxlIe8knmxj6tiP1YA0s76dkk=.5a5d9d17-2759-43b3-9b26-fff9073e2145@github.com>

On Mon, 17 Oct 2022 13:40:23 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> After [JDK-8294314](https://bugs.openjdk.org/browse/JDK-8294314), we would have signals_posix.cpp excluded with cast-function-type warning:
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge branch 'master' into JDK-8294594-warning-cast-function-type-signals
>  - Naming
>  - Redo using the proper signatures
>  - Merge branch 'master' into JDK-8294594-warning-cast-function-type-signals
>  - Fix

Build system changes now merged with upstream (look how nice they are). Ready to integrate.

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

PR: https://git.openjdk.org/jdk/pull/10494

From jpai at openjdk.org  Mon Oct 17 14:03:50 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 17 Oct 2022 14:03:50 GMT
Subject: RFR: 8030616: sun/management/jmxremote/bootstrap/RmiBootstrapTest
 fails intermittently with cannot find a free port
In-Reply-To: <txAkFc8XUg5T6ZiUjY2oP6NkB77JNeUJLfd26kySiRw=.88881c4f-1cb6-4171-ae11-75ad46e5cb25@github.com>
References: <txAkFc8XUg5T6ZiUjY2oP6NkB77JNeUJLfd26kySiRw=.88881c4f-1cb6-4171-ae11-75ad46e5cb25@github.com>
Message-ID: <kV_rKhrYtDEsLIFsCJ8fJqyLWt-nbjt-MlimSSn8ujY=.58e94369-7166-4bc8-a2f6-84b3d4fd92b4@github.com>

On Sun, 18 Sep 2022 11:52:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test only change which proposes to fix the recent intermittent failures in `RmiBootstrapTest` reported in https://bugs.openjdk.org/browse/JDK-8030616?
> 
> The test has been intermittently failing with `cannot find a free port after 10 tries`.  The tests uses the `jdk.test.lib.Utils.getFreePort()` utility method to get a free port to use in the tests. That port is then used to create and bind a JMX connector server. The issue resides in the fact that the `getFreePort` utility uses loopback address to identify a free port, whereas the JMX connector server uses that identified port to bind to a non-loopback address - there's logic in `sun.rmi.transport.tcp.TCPEndpoint` line 117 which calls `InetAddress.getLocalHost()` which can and does return a non-loopback address. This effectively means that the port that was identified as free (on loopback) may not really be free on (some other address) and a subsequent attempt to bind against it by the connector server will end up with a `BindException`.
> 
> Data collected in failures on the CI system has shown that this is indeed the case and the port that was chosen (for loopback) as free was already used by another process on a different address. The test additionally has logic to attempt retries upto a maximum of 10 times to find a new free port on such `BindException`. Turns out the next free port (on loopback) returned by `jdk.test.lib.Utils.getFreePort()` is incremental and it so happens that the systems where this failed had a process listening on a range of 10 to 12 ports, so these too ended up with `BindException` when the JMX connector server used that port for a different address.
> 
> The commit here makes sure that the JMX connector server in the test is now configured to loopback address as the address to bind to. That way the test uses the correct address (loopback) on which the port was free.
> 
> The commit also has a change to the javadoc of the test utility `jdk.test.lib.Utils.getFreePort()` to clarify that it returns a free port on loopback address. This now matches what the implementation of that method does.
> 
> Multiple test runs after this change hasn't yet run into the failure.

Please keep open. Waiting for reviews on this one.

Mark and me ran some experiments related to this issue and we did conclude that this change will help the issue at hand. @msheppar, please correct me if that's not an accurate summary.

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

PR: https://git.openjdk.org/jdk/pull/10322

From stuefe at openjdk.org  Mon Oct 17 14:53:06 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 17 Oct 2022 14:53:06 GMT
Subject: RFR: 8295395: Linux Alpha Zero builds fail after JDK-8292591 [v2]
In-Reply-To: <OKVTy09Wx6zqF3hN2N025U5CRu83pUjqWa61xQNdCdk=.b3736a4c-bb20-463d-ae2a-7142a1f5d792@github.com>
References: <U05zrRnWpH_7WCWay3v_GfxCwVAV6ehjUaow2cv1U3U=.a4d42dec-d458-45ec-9633-8552ca6f3aef@github.com>
 <OKVTy09Wx6zqF3hN2N025U5CRu83pUjqWa61xQNdCdk=.b3736a4c-bb20-463d-ae2a-7142a1f5d792@github.com>
Message-ID: <QM8n8YWk2SNIMiz1B-gBHeawu2WJ0t2xb8WqyQVvfz8=.8c24cf94-495b-41f1-9cd9-e1e834d23b38@github.com>

On Mon, 17 Oct 2022 13:26:40 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See bug for details. We can just add the fallback definition in the relevant block.
>> 
>> Additional testing:
>>  - [x] Linux Alpha Zero fastdebug build (now passes)
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Use 517
>  - Merge branch 'master' into JDK-8295395-alpha-gcc6
>  - Fix

Good and trivial.

Cheers, Thomas

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

Marked as reviewed by stuefe (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10721

From shade at openjdk.org  Mon Oct 17 18:00:26 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 17 Oct 2022 18:00:26 GMT
Subject: RFR: 8295395: Linux Alpha Zero builds fail after JDK-8292591 [v2]
In-Reply-To: <OKVTy09Wx6zqF3hN2N025U5CRu83pUjqWa61xQNdCdk=.b3736a4c-bb20-463d-ae2a-7142a1f5d792@github.com>
References: <U05zrRnWpH_7WCWay3v_GfxCwVAV6ehjUaow2cv1U3U=.a4d42dec-d458-45ec-9633-8552ca6f3aef@github.com>
 <OKVTy09Wx6zqF3hN2N025U5CRu83pUjqWa61xQNdCdk=.b3736a4c-bb20-463d-ae2a-7142a1f5d792@github.com>
Message-ID: <rHG4Y1yViTvq56UthNcW3TzEZLN1qg4EpHE6MmmIb2g=.a619e8fb-c8d0-46d7-8416-440858a3c835@github.com>

On Mon, 17 Oct 2022 13:26:40 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See bug for details. We can just add the fallback definition in the relevant block.
>> 
>> Additional testing:
>>  - [x] Linux Alpha Zero fastdebug build (now passes)
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Use 517
>  - Merge branch 'master' into JDK-8295395-alpha-gcc6
>  - Fix

Thanks!

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

PR: https://git.openjdk.org/jdk/pull/10721

From shade at openjdk.org  Mon Oct 17 18:00:27 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 17 Oct 2022 18:00:27 GMT
Subject: Integrated: 8295395: Linux Alpha Zero builds fail after JDK-8292591
In-Reply-To: <U05zrRnWpH_7WCWay3v_GfxCwVAV6ehjUaow2cv1U3U=.a4d42dec-d458-45ec-9633-8552ca6f3aef@github.com>
References: <U05zrRnWpH_7WCWay3v_GfxCwVAV6ehjUaow2cv1U3U=.a4d42dec-d458-45ec-9633-8552ca6f3aef@github.com>
Message-ID: <KD6zQfm_bAQWDGO9h2cnTu_XzEsLd0n6tiJ_0_bILLY=.ba449eca-99d3-4e4d-aa4c-2cf629296118@github.com>

On Mon, 17 Oct 2022 07:44:55 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See bug for details. We can just add the fallback definition in the relevant block.
> 
> Additional testing:
>  - [x] Linux Alpha Zero fastdebug build (now passes)

This pull request has now been integrated.

Changeset: b269c51d
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b269c51d10c353d9b7143b2239beb23c01352182
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8295395: Linux Alpha Zero builds fail after JDK-8292591

Reviewed-by: stuefe

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

PR: https://git.openjdk.org/jdk/pull/10721

From kbarrett at openjdk.org  Mon Oct 17 20:18:02 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 17 Oct 2022 20:18:02 GMT
Subject: RFR: 8295124: Atomic::add to pointer type may return wrong value
 [v2]
In-Reply-To: <pLyuIraAHIPX4fT5YJG14TSjcoETKZbazFG8EBq3YjI=.3ad05410-1860-4a92-8ae7-a28599f80e26@github.com>
References: <8MVHNI6FliDXtf6MFWwrL9cj3o_VaM98dPj_TuRgkWI=.83b5aee8-f553-48fa-9d86-80d5d54a5a5e@github.com>
 <pLyuIraAHIPX4fT5YJG14TSjcoETKZbazFG8EBq3YjI=.3ad05410-1860-4a92-8ae7-a28599f80e26@github.com>
Message-ID: <321M4ZmND-62GI4tZCDoRGxo_kWWJSNXppL43nfjZjk=.c6b3a42c-cc04-4c2e-b8c4-f7ed46a7f397@github.com>

On Wed, 12 Oct 2022 20:38:10 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to the handling of Atomic pointer arithmetic. When
>> the value being modified is a pointer `P*`, the type of the value in the
>> destination passed to the platform operation is `const char*`, so a pointer
>> type whose pointee is size 1. This allows the platform operation to just treat
>> the arithmetic as a simple byte adjustment.
>> 
>> To demonstrate the problem described in the bug (possible incorrect result for
>> Atomic pointer arithmetic) and show that it is now fixed, this change also
>> includes some gtests for Atomic operations, including pointer arithmetic which
>> fails before the change and succeeds after.
>> 
>> Testing: mach5 tier1-3
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   conditionalize 64bit tests on 64bit platform

Poke - any takers.

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

PR: https://git.openjdk.org/jdk/pull/10667

From iklam at openjdk.org  Mon Oct 17 20:35:59 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 17 Oct 2022 20:35:59 GMT
Subject: RFR: 8295029: runtime/cds/appcds/LotsOfClasses.java fail with jfx
In-Reply-To: <Q9zXbTPMiOsu-e3Wd2EsBAC7a6cwoxyn0a_ATFyMJT0=.a4978796-143b-4ed3-9c76-b3c4dce3629c@github.com>
References: <Q9zXbTPMiOsu-e3Wd2EsBAC7a6cwoxyn0a_ATFyMJT0=.a4978796-143b-4ed3-9c76-b3c4dce3629c@github.com>
Message-ID: <710Rv-Kv5AuWr1D1FrFqwD51KHtX9s-J5cvrswqO758=.550289a5-4e38-47c3-9ada-20daefbe170a@github.com>

On Fri, 14 Oct 2022 02:27:01 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This removes the can-resize parameter for ClassLoaderData dictionaries. They can all resize now that the shared dictionaries are moved to the CompactHashtable. This also removes an unused/untested development option to disallow resizing.
> Tested with tiers1-4 and tested with the failing test case. It can't be added because it requires outside code or simulated because it would be an expensive test to generate all those class files.  There's an existing test for resizing.

LGTM. I agree that if the test is too hard to write (it depends on the exact names of classes being loaded) then we can skip it, because the code change is pretty simple -- it removes a special case for `java -Xshare:dump`. The effect of the removal will be tested by all the tests that dumps a CDS archive.

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

Marked as reviewed by iklam (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10708

From iklam at openjdk.org  Mon Oct 17 22:21:07 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 17 Oct 2022 22:21:07 GMT
Subject: RFR: 8279366: CDS should allow alternative locations for JAR files
 in classpath [v2]
In-Reply-To: <vE4QFnE0HK7b-rn5jcY1uK3x7Cv62luelsIgLhFEA5o=.3bf5a547-bc67-418b-8639-c7d0117f3860@github.com>
References: <gjn5N9Lmavel1A8AHZFHxbp0J2l6XklY_-Pr-N04k7g=.dd8b5ed1-2c55-40cf-88e1-770e16c4c911@github.com>
 <vE4QFnE0HK7b-rn5jcY1uK3x7Cv62luelsIgLhFEA5o=.3bf5a547-bc67-418b-8639-c7d0117f3860@github.com>
Message-ID: <ZbA9QYoEqgHjkiWM8qFt42H_dJ1jGoo86UDPAfQkAhk=.c40adf49-980c-4f95-b705-a19f05d57a4f@github.com>

On Fri, 14 Oct 2022 16:51:10 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Please review this RFE for allowing alternative locations for jar files in the app classpath during runtime.
>> 
>> During dump time, the longest common prefix of the app classpath will be stored in the CDS archive header. During runtime, existing checks of the app classpath will be performed first. Upon failure, the longest common prefix of the runtime app classpath will be computed and another check of the app classpath will be performed ignoring the longest common prefix.
>> 
>> Refer to the [bug report comment](https://bugs.openjdk.org/browse/JDK-8279366?focusedCommentId=14509536&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14509536) for an example.
>> 
>> Passed tiers 1 - 4 testing (including the new tests).
>
> Calvin Cheung 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 four additional commits since the last revision:
> 
>  - not storing the common app path string in the archive header
>  - Merge branch 'master' into 8279366-longest-common-prefix
>  - remove trailing whitespace
>  - 8279366: CDS should allow alternative locations for JAR files in classpath

Changes requested by iklam (Reviewer).

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

> 206:   size_t base_archive_name_offset = 0;
> 207:   size_t longest_common_prefix_size = 0;
> 208:   size_t longest_common_prefix_offset = 0;

This variable can also be removed.

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

> 885: }
> 886: 
> 887: bool FileMapInfo::check_paths_ignoring_common_path(int shared_path_start_idx, int num_paths,

I think we should use the word "prefix" in the names. This way, it's clear that we are talking about a portion of a path string. How about `check_paths_ignoring_common_prefix`?

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

> 1031:     if (mismatch) {
> 1032:       unsigned int dumptime_prefix_len = header()->common_app_classpath_size();
> 1033:       unsigned int runtime_prefix_len = longest_common_app_classpath_len(shared_app_paths_len, rp_array);

How about `header()->common_app_classpath_prefix_size()` and `longest_common_app_classpath_prefix_len`?

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

> 1278:     }
> 1279: 
> 1280:     if (!check_common_app_classpath()) {

How about `check_common_app_classpath_prefix_len()`?

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

PR: https://git.openjdk.org/jdk/pull/10615

From dholmes at openjdk.org  Tue Oct 18 00:57:00 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 18 Oct 2022 00:57:00 GMT
Subject: RFR: 8293806: JDK_JAVA_OPTIONS picked up twice if launcher
 re-executes it self
In-Reply-To: <o_7CQY9QGHSXKRvNGPndiAp6M8w_rjDztF30TMU4eqM=.499fd1ac-f0aa-4935-b971-44d67fea49fc@github.com>
References: <o_7CQY9QGHSXKRvNGPndiAp6M8w_rjDztF30TMU4eqM=.499fd1ac-f0aa-4935-b971-44d67fea49fc@github.com>
Message-ID: <xtgCou5OFQ62FUeMpMfIKzACvc2RfMvQVX97xIGcobI=.8d01d998-f5ef-43fa-a78b-8b968bed27e2@github.com>

On Mon, 26 Sep 2022 18:15:17 GMT, Dmitry Samersoff <dsamersoff at openjdk.org> wrote:

> If the user has set LD_LIBRARY_PATH to use a particular libjvm.so, options from the JDK_JAVA_OPTIONS environment variable are picked up twice.
> 
> If an option cannot be accepted twice (e.g., -agentlib), the application fails to start.
> 
> The same happens on operating systems that doesn't support $RPATH/$ORIGIN and always have to set LD_LIBRARY_PATH and re-exec the launcher.
> 
> The fix adds one additional argument - orig_argv to JLI_Launch() and use it in on relaunch in execv() call.
> 
> All relevant jtreg tests are passed.

Then can we fix the use of `relaunch` if it isn't working?

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

PR: https://git.openjdk.org/jdk/pull/10430

From dholmes at openjdk.org  Tue Oct 18 01:54:45 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 18 Oct 2022 01:54:45 GMT
Subject: RFR: 8294594: Fix cast-function-type warnings in signal handling
 code [v3]
In-Reply-To: <wOwAcasbkjXaIE6ke1Yp7cMRXdjbqo2sJspN_CeNm3k=.63b98484-ac36-46de-9887-d2f9e4bb6ede@github.com>
References: <Fp96nMrtVhISqFOO67MmNGQPoKyUKV9jgPFtGkoTzt0=.3436f114-0877-4513-91f7-4b611ebd8c8b@github.com>
 <wOwAcasbkjXaIE6ke1Yp7cMRXdjbqo2sJspN_CeNm3k=.63b98484-ac36-46de-9887-d2f9e4bb6ede@github.com>
Message-ID: <cgI4Uv-g3yJfQ7P2v1i5kOCzSVv1mZDRqXUxLhQC6gk=.fc3c2062-d63b-47ce-a602-c0539f748817@github.com>

On Mon, 17 Oct 2022 13:40:23 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> After [JDK-8294314](https://bugs.openjdk.org/browse/JDK-8294314), we would have signals_posix.cpp excluded with cast-function-type warning:
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge branch 'master' into JDK-8294594-warning-cast-function-type-signals
>  - Naming
>  - Redo using the proper signatures
>  - Merge branch 'master' into JDK-8294594-warning-cast-function-type-signals
>  - Fix

Marked as reviewed by dholmes (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10494

From dholmes at openjdk.org  Tue Oct 18 02:08:09 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 18 Oct 2022 02:08:09 GMT
Subject: RFR: JDK-8295412 : support latest VS2022 MSC_VER in
 abstract_vm_version.cpp
In-Reply-To: <2fCXFv9XHrDnz6y9X7MKpOweXWDbOpjpkBFB87LfEdE=.949d476d-7168-4abc-b5ff-7aefcb45e689@github.com>
References: <2fCXFv9XHrDnz6y9X7MKpOweXWDbOpjpkBFB87LfEdE=.949d476d-7168-4abc-b5ff-7aefcb45e689@github.com>
Message-ID: <LT3LhNQNqUJ4lcrypL-coeE6jhBDBjg4splNkFpm9zE=.c978ddc2-c463-4b51-8ff5-4bfbafa1fda5@github.com>

On Mon, 17 Oct 2022 13:19:48 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently the latest VS2022 versions are not supported when checking _MSC_VER in abstract_vm_version.cpp, that should be improved.
> See
> https://learn.microsoft.com/en-us/cpp/preprocessor/predefined-macros?view=msvc-170
> https://learn.microsoft.com/de-de/visualstudio/install/visual-studio-build-numbers-and-release-dates?view=vs-2022
> Visual Studio 2022 version 17.3 1933
> Visual Studio 2022 version 17.2 1932

Looks fine and trivial.

It is so annoying we need to do this. :(

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10727

From lucy at openjdk.org  Tue Oct 18 07:45:07 2022
From: lucy at openjdk.org (Lutz Schmidt)
Date: Tue, 18 Oct 2022 07:45:07 GMT
Subject: RFR: JDK-8295412 : support latest VS2022 MSC_VER in
 abstract_vm_version.cpp
In-Reply-To: <2fCXFv9XHrDnz6y9X7MKpOweXWDbOpjpkBFB87LfEdE=.949d476d-7168-4abc-b5ff-7aefcb45e689@github.com>
References: <2fCXFv9XHrDnz6y9X7MKpOweXWDbOpjpkBFB87LfEdE=.949d476d-7168-4abc-b5ff-7aefcb45e689@github.com>
Message-ID: <Ogp1pvFAVegUu2xVznC7pGDHvj3faAceJSjwlAOIxFA=.e6400d3a-a2fc-47b3-9665-3cde57bcf769@github.com>

On Mon, 17 Oct 2022 13:19:48 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently the latest VS2022 versions are not supported when checking _MSC_VER in abstract_vm_version.cpp, that should be improved.
> See
> https://learn.microsoft.com/en-us/cpp/preprocessor/predefined-macros?view=msvc-170
> https://learn.microsoft.com/de-de/visualstudio/install/visual-studio-build-numbers-and-release-dates?view=vs-2022
> Visual Studio 2022 version 17.3 1933
> Visual Studio 2022 version 17.2 1932

LGTM.

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

Marked as reviewed by lucy (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10727

From mbaesken at openjdk.org  Tue Oct 18 07:45:07 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 18 Oct 2022 07:45:07 GMT
Subject: RFR: JDK-8295412 : support latest VS2022 MSC_VER in
 abstract_vm_version.cpp
In-Reply-To: <2fCXFv9XHrDnz6y9X7MKpOweXWDbOpjpkBFB87LfEdE=.949d476d-7168-4abc-b5ff-7aefcb45e689@github.com>
References: <2fCXFv9XHrDnz6y9X7MKpOweXWDbOpjpkBFB87LfEdE=.949d476d-7168-4abc-b5ff-7aefcb45e689@github.com>
Message-ID: <jKmkihqeUAZ2Mcu8zU2LkGQT6cl3rKI_DnJw662qXgA=.8ad66a37-5308-43dc-9303-42e66e7f8ea5@github.com>

On Mon, 17 Oct 2022 13:19:48 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently the latest VS2022 versions are not supported when checking _MSC_VER in abstract_vm_version.cpp, that should be improved.
> See
> https://learn.microsoft.com/en-us/cpp/preprocessor/predefined-macros?view=msvc-170
> https://learn.microsoft.com/de-de/visualstudio/install/visual-studio-build-numbers-and-release-dates?view=vs-2022
> Visual Studio 2022 version 17.3 1933
> Visual Studio 2022 version 17.2 1932

Hi  David and Lutz, thanks for the reviews !

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

PR: https://git.openjdk.org/jdk/pull/10727

From mbaesken at openjdk.org  Tue Oct 18 07:47:04 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 18 Oct 2022 07:47:04 GMT
Subject: Integrated: JDK-8295412 : support latest VS2022 MSC_VER in
 abstract_vm_version.cpp
In-Reply-To: <2fCXFv9XHrDnz6y9X7MKpOweXWDbOpjpkBFB87LfEdE=.949d476d-7168-4abc-b5ff-7aefcb45e689@github.com>
References: <2fCXFv9XHrDnz6y9X7MKpOweXWDbOpjpkBFB87LfEdE=.949d476d-7168-4abc-b5ff-7aefcb45e689@github.com>
Message-ID: <g86uulwHi0lAeUzRyA9cKIh0Js3DYnA5E_u5BbQxU44=.388034df-b72d-4370-947e-9e243f092bc3@github.com>

On Mon, 17 Oct 2022 13:19:48 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently the latest VS2022 versions are not supported when checking _MSC_VER in abstract_vm_version.cpp, that should be improved.
> See
> https://learn.microsoft.com/en-us/cpp/preprocessor/predefined-macros?view=msvc-170
> https://learn.microsoft.com/de-de/visualstudio/install/visual-studio-build-numbers-and-release-dates?view=vs-2022
> Visual Studio 2022 version 17.3 1933
> Visual Studio 2022 version 17.2 1932

This pull request has now been integrated.

Changeset: bca7ab3c
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bca7ab3c1109e6cff9b50ecdd3045cb0ae8f6953
Stats:     4 lines in 1 file changed: 4 ins; 0 del; 0 mod

8295412: support latest VS2022 MSC_VER in abstract_vm_version.cpp

Reviewed-by: dholmes, lucy

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

PR: https://git.openjdk.org/jdk/pull/10727

From shade at openjdk.org  Tue Oct 18 08:50:18 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 18 Oct 2022 08:50:18 GMT
Subject: Integrated: 8294594: Fix cast-function-type warnings in signal
 handling code
In-Reply-To: <Fp96nMrtVhISqFOO67MmNGQPoKyUKV9jgPFtGkoTzt0=.3436f114-0877-4513-91f7-4b611ebd8c8b@github.com>
References: <Fp96nMrtVhISqFOO67MmNGQPoKyUKV9jgPFtGkoTzt0=.3436f114-0877-4513-91f7-4b611ebd8c8b@github.com>
Message-ID: <PDWZ1TRaf3PCjbTxrC8vTUpDl4udVa00xKg_Ap_Xt6k=.9dafe0fd-9145-4b90-b4c0-b5c8c19e36a9@github.com>

On Thu, 29 Sep 2022 16:12:11 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> After [JDK-8294314](https://bugs.openjdk.org/browse/JDK-8294314), we would have signals_posix.cpp excluded with cast-function-type warning:

This pull request has now been integrated.

Changeset: b06f1b14
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b06f1b149c8f8a49d4e42c4b782a4b3a22aa79f6
Stats:     10 lines in 4 files changed: 0 ins; 2 del; 8 mod

8294594: Fix cast-function-type warnings in signal handling code

Reviewed-by: dholmes, kbarrett

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

PR: https://git.openjdk.org/jdk/pull/10494

From luhenry at openjdk.org  Tue Oct 18 09:53:06 2022
From: luhenry at openjdk.org (Ludovic Henry)
Date: Tue, 18 Oct 2022 09:53:06 GMT
Subject: Integrated: 8295264: Fix PaX check on RISC-V
In-Reply-To: <Djj2_7ZL0rARimJOIpy07-jWSo-xfBbWreb9G0GjOjc=.14dcc827-4735-4136-ac26-391c3175dfa1@github.com>
References: <Djj2_7ZL0rARimJOIpy07-jWSo-xfBbWreb9G0GjOjc=.14dcc827-4735-4136-ac26-391c3175dfa1@github.com>
Message-ID: <xeU53stHMaZr05IQKpj5Hu4dGrqetLaj2_f8c_Kh-io=.1814b111-6cf2-45dc-9b47-fab5099632cb@github.com>

On Thu, 13 Oct 2022 07:49:55 GMT, Ludovic Henry <luhenry at openjdk.org> wrote:

> On Linux RISC-V, PROT_WRITE doesn't imply PROT_READ [1]
> 
> The fix is to pass PROT_READ|PROT_WRITE. That matches all other calls to mmap in hotspot.
> 
> [1] https://lkml.org/lkml/2022/9/8/1066

This pull request has now been integrated.

Changeset: 4434cbb7
Author:    Ludovic Henry <luhenry at openjdk.org>
Committer: Fei Yang <fyang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4434cbb719db37880b48474ba342f300ed4828a8
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8295264: Fix PaX check on RISC-V

Reviewed-by: yadongwang, fyang

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

PR: https://git.openjdk.org/jdk/pull/10690

From jsjolen at openjdk.org  Tue Oct 18 11:48:09 2022
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 18 Oct 2022 11:48:09 GMT
Subject: RFR: 8291714: Implement a Multi-Reader Single-Writer mutex for
 Hotspot [v4]
In-Reply-To: <SPVZ6SM0l47L0EL9Uot7d1Av9HNHfy6AAGs77cPoUR4=.2c74d74c-868b-47ca-92f8-69720dc6dff4@github.com>
References: <Gq8Ci4GZW1jVRfd8NPc7IImtnY2TYO7kyo8FFYaMQzs=.9e62b134-bed1-4970-a840-ee217f6d5e98@github.com>
 <iDa2k0mZ0jEolNi3QBW9gK9ALGXiW9le6zfhgHV2CNE=.350b64a5-fde6-4c89-a792-85307a03da09@github.com>
 <SPVZ6SM0l47L0EL9Uot7d1Av9HNHfy6AAGs77cPoUR4=.2c74d74c-868b-47ca-92f8-69720dc6dff4@github.com>
Message-ID: <V1P8LNkrYRvJS7VdU7db1C9NBgy5rNYTBWSqT755PhE=.12a2e98f-7983-422f-8963-47d42bf9312e@github.com>

On Thu, 25 Aug 2022 21:41:46 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Johan Sj?len 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:
>> 
>>  - Fix tests for updated threadHelper
>>  - Remove outdated threadHelper
>>  - Update documentation
>>  - Fix outdated headers and remove dead code
>>  - Review comments
>>  - Implement MRSWMutex
>
> src/hotspot/share/utilities/readWriteLock.cpp line 139:
> 
>> 137:     return;
>> 138:   }
>> 139: }
> 
> I was wondering why a lock for write doesn't hold the underlying
> PlatformMonitor across the scope of the mutex region. Something like this
> (completely untested)
> 
> 
> void ReadWriteLock::write_lock(Thread* current) {
>   _mon.lock();
>   while (true) {
>     const int32_t count = Atomic::load_acquire(&_count);
>     if (count < 0) {
>       // Some other writer is waiting for readers to complete.
>       // Approx:
>       // while (Atomic::load_acquire(&_count)) _mon.wait();
>       await_write_unlock(current);
>     } else if (Atomic::cmpxchg(&_count, count, -(count + 1)) == count) {
>       // Claimed the write slot, but there might be active readers.
>       if (count != 0) {
>         // Approx:
>         // while (Atomic::load_acquire(&_count) != -1) _mon.wait();
>         await_no_active_readers(current);
>       }
>       return; // return still holding lock
>     } // else failed to claim write ownership, so try again.
>   }
> }
> 
> void ReadWriteLock::write_unlock() {
>   assert(Atomic::load(&_count) == -1, "invariant");
>   Atomic::release_store(&_count, (int32_t)0);
>   _mon.notify_all();
>   _mon.unlock();
> }
> 
> 
> This seems simpler to me.  Am I missing something?
> 
> And looking at this also makes me wonder if `_mon` can just be a normal
> HotSpot `Monitor`, which would resolve many of the questions and comments I've
> made that are mostly driven by the direct use of `PlatformMonitor`.

This lock is essentially unbounded, are there any implications regarding stopping the VM from going into safepoints? I assume not, if we're using `Monitor`.

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

PR: https://git.openjdk.org/jdk/pull/9838

From dsamersoff at openjdk.org  Tue Oct 18 15:01:58 2022
From: dsamersoff at openjdk.org (Dmitry Samersoff)
Date: Tue, 18 Oct 2022 15:01:58 GMT
Subject: RFR: 8293806: JDK_JAVA_OPTIONS picked up twice if launcher
 re-executes it self
In-Reply-To: <o_7CQY9QGHSXKRvNGPndiAp6M8w_rjDztF30TMU4eqM=.499fd1ac-f0aa-4935-b971-44d67fea49fc@github.com>
References: <o_7CQY9QGHSXKRvNGPndiAp6M8w_rjDztF30TMU4eqM=.499fd1ac-f0aa-4935-b971-44d67fea49fc@github.com>
Message-ID: <bJLWHZ39M5EIkgSv6LA7kcbj44eXf9ZTpwHKwEV1Ouc=.d1188838-7aca-4d95-9627-6ba44a5e2f33@github.com>

On Mon, 26 Sep 2022 18:15:17 GMT, Dmitry Samersoff <dsamersoff at openjdk.org> wrote:

> If the user has set LD_LIBRARY_PATH to use a particular libjvm.so, options from the JDK_JAVA_OPTIONS environment variable are picked up twice.
> 
> If an option cannot be accepted twice (e.g., -agentlib), the application fails to start.
> 
> The same happens on operating systems that doesn't support $RPATH/$ORIGIN and always have to set LD_LIBRARY_PATH and re-exec the launcher.
> 
> The fix adds one additional argument - orig_argv to JLI_Launch() and use it in on relaunch in execv() call.
> 
> All relevant jtreg tests are passed.

It's exactly what I'm trying to do - fix the broken logic around relaunch variable. 

We have couple of options here:

1. Decide re-launch/not-relaunch before processing arguments.
      - it's (IMHO) the best solution, but it requires significant refactor of the launcher.
      
2. Pass initial argv to the secondary launcher, which is re-launched and repeat argument processing. 
    -  it's what was implemented in this patch.
    
4. Let the secondary launcher know that the arguments was already processed.
    - to do this we need to use some kind of IPC: another environment variable; additional command-line option, which we will then remove etc.    
      @dholmes-ora if you think that this is the way, please advice - which method of such communication you prefer.

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

PR: https://git.openjdk.org/jdk/pull/10430

From iklam at openjdk.org  Tue Oct 18 15:33:30 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 18 Oct 2022 15:33:30 GMT
Subject: RFR: 8293291: Simplify relocation of native pointers in archive
 heap [v4]
In-Reply-To: <ElL_R-ZOAf6qfTzAypZPN0G5VrE9yLMuMznOJNauYFA=.85a3978c-c93a-4848-923f-92631a5c840e@github.com>
References: <ElL_R-ZOAf6qfTzAypZPN0G5VrE9yLMuMznOJNauYFA=.85a3978c-c93a-4848-923f-92631a5c840e@github.com>
Message-ID: <ajeiyfIn71N0DfSQzHrs2uJvE0kdg_oWQt2SW4Tb5aw=.55355db8-5f6f-497b-b0d0-7a191599e22e@github.com>

> Some objects in the archive heap contain native pointers. E.g., archived `java.lang.Class` objects contain a pointer to its `Klass*`.
> 
> At runtime, if the archived metadata are mapped at an alternative address, all of the `Klass*` pointers must be relocated. Instead of doing this in an ad-hoc way, this PR uses a bitmap, `FileMapRegion::ptrmap_view()`, to track the position of all the native pointers.
> 
> This PR is done in preparation for supporting new types of archived heap objects that have native pointers. E.g., `java.lang.invoke.ResolvedMethodName` has a pointer to a `Method*`.
> 
> 
> Notes for reviewers:
> 
> - At dump time, the native pointers are remembered in `HeapShared::mark_native_pointers()`.
> - At runtime, the native pointers are patched in `ArchiveHeapLoader::patch_native_pointers()`.
> - The ad-hoc relocation code has been removed from javaClasses.cpp and systemDictionaryShared.cpp
> - Many of the changes are for renaming from "oopmaps" to "bitmaps": the old code handled only a single type of pointers (oop references). The new code handles two types of bitmaps ("oopmap" is for oop references, "ptrmap" is for native pointers).

Ioi Lam 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:

 - cleaned up code; fixed test that failed on windows because archive heap is not supported there
 - Merge branch 'master' into 8293291-simplify-archive-heap-native-ptr-relocation
 - Merge branch 'master' into 8293291-simplify-archive-heap-native-ptr-relocation
 - Merge branch 'master' into 8293291-simplify-archive-heap-native-ptr-relocation
 - @calvinccheung comments
 - clean up
 - 8293291: Simplify relocation of native pointers in archive heap

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10296/files
  - new: https://git.openjdk.org/jdk/pull/10296/files/d2e969bb..54f78f56

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10296&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10296&range=02-03

  Stats: 6086 lines in 165 files changed: 3507 ins; 1804 del; 775 mod
  Patch: https://git.openjdk.org/jdk/pull/10296.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10296/head:pull/10296

PR: https://git.openjdk.org/jdk/pull/10296

From ccheung at openjdk.org  Tue Oct 18 18:39:58 2022
From: ccheung at openjdk.org (Calvin Cheung)
Date: Tue, 18 Oct 2022 18:39:58 GMT
Subject: RFR: 8295029: runtime/cds/appcds/LotsOfClasses.java fail with jfx
In-Reply-To: <Q9zXbTPMiOsu-e3Wd2EsBAC7a6cwoxyn0a_ATFyMJT0=.a4978796-143b-4ed3-9c76-b3c4dce3629c@github.com>
References: <Q9zXbTPMiOsu-e3Wd2EsBAC7a6cwoxyn0a_ATFyMJT0=.a4978796-143b-4ed3-9c76-b3c4dce3629c@github.com>
Message-ID: <VE6D9P1iggEljgU5irpkKJCv9CPAChrsijKWe7-yCWM=.5441d3fd-7bc2-4ad2-92e8-f74faf8bedf8@github.com>

On Fri, 14 Oct 2022 02:27:01 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This removes the can-resize parameter for ClassLoaderData dictionaries. They can all resize now that the shared dictionaries are moved to the CompactHashtable. This also removes an unused/untested development option to disallow resizing.
> Tested with tiers1-4 and tested with the failing test case. It can't be added because it requires outside code or simulated because it would be an expensive test to generate all those class files.  There's an existing test for resizing.

LGTM.

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

Marked as reviewed by ccheung (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10708

From gziemski at openjdk.org  Tue Oct 18 19:10:59 2022
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Tue, 18 Oct 2022 19:10:59 GMT
Subject: RFR: 8295029: runtime/cds/appcds/LotsOfClasses.java fail with jfx
In-Reply-To: <Q9zXbTPMiOsu-e3Wd2EsBAC7a6cwoxyn0a_ATFyMJT0=.a4978796-143b-4ed3-9c76-b3c4dce3629c@github.com>
References: <Q9zXbTPMiOsu-e3Wd2EsBAC7a6cwoxyn0a_ATFyMJT0=.a4978796-143b-4ed3-9c76-b3c4dce3629c@github.com>
Message-ID: <tUqaeJ3IZTseyEMk-5YJfA9VnFASgzPn_rfY00i_ZTs=.87dce3a2-10cd-4ae4-890d-9705ed973c02@github.com>

On Fri, 14 Oct 2022 02:27:01 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This removes the can-resize parameter for ClassLoaderData dictionaries. They can all resize now that the shared dictionaries are moved to the CompactHashtable. This also removes an unused/untested development option to disallow resizing.
> Tested with tiers1-4 and tested with the failing test case. It can't be added because it requires outside code or simulated because it would be an expensive test to generate all those class files.  There's an existing test for resizing.

LGTM

So the only one type of dictionary that gains the super powers of resizing is the DelegatingClassLoader dictionary, but based on comments it's always size 1, so it never will need to be resized?

Related question, but not part of this fix - can we simplify things and not have to bother with 1 element dictionary for DelegatingClassLoader somehow?

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

Marked as reviewed by gziemski (Committer).

PR: https://git.openjdk.org/jdk/pull/10708

From coleenp at openjdk.org  Tue Oct 18 20:26:01 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 18 Oct 2022 20:26:01 GMT
Subject: RFR: 8295029: runtime/cds/appcds/LotsOfClasses.java fail with jfx
In-Reply-To: <Q9zXbTPMiOsu-e3Wd2EsBAC7a6cwoxyn0a_ATFyMJT0=.a4978796-143b-4ed3-9c76-b3c4dce3629c@github.com>
References: <Q9zXbTPMiOsu-e3Wd2EsBAC7a6cwoxyn0a_ATFyMJT0=.a4978796-143b-4ed3-9c76-b3c4dce3629c@github.com>
Message-ID: <CdLXCHCGGL8Wbs_dLvsAmbvbNmS-kYeOORW20DMuC-k=.fb263877-1849-4e22-a3ed-de693595c681@github.com>

On Fri, 14 Oct 2022 02:27:01 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This removes the can-resize parameter for ClassLoaderData dictionaries. They can all resize now that the shared dictionaries are moved to the CompactHashtable. This also removes an unused/untested development option to disallow resizing.
> Tested with tiers1-4 and tested with the failing test case. It can't be added because it requires outside code or simulated because it would be an expensive test to generate all those class files.  There's an existing test for resizing.

Thanks for the reviews, Ioi, Calvin and Gerard.
To answer your question about the DelegatingClassLoader - it's always a 1 element hashtable so would never need to be resized. Seems efficient to specify a very small hashtable.  We may be able to eventually remove it because of JEP 416: [JDK-8271820](https://bugs.openjdk.org/browse/JDK-8271820).
Thanks.

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

PR: https://git.openjdk.org/jdk/pull/10708

From coleenp at openjdk.org  Tue Oct 18 20:29:31 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 18 Oct 2022 20:29:31 GMT
Subject: Integrated: 8295029: runtime/cds/appcds/LotsOfClasses.java fail with
 jfx
In-Reply-To: <Q9zXbTPMiOsu-e3Wd2EsBAC7a6cwoxyn0a_ATFyMJT0=.a4978796-143b-4ed3-9c76-b3c4dce3629c@github.com>
References: <Q9zXbTPMiOsu-e3Wd2EsBAC7a6cwoxyn0a_ATFyMJT0=.a4978796-143b-4ed3-9c76-b3c4dce3629c@github.com>
Message-ID: <Q_uFpTktCT2CRckNSfxL4bl9flwjmoqE19Bs6QcO5lQ=.5fa146ec-f523-4cf8-b7ea-d3271d143ed9@github.com>

On Fri, 14 Oct 2022 02:27:01 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This removes the can-resize parameter for ClassLoaderData dictionaries. They can all resize now that the shared dictionaries are moved to the CompactHashtable. This also removes an unused/untested development option to disallow resizing.
> Tested with tiers1-4 and tested with the failing test case. It can't be added because it requires outside code or simulated because it would be an expensive test to generate all those class files.  There's an existing test for resizing.

This pull request has now been integrated.

Changeset: 37f93b67
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/37f93b6728ae9ebe4bbd89edcf521def67845fdf
Stats:     19 lines in 4 files changed: 0 ins; 12 del; 7 mod

8295029: runtime/cds/appcds/LotsOfClasses.java fail with jfx

Reviewed-by: iklam, ccheung, gziemski

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

PR: https://git.openjdk.org/jdk/pull/10708

From ccheung at openjdk.org  Tue Oct 18 20:31:17 2022
From: ccheung at openjdk.org (Calvin Cheung)
Date: Tue, 18 Oct 2022 20:31:17 GMT
Subject: RFR: 8279366: CDS should allow alternative locations for JAR files
 in classpath [v3]
In-Reply-To: <gjn5N9Lmavel1A8AHZFHxbp0J2l6XklY_-Pr-N04k7g=.dd8b5ed1-2c55-40cf-88e1-770e16c4c911@github.com>
References: <gjn5N9Lmavel1A8AHZFHxbp0J2l6XklY_-Pr-N04k7g=.dd8b5ed1-2c55-40cf-88e1-770e16c4c911@github.com>
Message-ID: <WyUBvQXQnYdU4YGOYt1NztHwfdsA-wpCWEaIxIl2IRk=.5e87dbeb-e5e0-43f3-9510-effd2b0d1f07@github.com>

> Please review this RFE for allowing alternative locations for jar files in the app classpath during runtime.
> 
> During dump time, the longest common prefix of the app classpath will be stored in the CDS archive header. During runtime, existing checks of the app classpath will be performed first. Upon failure, the longest common prefix of the runtime app classpath will be computed and another check of the app classpath will be performed ignoring the longest common prefix.
> 
> Refer to the [bug report comment](https://bugs.openjdk.org/browse/JDK-8279366?focusedCommentId=14509536&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14509536) for an example.
> 
> Passed tiers 1 - 4 testing (including the new tests).

Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:

  rename variable names and add more tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10615/files
  - new: https://git.openjdk.org/jdk/pull/10615/files/d572c2e0..11faf0cb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10615&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10615&range=01-02

  Stats: 90 lines in 9 files changed: 29 ins; 4 del; 57 mod
  Patch: https://git.openjdk.org/jdk/pull/10615.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10615/head:pull/10615

PR: https://git.openjdk.org/jdk/pull/10615

From ccheung at openjdk.org  Tue Oct 18 20:32:50 2022
From: ccheung at openjdk.org (Calvin Cheung)
Date: Tue, 18 Oct 2022 20:32:50 GMT
Subject: RFR: 8279366: CDS should allow alternative locations for JAR files
 in classpath [v2]
In-Reply-To: <ZbA9QYoEqgHjkiWM8qFt42H_dJ1jGoo86UDPAfQkAhk=.c40adf49-980c-4f95-b705-a19f05d57a4f@github.com>
References: <gjn5N9Lmavel1A8AHZFHxbp0J2l6XklY_-Pr-N04k7g=.dd8b5ed1-2c55-40cf-88e1-770e16c4c911@github.com>
 <vE4QFnE0HK7b-rn5jcY1uK3x7Cv62luelsIgLhFEA5o=.3bf5a547-bc67-418b-8639-c7d0117f3860@github.com>
 <ZbA9QYoEqgHjkiWM8qFt42H_dJ1jGoo86UDPAfQkAhk=.c40adf49-980c-4f95-b705-a19f05d57a4f@github.com>
Message-ID: <R5Z0I0WGh-73KGUF3j5AClODS0siJbjTzGOcYHoL7qQ=.37ae6aac-21eb-4d8f-951c-6b61909d5a78@github.com>

On Mon, 17 Oct 2022 20:23:52 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Calvin Cheung 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 four additional commits since the last revision:
>> 
>>  - not storing the common app path string in the archive header
>>  - Merge branch 'master' into 8279366-longest-common-prefix
>>  - remove trailing whitespace
>>  - 8279366: CDS should allow alternative locations for JAR files in classpath
>
> src/hotspot/share/cds/filemap.cpp line 208:
> 
>> 206:   size_t base_archive_name_offset = 0;
>> 207:   size_t longest_common_prefix_size = 0;
>> 208:   size_t longest_common_prefix_offset = 0;
> 
> This variable can also be removed.

Fixed.

> src/hotspot/share/cds/filemap.cpp line 887:
> 
>> 885: }
>> 886: 
>> 887: bool FileMapInfo::check_paths_ignoring_common_path(int shared_path_start_idx, int num_paths,
> 
> I think we should use the word "prefix" in the names. This way, it's clear that we are talking about a portion of a path string. How about `check_paths_ignoring_common_prefix`?

Done.

> src/hotspot/share/cds/filemap.cpp line 1033:
> 
>> 1031:     if (mismatch) {
>> 1032:       unsigned int dumptime_prefix_len = header()->common_app_classpath_size();
>> 1033:       unsigned int runtime_prefix_len = longest_common_app_classpath_len(shared_app_paths_len, rp_array);
> 
> How about `header()->common_app_classpath_prefix_size()` and `longest_common_app_classpath_prefix_len`?

Done.

> src/hotspot/share/cds/filemap.cpp line 1280:
> 
>> 1278:     }
>> 1279: 
>> 1280:     if (!check_common_app_classpath()) {
> 
> How about `check_common_app_classpath_prefix_len()`?

Done.
I also did similar renaming in cdsConstants.cpp and CDSArchiveUtils.java.
Also added more tests for testing single app class path case.

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

PR: https://git.openjdk.org/jdk/pull/10615

From iklam at openjdk.org  Tue Oct 18 21:50:15 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 18 Oct 2022 21:50:15 GMT
Subject: RFR: 8293291: Simplify relocation of native pointers in archive
 heap [v5]
In-Reply-To: <ElL_R-ZOAf6qfTzAypZPN0G5VrE9yLMuMznOJNauYFA=.85a3978c-c93a-4848-923f-92631a5c840e@github.com>
References: <ElL_R-ZOAf6qfTzAypZPN0G5VrE9yLMuMznOJNauYFA=.85a3978c-c93a-4848-923f-92631a5c840e@github.com>
Message-ID: <I0JG4xKeI4Thn3m6woeGbNwwLvWc5yeYIH2u4zkQIgA=.8cd71b36-8c5c-451c-8881-e436cd16f996@github.com>

> Some objects in the archive heap contain native pointers. E.g., archived `java.lang.Class` objects contain a pointer to its `Klass*`.
> 
> At runtime, if the archived metadata are mapped at an alternative address, all of the `Klass*` pointers must be relocated. Instead of doing this in an ad-hoc way, this PR uses a bitmap, `FileMapRegion::ptrmap_view()`, to track the position of all the native pointers.
> 
> This PR is done in preparation for supporting new types of archived heap objects that have native pointers. E.g., `java.lang.invoke.ResolvedMethodName` has a pointer to a `Method*`.
> 
> 
> Notes for reviewers:
> 
> - At dump time, the native pointers are remembered in `HeapShared::mark_native_pointers()`.
> - At runtime, the native pointers are patched in `ArchiveHeapLoader::patch_native_pointers()`.
> - The ad-hoc relocation code has been removed from javaClasses.cpp and systemDictionaryShared.cpp
> - Many of the changes are for renaming from "oopmaps" to "bitmaps": the old code handled only a single type of pointers (oop references). The new code handles two types of bitmaps ("oopmap" is for oop references, "ptrmap" is for native pointers).

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  Fixed windows test failure

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10296/files
  - new: https://git.openjdk.org/jdk/pull/10296/files/54f78f56..810289f7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10296&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10296&range=03-04

  Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10296.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10296/head:pull/10296

PR: https://git.openjdk.org/jdk/pull/10296

From ccheung at openjdk.org  Tue Oct 18 23:47:44 2022
From: ccheung at openjdk.org (Calvin Cheung)
Date: Tue, 18 Oct 2022 23:47:44 GMT
Subject: RFR: 8293291: Simplify relocation of native pointers in archive
 heap [v5]
In-Reply-To: <I0JG4xKeI4Thn3m6woeGbNwwLvWc5yeYIH2u4zkQIgA=.8cd71b36-8c5c-451c-8881-e436cd16f996@github.com>
References: <ElL_R-ZOAf6qfTzAypZPN0G5VrE9yLMuMznOJNauYFA=.85a3978c-c93a-4848-923f-92631a5c840e@github.com>
 <I0JG4xKeI4Thn3m6woeGbNwwLvWc5yeYIH2u4zkQIgA=.8cd71b36-8c5c-451c-8881-e436cd16f996@github.com>
Message-ID: <qZP-L6xOggJ6bx3SzvAqhjojIA5CI4CgswGDkHqj-Z0=.da1f85f3-5763-4a48-be7d-e35a6aa42191@github.com>

On Tue, 18 Oct 2022 21:50:15 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Some objects in the archive heap contain native pointers. E.g., archived `java.lang.Class` objects contain a pointer to its `Klass*`.
>> 
>> At runtime, if the archived metadata are mapped at an alternative address, all of the `Klass*` pointers must be relocated. Instead of doing this in an ad-hoc way, this PR uses a bitmap, `FileMapRegion::ptrmap_view()`, to track the position of all the native pointers.
>> 
>> This PR is done in preparation for supporting new types of archived heap objects that have native pointers. E.g., `java.lang.invoke.ResolvedMethodName` has a pointer to a `Method*`.
>> 
>> 
>> Notes for reviewers:
>> 
>> - At dump time, the native pointers are remembered in `HeapShared::mark_native_pointers()`.
>> - At runtime, the native pointers are patched in `ArchiveHeapLoader::patch_native_pointers()`.
>> - The ad-hoc relocation code has been removed from javaClasses.cpp and systemDictionaryShared.cpp
>> - Many of the changes are for renaming from "oopmaps" to "bitmaps": the old code handled only a single type of pointers (oop references). The new code handles two types of bitmaps ("oopmap" is for oop references, "ptrmap" is for native pointers).
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed windows test failure

Marked as reviewed by ccheung (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10296

From coleenp at openjdk.org  Wed Oct 19 00:38:54 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 19 Oct 2022 00:38:54 GMT
Subject: RFR: 8293291: Simplify relocation of native pointers in archive
 heap [v5]
In-Reply-To: <I0JG4xKeI4Thn3m6woeGbNwwLvWc5yeYIH2u4zkQIgA=.8cd71b36-8c5c-451c-8881-e436cd16f996@github.com>
References: <ElL_R-ZOAf6qfTzAypZPN0G5VrE9yLMuMznOJNauYFA=.85a3978c-c93a-4848-923f-92631a5c840e@github.com>
 <I0JG4xKeI4Thn3m6woeGbNwwLvWc5yeYIH2u4zkQIgA=.8cd71b36-8c5c-451c-8881-e436cd16f996@github.com>
Message-ID: <YJzg6CB-iD-h3XLbgZRhb-uWB38ejVrtHF4adZixmDI=.f9040409-cdda-4a83-9554-4be8af3f7c3e@github.com>

On Tue, 18 Oct 2022 21:50:15 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Some objects in the archive heap contain native pointers. E.g., archived `java.lang.Class` objects contain a pointer to its `Klass*`.
>> 
>> At runtime, if the archived metadata are mapped at an alternative address, all of the `Klass*` pointers must be relocated. Instead of doing this in an ad-hoc way, this PR uses a bitmap, `FileMapRegion::ptrmap_view()`, to track the position of all the native pointers.
>> 
>> This PR is done in preparation for supporting new types of archived heap objects that have native pointers. E.g., `java.lang.invoke.ResolvedMethodName` has a pointer to a `Method*`.
>> 
>> 
>> Notes for reviewers:
>> 
>> - At dump time, the native pointers are remembered in `HeapShared::mark_native_pointers()`.
>> - At runtime, the native pointers are patched in `ArchiveHeapLoader::patch_native_pointers()`.
>> - The ad-hoc relocation code has been removed from javaClasses.cpp and systemDictionaryShared.cpp
>> - Many of the changes are for renaming from "oopmaps" to "bitmaps": the old code handled only a single type of pointers (oop references). The new code handles two types of bitmaps ("oopmap" is for oop references, "ptrmap" is for native pointers).
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed windows test failure

This makes sense and does seem cleaner.

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

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10296

From iklam at openjdk.org  Wed Oct 19 01:00:10 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 19 Oct 2022 01:00:10 GMT
Subject: RFR: 8293291: Simplify relocation of native pointers in archive
 heap [v6]
In-Reply-To: <ElL_R-ZOAf6qfTzAypZPN0G5VrE9yLMuMznOJNauYFA=.85a3978c-c93a-4848-923f-92631a5c840e@github.com>
References: <ElL_R-ZOAf6qfTzAypZPN0G5VrE9yLMuMznOJNauYFA=.85a3978c-c93a-4848-923f-92631a5c840e@github.com>
Message-ID: <rettd4eZINgBU4NgPy0lTyT10FU-K7WjeGJepsOsTpA=.3893bae3-2644-4369-8570-4e32fd353546@github.com>

> Some objects in the archive heap contain native pointers. E.g., archived `java.lang.Class` objects contain a pointer to its `Klass*`.
> 
> At runtime, if the archived metadata are mapped at an alternative address, all of the `Klass*` pointers must be relocated. Instead of doing this in an ad-hoc way, this PR uses a bitmap, `FileMapRegion::ptrmap_view()`, to track the position of all the native pointers.
> 
> This PR is done in preparation for supporting new types of archived heap objects that have native pointers. E.g., `java.lang.invoke.ResolvedMethodName` has a pointer to a `Method*`.
> 
> 
> Notes for reviewers:
> 
> - At dump time, the native pointers are remembered in `HeapShared::mark_native_pointers()`.
> - At runtime, the native pointers are patched in `ArchiveHeapLoader::patch_native_pointers()`.
> - The ad-hoc relocation code has been removed from javaClasses.cpp and systemDictionaryShared.cpp
> - Many of the changes are for renaming from "oopmaps" to "bitmaps": the old code handled only a single type of pointers (oop references). The new code handles two types of bitmaps ("oopmap" is for oop references, "ptrmap" is for native pointers).

Ioi Lam 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 ten additional commits since the last revision:

 - Merge branch 'master' of https://github.com/openjdk/jdk into 8293291-simplify-archive-heap-native-ptr-relocation
 - Fixed windows test failure
 - cleaned up code; fixed test that failed on windows because archive heap is not supported there
 - Merge branch 'master' into 8293291-simplify-archive-heap-native-ptr-relocation
 - Merge branch 'master' into 8293291-simplify-archive-heap-native-ptr-relocation
 - Merge branch 'master' into 8293291-simplify-archive-heap-native-ptr-relocation
 - @calvinccheung comments
 - clean up
 - 8293291: Simplify relocation of native pointers in archive heap

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10296/files
  - new: https://git.openjdk.org/jdk/pull/10296/files/810289f7..a39ca652

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10296&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10296&range=04-05

  Stats: 3347 lines in 575 files changed: 1740 ins; 114 del; 1493 mod
  Patch: https://git.openjdk.org/jdk/pull/10296.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10296/head:pull/10296

PR: https://git.openjdk.org/jdk/pull/10296

From iklam at openjdk.org  Wed Oct 19 05:01:43 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 19 Oct 2022 05:01:43 GMT
Subject: RFR: 8293291: Simplify relocation of native pointers in archive
 heap [v5]
In-Reply-To: <qZP-L6xOggJ6bx3SzvAqhjojIA5CI4CgswGDkHqj-Z0=.da1f85f3-5763-4a48-be7d-e35a6aa42191@github.com>
References: <ElL_R-ZOAf6qfTzAypZPN0G5VrE9yLMuMznOJNauYFA=.85a3978c-c93a-4848-923f-92631a5c840e@github.com>
 <I0JG4xKeI4Thn3m6woeGbNwwLvWc5yeYIH2u4zkQIgA=.8cd71b36-8c5c-451c-8881-e436cd16f996@github.com>
 <qZP-L6xOggJ6bx3SzvAqhjojIA5CI4CgswGDkHqj-Z0=.da1f85f3-5763-4a48-be7d-e35a6aa42191@github.com>
Message-ID: <OcKZ0roiB65evGfiLwE3Jygkg-Pjo41qck_Yh4s78Jw=.e7437611-2e19-49c8-9f31-9725b7ca1cce@github.com>

On Tue, 18 Oct 2022 23:44:02 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed windows test failure
>
> Marked as reviewed by ccheung (Reviewer).

Thanks @calvinccheung and @coleenp for the review. I have merged with latest repo (after CPU sync) and retested with tiers 1-4. All passed.

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

PR: https://git.openjdk.org/jdk/pull/10296

From iklam at openjdk.org  Wed Oct 19 05:01:45 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 19 Oct 2022 05:01:45 GMT
Subject: Integrated: 8293291: Simplify relocation of native pointers in archive
 heap
In-Reply-To: <ElL_R-ZOAf6qfTzAypZPN0G5VrE9yLMuMznOJNauYFA=.85a3978c-c93a-4848-923f-92631a5c840e@github.com>
References: <ElL_R-ZOAf6qfTzAypZPN0G5VrE9yLMuMznOJNauYFA=.85a3978c-c93a-4848-923f-92631a5c840e@github.com>
Message-ID: <qQp0zW6HiQi2Z8LQLqtdyHTZeTYAj8eW6aZIutN2QmE=.0a9292e5-c0be-4a90-9cc5-4f9b23e53c4d@github.com>

On Thu, 15 Sep 2022 20:49:24 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Some objects in the archive heap contain native pointers. E.g., archived `java.lang.Class` objects contain a pointer to its `Klass*`.
> 
> At runtime, if the archived metadata are mapped at an alternative address, all of the `Klass*` pointers must be relocated. Instead of doing this in an ad-hoc way, this PR uses a bitmap, `FileMapRegion::ptrmap_view()`, to track the position of all the native pointers.
> 
> This PR is done in preparation for supporting new types of archived heap objects that have native pointers. E.g., `java.lang.invoke.ResolvedMethodName` has a pointer to a `Method*`.
> 
> 
> Notes for reviewers:
> 
> - At dump time, the native pointers are remembered in `HeapShared::mark_native_pointers()`.
> - At runtime, the native pointers are patched in `ArchiveHeapLoader::patch_native_pointers()`.
> - The ad-hoc relocation code has been removed from javaClasses.cpp and systemDictionaryShared.cpp
> - Many of the changes are for renaming from "oopmaps" to "bitmaps": the old code handled only a single type of pointers (oop references). The new code handles two types of bitmaps ("oopmap" is for oop references, "ptrmap" is for native pointers).

This pull request has now been integrated.

Changeset: 3f4964f8
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3f4964f83d6f03efbee2fb34aa8258d4fc923efb
Stats:     428 lines in 17 files changed: 193 ins; 153 del; 82 mod

8293291: Simplify relocation of native pointers in archive heap

Reviewed-by: ccheung, coleenp

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

PR: https://git.openjdk.org/jdk/pull/10296

From tschatzl at openjdk.org  Wed Oct 19 07:52:06 2022
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 19 Oct 2022 07:52:06 GMT
Subject: RFR: 8295124: Atomic::add to pointer type may return wrong value
 [v2]
In-Reply-To: <pLyuIraAHIPX4fT5YJG14TSjcoETKZbazFG8EBq3YjI=.3ad05410-1860-4a92-8ae7-a28599f80e26@github.com>
References: <8MVHNI6FliDXtf6MFWwrL9cj3o_VaM98dPj_TuRgkWI=.83b5aee8-f553-48fa-9d86-80d5d54a5a5e@github.com>
 <pLyuIraAHIPX4fT5YJG14TSjcoETKZbazFG8EBq3YjI=.3ad05410-1860-4a92-8ae7-a28599f80e26@github.com>
Message-ID: <OWcpe6chcuYaoSVWNC-Jvdcb_BTv78u7e2o6DBNSaqE=.f1def790-f1db-4ea2-95f3-1072526545b4@github.com>

On Wed, 12 Oct 2022 20:38:10 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to the handling of Atomic pointer arithmetic. When
>> the value being modified is a pointer `P*`, the type of the value in the
>> destination passed to the platform operation is `const char*`, so a pointer
>> type whose pointee is size 1. This allows the platform operation to just treat
>> the arithmetic as a simple byte adjustment.
>> 
>> To demonstrate the problem described in the bug (possible incorrect result for
>> Atomic pointer arithmetic) and show that it is now fixed, this change also
>> includes some gtests for Atomic operations, including pointer arithmetic which
>> fails before the change and succeeds after.
>> 
>> Testing: mach5 tier1-3
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   conditionalize 64bit tests on 64bit platform

Lgtm.

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

Marked as reviewed by tschatzl (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10667

From dholmes at openjdk.org  Wed Oct 19 08:01:00 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 19 Oct 2022 08:01:00 GMT
Subject: RFR: 8293806: JDK_JAVA_OPTIONS picked up twice if launcher
 re-executes it self
In-Reply-To: <o_7CQY9QGHSXKRvNGPndiAp6M8w_rjDztF30TMU4eqM=.499fd1ac-f0aa-4935-b971-44d67fea49fc@github.com>
References: <o_7CQY9QGHSXKRvNGPndiAp6M8w_rjDztF30TMU4eqM=.499fd1ac-f0aa-4935-b971-44d67fea49fc@github.com>
Message-ID: <D3wHu5JV0TpC2UrILY9CCc6zaHwkfGtazF8RaMW4A-k=.fb897b7b-4958-4f77-927b-cd035ae79ce7@github.com>

On Mon, 26 Sep 2022 18:15:17 GMT, Dmitry Samersoff <dsamersoff at openjdk.org> wrote:

> If the user has set LD_LIBRARY_PATH to use a particular libjvm.so, options from the JDK_JAVA_OPTIONS environment variable are picked up twice.
> 
> If an option cannot be accepted twice (e.g., -agentlib), the application fails to start.
> 
> The same happens on operating systems that doesn't support $RPATH/$ORIGIN and always have to set LD_LIBRARY_PATH and re-exec the launcher.
> 
> The fix adds one additional argument - orig_argv to JLI_Launch() and use it in on relaunch in execv() call.
> 
> All relevant jtreg tests are passed.

I don't think solution #2 is desirable whilst the broken re-launch logic remains in place - but I might be swayed to defer that code removal to a separate RFE.

That said solution #1 is certainly preferable as there was obviously an intent that relaunch was handled correctly.

Happy to hear other opinions.

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

PR: https://git.openjdk.org/jdk/pull/10430

From dcubed at openjdk.org  Wed Oct 19 14:16:49 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 19 Oct 2022 14:16:49 GMT
Subject: RFR: 8295665: [BACKOUT] JDK-8293409 [vectorapi] Intrinsify
 VectorSupport.indexVector
Message-ID: <uNa7LiucCK4oVJz7orZH-9X4WT-Fk4lU9UgAdqf6fn4=.3be3ad89-0452-4d67-bf56-c5ae491e6edf@github.com>

This reverts commit 857b0f9b05bc711f3282a0da85fcff131fffab91.

This [BACKOUT] was created via:
`git revert 857b0f9b05bc711f3282a0da85fcff131fffab91`
and there were no conflicts detected.

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

Commit messages:
 - 8295665: [BACKOUT] JDK-8293409 [vectorapi] Intrinsify VectorSupport.indexVector

Changes: https://git.openjdk.org/jdk/pull/10765/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10765&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295665
  Stats: 391 lines in 14 files changed: 9 ins; 361 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/10765.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10765/head:pull/10765

PR: https://git.openjdk.org/jdk/pull/10765

From thartmann at openjdk.org  Wed Oct 19 14:16:50 2022
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 19 Oct 2022 14:16:50 GMT
Subject: RFR: 8295665: [BACKOUT] JDK-8293409 [vectorapi] Intrinsify
 VectorSupport.indexVector
In-Reply-To: <uNa7LiucCK4oVJz7orZH-9X4WT-Fk4lU9UgAdqf6fn4=.3be3ad89-0452-4d67-bf56-c5ae491e6edf@github.com>
References: <uNa7LiucCK4oVJz7orZH-9X4WT-Fk4lU9UgAdqf6fn4=.3be3ad89-0452-4d67-bf56-c5ae491e6edf@github.com>
Message-ID: <0XQbvWCNFEyWgyG78LqW28xJyhR8mxvElIIjsKrcNUc=.aecf06e0-c0e6-4c0a-9d0b-e663f8677cea@github.com>

On Wed, 19 Oct 2022 14:08:55 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> This reverts commit 857b0f9b05bc711f3282a0da85fcff131fffab91.
> 
> This [BACKOUT] was created via:
> `git revert 857b0f9b05bc711f3282a0da85fcff131fffab91`
> and there were no conflicts detected.

Looks good.

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

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10765

From chagedorn at openjdk.org  Wed Oct 19 14:16:51 2022
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Wed, 19 Oct 2022 14:16:51 GMT
Subject: RFR: 8295665: [BACKOUT] JDK-8293409 [vectorapi] Intrinsify
 VectorSupport.indexVector
In-Reply-To: <uNa7LiucCK4oVJz7orZH-9X4WT-Fk4lU9UgAdqf6fn4=.3be3ad89-0452-4d67-bf56-c5ae491e6edf@github.com>
References: <uNa7LiucCK4oVJz7orZH-9X4WT-Fk4lU9UgAdqf6fn4=.3be3ad89-0452-4d67-bf56-c5ae491e6edf@github.com>
Message-ID: <36JBo2TaxGIEjlZ8Y2Olmu2-RfsvrVHVB6yxKVEnsBo=.23534a34-b568-4382-bb4c-df9628d60163@github.com>

On Wed, 19 Oct 2022 14:08:55 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> This reverts commit 857b0f9b05bc711f3282a0da85fcff131fffab91.
> 
> This [BACKOUT] was created via:
> `git revert 857b0f9b05bc711f3282a0da85fcff131fffab91`
> and there were no conflicts detected.

Looks good!

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

Marked as reviewed by chagedorn (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10765

From qamai at openjdk.org  Wed Oct 19 14:16:52 2022
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 19 Oct 2022 14:16:52 GMT
Subject: RFR: 8295665: [BACKOUT] JDK-8293409 [vectorapi] Intrinsify
 VectorSupport.indexVector
In-Reply-To: <uNa7LiucCK4oVJz7orZH-9X4WT-Fk4lU9UgAdqf6fn4=.3be3ad89-0452-4d67-bf56-c5ae491e6edf@github.com>
References: <uNa7LiucCK4oVJz7orZH-9X4WT-Fk4lU9UgAdqf6fn4=.3be3ad89-0452-4d67-bf56-c5ae491e6edf@github.com>
Message-ID: <i_pn4JzuZjotP7S4uh_6dAouwhgFXE3R8AM-ntBdcgw=.fb54963c-5fb5-4a51-a21b-23e663f1fdc1@github.com>

On Wed, 19 Oct 2022 14:08:55 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> This reverts commit 857b0f9b05bc711f3282a0da85fcff131fffab91.
> 
> This [BACKOUT] was created via:
> `git revert 857b0f9b05bc711f3282a0da85fcff131fffab91`
> and there were no conflicts detected.

Can you check if #10764 fix the issue? Thanks a lot.

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

PR: https://git.openjdk.org/jdk/pull/10765

From dcubed at openjdk.org  Wed Oct 19 14:20:14 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 19 Oct 2022 14:20:14 GMT
Subject: RFR: 8295665: [BACKOUT] JDK-8293409 [vectorapi] Intrinsify
 VectorSupport.indexVector
In-Reply-To: <0XQbvWCNFEyWgyG78LqW28xJyhR8mxvElIIjsKrcNUc=.aecf06e0-c0e6-4c0a-9d0b-e663f8677cea@github.com>
References: <uNa7LiucCK4oVJz7orZH-9X4WT-Fk4lU9UgAdqf6fn4=.3be3ad89-0452-4d67-bf56-c5ae491e6edf@github.com>
 <0XQbvWCNFEyWgyG78LqW28xJyhR8mxvElIIjsKrcNUc=.aecf06e0-c0e6-4c0a-9d0b-e663f8677cea@github.com>
Message-ID: <MhgyZhkEW7mCApSnqxZhVf5m9ZKtbEqj-jDCKRpJ3N0=.059d34ab-7efb-4807-8f7e-c4e237a93ae9@github.com>

On Wed, 19 Oct 2022 14:12:16 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> This reverts commit 857b0f9b05bc711f3282a0da85fcff131fffab91.
>> 
>> This [BACKOUT] was created via:
>> `git revert 857b0f9b05bc711f3282a0da85fcff131fffab91`
>> and there were no conflicts detected.
>
> Looks good.

@TobiHartmann and @chhagedorn - Thanks for the fast reviews! I've kicked off a
sanity check Tier1...

@merykitty - It's not clear what testing you've already done on https://github.com/openjdk/jdk/pull/10764

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

PR: https://git.openjdk.org/jdk/pull/10765

From chagedorn at openjdk.org  Wed Oct 19 14:30:07 2022
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Wed, 19 Oct 2022 14:30:07 GMT
Subject: RFR: 8295665: [BACKOUT] JDK-8293409 [vectorapi] Intrinsify
 VectorSupport.indexVector
In-Reply-To: <i_pn4JzuZjotP7S4uh_6dAouwhgFXE3R8AM-ntBdcgw=.fb54963c-5fb5-4a51-a21b-23e663f1fdc1@github.com>
References: <uNa7LiucCK4oVJz7orZH-9X4WT-Fk4lU9UgAdqf6fn4=.3be3ad89-0452-4d67-bf56-c5ae491e6edf@github.com>
 <i_pn4JzuZjotP7S4uh_6dAouwhgFXE3R8AM-ntBdcgw=.fb54963c-5fb5-4a51-a21b-23e663f1fdc1@github.com>
Message-ID: <SiPCLCXZd3HW85NFzo9RJUfljQ7H_-gQj5_153IBxls=.7cd4ecdc-dc4e-4126-b63f-6d6b5407f53e@github.com>

On Wed, 19 Oct 2022 14:13:38 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> This reverts commit 857b0f9b05bc711f3282a0da85fcff131fffab91.
>> 
>> This [BACKOUT] was created via:
>> `git revert 857b0f9b05bc711f3282a0da85fcff131fffab91`
>> and there were no conflicts detected.
>
> Can you check if #10764 fix the issue? Thanks a lot.

@merykitty's fix looks reasonable. I've started a tier3 testing where we've seen these failures. I've also started a sanity tier1+2 testing. If that looks clean, we could go with @merykitty fix instead.

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

PR: https://git.openjdk.org/jdk/pull/10765

From dcubed at openjdk.org  Wed Oct 19 14:38:05 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 19 Oct 2022 14:38:05 GMT
Subject: RFR: 8295665: [BACKOUT] JDK-8293409 [vectorapi] Intrinsify
 VectorSupport.indexVector
In-Reply-To: <uNa7LiucCK4oVJz7orZH-9X4WT-Fk4lU9UgAdqf6fn4=.3be3ad89-0452-4d67-bf56-c5ae491e6edf@github.com>
References: <uNa7LiucCK4oVJz7orZH-9X4WT-Fk4lU9UgAdqf6fn4=.3be3ad89-0452-4d67-bf56-c5ae491e6edf@github.com>
Message-ID: <KAyx4x0mIJBoKqz0z-cyO9rwQRl2PqnhySISxJFMwTA=.fef74873-ca2a-4ea0-874c-89891d037be4@github.com>

On Wed, 19 Oct 2022 14:08:55 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> This reverts commit 857b0f9b05bc711f3282a0da85fcff131fffab91.
> 
> This [BACKOUT] was created via:
> `git revert 857b0f9b05bc711f3282a0da85fcff131fffab91`
> and there were no conflicts detected.

Sounds like a good plan to me.

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

PR: https://git.openjdk.org/jdk/pull/10765

From dcubed at openjdk.org  Wed Oct 19 15:44:01 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 19 Oct 2022 15:44:01 GMT
Subject: RFR: 8295665: [BACKOUT] JDK-8293409 [vectorapi] Intrinsify
 VectorSupport.indexVector
In-Reply-To: <uNa7LiucCK4oVJz7orZH-9X4WT-Fk4lU9UgAdqf6fn4=.3be3ad89-0452-4d67-bf56-c5ae491e6edf@github.com>
References: <uNa7LiucCK4oVJz7orZH-9X4WT-Fk4lU9UgAdqf6fn4=.3be3ad89-0452-4d67-bf56-c5ae491e6edf@github.com>
Message-ID: <ytuYGJVTyg5jlH2S-pb4e_kluUB5s07v0gtIPGB8ohY=.fca8db8e-82a0-47fc-93da-0b4049bd1395@github.com>

On Wed, 19 Oct 2022 14:08:55 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> This reverts commit 857b0f9b05bc711f3282a0da85fcff131fffab91.
> 
> This [BACKOUT] was created via:
> `git revert 857b0f9b05bc711f3282a0da85fcff131fffab91`
> and there were no conflicts detected.

My Tier1 testing for the [BACKOUT] has passed with no failures. I'm still in a holding
pattern for integration of the [BACKOUT] for now.

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

PR: https://git.openjdk.org/jdk/pull/10765

From dcubed at openjdk.org  Wed Oct 19 16:27:10 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 19 Oct 2022 16:27:10 GMT
Subject: RFR: 8295668: validate-source failure after JDK-8290011
Message-ID: <IA8Bx4C4Z3wSc-PJ6A59g4xtWEjVXo2REAarunV50TA=.73ef8d9c-1f4b-4ddc-aadc-38bc63a15441@github.com>

A trivia copyright fix for validate-source failure after JDK-8290011.

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

Commit messages:
 - 8295668: validate-source failure after JDK-8290011

Changes: https://git.openjdk.org/jdk/pull/10772/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10772&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295668
  Stats: 10 lines in 9 files changed: 0 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/10772.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10772/head:pull/10772

PR: https://git.openjdk.org/jdk/pull/10772

From chagedorn at openjdk.org  Wed Oct 19 16:33:00 2022
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Wed, 19 Oct 2022 16:33:00 GMT
Subject: RFR: 8295668: validate-source failure after JDK-8290011
In-Reply-To: <IA8Bx4C4Z3wSc-PJ6A59g4xtWEjVXo2REAarunV50TA=.73ef8d9c-1f4b-4ddc-aadc-38bc63a15441@github.com>
References: <IA8Bx4C4Z3wSc-PJ6A59g4xtWEjVXo2REAarunV50TA=.73ef8d9c-1f4b-4ddc-aadc-38bc63a15441@github.com>
Message-ID: <R4rFb_Ty4FK3OggHWEWn-maQJqb3iKtXBsYxFnBQgwA=.902a49d9-4637-4787-8985-0d1362e221d5@github.com>

On Wed, 19 Oct 2022 16:20:38 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivia copyright fix for validate-source failure after JDK-8290011.

Looks good and trivial!

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

Marked as reviewed by chagedorn (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10772

From dcubed at openjdk.org  Wed Oct 19 16:33:01 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 19 Oct 2022 16:33:01 GMT
Subject: RFR: 8295668: validate-source failure after JDK-8290011
In-Reply-To: <R4rFb_Ty4FK3OggHWEWn-maQJqb3iKtXBsYxFnBQgwA=.902a49d9-4637-4787-8985-0d1362e221d5@github.com>
References: <IA8Bx4C4Z3wSc-PJ6A59g4xtWEjVXo2REAarunV50TA=.73ef8d9c-1f4b-4ddc-aadc-38bc63a15441@github.com>
 <R4rFb_Ty4FK3OggHWEWn-maQJqb3iKtXBsYxFnBQgwA=.902a49d9-4637-4787-8985-0d1362e221d5@github.com>
Message-ID: <nYITC6O8QCVtIUJQIobe-spg6Ve9xwDySToPglwPrtA=.77cb48b9-2f39-47b1-8848-ca68cb5d0fa1@github.com>

On Wed, 19 Oct 2022 16:28:08 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> A trivia copyright fix for validate-source failure after JDK-8290011.
>
> Looks good and trivial!

@chhagedorn - Thanks for the fast review.

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

PR: https://git.openjdk.org/jdk/pull/10772

From dcubed at openjdk.org  Wed Oct 19 16:35:58 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 19 Oct 2022 16:35:58 GMT
Subject: Integrated: 8295668: validate-source failure after JDK-8290011
In-Reply-To: <IA8Bx4C4Z3wSc-PJ6A59g4xtWEjVXo2REAarunV50TA=.73ef8d9c-1f4b-4ddc-aadc-38bc63a15441@github.com>
References: <IA8Bx4C4Z3wSc-PJ6A59g4xtWEjVXo2REAarunV50TA=.73ef8d9c-1f4b-4ddc-aadc-38bc63a15441@github.com>
Message-ID: <Ny1SGDHitHbVTtx1Qt23NGByfJfu1YJnPZ-mdeaUm7s=.bedf82d8-ef80-4aa1-9b1d-1a5e27d9badd@github.com>

On Wed, 19 Oct 2022 16:20:38 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivia copyright fix for validate-source failure after JDK-8290011.

This pull request has now been integrated.

Changeset: 5eaf5686
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5eaf5686656a10ee27977de23ed5290a723b96a8
Stats:     10 lines in 9 files changed: 0 ins; 0 del; 10 mod

8295668: validate-source failure after JDK-8290011

Reviewed-by: chagedorn

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

PR: https://git.openjdk.org/jdk/pull/10772

From ccheung at openjdk.org  Wed Oct 19 16:36:56 2022
From: ccheung at openjdk.org (Calvin Cheung)
Date: Wed, 19 Oct 2022 16:36:56 GMT
Subject: RFR: 8279366: CDS should allow alternative locations for JAR files
 in classpath [v4]
In-Reply-To: <gjn5N9Lmavel1A8AHZFHxbp0J2l6XklY_-Pr-N04k7g=.dd8b5ed1-2c55-40cf-88e1-770e16c4c911@github.com>
References: <gjn5N9Lmavel1A8AHZFHxbp0J2l6XklY_-Pr-N04k7g=.dd8b5ed1-2c55-40cf-88e1-770e16c4c911@github.com>
Message-ID: <MMhJ6k7YdCD6-jcqEtHBnVrszfDXWKoz5nFPiR95NXk=.31d7a11a-4bc1-47ad-9fd8-0521cdb58ba1@github.com>

> Please review this RFE for allowing alternative locations for jar files in the app classpath during runtime.
> 
> During dump time, the longest common prefix of the app classpath will be stored in the CDS archive header. During runtime, existing checks of the app classpath will be performed first. Upon failure, the longest common prefix of the runtime app classpath will be computed and another check of the app classpath will be performed ignoring the longest common prefix.
> 
> Refer to the [bug report comment](https://bugs.openjdk.org/browse/JDK-8279366?focusedCommentId=14509536&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14509536) for an example.
> 
> Passed tiers 1 - 4 testing (including the new tests).

Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:

  merge check_paths_ignoring_common_prefix() into check_paths()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10615/files
  - new: https://git.openjdk.org/jdk/pull/10615/files/11faf0cb..59fad702

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10615&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10615&range=02-03

  Stats: 41 lines in 2 files changed: 7 ins; 24 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/10615.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10615/head:pull/10615

PR: https://git.openjdk.org/jdk/pull/10615

From chagedorn at openjdk.org  Wed Oct 19 16:41:03 2022
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Wed, 19 Oct 2022 16:41:03 GMT
Subject: RFR: 8295665: [BACKOUT] JDK-8293409 [vectorapi] Intrinsify
 VectorSupport.indexVector
In-Reply-To: <i_pn4JzuZjotP7S4uh_6dAouwhgFXE3R8AM-ntBdcgw=.fb54963c-5fb5-4a51-a21b-23e663f1fdc1@github.com>
References: <uNa7LiucCK4oVJz7orZH-9X4WT-Fk4lU9UgAdqf6fn4=.3be3ad89-0452-4d67-bf56-c5ae491e6edf@github.com>
 <i_pn4JzuZjotP7S4uh_6dAouwhgFXE3R8AM-ntBdcgw=.fb54963c-5fb5-4a51-a21b-23e663f1fdc1@github.com>
Message-ID: <NMp04gh3y84pK6_mbhmxD-0xdkBvee-895-z3WBeQKQ=.d068ba24-5373-4d5e-b356-2f46e51f5a33@github.com>

On Wed, 19 Oct 2022 14:13:38 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> This reverts commit 857b0f9b05bc711f3282a0da85fcff131fffab91.
>> 
>> This [BACKOUT] was created via:
>> `git revert 857b0f9b05bc711f3282a0da85fcff131fffab91`
>> and there were no conflicts detected.
>
> Can you check if #10764 fix the issue? Thanks a lot.

Testing of #10764 looked good! Tier1 and 2 is completed and tier 3 is almost completed but the relevant tasks were successful. @merykitty you can proceed with the integration of #10764.

Thanks,
Christian

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

PR: https://git.openjdk.org/jdk/pull/10765

From qamai at openjdk.org  Wed Oct 19 16:41:05 2022
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 19 Oct 2022 16:41:05 GMT
Subject: RFR: 8295665: [BACKOUT] JDK-8293409 [vectorapi] Intrinsify
 VectorSupport.indexVector
In-Reply-To: <uNa7LiucCK4oVJz7orZH-9X4WT-Fk4lU9UgAdqf6fn4=.3be3ad89-0452-4d67-bf56-c5ae491e6edf@github.com>
References: <uNa7LiucCK4oVJz7orZH-9X4WT-Fk4lU9UgAdqf6fn4=.3be3ad89-0452-4d67-bf56-c5ae491e6edf@github.com>
Message-ID: <9LORcEXrNh6vMiZTYrPUWrNhNIjBJgVr66Enzrgb9Mk=.c8df746f-3a6a-406d-abfb-852f04be9ed7@github.com>

On Wed, 19 Oct 2022 14:08:55 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> This reverts commit 857b0f9b05bc711f3282a0da85fcff131fffab91.
> 
> This [BACKOUT] was created via:
> `git revert 857b0f9b05bc711f3282a0da85fcff131fffab91`
> and there were no conflicts detected.

Thanks a lot for your testing, I will integrate now

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

PR: https://git.openjdk.org/jdk/pull/10765

From dcubed at openjdk.org  Wed Oct 19 16:47:18 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 19 Oct 2022 16:47:18 GMT
Subject: RFR: 8295665: [BACKOUT] JDK-8293409 [vectorapi] Intrinsify
 VectorSupport.indexVector
In-Reply-To: <uNa7LiucCK4oVJz7orZH-9X4WT-Fk4lU9UgAdqf6fn4=.3be3ad89-0452-4d67-bf56-c5ae491e6edf@github.com>
References: <uNa7LiucCK4oVJz7orZH-9X4WT-Fk4lU9UgAdqf6fn4=.3be3ad89-0452-4d67-bf56-c5ae491e6edf@github.com>
Message-ID: <qFUVexKBRlyIIOBLEk2NAS-LEt4GJieH_P-5uGoF8tk=.3f372e0b-75e5-4cd2-af0f-c062c9329565@github.com>

On Wed, 19 Oct 2022 14:08:55 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> This reverts commit 857b0f9b05bc711f3282a0da85fcff131fffab91.
> 
> This [BACKOUT] was created via:
> `git revert 857b0f9b05bc711f3282a0da85fcff131fffab91`
> and there were no conflicts detected.

The fix for the following bug: 

[JDK-8295662](https://bugs.openjdk.org/browse/JDK-8295662) jdk/incubator/vector tests fail "assert(VM_Version::supports_avx512vlbw()) failed" 

has been reviewed and tested so we no longer need this [BACKOUT].

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

PR: https://git.openjdk.org/jdk/pull/10765

From dcubed at openjdk.org  Wed Oct 19 16:47:18 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 19 Oct 2022 16:47:18 GMT
Subject: Withdrawn: 8295665: [BACKOUT] JDK-8293409 [vectorapi] Intrinsify
 VectorSupport.indexVector
In-Reply-To: <uNa7LiucCK4oVJz7orZH-9X4WT-Fk4lU9UgAdqf6fn4=.3be3ad89-0452-4d67-bf56-c5ae491e6edf@github.com>
References: <uNa7LiucCK4oVJz7orZH-9X4WT-Fk4lU9UgAdqf6fn4=.3be3ad89-0452-4d67-bf56-c5ae491e6edf@github.com>
Message-ID: <XP1xnXloDMLNDgaz4ls6F0JY7GD3cnNVGlGc18qRN2Q=.d3957062-057c-419a-8e21-d463f6f26ca5@github.com>

On Wed, 19 Oct 2022 14:08:55 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> This reverts commit 857b0f9b05bc711f3282a0da85fcff131fffab91.
> 
> This [BACKOUT] was created via:
> `git revert 857b0f9b05bc711f3282a0da85fcff131fffab91`
> and there were no conflicts detected.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/10765

From iklam at openjdk.org  Wed Oct 19 17:33:00 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 19 Oct 2022 17:33:00 GMT
Subject: RFR: 8279366: CDS should allow alternative locations for JAR files
 in classpath [v4]
In-Reply-To: <MMhJ6k7YdCD6-jcqEtHBnVrszfDXWKoz5nFPiR95NXk=.31d7a11a-4bc1-47ad-9fd8-0521cdb58ba1@github.com>
References: <gjn5N9Lmavel1A8AHZFHxbp0J2l6XklY_-Pr-N04k7g=.dd8b5ed1-2c55-40cf-88e1-770e16c4c911@github.com>
 <MMhJ6k7YdCD6-jcqEtHBnVrszfDXWKoz5nFPiR95NXk=.31d7a11a-4bc1-47ad-9fd8-0521cdb58ba1@github.com>
Message-ID: <0GsGZ0ert4vqgIvKDTuM6yBtY32B5RhRkXZemfOIM8w=.d972e6e8-e262-41fe-b7c2-d26d281ac4a9@github.com>

On Wed, 19 Oct 2022 16:36:56 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Please review this RFE for allowing alternative locations for jar files in the app classpath during runtime.
>> 
>> During dump time, the longest common prefix of the app classpath will be stored in the CDS archive header. During runtime, existing checks of the app classpath will be performed first. Upon failure, the longest common prefix of the runtime app classpath will be computed and another check of the app classpath will be performed ignoring the longest common prefix.
>> 
>> Refer to the [bug report comment](https://bugs.openjdk.org/browse/JDK-8279366?focusedCommentId=14509536&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14509536) for an example.
>> 
>> Passed tiers 1 - 4 testing (including the new tests).
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   merge check_paths_ignoring_common_prefix() into check_paths()

LGTM

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

Marked as reviewed by iklam (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10615

From sspitsyn at openjdk.org  Thu Oct 20 00:33:57 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 20 Oct 2022 00:33:57 GMT
Subject: RFR: 8030616: sun/management/jmxremote/bootstrap/RmiBootstrapTest
 fails intermittently with cannot find a free port
In-Reply-To: <txAkFc8XUg5T6ZiUjY2oP6NkB77JNeUJLfd26kySiRw=.88881c4f-1cb6-4171-ae11-75ad46e5cb25@github.com>
References: <txAkFc8XUg5T6ZiUjY2oP6NkB77JNeUJLfd26kySiRw=.88881c4f-1cb6-4171-ae11-75ad46e5cb25@github.com>
Message-ID: <BvE4r9TdgOEe8r7urVd4j0IvzhukESe4E1zdu7daCcA=.db72b11a-4658-4e3d-b0cb-32cde0e983b8@github.com>

On Sun, 18 Sep 2022 11:52:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test only change which proposes to fix the recent intermittent failures in `RmiBootstrapTest` reported in https://bugs.openjdk.org/browse/JDK-8030616?
> 
> The test has been intermittently failing with `cannot find a free port after 10 tries`.  The tests uses the `jdk.test.lib.Utils.getFreePort()` utility method to get a free port to use in the tests. That port is then used to create and bind a JMX connector server. The issue resides in the fact that the `getFreePort` utility uses loopback address to identify a free port, whereas the JMX connector server uses that identified port to bind to a non-loopback address - there's logic in `sun.rmi.transport.tcp.TCPEndpoint` line 117 which calls `InetAddress.getLocalHost()` which can and does return a non-loopback address. This effectively means that the port that was identified as free (on loopback) may not really be free on (some other address) and a subsequent attempt to bind against it by the connector server will end up with a `BindException`.
> 
> Data collected in failures on the CI system has shown that this is indeed the case and the port that was chosen (for loopback) as free was already used by another process on a different address. The test additionally has logic to attempt retries upto a maximum of 10 times to find a new free port on such `BindException`. Turns out the next free port (on loopback) returned by `jdk.test.lib.Utils.getFreePort()` is incremental and it so happens that the systems where this failed had a process listening on a range of 10 to 12 ports, so these too ended up with `BindException` when the JMX connector server used that port for a different address.
> 
> The commit here makes sure that the JMX connector server in the test is now configured to loopback address as the address to bind to. That way the test uses the correct address (loopback) on which the port was free.
> 
> The commit also has a change to the javadoc of the test utility `jdk.test.lib.Utils.getFreePort()` to clarify that it returns a free port on loopback address. This now matches what the implementation of that method does.
> 
> Multiple test runs after this change hasn't yet run into the failure.

This looks okay to me.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10322

From dholmes at openjdk.org  Thu Oct 20 06:08:28 2022
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 20 Oct 2022 06:08:28 GMT
Subject: RFR: 8295125: os::signal should be os specific
Message-ID: <DH7P6SqkigS2I09UR4i_7iQ2gmn28rmlTVPeuAWNQPs=.df77c4e1-2291-4633-b33a-6ab489905e09@github.com>

This was intended as a significant cleanup RFE but it turned out things were a lot messier than initially envisaged, so the resultant cleanup is quite limited.

The OS API/namespace was simplified by removing three signal related functions that are not needed in shared code:
 - signal
 - user_handler
 - raise
The first two were reworked and placed into PosixSignals and os::win32.
There was no need for a specific XX::raise API as os::raise simply called ::raise.

On the Posix side we had the basic signal handler installation code in two places:

1. Inline in set_signal_handler and used by nearly all the VM signals
2. In os::signal which was used by three different "clients"
  - VM error handler for updating crash handler
  - VM for installing SIG_BREAK handler
  - JDK via JVM_RegisterSignal

This was refactored so that we have:

1. PosixSignals::install_sigaction_signal_handler
  - used by the VM only
    - set_signal_handler
    - VM error handler for updating crash handler
    - VM for installing SIG_BREAK handler

2. PosixSignals::install_generic_signal_handler
  - used by JDK via JVM_RegisterSignal

The sigaction handlers were all consistently defined as per the posix definition:
    void func(int signo, siginfo_t *info, void *context);
  

On the Windows side we just fixed the incorrect definition of UserHandler and made some consistency changes to use the right signal handler type where possible.

Thanks.

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

Commit messages:
 - Fix erroneous cast after merge
 - Merge branch 'master' into 8295125-os_signal
 - 8295125: os::signal should be os specific

Changes: https://git.openjdk.org/jdk/pull/10780/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10780&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295125
  Stats: 165 lines in 9 files changed: 81 ins; 33 del; 51 mod
  Patch: https://git.openjdk.org/jdk/pull/10780.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10780/head:pull/10780

PR: https://git.openjdk.org/jdk/pull/10780

From bulasevich at openjdk.org  Thu Oct 20 06:44:47 2022
From: bulasevich at openjdk.org (Boris Ulasevich)
Date: Thu, 20 Oct 2022 06:44:47 GMT
Subject: RFR: 8295666: Linux x86 build fails after 8292591
Message-ID: <O-dFer7ZQtVP0ukIsggOlue5t__qMIFO1CS3t9xwDnY=.e73cfad6-ba70-4b54-bf6d-49f268ecf5c8@github.com>

I have got build failure similar to recent [Linux aarch64](https://github.com/openjdk/jdk/pull/10265) and [Linux Alpha Zero](https://github.com/openjdk/jdk/pull/10721) failures:


src/hotspot/os/linux/systemMemoryBarrier_linux.cpp:65:18: error: 'SYS_membarrier' was not declared in this scope
   return syscall(SYS_membarrier, cmd, flags, cpu_id); // cpu_id only on >= 5.10
                  ^~~~~~~~~~~~~~ 


The failure is known to be fixed by adding missing ` SYS_membarrier` definition. The raw constant 375 is taken from the `linux-libc-dev_6.0.2-1_i386.deb' cross-compilation headers:

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

Commit messages:
 - 8295666: Linux x86 build fails after 8292591

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

PR: https://git.openjdk.org/jdk/pull/10771

From dholmes at openjdk.org  Thu Oct 20 07:08:51 2022
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 20 Oct 2022 07:08:51 GMT
Subject: RFR: 8295666: Linux x86 build fails after 8292591
In-Reply-To: <O-dFer7ZQtVP0ukIsggOlue5t__qMIFO1CS3t9xwDnY=.e73cfad6-ba70-4b54-bf6d-49f268ecf5c8@github.com>
References: <O-dFer7ZQtVP0ukIsggOlue5t__qMIFO1CS3t9xwDnY=.e73cfad6-ba70-4b54-bf6d-49f268ecf5c8@github.com>
Message-ID: <86O4_QEMfllgUaUNxfJfamGJsih_YhJAVImz_Hjzbys=.0e24b630-c808-4af4-a9ff-f1e03e531c52@github.com>

On Wed, 19 Oct 2022 16:15:18 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

> I have got build failure similar to recent [Linux aarch64](https://github.com/openjdk/jdk/pull/10265) and [Linux Alpha Zero](https://github.com/openjdk/jdk/pull/10721) failures:
> 
> 
> src/hotspot/os/linux/systemMemoryBarrier_linux.cpp:65:18: error: 'SYS_membarrier' was not declared in this scope
>    return syscall(SYS_membarrier, cmd, flags, cpu_id); // cpu_id only on >= 5.10
>                   ^~~~~~~~~~~~~~ 
> 
> 
> The failure is known to be fixed by adding missing ` SYS_membarrier` definition. The raw constant 375 is taken from the `linux-libc-dev_6.0.2-1_i386.deb' cross-compilation headers:

Seems okay - and trivial. But I would have expected this to be reported weeks ago - has the linux-x86 build in GHA been failing all this time?

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10771

From shade at openjdk.org  Thu Oct 20 07:23:33 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 20 Oct 2022 07:23:33 GMT
Subject: RFR: 8295666: Linux x86 build fails after 8292591
In-Reply-To: <O-dFer7ZQtVP0ukIsggOlue5t__qMIFO1CS3t9xwDnY=.e73cfad6-ba70-4b54-bf6d-49f268ecf5c8@github.com>
References: <O-dFer7ZQtVP0ukIsggOlue5t__qMIFO1CS3t9xwDnY=.e73cfad6-ba70-4b54-bf6d-49f268ecf5c8@github.com>
Message-ID: <KVILW0frbbbMpC97fFKYKVSW1oLqEpyhYU4NgzCZdOI=.8ae034d7-06a2-4eb4-82dc-e8efefde87a4@github.com>

On Wed, 19 Oct 2022 16:15:18 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

> I have got build failure similar to recent [Linux aarch64](https://github.com/openjdk/jdk/pull/10265) and [Linux Alpha Zero](https://github.com/openjdk/jdk/pull/10721) failures:
> 
> 
> src/hotspot/os/linux/systemMemoryBarrier_linux.cpp:65:18: error: 'SYS_membarrier' was not declared in this scope
>    return syscall(SYS_membarrier, cmd, flags, cpu_id); // cpu_id only on >= 5.10
>                   ^~~~~~~~~~~~~~ 
> 
> 
> The failure is known to be fixed by adding missing ` SYS_membarrier` definition. The raw constant 375 is taken from the `linux-libc-dev_6.0.2-1_i386.deb' cross-compilation headers:

This looks right, thanks.

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

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10771

From shade at openjdk.org  Thu Oct 20 07:23:35 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 20 Oct 2022 07:23:35 GMT
Subject: RFR: 8295666: Linux x86 build fails after 8292591
In-Reply-To: <86O4_QEMfllgUaUNxfJfamGJsih_YhJAVImz_Hjzbys=.0e24b630-c808-4af4-a9ff-f1e03e531c52@github.com>
References: <O-dFer7ZQtVP0ukIsggOlue5t__qMIFO1CS3t9xwDnY=.e73cfad6-ba70-4b54-bf6d-49f268ecf5c8@github.com>
 <86O4_QEMfllgUaUNxfJfamGJsih_YhJAVImz_Hjzbys=.0e24b630-c808-4af4-a9ff-f1e03e531c52@github.com>
Message-ID: <eLl8F9wbq0gq_Slod-l1y4NPovlL-K1LkR88pyjA0L0=.1f69cc7a-df10-4a64-b235-33fc6f62a18a@github.com>

On Thu, 20 Oct 2022 07:05:10 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Seems okay - and trivial. But I would have expected this to be reported weeks ago - has the linux-x86 build in GHA been failing all this time?

As previous bugs on other arches show, this would only happen if you (cross-)compile with older toolchains. GHA uses a reasonably modern toolchain to never hit it.

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

PR: https://git.openjdk.org/jdk/pull/10771

From mbaesken at openjdk.org  Thu Oct 20 08:20:16 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 20 Oct 2022 08:20:16 GMT
Subject: RFR: JDK-8295710 : unify os::dll_file_extension
Message-ID: <KIZm_XUGrbE0MHg0g73rv9FTdZXOKPR9CkURVixZ01c=.638be20f-7b02-4c3b-9b11-4ca3bedef125@github.com>

The os::dll_file_extension() function could be unified for the different OS platforms.

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

Commit messages:
 - JDK-8295710

Changes: https://git.openjdk.org/jdk/pull/10782/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10782&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295710
  Stats: 11 lines in 5 files changed: 2 ins; 9 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10782.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10782/head:pull/10782

PR: https://git.openjdk.org/jdk/pull/10782

From jpai at openjdk.org  Thu Oct 20 10:01:19 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 20 Oct 2022 10:01:19 GMT
Subject: RFR: 8030616: sun/management/jmxremote/bootstrap/RmiBootstrapTest
 fails intermittently with cannot find a free port [v2]
In-Reply-To: <txAkFc8XUg5T6ZiUjY2oP6NkB77JNeUJLfd26kySiRw=.88881c4f-1cb6-4171-ae11-75ad46e5cb25@github.com>
References: <txAkFc8XUg5T6ZiUjY2oP6NkB77JNeUJLfd26kySiRw=.88881c4f-1cb6-4171-ae11-75ad46e5cb25@github.com>
Message-ID: <mqXVsmAkFvgDvu8oFjAE-qZIqTG9ZsuuTSCAJewcYNo=.68c553c8-d187-44a9-9d87-4547ad50a1c8@github.com>

> Can I please get a review of this test only change which proposes to fix the recent intermittent failures in `RmiBootstrapTest` reported in https://bugs.openjdk.org/browse/JDK-8030616?
> 
> The test has been intermittently failing with `cannot find a free port after 10 tries`.  The tests uses the `jdk.test.lib.Utils.getFreePort()` utility method to get a free port to use in the tests. That port is then used to create and bind a JMX connector server. The issue resides in the fact that the `getFreePort` utility uses loopback address to identify a free port, whereas the JMX connector server uses that identified port to bind to a non-loopback address - there's logic in `sun.rmi.transport.tcp.TCPEndpoint` line 117 which calls `InetAddress.getLocalHost()` which can and does return a non-loopback address. This effectively means that the port that was identified as free (on loopback) may not really be free on (some other address) and a subsequent attempt to bind against it by the connector server will end up with a `BindException`.
> 
> Data collected in failures on the CI system has shown that this is indeed the case and the port that was chosen (for loopback) as free was already used by another process on a different address. The test additionally has logic to attempt retries upto a maximum of 10 times to find a new free port on such `BindException`. Turns out the next free port (on loopback) returned by `jdk.test.lib.Utils.getFreePort()` is incremental and it so happens that the systems where this failed had a process listening on a range of 10 to 12 ports, so these too ended up with `BindException` when the JMX connector server used that port for a different address.
> 
> The commit here makes sure that the JMX connector server in the test is now configured to loopback address as the address to bind to. That way the test uses the correct address (loopback) on which the port was free.
> 
> The commit also has a change to the javadoc of the test utility `jdk.test.lib.Utils.getFreePort()` to clarify that it returns a free port on loopback address. This now matches what the implementation of that method does.
> 
> Multiple test runs after this change hasn't yet run into the failure.

Jaikiran Pai 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 latest from master branch
 - remove unintentionally committed file
 - 8030616: sun/management/jmxremote/bootstrap/RmiBootstrapTest fails intermittently with cannot find a free port

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10322/files
  - new: https://git.openjdk.org/jdk/pull/10322/files/ddfb8c95..01267c65

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10322&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10322&range=00-01

  Stats: 66155 lines in 2020 files changed: 37805 ins; 19685 del; 8665 mod
  Patch: https://git.openjdk.org/jdk/pull/10322.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10322/head:pull/10322

PR: https://git.openjdk.org/jdk/pull/10322

From jpai at openjdk.org  Thu Oct 20 10:01:20 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 20 Oct 2022 10:01:20 GMT
Subject: RFR: 8030616: sun/management/jmxremote/bootstrap/RmiBootstrapTest
 fails intermittently with cannot find a free port
In-Reply-To: <txAkFc8XUg5T6ZiUjY2oP6NkB77JNeUJLfd26kySiRw=.88881c4f-1cb6-4171-ae11-75ad46e5cb25@github.com>
References: <txAkFc8XUg5T6ZiUjY2oP6NkB77JNeUJLfd26kySiRw=.88881c4f-1cb6-4171-ae11-75ad46e5cb25@github.com>
Message-ID: <u_HgyeNwDcLAoB2YG-VY9NX1dMnHThl3iSH9OcwNaK8=.220c5237-a512-4f4f-9c82-50a97ba9fa25@github.com>

On Sun, 18 Sep 2022 11:52:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test only change which proposes to fix the recent intermittent failures in `RmiBootstrapTest` reported in https://bugs.openjdk.org/browse/JDK-8030616?
> 
> The test has been intermittently failing with `cannot find a free port after 10 tries`.  The tests uses the `jdk.test.lib.Utils.getFreePort()` utility method to get a free port to use in the tests. That port is then used to create and bind a JMX connector server. The issue resides in the fact that the `getFreePort` utility uses loopback address to identify a free port, whereas the JMX connector server uses that identified port to bind to a non-loopback address - there's logic in `sun.rmi.transport.tcp.TCPEndpoint` line 117 which calls `InetAddress.getLocalHost()` which can and does return a non-loopback address. This effectively means that the port that was identified as free (on loopback) may not really be free on (some other address) and a subsequent attempt to bind against it by the connector server will end up with a `BindException`.
> 
> Data collected in failures on the CI system has shown that this is indeed the case and the port that was chosen (for loopback) as free was already used by another process on a different address. The test additionally has logic to attempt retries upto a maximum of 10 times to find a new free port on such `BindException`. Turns out the next free port (on loopback) returned by `jdk.test.lib.Utils.getFreePort()` is incremental and it so happens that the systems where this failed had a process listening on a range of 10 to 12 ports, so these too ended up with `BindException` when the JMX connector server used that port for a different address.
> 
> The commit here makes sure that the JMX connector server in the test is now configured to loopback address as the address to bind to. That way the test uses the correct address (loopback) on which the port was free.
> 
> The commit also has a change to the javadoc of the test utility `jdk.test.lib.Utils.getFreePort()` to clarify that it returns a free port on loopback address. This now matches what the implementation of that method does.
> 
> Multiple test runs after this change hasn't yet run into the failure.

Hello Serguei,

Thank you for your review. I was about to integrate this when I just noticed that I had unintentionally included a new empty file in this commit. 

I've now updated this PR to remove that stray file (and no other changes). Could you please review the current state of this PR once more?

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

PR: https://git.openjdk.org/jdk/pull/10322

From jsjolen at openjdk.org  Thu Oct 20 10:13:54 2022
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Thu, 20 Oct 2022 10:13:54 GMT
Subject: RFR: 8295125: os::signal should be os specific
In-Reply-To: <DH7P6SqkigS2I09UR4i_7iQ2gmn28rmlTVPeuAWNQPs=.df77c4e1-2291-4633-b33a-6ab489905e09@github.com>
References: <DH7P6SqkigS2I09UR4i_7iQ2gmn28rmlTVPeuAWNQPs=.df77c4e1-2291-4633-b33a-6ab489905e09@github.com>
Message-ID: <Wn9VI24WLeuJnCl86ekuk-4AWOLWT_Xgle0t6W_ZfOo=.380d6055-e02c-48aa-a416-abfb1c8f6767@github.com>

On Thu, 20 Oct 2022 05:59:33 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This was intended as a significant cleanup RFE but it turned out things were a lot messier than initially envisaged, so the resultant cleanup is quite limited.
> 
> The OS API/namespace was simplified by removing three signal related functions that are not needed in shared code:
>  - signal
>  - user_handler
>  - raise
> The first two were reworked and placed into PosixSignals and os::win32.
> There was no need for a specific XX::raise API as os::raise simply called ::raise.
> 
> On the Posix side we had the basic signal handler installation code in two places:
> 
> 1. Inline in set_signal_handler and used by nearly all the VM signals
> 2. In os::signal which was used by three different "clients"
>   - VM error handler for updating crash handler
>   - VM for installing SIG_BREAK handler
>   - JDK via JVM_RegisterSignal
> 
> This was refactored so that we have:
> 
> 1. PosixSignals::install_sigaction_signal_handler
>   - used by the VM only
>     - set_signal_handler
>     - VM error handler for updating crash handler
>     - VM for installing SIG_BREAK handler
> 
> 2. PosixSignals::install_generic_signal_handler
>   - used by JDK via JVM_RegisterSignal
> 
> The sigaction handlers were all consistently defined as per the posix definition:
>     void func(int signo, siginfo_t *info, void *context);
>   
> 
> On the Windows side we just fixed the incorrect definition of UserHandler and made some consistency changes to use the right signal handler type where possible.
> 
> Thanks.

Thank you for this change, it looks like a good clean up to me.

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

Marked as reviewed by jsjolen (Committer).

PR: https://git.openjdk.org/jdk/pull/10780

From bulasevich at openjdk.org  Thu Oct 20 11:53:54 2022
From: bulasevich at openjdk.org (Boris Ulasevich)
Date: Thu, 20 Oct 2022 11:53:54 GMT
Subject: RFR: 8295666: Linux x86 build fails after 8292591
In-Reply-To: <eLl8F9wbq0gq_Slod-l1y4NPovlL-K1LkR88pyjA0L0=.1f69cc7a-df10-4a64-b235-33fc6f62a18a@github.com>
References: <O-dFer7ZQtVP0ukIsggOlue5t__qMIFO1CS3t9xwDnY=.e73cfad6-ba70-4b54-bf6d-49f268ecf5c8@github.com>
 <86O4_QEMfllgUaUNxfJfamGJsih_YhJAVImz_Hjzbys=.0e24b630-c808-4af4-a9ff-f1e03e531c52@github.com>
 <eLl8F9wbq0gq_Slod-l1y4NPovlL-K1LkR88pyjA0L0=.1f69cc7a-df10-4a64-b235-33fc6f62a18a@github.com>
Message-ID: <BfdZDujXSi-gLbJXosygqv3FjIcUNpqwBIdw6nnOOfk=.bb85628a-716a-4be5-ace5-68d4a1007dcb@github.com>

On Thu, 20 Oct 2022 07:18:12 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Seems okay - and trivial. But I would have expected this to be reported weeks ago - has the linux-x86 build in GHA been failing all this time?

It depends on build machine /usr/include headers. My machine is pretty old.
Thank you!

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

PR: https://git.openjdk.org/jdk/pull/10771

From dholmes at openjdk.org  Thu Oct 20 12:18:48 2022
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 20 Oct 2022 12:18:48 GMT
Subject: RFR: JDK-8295710 : unify os::dll_file_extension
In-Reply-To: <KIZm_XUGrbE0MHg0g73rv9FTdZXOKPR9CkURVixZ01c=.638be20f-7b02-4c3b-9b11-4ca3bedef125@github.com>
References: <KIZm_XUGrbE0MHg0g73rv9FTdZXOKPR9CkURVixZ01c=.638be20f-7b02-4c3b-9b11-4ca3bedef125@github.com>
Message-ID: <m6CeH_1bx16POhqjxChCMJYx9Fj5A4P5KzMDfg8Naj8=.a2c9546b-be55-4a63-a2f2-f9639e15ecca@github.com>

On Thu, 20 Oct 2022 08:12:04 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The os::dll_file_extension() function could be unified for the different OS platforms.

This looks good but I think we can do better :) There is only a single use of `os::dll_file_extension`:

./share/compiler/disassembler.cpp:  int written = jio_snprintf(&buf[offset], sz, "%s%s", hsdis_library_name, os::dll_file_extension());

so we can remove it altogether and just replace with `JNI_LIB_SUFFIX`.

Thanks.

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

Changes requested by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10782

From duke at openjdk.org  Thu Oct 20 14:26:44 2022
From: duke at openjdk.org (Matias Saavedra Silva)
Date: Thu, 20 Oct 2022 14:26:44 GMT
Subject: RFR: 8291443: Remove the PrintSharedDictionary flag
Message-ID: <PtAYxONL_XuczvPDhgSv4TsgFk6N3bosc5DC8flMAxY=.f3e7c242-0be7-439a-8a16-b529b58773f4@github.com>

Obsoleted the unused PrintSharedDictionary flag and removed the flag from all tests. Verified with tier1-4 tests.

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

Commit messages:
 - 8291443: Remove the PrintSharedDictionary flag
 - 8291443: Remove the PrintSharedDictionary flag

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

PR: https://git.openjdk.org/jdk/pull/10596

From ihse at openjdk.org  Thu Oct 20 14:30:56 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 20 Oct 2022 14:30:56 GMT
Subject: RFR: JDK-8295412 : support latest VS2022 MSC_VER in
 abstract_vm_version.cpp
In-Reply-To: <LT3LhNQNqUJ4lcrypL-coeE6jhBDBjg4splNkFpm9zE=.c978ddc2-c463-4b51-8ff5-4bfbafa1fda5@github.com>
References: <2fCXFv9XHrDnz6y9X7MKpOweXWDbOpjpkBFB87LfEdE=.949d476d-7168-4abc-b5ff-7aefcb45e689@github.com>
 <LT3LhNQNqUJ4lcrypL-coeE6jhBDBjg4splNkFpm9zE=.c978ddc2-c463-4b51-8ff5-4bfbafa1fda5@github.com>
Message-ID: <CX4P3vZK9WhCX1s5LtzBjDhCuR7deXUZKvpKYWpX690=.ff4b15f1-60a5-494c-8ed4-b20889eb586b@github.com>

On Tue, 18 Oct 2022 02:04:04 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Currently the latest VS2022 versions are not supported when checking _MSC_VER in abstract_vm_version.cpp, that should be improved.
>> See
>> https://learn.microsoft.com/en-us/cpp/preprocessor/predefined-macros?view=msvc-170
>> https://learn.microsoft.com/de-de/visualstudio/install/visual-studio-build-numbers-and-release-dates?view=vs-2022
>> Visual Studio 2022 version 17.3 1933
>> Visual Studio 2022 version 17.2 1932
>
> Looks fine and trivial.
> 
> It is so annoying we need to do this. :(

@dholmes-ora Why do you do this? If it needs to be done it should probably be extracted by the build system and sent into Hotspot as a define. But before I'd try to fix that, the first question is: do we really need this value?

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

PR: https://git.openjdk.org/jdk/pull/10727

From sspitsyn at openjdk.org  Thu Oct 20 14:34:19 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 20 Oct 2022 14:34:19 GMT
Subject: RFR: 8030616: sun/management/jmxremote/bootstrap/RmiBootstrapTest
 fails intermittently with cannot find a free port [v2]
In-Reply-To: <mqXVsmAkFvgDvu8oFjAE-qZIqTG9ZsuuTSCAJewcYNo=.68c553c8-d187-44a9-9d87-4547ad50a1c8@github.com>
References: <txAkFc8XUg5T6ZiUjY2oP6NkB77JNeUJLfd26kySiRw=.88881c4f-1cb6-4171-ae11-75ad46e5cb25@github.com>
 <mqXVsmAkFvgDvu8oFjAE-qZIqTG9ZsuuTSCAJewcYNo=.68c553c8-d187-44a9-9d87-4547ad50a1c8@github.com>
Message-ID: <EGTFUUFqShqr3vjtYisj2s0-fA1y5nrwC5QYj3gMPyM=.194e98d2-0c98-4899-a7e8-e02f36646315@github.com>

On Thu, 20 Oct 2022 10:01:19 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this test only change which proposes to fix the recent intermittent failures in `RmiBootstrapTest` reported in https://bugs.openjdk.org/browse/JDK-8030616?
>> 
>> The test has been intermittently failing with `cannot find a free port after 10 tries`.  The tests uses the `jdk.test.lib.Utils.getFreePort()` utility method to get a free port to use in the tests. That port is then used to create and bind a JMX connector server. The issue resides in the fact that the `getFreePort` utility uses loopback address to identify a free port, whereas the JMX connector server uses that identified port to bind to a non-loopback address - there's logic in `sun.rmi.transport.tcp.TCPEndpoint` line 117 which calls `InetAddress.getLocalHost()` which can and does return a non-loopback address. This effectively means that the port that was identified as free (on loopback) may not really be free on (some other address) and a subsequent attempt to bind against it by the connector server will end up with a `BindException`.
>> 
>> Data collected in failures on the CI system has shown that this is indeed the case and the port that was chosen (for loopback) as free was already used by another process on a different address. The test additionally has logic to attempt retries upto a maximum of 10 times to find a new free port on such `BindException`. Turns out the next free port (on loopback) returned by `jdk.test.lib.Utils.getFreePort()` is incremental and it so happens that the systems where this failed had a process listening on a range of 10 to 12 ports, so these too ended up with `BindException` when the JMX connector server used that port for a different address.
>> 
>> The commit here makes sure that the JMX connector server in the test is now configured to loopback address as the address to bind to. That way the test uses the correct address (loopback) on which the port was free.
>> 
>> The commit also has a change to the javadoc of the test utility `jdk.test.lib.Utils.getFreePort()` to clarify that it returns a free port on loopback address. This now matches what the implementation of that method does.
>> 
>> Multiple test runs after this change hasn't yet run into the failure.
>
> Jaikiran Pai 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 latest from master branch
>  - remove unintentionally committed file
>  - 8030616: sun/management/jmxremote/bootstrap/RmiBootstrapTest fails intermittently with cannot find a free port

Marked as reviewed by sspitsyn (Reviewer).

Two reviews are required in the Serviceability area.
So, please, wait for one more.

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

PR: https://git.openjdk.org/jdk/pull/10322

From jpai at openjdk.org  Thu Oct 20 14:47:53 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 20 Oct 2022 14:47:53 GMT
Subject: RFR: 8030616: sun/management/jmxremote/bootstrap/RmiBootstrapTest
 fails intermittently with cannot find a free port [v2]
In-Reply-To: <mqXVsmAkFvgDvu8oFjAE-qZIqTG9ZsuuTSCAJewcYNo=.68c553c8-d187-44a9-9d87-4547ad50a1c8@github.com>
References: <txAkFc8XUg5T6ZiUjY2oP6NkB77JNeUJLfd26kySiRw=.88881c4f-1cb6-4171-ae11-75ad46e5cb25@github.com>
 <mqXVsmAkFvgDvu8oFjAE-qZIqTG9ZsuuTSCAJewcYNo=.68c553c8-d187-44a9-9d87-4547ad50a1c8@github.com>
Message-ID: <-jTKvVALRloZ4SS6xWVZYOtfN6IDo4dVDRNhH4OnY_0=.2b6327a2-c5af-491b-9963-65fb9128d22b@github.com>

On Thu, 20 Oct 2022 10:01:19 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this test only change which proposes to fix the recent intermittent failures in `RmiBootstrapTest` reported in https://bugs.openjdk.org/browse/JDK-8030616?
>> 
>> The test has been intermittently failing with `cannot find a free port after 10 tries`.  The tests uses the `jdk.test.lib.Utils.getFreePort()` utility method to get a free port to use in the tests. That port is then used to create and bind a JMX connector server. The issue resides in the fact that the `getFreePort` utility uses loopback address to identify a free port, whereas the JMX connector server uses that identified port to bind to a non-loopback address - there's logic in `sun.rmi.transport.tcp.TCPEndpoint` line 117 which calls `InetAddress.getLocalHost()` which can and does return a non-loopback address. This effectively means that the port that was identified as free (on loopback) may not really be free on (some other address) and a subsequent attempt to bind against it by the connector server will end up with a `BindException`.
>> 
>> Data collected in failures on the CI system has shown that this is indeed the case and the port that was chosen (for loopback) as free was already used by another process on a different address. The test additionally has logic to attempt retries upto a maximum of 10 times to find a new free port on such `BindException`. Turns out the next free port (on loopback) returned by `jdk.test.lib.Utils.getFreePort()` is incremental and it so happens that the systems where this failed had a process listening on a range of 10 to 12 ports, so these too ended up with `BindException` when the JMX connector server used that port for a different address.
>> 
>> The commit here makes sure that the JMX connector server in the test is now configured to loopback address as the address to bind to. That way the test uses the correct address (loopback) on which the port was free.
>> 
>> The commit also has a change to the javadoc of the test utility `jdk.test.lib.Utils.getFreePort()` to clarify that it returns a free port on loopback address. This now matches what the implementation of that method does.
>> 
>> Multiple test runs after this change hasn't yet run into the failure.
>
> Jaikiran Pai 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 latest from master branch
>  - remove unintentionally committed file
>  - 8030616: sun/management/jmxremote/bootstrap/RmiBootstrapTest fails intermittently with cannot find a free port

Thank you again Serguei for the review.

> Two reviews are required in the Serviceability area.
So, please, wait for one more.

I wasn't aware of that. Will certainly wait. I have triggered some tests in our internal CI system too to make sure the latest runs too are clean.

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

PR: https://git.openjdk.org/jdk/pull/10322

From msheppar at openjdk.org  Thu Oct 20 16:16:53 2022
From: msheppar at openjdk.org (Mark Sheppard)
Date: Thu, 20 Oct 2022 16:16:53 GMT
Subject: RFR: 8030616: sun/management/jmxremote/bootstrap/RmiBootstrapTest
 fails intermittently with cannot find a free port [v2]
In-Reply-To: <mqXVsmAkFvgDvu8oFjAE-qZIqTG9ZsuuTSCAJewcYNo=.68c553c8-d187-44a9-9d87-4547ad50a1c8@github.com>
References: <txAkFc8XUg5T6ZiUjY2oP6NkB77JNeUJLfd26kySiRw=.88881c4f-1cb6-4171-ae11-75ad46e5cb25@github.com>
 <mqXVsmAkFvgDvu8oFjAE-qZIqTG9ZsuuTSCAJewcYNo=.68c553c8-d187-44a9-9d87-4547ad50a1c8@github.com>
Message-ID: <eqttcOVozBKxZWZwhgARUS_nMXI3U-dc-vG7RSzKb9A=.d2dac29b-87cd-49e2-9be7-8e792113dcde@github.com>

On Thu, 20 Oct 2022 10:01:19 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this test only change which proposes to fix the recent intermittent failures in `RmiBootstrapTest` reported in https://bugs.openjdk.org/browse/JDK-8030616?
>> 
>> The test has been intermittently failing with `cannot find a free port after 10 tries`.  The tests uses the `jdk.test.lib.Utils.getFreePort()` utility method to get a free port to use in the tests. That port is then used to create and bind a JMX connector server. The issue resides in the fact that the `getFreePort` utility uses loopback address to identify a free port, whereas the JMX connector server uses that identified port to bind to a non-loopback address - there's logic in `sun.rmi.transport.tcp.TCPEndpoint` line 117 which calls `InetAddress.getLocalHost()` which can and does return a non-loopback address. This effectively means that the port that was identified as free (on loopback) may not really be free on (some other address) and a subsequent attempt to bind against it by the connector server will end up with a `BindException`.
>> 
>> Data collected in failures on the CI system has shown that this is indeed the case and the port that was chosen (for loopback) as free was already used by another process on a different address. The test additionally has logic to attempt retries upto a maximum of 10 times to find a new free port on such `BindException`. Turns out the next free port (on loopback) returned by `jdk.test.lib.Utils.getFreePort()` is incremental and it so happens that the systems where this failed had a process listening on a range of 10 to 12 ports, so these too ended up with `BindException` when the JMX connector server used that port for a different address.
>> 
>> The commit here makes sure that the JMX connector server in the test is now configured to loopback address as the address to bind to. That way the test uses the correct address (loopback) on which the port was free.
>> 
>> The commit also has a change to the javadoc of the test utility `jdk.test.lib.Utils.getFreePort()` to clarify that it returns a free port on loopback address. This now matches what the implementation of that method does.
>> 
>> Multiple test runs after this change hasn't yet run into the failure.
>
> Jaikiran Pai 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 latest from master branch
>  - remove unintentionally committed file
>  - 8030616: sun/management/jmxremote/bootstrap/RmiBootstrapTest fails intermittently with cannot find a free port

yes, I think we found the change will be benefial

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

Marked as reviewed by msheppar (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10322

From kbarrett at openjdk.org  Thu Oct 20 16:47:51 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 20 Oct 2022 16:47:51 GMT
Subject: RFR: 8295125: os::signal should be os specific
In-Reply-To: <DH7P6SqkigS2I09UR4i_7iQ2gmn28rmlTVPeuAWNQPs=.df77c4e1-2291-4633-b33a-6ab489905e09@github.com>
References: <DH7P6SqkigS2I09UR4i_7iQ2gmn28rmlTVPeuAWNQPs=.df77c4e1-2291-4633-b33a-6ab489905e09@github.com>
Message-ID: <qZ2IyMS16MHa52MgiF2X8YtNNnYcJrNRXSDcENRMkEE=.48208645-6a52-49e6-a091-b2ee76426028@github.com>

On Thu, 20 Oct 2022 05:59:33 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This was intended as a significant cleanup RFE but it turned out things were a lot messier than initially envisaged, so the resultant cleanup is quite limited.
> 
> The OS API/namespace was simplified by removing three signal related functions that are not needed in shared code:
>  - signal
>  - user_handler
>  - raise
> The first two were reworked and placed into PosixSignals and os::win32.
> There was no need for a specific XX::raise API as os::raise simply called ::raise.
> 
> On the Posix side we had the basic signal handler installation code in two places:
> 
> 1. Inline in set_signal_handler and used by nearly all the VM signals
> 2. In os::signal which was used by three different "clients"
>   - VM error handler for updating crash handler
>   - VM for installing SIG_BREAK handler
>   - JDK via JVM_RegisterSignal
> 
> This was refactored so that we have:
> 
> 1. PosixSignals::install_sigaction_signal_handler
>   - used by the VM only
>     - set_signal_handler
>     - VM error handler for updating crash handler
>     - VM for installing SIG_BREAK handler
> 
> 2. PosixSignals::install_generic_signal_handler
>   - used by JDK via JVM_RegisterSignal
> 
> The sigaction handlers were all consistently defined as per the posix definition:
>     void func(int signo, siginfo_t *info, void *context);
>   
> 
> On the Windows side we just fixed the incorrect definition of UserHandler and made some consistency changes to use the right signal handler type where possible.
> 
> Thanks.

Changes requested by kbarrett (Reviewer).

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

> 875: // - sigAct: the new struct sigaction to be filled in and used
> 876: //           for this signal. The caller must provide this as it
> 877: //           may need to be stored/accessed by that caller.

Maybe I missed something, but I didn't find any places where the caller needs sigAct.

src/hotspot/os/windows/jvm_windows.cpp line 48:

> 46: JVM_ENTRY_NO_ENV(void*, JVM_RegisterSignal(jint sig, void* handler))
> 47:   signal_handler_t newHandler = handler == (void *)2 ?
> 48:                                 CAST_TO_FN_PTR(signal_handler_t, os::win32::user_handler()) :

If `user_handler` returned `signal_handler_t` instead of `void*` then this cast wouldn't be needed.

src/hotspot/os/windows/os_windows.hpp line 128:

> 126:   // signal support
> 127:   static void* install_signal_handler(int sig, signal_handler_t handler);
> 128:   static void* user_handler();

Why does `user_handler` return `void*` instead of `signal_handler_t`?  I'd prefer the handler type be used everywhere except where it really can't be, which I _think_ is only the parameter and return type of JVM_RegisterSignal.  I don't know if that makes some places overly messy though.

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

PR: https://git.openjdk.org/jdk/pull/10780

From coleenp at openjdk.org  Thu Oct 20 19:03:54 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 20 Oct 2022 19:03:54 GMT
Subject: RFR: 8295124: Atomic::add to pointer type may return wrong value
 [v2]
In-Reply-To: <pLyuIraAHIPX4fT5YJG14TSjcoETKZbazFG8EBq3YjI=.3ad05410-1860-4a92-8ae7-a28599f80e26@github.com>
References: <8MVHNI6FliDXtf6MFWwrL9cj3o_VaM98dPj_TuRgkWI=.83b5aee8-f553-48fa-9d86-80d5d54a5a5e@github.com>
 <pLyuIraAHIPX4fT5YJG14TSjcoETKZbazFG8EBq3YjI=.3ad05410-1860-4a92-8ae7-a28599f80e26@github.com>
Message-ID: <61CmZKkB8FD2X3FqZHbZrpqhQCuezDux7uvtURiAGtw=.150175a4-5825-4d4f-84f4-2cb177c7caf2@github.com>

On Wed, 12 Oct 2022 20:38:10 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to the handling of Atomic pointer arithmetic. When
>> the value being modified is a pointer `P*`, the type of the value in the
>> destination passed to the platform operation is `const char*`, so a pointer
>> type whose pointee is size 1. This allows the platform operation to just treat
>> the arithmetic as a simple byte adjustment.
>> 
>> To demonstrate the problem described in the bug (possible incorrect result for
>> Atomic pointer arithmetic) and show that it is now fixed, this change also
>> includes some gtests for Atomic operations, including pointer arithmetic which
>> fails before the change and succeeds after.
>> 
>> Testing: mach5 tier1-3
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   conditionalize 64bit tests on 64bit platform

I get it!  Looks good.

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

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10667

From iklam at openjdk.org  Thu Oct 20 19:04:47 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 20 Oct 2022 19:04:47 GMT
Subject: RFR: 8291443: Remove the PrintSharedDictionary flag
In-Reply-To: <PtAYxONL_XuczvPDhgSv4TsgFk6N3bosc5DC8flMAxY=.f3e7c242-0be7-439a-8a16-b529b58773f4@github.com>
References: <PtAYxONL_XuczvPDhgSv4TsgFk6N3bosc5DC8flMAxY=.f3e7c242-0be7-439a-8a16-b529b58773f4@github.com>
Message-ID: <WIpQqGqUc3mwvCd5QGVEiSBiHxYS0HKcBJW9h4OO-qY=.e85b32bc-4e27-40be-b2ac-c7d61f3e345d@github.com>

On Thu, 6 Oct 2022 14:46:46 GMT, Matias Saavedra Silva <duke at openjdk.org> wrote:

> Obsoleted the unused PrintSharedDictionary flag and removed the flag from all tests. Verified with tier1-4 tests.

Should the issue title be "Obsolete the PrintSharedDictionary flag" instead, since we are not doing a complete removal yet?

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

PR: https://git.openjdk.org/jdk/pull/10596

From kbarrett at openjdk.org  Thu Oct 20 22:29:04 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 20 Oct 2022 22:29:04 GMT
Subject: RFR: 8295124: Atomic::add to pointer type may return wrong value
 [v3]
In-Reply-To: <8MVHNI6FliDXtf6MFWwrL9cj3o_VaM98dPj_TuRgkWI=.83b5aee8-f553-48fa-9d86-80d5d54a5a5e@github.com>
References: <8MVHNI6FliDXtf6MFWwrL9cj3o_VaM98dPj_TuRgkWI=.83b5aee8-f553-48fa-9d86-80d5d54a5a5e@github.com>
Message-ID: <VMdFbOsRuKjNIkcdFRcQhyYxz5ApmbGwaRen-owX6v0=.4f81891c-ba77-466a-9e7f-0a57490afa47@github.com>

> Please review this change to the handling of Atomic pointer arithmetic. When
> the value being modified is a pointer `P*`, the type of the value in the
> destination passed to the platform operation is `const char*`, so a pointer
> type whose pointee is size 1. This allows the platform operation to just treat
> the arithmetic as a simple byte adjustment.
> 
> To demonstrate the problem described in the bug (possible incorrect result for
> Atomic pointer arithmetic) and show that it is now fixed, this change also
> includes some gtests for Atomic operations, including pointer arithmetic which
> fails before the change and succeeds after.
> 
> Testing: mach5 tier1-3

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 four additional commits since the last revision:

 - Merge branch 'master' into test-atomic
 - conditionalize 64bit tests on 64bit platform
 - shared conversion of pointer type
 - add more gtests of Atomic

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10667/files
  - new: https://git.openjdk.org/jdk/pull/10667/files/e44e81cd..87d98eee

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10667&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10667&range=01-02

  Stats: 29786 lines in 1219 files changed: 16401 ins; 8377 del; 5008 mod
  Patch: https://git.openjdk.org/jdk/pull/10667.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10667/head:pull/10667

PR: https://git.openjdk.org/jdk/pull/10667

From kbarrett at openjdk.org  Thu Oct 20 22:29:05 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 20 Oct 2022 22:29:05 GMT
Subject: RFR: 8295124: Atomic::add to pointer type may return wrong value
 [v2]
In-Reply-To: <OWcpe6chcuYaoSVWNC-Jvdcb_BTv78u7e2o6DBNSaqE=.f1def790-f1db-4ea2-95f3-1072526545b4@github.com>
References: <8MVHNI6FliDXtf6MFWwrL9cj3o_VaM98dPj_TuRgkWI=.83b5aee8-f553-48fa-9d86-80d5d54a5a5e@github.com>
 <pLyuIraAHIPX4fT5YJG14TSjcoETKZbazFG8EBq3YjI=.3ad05410-1860-4a92-8ae7-a28599f80e26@github.com>
 <OWcpe6chcuYaoSVWNC-Jvdcb_BTv78u7e2o6DBNSaqE=.f1def790-f1db-4ea2-95f3-1072526545b4@github.com>
Message-ID: <E4_v7zMF1POo3EFmoA-Ff538AFmbTsTFGZZCLp3f408=.3b689691-3df9-4811-975d-e66883a76896@github.com>

On Wed, 19 Oct 2022 07:48:11 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   conditionalize 64bit tests on 64bit platform
>
> Lgtm.

Thanks @tschatzl and @coleenp for reviews.

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

PR: https://git.openjdk.org/jdk/pull/10667

From kbarrett at openjdk.org  Thu Oct 20 22:29:05 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 20 Oct 2022 22:29:05 GMT
Subject: Integrated: 8295124: Atomic::add to pointer type may return wrong
 value
In-Reply-To: <8MVHNI6FliDXtf6MFWwrL9cj3o_VaM98dPj_TuRgkWI=.83b5aee8-f553-48fa-9d86-80d5d54a5a5e@github.com>
References: <8MVHNI6FliDXtf6MFWwrL9cj3o_VaM98dPj_TuRgkWI=.83b5aee8-f553-48fa-9d86-80d5d54a5a5e@github.com>
Message-ID: <uABw5hF1u9YVlxVnl6MaQzWY3KOw8R0Wry5nc3139EA=.03069365-8adb-49dc-99f8-725784b8d6c4@github.com>

On Wed, 12 Oct 2022 01:09:04 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to the handling of Atomic pointer arithmetic. When
> the value being modified is a pointer `P*`, the type of the value in the
> destination passed to the platform operation is `const char*`, so a pointer
> type whose pointee is size 1. This allows the platform operation to just treat
> the arithmetic as a simple byte adjustment.
> 
> To demonstrate the problem described in the bug (possible incorrect result for
> Atomic pointer arithmetic) and show that it is now fixed, this change also
> includes some gtests for Atomic operations, including pointer arithmetic which
> fails before the change and succeeds after.
> 
> Testing: mach5 tier1-3

This pull request has now been integrated.

Changeset: 1164258e
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1164258ec7d173944f48cba368d6c50a07b4c283
Stats:     167 lines in 2 files changed: 152 ins; 3 del; 12 mod

8295124: Atomic::add to pointer type may return wrong value

Reviewed-by: tschatzl, coleenp

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

PR: https://git.openjdk.org/jdk/pull/10667

From dholmes at openjdk.org  Fri Oct 21 01:50:50 2022
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 21 Oct 2022 01:50:50 GMT
Subject: RFR: 8291443: Remove the PrintSharedDictionary flag
In-Reply-To: <PtAYxONL_XuczvPDhgSv4TsgFk6N3bosc5DC8flMAxY=.f3e7c242-0be7-439a-8a16-b529b58773f4@github.com>
References: <PtAYxONL_XuczvPDhgSv4TsgFk6N3bosc5DC8flMAxY=.f3e7c242-0be7-439a-8a16-b529b58773f4@github.com>
Message-ID: <wmGX9PkF2Vb3dwWEbdTbLqHZ-9lalBprZH0YCIFSV5A=.b1a67acf-7296-48da-ab02-b49a457bd657@github.com>

On Thu, 6 Oct 2022 14:46:46 GMT, Matias Saavedra Silva <duke at openjdk.org> wrote:

> Obsoleted the unused PrintSharedDictionary flag and removed the flag from all tests. Verified with tier1-4 tests.

What you have looks good but the flag should also be deleted from:

./src/hotspot/share/cds/cds_globals.hpp

Thanks.

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

Changes requested by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10596

From dholmes at openjdk.org  Fri Oct 21 02:57:18 2022
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 21 Oct 2022 02:57:18 GMT
Subject: RFR: 8295125: os::signal should be os specific
In-Reply-To: <qZ2IyMS16MHa52MgiF2X8YtNNnYcJrNRXSDcENRMkEE=.48208645-6a52-49e6-a091-b2ee76426028@github.com>
References: <DH7P6SqkigS2I09UR4i_7iQ2gmn28rmlTVPeuAWNQPs=.df77c4e1-2291-4633-b33a-6ab489905e09@github.com>
 <qZ2IyMS16MHa52MgiF2X8YtNNnYcJrNRXSDcENRMkEE=.48208645-6a52-49e6-a091-b2ee76426028@github.com>
Message-ID: <XojPIIQM4Z1mg5MvNYOS1x2YLNXZhMtSy8dGPQPyn_k=.cf33a3bd-029d-481d-a2e9-f78d0c7b283b@github.com>

On Thu, 20 Oct 2022 06:29:08 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> This was intended as a significant cleanup RFE but it turned out things were a lot messier than initially envisaged, so the resultant cleanup is quite limited.
>> 
>> The OS API/namespace was simplified by removing three signal related functions that are not needed in shared code:
>>  - signal
>>  - user_handler
>>  - raise
>> The first two were reworked and placed into PosixSignals and os::win32.
>> There was no need for a specific XX::raise API as os::raise simply called ::raise.
>> 
>> On the Posix side we had the basic signal handler installation code in two places:
>> 
>> 1. Inline in set_signal_handler and used by nearly all the VM signals
>> 2. In os::signal which was used by three different "clients"
>>   - VM error handler for updating crash handler
>>   - VM for installing SIG_BREAK handler
>>   - JDK via JVM_RegisterSignal
>> 
>> This was refactored so that we have:
>> 
>> 1. PosixSignals::install_sigaction_signal_handler
>>   - used by the VM only
>>     - set_signal_handler
>>     - VM error handler for updating crash handler
>>     - VM for installing SIG_BREAK handler
>> 
>> 2. PosixSignals::install_generic_signal_handler
>>   - used by JDK via JVM_RegisterSignal
>> 
>> The sigaction handlers were all consistently defined as per the posix definition:
>>     void func(int signo, siginfo_t *info, void *context);
>>   
>> 
>> On the Windows side we just fixed the incorrect definition of UserHandler and made some consistency changes to use the right signal handler type where possible.
>> 
>> Thanks.
>
> src/hotspot/os/windows/jvm_windows.cpp line 48:
> 
>> 46: JVM_ENTRY_NO_ENV(void*, JVM_RegisterSignal(jint sig, void* handler))
>> 47:   signal_handler_t newHandler = handler == (void *)2 ?
>> 48:                                 CAST_TO_FN_PTR(signal_handler_t, os::win32::user_handler()) :
> 
> If `user_handler` returned `signal_handler_t` instead of `void*` then this cast wouldn't be needed.

See previous response.

> src/hotspot/os/windows/os_windows.hpp line 128:
> 
>> 126:   // signal support
>> 127:   static void* install_signal_handler(int sig, signal_handler_t handler);
>> 128:   static void* user_handler();
> 
> Why does `user_handler` return `void*` instead of `signal_handler_t`?  I'd prefer the handler type be used everywhere except where it really can't be, which I _think_ is only the parameter and return type of JVM_RegisterSignal.  I don't know if that makes some places overly messy though.

If `user_handler` returned the actual type you would have to cast it to `void*` in the later comparison, just moving the cast in `JVM_RegisterSignal` but saving the cast in `os::win32::user_handler()`. This seemed a small gain compared to maintaining consistency with the Posix version - but I can change it if you want.

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

PR: https://git.openjdk.org/jdk/pull/10780

From dholmes at openjdk.org  Fri Oct 21 03:03:51 2022
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 21 Oct 2022 03:03:51 GMT
Subject: RFR: 8295125: os::signal should be os specific
In-Reply-To: <Wn9VI24WLeuJnCl86ekuk-4AWOLWT_Xgle0t6W_ZfOo=.380d6055-e02c-48aa-a416-abfb1c8f6767@github.com>
References: <DH7P6SqkigS2I09UR4i_7iQ2gmn28rmlTVPeuAWNQPs=.df77c4e1-2291-4633-b33a-6ab489905e09@github.com>
 <Wn9VI24WLeuJnCl86ekuk-4AWOLWT_Xgle0t6W_ZfOo=.380d6055-e02c-48aa-a416-abfb1c8f6767@github.com>
Message-ID: <OMh_Q3wOKScVxBRD3hN04Ihsc1oIUtcD1jUS0Q5gKGE=.6bcbded4-4179-41f5-813c-7095b883640e@github.com>

On Thu, 20 Oct 2022 10:11:28 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> This was intended as a significant cleanup RFE but it turned out things were a lot messier than initially envisaged, so the resultant cleanup is quite limited.
>> 
>> The OS API/namespace was simplified by removing three signal related functions that are not needed in shared code:
>>  - signal
>>  - user_handler
>>  - raise
>> The first two were reworked and placed into PosixSignals and os::win32.
>> There was no need for a specific XX::raise API as os::raise simply called ::raise.
>> 
>> On the Posix side we had the basic signal handler installation code in two places:
>> 
>> 1. Inline in set_signal_handler and used by nearly all the VM signals
>> 2. In os::signal which was used by three different "clients"
>>   - VM error handler for updating crash handler
>>   - VM for installing SIG_BREAK handler
>>   - JDK via JVM_RegisterSignal
>> 
>> This was refactored so that we have:
>> 
>> 1. PosixSignals::install_sigaction_signal_handler
>>   - used by the VM only
>>     - set_signal_handler
>>     - VM error handler for updating crash handler
>>     - VM for installing SIG_BREAK handler
>> 
>> 2. PosixSignals::install_generic_signal_handler
>>   - used by JDK via JVM_RegisterSignal
>> 
>> The sigaction handlers were all consistently defined as per the posix definition:
>>     void func(int signo, siginfo_t *info, void *context);
>>   
>> 
>> On the Windows side we just fixed the incorrect definition of UserHandler and made some consistency changes to use the right signal handler type where possible.
>> 
>> Thanks.
>
> Thank you for this change, it looks like a good clean up to me.

Thanks for looking at this @jdksjolen  and @kimbarrett !

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

PR: https://git.openjdk.org/jdk/pull/10780

From dholmes at openjdk.org  Fri Oct 21 03:03:53 2022
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 21 Oct 2022 03:03:53 GMT
Subject: RFR: 8295125: os::signal should be os specific
In-Reply-To: <qZ2IyMS16MHa52MgiF2X8YtNNnYcJrNRXSDcENRMkEE=.48208645-6a52-49e6-a091-b2ee76426028@github.com>
References: <DH7P6SqkigS2I09UR4i_7iQ2gmn28rmlTVPeuAWNQPs=.df77c4e1-2291-4633-b33a-6ab489905e09@github.com>
 <qZ2IyMS16MHa52MgiF2X8YtNNnYcJrNRXSDcENRMkEE=.48208645-6a52-49e6-a091-b2ee76426028@github.com>
Message-ID: <JV0klt4NWJ_neqLqSHck40Es2HbaV8wZC8aO6LVYxDY=.9fe846b8-5e94-4073-bd05-841344eca516@github.com>

On Thu, 20 Oct 2022 16:38:47 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> This was intended as a significant cleanup RFE but it turned out things were a lot messier than initially envisaged, so the resultant cleanup is quite limited.
>> 
>> The OS API/namespace was simplified by removing three signal related functions that are not needed in shared code:
>>  - signal
>>  - user_handler
>>  - raise
>> The first two were reworked and placed into PosixSignals and os::win32.
>> There was no need for a specific XX::raise API as os::raise simply called ::raise.
>> 
>> On the Posix side we had the basic signal handler installation code in two places:
>> 
>> 1. Inline in set_signal_handler and used by nearly all the VM signals
>> 2. In os::signal which was used by three different "clients"
>>   - VM error handler for updating crash handler
>>   - VM for installing SIG_BREAK handler
>>   - JDK via JVM_RegisterSignal
>> 
>> This was refactored so that we have:
>> 
>> 1. PosixSignals::install_sigaction_signal_handler
>>   - used by the VM only
>>     - set_signal_handler
>>     - VM error handler for updating crash handler
>>     - VM for installing SIG_BREAK handler
>> 
>> 2. PosixSignals::install_generic_signal_handler
>>   - used by JDK via JVM_RegisterSignal
>> 
>> The sigaction handlers were all consistently defined as per the posix definition:
>>     void func(int signo, siginfo_t *info, void *context);
>>   
>> 
>> On the Windows side we just fixed the incorrect definition of UserHandler and made some consistency changes to use the right signal handler type where possible.
>> 
>> Thanks.
>
> src/hotspot/os/posix/signals_posix.cpp line 877:
> 
>> 875: // - sigAct: the new struct sigaction to be filled in and used
>> 876: //           for this signal. The caller must provide this as it
>> 877: //           may need to be stored/accessed by that caller.
> 
> Maybe I missed something, but I didn't find any places where the caller needs sigAct.

It is in `set_signal_handlers`:

struct sigaction sigAct;
  int ret = PosixSignals::install_sigaction_signal_handler(&sigAct, &oldAct,
                                                           sig, javaSignalHandler);
  assert(ret == 0, "check");
  // Save handler setup for possible later checking
  vm_handlers.set(sig, &sigAct);

and is the reason I pass it in.

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

PR: https://git.openjdk.org/jdk/pull/10780

From dholmes at openjdk.org  Fri Oct 21 03:41:55 2022
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 21 Oct 2022 03:41:55 GMT
Subject: RFR: JDK-8295412 : support latest VS2022 MSC_VER in
 abstract_vm_version.cpp
In-Reply-To: <CX4P3vZK9WhCX1s5LtzBjDhCuR7deXUZKvpKYWpX690=.ff4b15f1-60a5-494c-8ed4-b20889eb586b@github.com>
References: <2fCXFv9XHrDnz6y9X7MKpOweXWDbOpjpkBFB87LfEdE=.949d476d-7168-4abc-b5ff-7aefcb45e689@github.com>
 <LT3LhNQNqUJ4lcrypL-coeE6jhBDBjg4splNkFpm9zE=.c978ddc2-c463-4b51-8ff5-4bfbafa1fda5@github.com>
 <CX4P3vZK9WhCX1s5LtzBjDhCuR7deXUZKvpKYWpX690=.ff4b15f1-60a5-494c-8ed4-b20889eb586b@github.com>
Message-ID: <krZYR0QHqwwGvC_QwdAt2KgM-MFj6pTexKoLhKjmNRQ=.2d8d4a59-775a-4547-b1b7-c7114edb4b0e@github.com>

On Thu, 20 Oct 2022 14:28:28 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Looks fine and trivial.
>> 
>> It is so annoying we need to do this. :(
>
> @dholmes-ora Why do you do this? If it needs to be done it should probably be extracted by the build system and sent into Hotspot as a define. But before I'd try to fix that, the first question is: do we really need this value?

@magicus it is used to report the compiler version in hotspot internal version string (-Xinternalversion) in a clear way i.e.

MS VC++ 17.3 (VS2022)

versus

unknown MS VC++:  1933

 AFAIK MSC doesn't provide any exported means to map the build numbers back to a nice version string like this.

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

PR: https://git.openjdk.org/jdk/pull/10727

From ihse at openjdk.org  Fri Oct 21 07:25:55 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 21 Oct 2022 07:25:55 GMT
Subject: RFR: JDK-8295412 : support latest VS2022 MSC_VER in
 abstract_vm_version.cpp
In-Reply-To: <2fCXFv9XHrDnz6y9X7MKpOweXWDbOpjpkBFB87LfEdE=.949d476d-7168-4abc-b5ff-7aefcb45e689@github.com>
References: <2fCXFv9XHrDnz6y9X7MKpOweXWDbOpjpkBFB87LfEdE=.949d476d-7168-4abc-b5ff-7aefcb45e689@github.com>
Message-ID: <OxAnexOjinV6CgxNinwd5xhenPqNP0RcMZFpFkp8agY=.1b81c5a7-69bd-41db-a415-d5c7569f4241@github.com>

On Mon, 17 Oct 2022 13:19:48 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently the latest VS2022 versions are not supported when checking _MSC_VER in abstract_vm_version.cpp, that should be improved.
> See
> https://learn.microsoft.com/en-us/cpp/preprocessor/predefined-macros?view=msvc-170
> https://learn.microsoft.com/de-de/visualstudio/install/visual-studio-build-numbers-and-release-dates?view=vs-2022
> Visual Studio 2022 version 17.3 1933
> Visual Studio 2022 version 17.2 1932

Sorry, I was unclear. Yes, I know it is used for the version string. 

My question was more: I know this has traditionally been included in the version string, but is it *really* needed? What is the use case for having the compiler version? I can fully understand if this is included in a hs_err file, but in that case, maybe the simple "1933" value can suffice, and if the compiler version is suspected to be bad, we can look it up in a table.

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

PR: https://git.openjdk.org/jdk/pull/10727

From jpai at openjdk.org  Fri Oct 21 08:29:51 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 21 Oct 2022 08:29:51 GMT
Subject: RFR: 8030616: sun/management/jmxremote/bootstrap/RmiBootstrapTest
 fails intermittently with cannot find a free port [v2]
In-Reply-To: <mqXVsmAkFvgDvu8oFjAE-qZIqTG9ZsuuTSCAJewcYNo=.68c553c8-d187-44a9-9d87-4547ad50a1c8@github.com>
References: <txAkFc8XUg5T6ZiUjY2oP6NkB77JNeUJLfd26kySiRw=.88881c4f-1cb6-4171-ae11-75ad46e5cb25@github.com>
 <mqXVsmAkFvgDvu8oFjAE-qZIqTG9ZsuuTSCAJewcYNo=.68c553c8-d187-44a9-9d87-4547ad50a1c8@github.com>
Message-ID: <7zx8mBlRbPNKN4gNtAtiD3Ha1P5iaw4j4VeUsy0LfPA=.ed01337f-83bf-496a-803e-ff79aef67b4e@github.com>

On Thu, 20 Oct 2022 10:01:19 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this test only change which proposes to fix the recent intermittent failures in `RmiBootstrapTest` reported in https://bugs.openjdk.org/browse/JDK-8030616?
>> 
>> The test has been intermittently failing with `cannot find a free port after 10 tries`.  The tests uses the `jdk.test.lib.Utils.getFreePort()` utility method to get a free port to use in the tests. That port is then used to create and bind a JMX connector server. The issue resides in the fact that the `getFreePort` utility uses loopback address to identify a free port, whereas the JMX connector server uses that identified port to bind to a non-loopback address - there's logic in `sun.rmi.transport.tcp.TCPEndpoint` line 117 which calls `InetAddress.getLocalHost()` which can and does return a non-loopback address. This effectively means that the port that was identified as free (on loopback) may not really be free on (some other address) and a subsequent attempt to bind against it by the connector server will end up with a `BindException`.
>> 
>> Data collected in failures on the CI system has shown that this is indeed the case and the port that was chosen (for loopback) as free was already used by another process on a different address. The test additionally has logic to attempt retries upto a maximum of 10 times to find a new free port on such `BindException`. Turns out the next free port (on loopback) returned by `jdk.test.lib.Utils.getFreePort()` is incremental and it so happens that the systems where this failed had a process listening on a range of 10 to 12 ports, so these too ended up with `BindException` when the JMX connector server used that port for a different address.
>> 
>> The commit here makes sure that the JMX connector server in the test is now configured to loopback address as the address to bind to. That way the test uses the correct address (loopback) on which the port was free.
>> 
>> The commit also has a change to the javadoc of the test utility `jdk.test.lib.Utils.getFreePort()` to clarify that it returns a free port on loopback address. This now matches what the implementation of that method does.
>> 
>> Multiple test runs after this change hasn't yet run into the failure.
>
> Jaikiran Pai 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 latest from master branch
>  - remove unintentionally committed file
>  - 8030616: sun/management/jmxremote/bootstrap/RmiBootstrapTest fails intermittently with cannot find a free port

Thank you Mark for the review.

The CI tests for this came back fine.

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

PR: https://git.openjdk.org/jdk/pull/10322

From jpai at openjdk.org  Fri Oct 21 08:32:01 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 21 Oct 2022 08:32:01 GMT
Subject: Integrated: 8030616:
 sun/management/jmxremote/bootstrap/RmiBootstrapTest fails intermittently with
 cannot find a free port
In-Reply-To: <txAkFc8XUg5T6ZiUjY2oP6NkB77JNeUJLfd26kySiRw=.88881c4f-1cb6-4171-ae11-75ad46e5cb25@github.com>
References: <txAkFc8XUg5T6ZiUjY2oP6NkB77JNeUJLfd26kySiRw=.88881c4f-1cb6-4171-ae11-75ad46e5cb25@github.com>
Message-ID: <_IC9ikiTepKTv7KU3fGXyC6i8hh3GKUJAg9xCVjgzfc=.6184ddb6-7bd2-4059-a7cc-1d9028d7a86d@github.com>

On Sun, 18 Sep 2022 11:52:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test only change which proposes to fix the recent intermittent failures in `RmiBootstrapTest` reported in https://bugs.openjdk.org/browse/JDK-8030616?
> 
> The test has been intermittently failing with `cannot find a free port after 10 tries`.  The tests uses the `jdk.test.lib.Utils.getFreePort()` utility method to get a free port to use in the tests. That port is then used to create and bind a JMX connector server. The issue resides in the fact that the `getFreePort` utility uses loopback address to identify a free port, whereas the JMX connector server uses that identified port to bind to a non-loopback address - there's logic in `sun.rmi.transport.tcp.TCPEndpoint` line 117 which calls `InetAddress.getLocalHost()` which can and does return a non-loopback address. This effectively means that the port that was identified as free (on loopback) may not really be free on (some other address) and a subsequent attempt to bind against it by the connector server will end up with a `BindException`.
> 
> Data collected in failures on the CI system has shown that this is indeed the case and the port that was chosen (for loopback) as free was already used by another process on a different address. The test additionally has logic to attempt retries upto a maximum of 10 times to find a new free port on such `BindException`. Turns out the next free port (on loopback) returned by `jdk.test.lib.Utils.getFreePort()` is incremental and it so happens that the systems where this failed had a process listening on a range of 10 to 12 ports, so these too ended up with `BindException` when the JMX connector server used that port for a different address.
> 
> The commit here makes sure that the JMX connector server in the test is now configured to loopback address as the address to bind to. That way the test uses the correct address (loopback) on which the port was free.
> 
> The commit also has a change to the javadoc of the test utility `jdk.test.lib.Utils.getFreePort()` to clarify that it returns a free port on loopback address. This now matches what the implementation of that method does.
> 
> Multiple test runs after this change hasn't yet run into the failure.

This pull request has now been integrated.

Changeset: 8b010e01
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8b010e014c44ffb728b7a8343d3298466f5252fa
Stats:     7 lines in 2 files changed: 5 ins; 0 del; 2 mod

8030616: sun/management/jmxremote/bootstrap/RmiBootstrapTest fails intermittently with cannot find a free port

Reviewed-by: sspitsyn, msheppar

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

PR: https://git.openjdk.org/jdk/pull/10322

From bulasevich at openjdk.org  Fri Oct 21 09:01:59 2022
From: bulasevich at openjdk.org (Boris Ulasevich)
Date: Fri, 21 Oct 2022 09:01:59 GMT
Subject: Integrated: 8295666: Linux x86 build fails after 8292591
In-Reply-To: <O-dFer7ZQtVP0ukIsggOlue5t__qMIFO1CS3t9xwDnY=.e73cfad6-ba70-4b54-bf6d-49f268ecf5c8@github.com>
References: <O-dFer7ZQtVP0ukIsggOlue5t__qMIFO1CS3t9xwDnY=.e73cfad6-ba70-4b54-bf6d-49f268ecf5c8@github.com>
Message-ID: <-YezWMhTcmU9cZNjVMGvGtOWs0F8IVAho-EMK62SAnI=.8f352eb7-9d68-4ebe-9926-03dc8bc0fef7@github.com>

On Wed, 19 Oct 2022 16:15:18 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

> I have got build failure similar to recent [Linux aarch64](https://github.com/openjdk/jdk/pull/10265) and [Linux Alpha Zero](https://github.com/openjdk/jdk/pull/10721) failures:
> 
> 
> src/hotspot/os/linux/systemMemoryBarrier_linux.cpp:65:18: error: 'SYS_membarrier' was not declared in this scope
>    return syscall(SYS_membarrier, cmd, flags, cpu_id); // cpu_id only on >= 5.10
>                   ^~~~~~~~~~~~~~ 
> 
> 
> The failure is known to be fixed by adding missing ` SYS_membarrier` definition. The raw constant 375 is taken from the `linux-libc-dev_6.0.2-1_i386.deb' cross-compilation headers:

This pull request has now been integrated.

Changeset: 15bebf92
Author:    Boris Ulasevich <bulasevich at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/15bebf922fb3fe46b755c85bc0a459b3c1e34c98
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8295666: Linux x86 build fails after 8292591

Reviewed-by: dholmes, shade

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

PR: https://git.openjdk.org/jdk/pull/10771

From rehn at openjdk.org  Fri Oct 21 10:25:58 2022
From: rehn at openjdk.org (Robbin Ehn)
Date: Fri, 21 Oct 2022 10:25:58 GMT
Subject: RFR: 8293873: Centralize the initialization of UL [v2]
In-Reply-To: <x5NoG1WoM-W7-_Cg_P6kqMJJE0E_tv2KxJaBvjRuxUY=.fe7852b8-c68d-478a-9568-eec0a8d1da6e@github.com>
References: <dtoar0JxoD5Fukir-9tE3mivhVRXuO7-Ckg0N5t9ZdU=.ad9b3ba9-ccf8-4591-af97-dda12a10d9dc@github.com>
 <x5NoG1WoM-W7-_Cg_P6kqMJJE0E_tv2KxJaBvjRuxUY=.fe7852b8-c68d-478a-9568-eec0a8d1da6e@github.com>
Message-ID: <eeFYq_S9GsZWT-uvDvh97jw__YJGCc9c_-1jg0_Rk2M=.eb6ccfea-02b7-4303-8da4-432e377c0422@github.com>

On Fri, 23 Sep 2022 10:38:21 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi,
>> 
>> May I please have a review of this change? It moves around some of the initialization code of UL to one place (namely `LogConfiguration::initialize`). It does not change how UL works after VM start up, and it should not change how UL works after VM shut down, but it might change how UL works before VM start up. I don't believe that this causes any breakage.
>> 
>> Tier 2 and 3 tests are currently running, all green so far.
>> 
>> Some more context is available at https://bugs.openjdk.org/browse/JDK-8293873
>
> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright years

Looks like a good improvement and Thomas is happy, so I'm happy.

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

Marked as reviewed by rehn (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10307

From jsjolen at openjdk.org  Fri Oct 21 11:12:51 2022
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Fri, 21 Oct 2022 11:12:51 GMT
Subject: RFR: 8286431: Do not use resource array in posix
 mmap_attach_shared() [v2]
In-Reply-To: <NxfDFaKfwF3VckkQaIHw3rkgDQfcT3d4WAwB--lVqyQ=.31494c92-7e8e-4eb1-87a8-5faeb9d2beda@github.com>
References: <ilMQJwSkR-8ZsXHtlFKIXyvKf63185rovLf5l28KBnc=.8cf85ba9-93d3-4ba5-bdda-7de280f1583b@github.com>
 <NxfDFaKfwF3VckkQaIHw3rkgDQfcT3d4WAwB--lVqyQ=.31494c92-7e8e-4eb1-87a8-5faeb9d2beda@github.com>
Message-ID: <QXYrlLNXULrnj_kF1YrvWxEy6y0WepqFiOlDslLFp0g=.83e67f4e-f3ed-47ff-89d6-5369fa8cef10@github.com>

On Thu, 13 Oct 2022 19:57:04 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Please review this small clean up
>> 
>> perfMemory_posix.cpp uses a lot of explicit C heap alloc/free because the function may be called during early VM bootstrap, before ResourceMark can be used.
>> 
>> However, we have a single odd use of resource allocation in this file. It's supposed to work with Java exceptions. However, the code actually makes an explicitly exception check, so there's no need to do the resource alloc at all.
>> 
>> Also, there's no need to close the fd in case of exception.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @dholmes-ora comments

This looks good to me, thanks for the changes.

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

Marked as reviewed by jsjolen (Committer).

PR: https://git.openjdk.org/jdk/pull/10686

From duke at openjdk.org  Fri Oct 21 17:51:48 2022
From: duke at openjdk.org (Matias Saavedra Silva)
Date: Fri, 21 Oct 2022 17:51:48 GMT
Subject: RFR: 8291443: Remove the PrintSharedDictionary flag [v2]
In-Reply-To: <PtAYxONL_XuczvPDhgSv4TsgFk6N3bosc5DC8flMAxY=.f3e7c242-0be7-439a-8a16-b529b58773f4@github.com>
References: <PtAYxONL_XuczvPDhgSv4TsgFk6N3bosc5DC8flMAxY=.f3e7c242-0be7-439a-8a16-b529b58773f4@github.com>
Message-ID: <9LqZzJyCR4TyeY7O84dDW9iGLDNa7-jRvgqp8QQrUII=.6b9d451b-6cf9-47c4-94e4-65cf3ca62d31@github.com>

> Obsoleted the unused PrintSharedDictionary flag and removed the flag from all tests. Verified with tier1-4 tests.

Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:

  Removed flag from cds_globals

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10596/files
  - new: https://git.openjdk.org/jdk/pull/10596/files/b000c0db..55da0875

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10596&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10596&range=00-01

  Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10596.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10596/head:pull/10596

PR: https://git.openjdk.org/jdk/pull/10596

From coleenp at openjdk.org  Fri Oct 21 18:27:56 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 21 Oct 2022 18:27:56 GMT
Subject: RFR: 8295713: runtime/ParallelLoad/SuperWait/SuperWaitTest.java fails
 intermittently on Windows
Message-ID: <tk88whD-nXj1I8Ss1VpzWs85bLU162gSZU0RhlBfvYk=.670d0dd4-e891-4a9b-95b9-87716fc6a92e@github.com>

I added another semaphore so the test will run in the order I want it to.  Alternate suggestions or corrections welcome.
Running with GHA, and our tier1 in progress.

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

Commit messages:
 - 8295713: runtime/ParallelLoad/SuperWait/SuperWaitTest.java fails intermittently on Windows

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

PR: https://git.openjdk.org/jdk/pull/10822

From pchilanomate at openjdk.org  Fri Oct 21 20:45:48 2022
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 21 Oct 2022 20:45:48 GMT
Subject: RFR: 8295713: runtime/ParallelLoad/SuperWait/SuperWaitTest.java
 fails intermittently on Windows
In-Reply-To: <tk88whD-nXj1I8Ss1VpzWs85bLU162gSZU0RhlBfvYk=.670d0dd4-e891-4a9b-95b9-87716fc6a92e@github.com>
References: <tk88whD-nXj1I8Ss1VpzWs85bLU162gSZU0RhlBfvYk=.670d0dd4-e891-4a9b-95b9-87716fc6a92e@github.com>
Message-ID: <hUGe7y39xBDH4PB8IxzkNuslIW8E5EvCY0RGyRQPvH0=.f7d2bd3a-1203-404b-bf5f-d0ac674ef170@github.com>

On Fri, 21 Oct 2022 18:19:36 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> I added another semaphore so the test will run in the order I want it to.  Alternate suggestions or corrections welcome.
> Running with GHA, and our tier1 in progress.

Looks good to me. But I think mainSync is not needed now. Thread 1 will always get to wait() before Thread 2 reaches the notify()?call while loading D, so that should be enough to avoid the lost notification issue.

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

Marked as reviewed by pchilanomate (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10822

From coleenp at openjdk.org  Fri Oct 21 23:10:19 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 21 Oct 2022 23:10:19 GMT
Subject: RFR: 8295713: runtime/ParallelLoad/SuperWait/SuperWaitTest.java
 fails intermittently on Windows [v2]
In-Reply-To: <tk88whD-nXj1I8Ss1VpzWs85bLU162gSZU0RhlBfvYk=.670d0dd4-e891-4a9b-95b9-87716fc6a92e@github.com>
References: <tk88whD-nXj1I8Ss1VpzWs85bLU162gSZU0RhlBfvYk=.670d0dd4-e891-4a9b-95b9-87716fc6a92e@github.com>
Message-ID: <kqJpgk2m0RktSdcRsrJvk3t8IPU-NW82cVO69b9mdv0=.3ebbc092-070a-4f3d-a2df-222a2569ef29@github.com>

> I added another semaphore so the test will run in the order I want it to.  Alternate suggestions or corrections welcome.
> Running with GHA, and our tier1 in progress.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Thanks Patricio

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10822/files
  - new: https://git.openjdk.org/jdk/pull/10822/files/6c4eced2..d0089bb7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10822&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10822&range=00-01

  Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10822.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10822/head:pull/10822

PR: https://git.openjdk.org/jdk/pull/10822

From coleenp at openjdk.org  Fri Oct 21 23:10:19 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 21 Oct 2022 23:10:19 GMT
Subject: RFR: 8295713: runtime/ParallelLoad/SuperWait/SuperWaitTest.java
 fails intermittently on Windows
In-Reply-To: <tk88whD-nXj1I8Ss1VpzWs85bLU162gSZU0RhlBfvYk=.670d0dd4-e891-4a9b-95b9-87716fc6a92e@github.com>
References: <tk88whD-nXj1I8Ss1VpzWs85bLU162gSZU0RhlBfvYk=.670d0dd4-e891-4a9b-95b9-87716fc6a92e@github.com>
Message-ID: <OnnoKGoEBElIQeJikpdOh9yo1BngFqzDKGmuNBs1Wwk=.fa43c1c5-75f5-4da5-9642-50e26d9fb6af@github.com>

On Fri, 21 Oct 2022 18:19:36 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> I added another semaphore so the test will run in the order I want it to.  Alternate suggestions or corrections welcome.
> Running with GHA, and our tier1 in progress.

Thanks Patricio, I don't need mainSync anymore because the first thread will wait.

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

PR: https://git.openjdk.org/jdk/pull/10822

From dholmes at openjdk.org  Mon Oct 24 00:23:25 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 24 Oct 2022 00:23:25 GMT
Subject: RFR: 8295713: runtime/ParallelLoad/SuperWait/SuperWaitTest.java
 fails intermittently on Windows [v2]
In-Reply-To: <kqJpgk2m0RktSdcRsrJvk3t8IPU-NW82cVO69b9mdv0=.3ebbc092-070a-4f3d-a2df-222a2569ef29@github.com>
References: <tk88whD-nXj1I8Ss1VpzWs85bLU162gSZU0RhlBfvYk=.670d0dd4-e891-4a9b-95b9-87716fc6a92e@github.com>
 <kqJpgk2m0RktSdcRsrJvk3t8IPU-NW82cVO69b9mdv0=.3ebbc092-070a-4f3d-a2df-222a2569ef29@github.com>
Message-ID: <1NBKaaEQokixjafhutj4zTD-YOI2XipwWuK_IKpRY8M=.cbea0285-de9d-4899-ba29-e24e9b611ca3@github.com>

On Fri, 21 Oct 2022 23:10:19 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I added another semaphore so the test will run in the order I want it to.  Alternate suggestions or corrections welcome.
>> Running with GHA, and our tier1 in progress.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Thanks Patricio

Your are doing an unconditional `wait()` which in theory could be affected by a spurious wakeup. If you actually do:

while (!DisLoading) {
  wait();
}

with a corresponding

DisLoading = true;
notify();

then I think you could dispense with the semaphore altogether.

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

PR: https://git.openjdk.org/jdk/pull/10822

From kbarrett at openjdk.org  Mon Oct 24 03:53:58 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 24 Oct 2022 03:53:58 GMT
Subject: RFR: 8295125: os::signal should be os specific
In-Reply-To: <JV0klt4NWJ_neqLqSHck40Es2HbaV8wZC8aO6LVYxDY=.9fe846b8-5e94-4073-bd05-841344eca516@github.com>
References: <DH7P6SqkigS2I09UR4i_7iQ2gmn28rmlTVPeuAWNQPs=.df77c4e1-2291-4633-b33a-6ab489905e09@github.com>
 <qZ2IyMS16MHa52MgiF2X8YtNNnYcJrNRXSDcENRMkEE=.48208645-6a52-49e6-a091-b2ee76426028@github.com>
 <JV0klt4NWJ_neqLqSHck40Es2HbaV8wZC8aO6LVYxDY=.9fe846b8-5e94-4073-bd05-841344eca516@github.com>
Message-ID: <mhabURNyqwXxEHhV96iM5lx46hIz_F7TlSGMcSQEmQ0=.c4efdf07-d32c-4b3b-a44f-96f9132f0838@github.com>

On Fri, 21 Oct 2022 02:59:22 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/os/posix/signals_posix.cpp line 877:
>> 
>>> 875: // - sigAct: the new struct sigaction to be filled in and used
>>> 876: //           for this signal. The caller must provide this as it
>>> 877: //           may need to be stored/accessed by that caller.
>> 
>> Maybe I missed something, but I didn't find any places where the caller needs sigAct.
>
> It is in `set_signal_handlers`:
> 
> struct sigaction sigAct;
>   int ret = PosixSignals::install_sigaction_signal_handler(&sigAct, &oldAct,
>                                                            sig, javaSignalHandler);
>   assert(ret == 0, "check");
>   // Save handler setup for possible later checking
>   vm_handlers.set(sig, &sigAct);
> 
> and is the reason I pass it in.

Yes, I missed that.

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

PR: https://git.openjdk.org/jdk/pull/10780

From dholmes at openjdk.org  Mon Oct 24 04:50:40 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 24 Oct 2022 04:50:40 GMT
Subject: RFR: 8291443: Remove the PrintSharedDictionary flag [v2]
In-Reply-To: <9LqZzJyCR4TyeY7O84dDW9iGLDNa7-jRvgqp8QQrUII=.6b9d451b-6cf9-47c4-94e4-65cf3ca62d31@github.com>
References: <PtAYxONL_XuczvPDhgSv4TsgFk6N3bosc5DC8flMAxY=.f3e7c242-0be7-439a-8a16-b529b58773f4@github.com>
 <9LqZzJyCR4TyeY7O84dDW9iGLDNa7-jRvgqp8QQrUII=.6b9d451b-6cf9-47c4-94e4-65cf3ca62d31@github.com>
Message-ID: <2aqMgkf2a-Srj1a1KX2QwWoAWQV6aCxjh60fbycJLd4=.b8699330-2701-4179-ac98-e6c871f92710@github.com>

On Fri, 21 Oct 2022 17:51:48 GMT, Matias Saavedra Silva <duke at openjdk.org> wrote:

>> Obsoleted the unused PrintSharedDictionary flag and removed the flag from all tests. Verified with tier1-4 tests.
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed flag from cds_globals

Looks good. Thanks.

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10596

From dholmes at openjdk.org  Mon Oct 24 06:06:52 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 24 Oct 2022 06:06:52 GMT
Subject: RFR: JDK-8295412 : support latest VS2022 MSC_VER in
 abstract_vm_version.cpp
In-Reply-To: <OxAnexOjinV6CgxNinwd5xhenPqNP0RcMZFpFkp8agY=.1b81c5a7-69bd-41db-a415-d5c7569f4241@github.com>
References: <2fCXFv9XHrDnz6y9X7MKpOweXWDbOpjpkBFB87LfEdE=.949d476d-7168-4abc-b5ff-7aefcb45e689@github.com>
 <OxAnexOjinV6CgxNinwd5xhenPqNP0RcMZFpFkp8agY=.1b81c5a7-69bd-41db-a415-d5c7569f4241@github.com>
Message-ID: <U8G_1HKBDuuppkMfuN_H8j0pll2I1Kl6M_lVViOgJdo=.43a5b3c5-1389-4526-8797-c81e3008115d@github.com>

On Fri, 21 Oct 2022 07:23:22 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> is it really needed?

I assume it was desirable to have it hence it was added. I can't attest to the exact why. It was added by JDK-4286737 back in March 2000.

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

PR: https://git.openjdk.org/jdk/pull/10727

From dholmes at openjdk.org  Mon Oct 24 06:58:37 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 24 Oct 2022 06:58:37 GMT
Subject: RFR: 8291443: Remove the PrintSharedDictionary flag
In-Reply-To: <WIpQqGqUc3mwvCd5QGVEiSBiHxYS0HKcBJW9h4OO-qY=.e85b32bc-4e27-40be-b2ac-c7d61f3e345d@github.com>
References: <PtAYxONL_XuczvPDhgSv4TsgFk6N3bosc5DC8flMAxY=.f3e7c242-0be7-439a-8a16-b529b58773f4@github.com>
 <WIpQqGqUc3mwvCd5QGVEiSBiHxYS0HKcBJW9h4OO-qY=.e85b32bc-4e27-40be-b2ac-c7d61f3e345d@github.com>
Message-ID: <Fhu25VaELx8RhQA0SVV7uEh3kZzoOODkGASVSW6NtzQ=.b7a67ff7-f1ab-49e4-bf9b-a66fc2bd52f8@github.com>

On Thu, 20 Oct 2022 19:02:23 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Obsoleted the unused PrintSharedDictionary flag and removed the flag from all tests. Verified with tier1-4 tests.
>
> Should the issue title be "Obsolete the PrintSharedDictionary flag" instead, since we are not doing a complete removal yet?

As @iklam suggested it would be more precise to change the bug title to say "Obsolete" rather than "Remove". Thanks.

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

PR: https://git.openjdk.org/jdk/pull/10596

From dholmes at openjdk.org  Mon Oct 24 07:14:01 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 24 Oct 2022 07:14:01 GMT
Subject: RFR: 8292695: SIGQUIT and jcmd attaching mechanism does not work
 with signal chaining library [v4]
In-Reply-To: <DwmpYkb2Nc1Pm1DN2WnCOli_yyCRqjPeVZDBIkkGkMg=.f06bd645-519e-49c9-b642-3affa0e62179@github.com>
References: <SmfKgkQzLCjbcgPxTAEDnB9l-5j6OvRATc-Ub-07uYw=.7f084d20-c544-4cf1-943f-79df959c518d@github.com>
 <2ZrLsMRBHy8SbBdRvvSBkhYKkHKpPxi1TMZlY9T4EaY=.18cfd26e-0dfa-4dc8-aea5-df38daff5774@github.com>
 <Dk6t68vd4hTNEFJX3NVBs4f8PR_5K8igfJVNvYeFwbY=.c370d664-701e-4cf8-aebf-40bdd1802133@github.com>
 <DwmpYkb2Nc1Pm1DN2WnCOli_yyCRqjPeVZDBIkkGkMg=.f06bd645-519e-49c9-b642-3affa0e62179@github.com>
Message-ID: <VByPwYvSlDFJEQ1XId0gH6ueYpLsomtwOz6bJyt6ybo=.76854dff-961e-469f-b665-0a6fab2ae666@github.com>

On Tue, 20 Sep 2022 05:26:25 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Messing around with initialization order always makes me very nervous. While this may have solved the problem at hand it is far from clear to me that it has not introduced unexpected behaviour in other situations - situations that our testing is unlikely to expose.
>
>> Messing around with initialization order always makes me very nervous. While this may have solved the problem at hand it is far from clear to me that it has not introduced unexpected behaviour in other situations - situations that our testing is unlikely to expose.
> 
> Hmm, we put a lot of work and time into this solution. While I acknowledge this is a difficult area, so are many others in hotspot which we are not shy of changing. And we did not change the coding on a whim - the proposed solution IMHO is better than the assortment of piled-on hotfixes we had before and dissolves quite a bit of complexity. That makes the code easier to understand and maintain in the long run. @caoman also provided a regression test, so that's covered too.
> 
> But if you have concrete misgivings about the proposed solution, let's discuss it.

@tstuefe IIUC the earlier proposal from @caoman  simply moved the setting of the BREAK_HANDLER to inside `jdk_misc_signal_init`. But you then had it moved instead to `install_signal_handlers`, which then required that `install_signal_handlers` get moved after `jdk_misc_signal_init` as the `UserHandler` depends on initialization that occurs there. I don't understand why that complex double-shuffle was needed/wanted instead of what Man proposed??

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

PR: https://git.openjdk.org/jdk/pull/9955

From stuefe at openjdk.org  Mon Oct 24 07:41:58 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 24 Oct 2022 07:41:58 GMT
Subject: RFR: 8292695: SIGQUIT and jcmd attaching mechanism does not work
 with signal chaining library [v4]
In-Reply-To: <DwmpYkb2Nc1Pm1DN2WnCOli_yyCRqjPeVZDBIkkGkMg=.f06bd645-519e-49c9-b642-3affa0e62179@github.com>
References: <SmfKgkQzLCjbcgPxTAEDnB9l-5j6OvRATc-Ub-07uYw=.7f084d20-c544-4cf1-943f-79df959c518d@github.com>
 <2ZrLsMRBHy8SbBdRvvSBkhYKkHKpPxi1TMZlY9T4EaY=.18cfd26e-0dfa-4dc8-aea5-df38daff5774@github.com>
 <Dk6t68vd4hTNEFJX3NVBs4f8PR_5K8igfJVNvYeFwbY=.c370d664-701e-4cf8-aebf-40bdd1802133@github.com>
 <DwmpYkb2Nc1Pm1DN2WnCOli_yyCRqjPeVZDBIkkGkMg=.f06bd645-519e-49c9-b642-3affa0e62179@github.com>
Message-ID: <vv5DiV5ys9HgLQB7IhUGlk8mhv03abOIJwWJv45OBcM=.de952b49-a42d-49af-a1d9-8b852f85bbc3@github.com>

On Tue, 20 Sep 2022 05:26:25 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Messing around with initialization order always makes me very nervous. While this may have solved the problem at hand it is far from clear to me that it has not introduced unexpected behaviour in other situations - situations that our testing is unlikely to expose.
>
>> Messing around with initialization order always makes me very nervous. While this may have solved the problem at hand it is far from clear to me that it has not introduced unexpected behaviour in other situations - situations that our testing is unlikely to expose.
> 
> Hmm, we put a lot of work and time into this solution. While I acknowledge this is a difficult area, so are many others in hotspot which we are not shy of changing. And we did not change the coding on a whim - the proposed solution IMHO is better than the assortment of piled-on hotfixes we had before and dissolves quite a bit of complexity. That makes the code easier to understand and maintain in the long run. @caoman also provided a regression test, so that's covered too.
> 
> But if you have concrete misgivings about the proposed solution, let's discuss it.

> @tstuefe IIUC the earlier proposal from @caoman simply moved the setting of the BREAK_HANDLER to inside `jdk_misc_signal_init`. But you then had it moved instead to `install_signal_handlers`, which then required that `install_signal_handlers` get moved after `jdk_misc_signal_init` as the `UserHandler` depends on initialization that occurs there. I don't understand why that complex double-shuffle was needed/wanted instead of what Man proposed??

See my comment at https://github.com/openjdk/jdk/pull/9955#issuecomment-1239643684. The original solution by @caoman , while it would have worked, was a bandaid atop of a bandaid (see also https://bugs.openjdk.org/browse/JDK-8279124). It was perpetuating a crooked solution, and the crookedness stems from the fact that SIGQUIT is semantically a VM signal, owned by the VM, but initialized outside the libjsig-VM-signal-initialization window. The solution proposed by me makes SIGQUIT initialize like any other VM signal, therefore we can remove the SIGQUIT-related special handling and hopefully don't need further patches in this area.

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

PR: https://git.openjdk.org/jdk/pull/9955

From dholmes at openjdk.org  Mon Oct 24 08:13:59 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 24 Oct 2022 08:13:59 GMT
Subject: RFR: 8292695: SIGQUIT and jcmd attaching mechanism does not work
 with signal chaining library [v4]
In-Reply-To: <2ZrLsMRBHy8SbBdRvvSBkhYKkHKpPxi1TMZlY9T4EaY=.18cfd26e-0dfa-4dc8-aea5-df38daff5774@github.com>
References: <SmfKgkQzLCjbcgPxTAEDnB9l-5j6OvRATc-Ub-07uYw=.7f084d20-c544-4cf1-943f-79df959c518d@github.com>
 <2ZrLsMRBHy8SbBdRvvSBkhYKkHKpPxi1TMZlY9T4EaY=.18cfd26e-0dfa-4dc8-aea5-df38daff5774@github.com>
Message-ID: <GmVrE5wMQur02PpjBK6g-T13L1pwMDdirKxy5HMhfUY=.7b6b990d-7238-4437-8870-34188f9c7f67@github.com>

On Fri, 9 Sep 2022 08:27:41 GMT, Man Cao <manc at openjdk.org> wrote:

>> Hi all,
>> 
>> Could anyone review this bug fix? See https://bugs.openjdk.org/browse/JDK-8292695 for details.
>> 
>> I changed the temporary handler for SIGQUIT to use a dummy function, and use `os::signal()` to set it up, just as `os::initialize_jdk_signal_support()` does.
>> It is possible that just moving the `set_signal_handler(BREAK_SIGNAL, false);` in `install_signal_handlers()` outside of the window bounded by `JVM_{begin|end}_signal_setting()` could also fix this bug. However, `set_signal_handler()` and `JVM_HANDLE_XXX_SIGNAL()` are currently used for signals that support chaining and periodically check, which do not apply to SIGQUIT. I think it is cleaner to use different functions for SIGQUIT.
>> 
>> I also added a test to check that sending SIGQUIT should produce a thread dump on stdout, with and without using libjsig.so.
>> 
>> -Man
>
> Man Cao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address comments in test

I don't really agree with the rationale, but the fix is correct, and the reordering seems harmless enough on further inspection.

To me this is a JDK serviceability signal, both for dynamic attach and thread dumps, as it is the JDK serving "signal thread" that handles it. Most of the problems in this area have stemmed from initialization issues due to "too early" sending of SIGQUIT to initiate an attach attempt.

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

PR: https://git.openjdk.org/jdk/pull/9955

From jsjolen at openjdk.org  Mon Oct 24 09:16:19 2022
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 24 Oct 2022 09:16:19 GMT
Subject: Integrated: 8293873: Centralize the initialization of UL
In-Reply-To: <dtoar0JxoD5Fukir-9tE3mivhVRXuO7-Ckg0N5t9ZdU=.ad9b3ba9-ccf8-4591-af97-dda12a10d9dc@github.com>
References: <dtoar0JxoD5Fukir-9tE3mivhVRXuO7-Ckg0N5t9ZdU=.ad9b3ba9-ccf8-4591-af97-dda12a10d9dc@github.com>
Message-ID: <EaOvn0GvzKzeIdQF4QYwMtw0SSJzEEKGC0y_IWcfBqA=.1b3cf0a3-ecf8-43e3-b9b5-277fe26175a4@github.com>

On Fri, 16 Sep 2022 12:22:42 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Hi,
> 
> May I please have a review of this change? It moves around some of the initialization code of UL to one place (namely `LogConfiguration::initialize`). It does not change how UL works after VM start up, and it should not change how UL works after VM shut down, but it might change how UL works before VM start up. I don't believe that this causes any breakage.
> 
> Tier 2 and 3 tests are currently running, all green so far.
> 
> Some more context is available at https://bugs.openjdk.org/browse/JDK-8293873

This pull request has now been integrated.

Changeset: 89a94d05
Author:    Johan Sj?len <jsjolen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/89a94d050263fb5f71fabb32daa7949e137313e4
Stats:     106 lines in 10 files changed: 12 ins; 40 del; 54 mod

8293873: Centralize the initialization of UL

Reviewed-by: stuefe, rehn

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

PR: https://git.openjdk.org/jdk/pull/10307

From iklam at openjdk.org  Mon Oct 24 16:02:47 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 24 Oct 2022 16:02:47 GMT
Subject: RFR: 8291443: Obsolete the PrintSharedDictionary flag [v2]
In-Reply-To: <9LqZzJyCR4TyeY7O84dDW9iGLDNa7-jRvgqp8QQrUII=.6b9d451b-6cf9-47c4-94e4-65cf3ca62d31@github.com>
References: <PtAYxONL_XuczvPDhgSv4TsgFk6N3bosc5DC8flMAxY=.f3e7c242-0be7-439a-8a16-b529b58773f4@github.com>
 <9LqZzJyCR4TyeY7O84dDW9iGLDNa7-jRvgqp8QQrUII=.6b9d451b-6cf9-47c4-94e4-65cf3ca62d31@github.com>
Message-ID: <yt7nsxis_lNqH4KVuvA7MjqVeI5uEH64i3T0iS_X0Cs=.2421920c-005b-421f-b9c0-e4f73d600b55@github.com>

On Fri, 21 Oct 2022 17:51:48 GMT, Matias Saavedra Silva <duke at openjdk.org> wrote:

>> Obsoleted the unused PrintSharedDictionary flag and removed the flag from all tests. Verified with tier1-4 tests.
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed flag from cds_globals

Marked as reviewed by iklam (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10596

From duke at openjdk.org  Mon Oct 24 16:12:31 2022
From: duke at openjdk.org (Matias Saavedra Silva)
Date: Mon, 24 Oct 2022 16:12:31 GMT
Subject: Integrated: 8291443: Obsolete the PrintSharedDictionary flag
In-Reply-To: <PtAYxONL_XuczvPDhgSv4TsgFk6N3bosc5DC8flMAxY=.f3e7c242-0be7-439a-8a16-b529b58773f4@github.com>
References: <PtAYxONL_XuczvPDhgSv4TsgFk6N3bosc5DC8flMAxY=.f3e7c242-0be7-439a-8a16-b529b58773f4@github.com>
Message-ID: <8RgwMKV0BcbCpXDEFzAExxWZY1km_ErYxFJhzDJFg3A=.1cdf9173-e1bb-4fef-b989-9f68cfcd0033@github.com>

On Thu, 6 Oct 2022 14:46:46 GMT, Matias Saavedra Silva <duke at openjdk.org> wrote:

> Obsoleted the unused PrintSharedDictionary flag and removed the flag from all tests. Verified with tier1-4 tests.

This pull request has now been integrated.

Changeset: fefbddf8
Author:    Matias Saavedra Silva <matias.s.saavedra.silva at oracle.com>
Committer: Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fefbddf83595c15bbfd110a59e718ebf9f79b554
Stats:     12 lines in 6 files changed: 1 ins; 6 del; 5 mod

8291443: Obsolete the PrintSharedDictionary flag

Reviewed-by: dholmes, iklam

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

PR: https://git.openjdk.org/jdk/pull/10596

From coleenp at openjdk.org  Mon Oct 24 21:17:55 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 24 Oct 2022 21:17:55 GMT
Subject: RFR: 8295713: runtime/ParallelLoad/SuperWait/SuperWaitTest.java
 fails intermittently on Windows [v3]
In-Reply-To: <tk88whD-nXj1I8Ss1VpzWs85bLU162gSZU0RhlBfvYk=.670d0dd4-e891-4a9b-95b9-87716fc6a92e@github.com>
References: <tk88whD-nXj1I8Ss1VpzWs85bLU162gSZU0RhlBfvYk=.670d0dd4-e891-4a9b-95b9-87716fc6a92e@github.com>
Message-ID: <m5bpAa37IdA9jS-h37ygYOiIF8OyH2oqHocqXJPcx-g=.7385f5e6-6118-4991-a593-1c33db43dc4d@github.com>

> I added another semaphore so the test will run in the order I want it to.  Alternate suggestions or corrections welcome.
> Running with GHA, and our tier1 in progress.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Fix the logic some more. Wait for thread2 without being in the class loader locked region, and guard against spuriouss wakeups.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10822/files
  - new: https://git.openjdk.org/jdk/pull/10822/files/d0089bb7..e24117fc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10822&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10822&range=01-02

  Stats: 43 lines in 2 files changed: 14 ins; 17 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/10822.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10822/head:pull/10822

PR: https://git.openjdk.org/jdk/pull/10822

From coleenp at openjdk.org  Mon Oct 24 21:32:48 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 24 Oct 2022 21:32:48 GMT
Subject: RFR: 8295713: runtime/ParallelLoad/SuperWait/SuperWaitTest.java
 fails intermittently on Windows [v3]
In-Reply-To: <m5bpAa37IdA9jS-h37ygYOiIF8OyH2oqHocqXJPcx-g=.7385f5e6-6118-4991-a593-1c33db43dc4d@github.com>
References: <tk88whD-nXj1I8Ss1VpzWs85bLU162gSZU0RhlBfvYk=.670d0dd4-e891-4a9b-95b9-87716fc6a92e@github.com>
 <m5bpAa37IdA9jS-h37ygYOiIF8OyH2oqHocqXJPcx-g=.7385f5e6-6118-4991-a593-1c33db43dc4d@github.com>
Message-ID: <Tme-9UY2s5MuVFea1MFGdCPtSf-hlOXqgCw5TalRDMk=.9e91fcf4-a625-4b7d-9da2-0390e77472a4@github.com>

On Mon, 24 Oct 2022 21:17:55 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I added another semaphore so the test will run in the order I want it to.  Alternate suggestions or corrections welcome.
>> Running with GHA, and our tier1 in progress.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix the logic some more. Wait for thread2 without being in the class loader locked region, and guard against spuriouss wakeups.

I need to both handle the spurious wakeup and the case where the second thread loads everything, and then the first thread then waits, after D's notification - the missed notification.

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

PR: https://git.openjdk.org/jdk/pull/10822

From dcubed at openjdk.org  Mon Oct 24 21:38:39 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 24 Oct 2022 21:38:39 GMT
Subject: RFR: 8295855: ProblemList jdk/jshell/CommandCompletionTest.java on
 linux-all
Message-ID: <0ifpOEPM7f5v1gUoPUqzk0OnLEC2eYjtQ733hfxsmSo=.3bee0cfb-c533-479a-b69d-356a285df0de@github.com>

A trivial fix to ProblemList jdk/jshell/CommandCompletionTest.java on linux-all.

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

Commit messages:
 - 8295855: ProblemList jdk/jshell/CommandCompletionTest.java on linux-all

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

PR: https://git.openjdk.org/jdk/pull/10841

From dholmes at openjdk.org  Mon Oct 24 21:38:39 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 24 Oct 2022 21:38:39 GMT
Subject: RFR: 8295855: ProblemList jdk/jshell/CommandCompletionTest.java on
 linux-all
In-Reply-To: <0ifpOEPM7f5v1gUoPUqzk0OnLEC2eYjtQ733hfxsmSo=.3bee0cfb-c533-479a-b69d-356a285df0de@github.com>
References: <0ifpOEPM7f5v1gUoPUqzk0OnLEC2eYjtQ733hfxsmSo=.3bee0cfb-c533-479a-b69d-356a285df0de@github.com>
Message-ID: <j-RrRdjKv1piiWMrHYdWAGOPNWBQYOZHQfI6nAi4C_0=.7c844973-f21a-48c3-b6ac-aa0e1a3c5740@github.com>

On Mon, 24 Oct 2022 21:23:05 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList jdk/jshell/CommandCompletionTest.java on linux-all.

Marked as reviewed by dholmes (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10841

From dcubed at openjdk.org  Mon Oct 24 21:38:40 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 24 Oct 2022 21:38:40 GMT
Subject: RFR: 8295855: ProblemList jdk/jshell/CommandCompletionTest.java on
 linux-all
In-Reply-To: <j-RrRdjKv1piiWMrHYdWAGOPNWBQYOZHQfI6nAi4C_0=.7c844973-f21a-48c3-b6ac-aa0e1a3c5740@github.com>
References: <0ifpOEPM7f5v1gUoPUqzk0OnLEC2eYjtQ733hfxsmSo=.3bee0cfb-c533-479a-b69d-356a285df0de@github.com>
 <j-RrRdjKv1piiWMrHYdWAGOPNWBQYOZHQfI6nAi4C_0=.7c844973-f21a-48c3-b6ac-aa0e1a3c5740@github.com>
Message-ID: <Qj-Ws7fJM8sTo29Q7Hqf_Zhv9wcEzI32mQPL9WlsVM4=.6dd2714d-3152-46d9-a504-4108155c793f@github.com>

On Mon, 24 Oct 2022 21:30:31 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> A trivial fix to ProblemList jdk/jshell/CommandCompletionTest.java on linux-all.
>
> Marked as reviewed by dholmes (Reviewer).

@dholmes-ora - Thanks for the fast review!

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

PR: https://git.openjdk.org/jdk/pull/10841

From dcubed at openjdk.org  Mon Oct 24 21:43:04 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 24 Oct 2022 21:43:04 GMT
Subject: Integrated: 8295855: ProblemList jdk/jshell/CommandCompletionTest.java
 on linux-all
In-Reply-To: <0ifpOEPM7f5v1gUoPUqzk0OnLEC2eYjtQ733hfxsmSo=.3bee0cfb-c533-479a-b69d-356a285df0de@github.com>
References: <0ifpOEPM7f5v1gUoPUqzk0OnLEC2eYjtQ733hfxsmSo=.3bee0cfb-c533-479a-b69d-356a285df0de@github.com>
Message-ID: <eHA8kFpljKIzWhAL10ga8rPuGoYnaeG97b2KHSle5dY=.52c40c02-7478-400f-a593-1858e45c98ec@github.com>

On Mon, 24 Oct 2022 21:23:05 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList jdk/jshell/CommandCompletionTest.java on linux-all.

This pull request has now been integrated.

Changeset: 7520d0a7
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7520d0a72573ebaec0b6d9f9f1f1d87688bff8c0
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8295855: ProblemList jdk/jshell/CommandCompletionTest.java on linux-all

Reviewed-by: dholmes

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

PR: https://git.openjdk.org/jdk/pull/10841

From manc at openjdk.org  Mon Oct 24 22:00:01 2022
From: manc at openjdk.org (Man Cao)
Date: Mon, 24 Oct 2022 22:00:01 GMT
Subject: RFR: 8292695: SIGQUIT and jcmd attaching mechanism does not work
 with signal chaining library [v4]
In-Reply-To: <vv5DiV5ys9HgLQB7IhUGlk8mhv03abOIJwWJv45OBcM=.de952b49-a42d-49af-a1d9-8b852f85bbc3@github.com>
References: <SmfKgkQzLCjbcgPxTAEDnB9l-5j6OvRATc-Ub-07uYw=.7f084d20-c544-4cf1-943f-79df959c518d@github.com>
 <2ZrLsMRBHy8SbBdRvvSBkhYKkHKpPxi1TMZlY9T4EaY=.18cfd26e-0dfa-4dc8-aea5-df38daff5774@github.com>
 <Dk6t68vd4hTNEFJX3NVBs4f8PR_5K8igfJVNvYeFwbY=.c370d664-701e-4cf8-aebf-40bdd1802133@github.com>
 <DwmpYkb2Nc1Pm1DN2WnCOli_yyCRqjPeVZDBIkkGkMg=.f06bd645-519e-49c9-b642-3affa0e62179@github.com>
 <vv5DiV5ys9HgLQB7IhUGlk8mhv03abOIJwWJv45OBcM=.de952b49-a42d-49af-a1d9-8b852f85bbc3@github.com>
Message-ID: <Tft46QmGmEom0Fa1hjl0kgLdFF1xleLL3R5-wANdOTQ=.8e72dd7f-faf6-4e46-b04d-6e408a676191@github.com>

On Mon, 24 Oct 2022 07:38:17 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> SIGQUIT is semantically a VM signal, owned by the VM, but initialized outside the libjsig-VM-signal-initialization window. The solution proposed by me makes SIGQUIT initialize like any other VM signal, ...

Yes, this is main reason we installed BREAK_SIGNAL handler inside `install_signal_handlers` and reordered `jdk_misc_signal_init` and `install_signal_handlers`.

There was a concern that with libjsig present and without `-Xrs`, user could still install a custom BREAK_SIGNAL handler that overrides JVM's handler, see https://github.com/openjdk/jdk/pull/9955#discussion_r956623350. This change avoids this problem.

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

PR: https://git.openjdk.org/jdk/pull/9955

From dholmes at openjdk.org  Mon Oct 24 22:28:45 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 24 Oct 2022 22:28:45 GMT
Subject: RFR: 8295713: runtime/ParallelLoad/SuperWait/SuperWaitTest.java
 fails intermittently on Windows [v3]
In-Reply-To: <Tme-9UY2s5MuVFea1MFGdCPtSf-hlOXqgCw5TalRDMk=.9e91fcf4-a625-4b7d-9da2-0390e77472a4@github.com>
References: <tk88whD-nXj1I8Ss1VpzWs85bLU162gSZU0RhlBfvYk=.670d0dd4-e891-4a9b-95b9-87716fc6a92e@github.com>
 <m5bpAa37IdA9jS-h37ygYOiIF8OyH2oqHocqXJPcx-g=.7385f5e6-6118-4991-a593-1c33db43dc4d@github.com>
 <Tme-9UY2s5MuVFea1MFGdCPtSf-hlOXqgCw5TalRDMk=.9e91fcf4-a625-4b7d-9da2-0390e77472a4@github.com>
Message-ID: <w52pqYO5d3w6LSR8Zp5qyUrHcWU7ng_cMOHX_PNzUFg=.f3ef11c6-6d0d-43b6-827b-2819af2f845a@github.com>

On Mon, 24 Oct 2022 21:28:32 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> I need to both handle 1. the spurious wakeup from wait(), and 2. the case where the second thread loads everything, and then the first thread then waits, after D's notification - the missed notification.

That is what `DIsLoaded` indicates. There's no missed notification because you won't `wait` if D is already loaded.

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

PR: https://git.openjdk.org/jdk/pull/10822

From mbaesken at openjdk.org  Tue Oct 25 08:01:59 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 25 Oct 2022 08:01:59 GMT
Subject: RFR: JDK-8295710 : unify os::dll_file_extension [v2]
In-Reply-To: <KIZm_XUGrbE0MHg0g73rv9FTdZXOKPR9CkURVixZ01c=.638be20f-7b02-4c3b-9b11-4ca3bedef125@github.com>
References: <KIZm_XUGrbE0MHg0g73rv9FTdZXOKPR9CkURVixZ01c=.638be20f-7b02-4c3b-9b11-4ca3bedef125@github.com>
Message-ID: <Tee3DAG0i34T4txrqy8gr0otDcAOo7zWjw-mMGTk7dQ=.02c077ec-39bb-4d77-ab58-aaadd1edb8e3@github.com>

> The os::dll_file_extension() function could be unified for the different OS platforms.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  Remove os::dll_file_extension

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10782/files
  - new: https://git.openjdk.org/jdk/pull/10782/files/c533cd24..76a230e9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10782&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10782&range=00-01

  Stats: 3 lines in 2 files changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10782.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10782/head:pull/10782

PR: https://git.openjdk.org/jdk/pull/10782

From mbaesken at openjdk.org  Tue Oct 25 08:01:59 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 25 Oct 2022 08:01:59 GMT
Subject: RFR: JDK-8295710 : unify os::dll_file_extension
In-Reply-To: <KIZm_XUGrbE0MHg0g73rv9FTdZXOKPR9CkURVixZ01c=.638be20f-7b02-4c3b-9b11-4ca3bedef125@github.com>
References: <KIZm_XUGrbE0MHg0g73rv9FTdZXOKPR9CkURVixZ01c=.638be20f-7b02-4c3b-9b11-4ca3bedef125@github.com>
Message-ID: <62xJowOzxZ3_nVP8wvn9xGbdeVNMyptRnZFPv9FiVas=.4a70c7a6-218d-4133-8274-d11d1c03885e@github.com>

On Thu, 20 Oct 2022 08:12:04 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The os::dll_file_extension() function could be unified for the different OS platforms.

Hi David, yes we can remove  os::dll_file_extension ; I adjusted the change.

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

PR: https://git.openjdk.org/jdk/pull/10782

From dholmes at openjdk.org  Tue Oct 25 09:01:46 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 25 Oct 2022 09:01:46 GMT
Subject: RFR: JDK-8295710 : unify os::dll_file_extension [v2]
In-Reply-To: <Tee3DAG0i34T4txrqy8gr0otDcAOo7zWjw-mMGTk7dQ=.02c077ec-39bb-4d77-ab58-aaadd1edb8e3@github.com>
References: <KIZm_XUGrbE0MHg0g73rv9FTdZXOKPR9CkURVixZ01c=.638be20f-7b02-4c3b-9b11-4ca3bedef125@github.com>
 <Tee3DAG0i34T4txrqy8gr0otDcAOo7zWjw-mMGTk7dQ=.02c077ec-39bb-4d77-ab58-aaadd1edb8e3@github.com>
Message-ID: <4fBLGwNu1pmTuSRhjNwvoeF20mjlxN7wfFBInpSEC3c=.32b19cc0-cd94-4edd-8673-62d1ca7337d0@github.com>

On Tue, 25 Oct 2022 08:01:59 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> The os::dll_file_extension() function could be unified for the different OS platforms.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove os::dll_file_extension

You need to remove it from ./share/runtime/os.hpp too. Thanks.

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

Changes requested by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10782

From mdoerr at openjdk.org  Tue Oct 25 10:43:45 2022
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 25 Oct 2022 10:43:45 GMT
Subject: RFR: 8295872: [PPC64] JfrGetCallTrace: Need pc == nullptr check before
 frame constructor
Message-ID: <U3rHwkyuYs_sOYA23U4WwYyPJYLLj5F9OuWGTiqQIfI=.61f44411-215b-4ca0-9a26-4162fbc4d1cf@github.com>

The check pc == nullptr is needed before the frame constructor.

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

Commit messages:
 - 8295872: [PPC64] JfrGetCallTrace: Need pc == nullptr check before frame constructor

Changes: https://git.openjdk.org/jdk/pull/10846/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10846&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295872
  Stats: 12 lines in 2 files changed: 6 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/10846.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10846/head:pull/10846

PR: https://git.openjdk.org/jdk/pull/10846

From shade at openjdk.org  Tue Oct 25 10:51:51 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 25 Oct 2022 10:51:51 GMT
Subject: RFR: 8295872: [PPC64] JfrGetCallTrace: Need pc == nullptr check
 before frame constructor
In-Reply-To: <U3rHwkyuYs_sOYA23U4WwYyPJYLLj5F9OuWGTiqQIfI=.61f44411-215b-4ca0-9a26-4162fbc4d1cf@github.com>
References: <U3rHwkyuYs_sOYA23U4WwYyPJYLLj5F9OuWGTiqQIfI=.61f44411-215b-4ca0-9a26-4162fbc4d1cf@github.com>
Message-ID: <OX7MtcK0JeCMxthN89wup0bPKS3ZIVMOvyGG9SbJk04=.3bb5855e-28e2-483e-8b7b-8646434159c6@github.com>

On Tue, 25 Oct 2022 10:36:34 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> The check pc == nullptr is needed before the frame constructor.

Looks okay

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

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10846

From mbaesken at openjdk.org  Tue Oct 25 11:35:03 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 25 Oct 2022 11:35:03 GMT
Subject: RFR: JDK-8295710 : unify os::dll_file_extension [v3]
In-Reply-To: <KIZm_XUGrbE0MHg0g73rv9FTdZXOKPR9CkURVixZ01c=.638be20f-7b02-4c3b-9b11-4ca3bedef125@github.com>
References: <KIZm_XUGrbE0MHg0g73rv9FTdZXOKPR9CkURVixZ01c=.638be20f-7b02-4c3b-9b11-4ca3bedef125@github.com>
Message-ID: <Wb39gXKWs7nmunyZoC2JXsnMA9U6SEDO_b3m9A51o6c=.b5111e7b-2ddf-4900-bdcc-d7e5c69aa1c6@github.com>

> The os::dll_file_extension() function could be unified for the different OS platforms.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  remove dll_file_extension from os.hpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10782/files
  - new: https://git.openjdk.org/jdk/pull/10782/files/76a230e9..56495228

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10782&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10782&range=01-02

  Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10782.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10782/head:pull/10782

PR: https://git.openjdk.org/jdk/pull/10782

From mbaesken at openjdk.org  Tue Oct 25 11:39:31 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 25 Oct 2022 11:39:31 GMT
Subject: RFR: JDK-8295710 : unify os::dll_file_extension [v3]
In-Reply-To: <Wb39gXKWs7nmunyZoC2JXsnMA9U6SEDO_b3m9A51o6c=.b5111e7b-2ddf-4900-bdcc-d7e5c69aa1c6@github.com>
References: <KIZm_XUGrbE0MHg0g73rv9FTdZXOKPR9CkURVixZ01c=.638be20f-7b02-4c3b-9b11-4ca3bedef125@github.com>
 <Wb39gXKWs7nmunyZoC2JXsnMA9U6SEDO_b3m9A51o6c=.b5111e7b-2ddf-4900-bdcc-d7e5c69aa1c6@github.com>
Message-ID: <uqeTK6uaOhW_9768BTcxWVhX-S50Hvn0T-uulBmp2KM=.80cd5be7-53a7-4a6a-bc3e-f4ed1552e698@github.com>

On Tue, 25 Oct 2022 11:35:03 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> The os::dll_file_extension() function could be unified for the different OS platforms.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove dll_file_extension from os.hpp

Hi David, I removed dll_file_extension() from os.hpp .

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

PR: https://git.openjdk.org/jdk/pull/10782

From mdoerr at openjdk.org  Tue Oct 25 12:05:30 2022
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 25 Oct 2022 12:05:30 GMT
Subject: RFR: 8295872: [PPC64] JfrGetCallTrace: Need pc == nullptr check
 before frame constructor
In-Reply-To: <U3rHwkyuYs_sOYA23U4WwYyPJYLLj5F9OuWGTiqQIfI=.61f44411-215b-4ca0-9a26-4162fbc4d1cf@github.com>
References: <U3rHwkyuYs_sOYA23U4WwYyPJYLLj5F9OuWGTiqQIfI=.61f44411-215b-4ca0-9a26-4162fbc4d1cf@github.com>
Message-ID: <T5ZFToHf-C-PxLcQPmJhgQvtQb0M-XrKf2U86VLoDLo=.71096c1b-6bec-4763-80b5-bcad4cfdd21d@github.com>

On Tue, 25 Oct 2022 10:36:34 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> The check pc == nullptr is needed before the frame constructor.

Thanks for the prompt review!

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

PR: https://git.openjdk.org/jdk/pull/10846

From coleenp at openjdk.org  Tue Oct 25 12:15:55 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 25 Oct 2022 12:15:55 GMT
Subject: RFR: 8295713: runtime/ParallelLoad/SuperWait/SuperWaitTest.java
 fails intermittently on Windows [v3]
In-Reply-To: <m5bpAa37IdA9jS-h37ygYOiIF8OyH2oqHocqXJPcx-g=.7385f5e6-6118-4991-a593-1c33db43dc4d@github.com>
References: <tk88whD-nXj1I8Ss1VpzWs85bLU162gSZU0RhlBfvYk=.670d0dd4-e891-4a9b-95b9-87716fc6a92e@github.com>
 <m5bpAa37IdA9jS-h37ygYOiIF8OyH2oqHocqXJPcx-g=.7385f5e6-6118-4991-a593-1c33db43dc4d@github.com>
Message-ID: <LxIkQXP_PkCRPjGzvoHncZtteCJtBEin03t2s6UkNw0=.2e8dc2e9-fed2-4317-9117-8b89853f62e5@github.com>

On Mon, 24 Oct 2022 21:17:55 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I added another semaphore so the test will run in the order I want it to.  Alternate suggestions or corrections welcome.
>> Running with GHA, and our tier1 in progress.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix the logic some more. Wait for thread2 without being in the class loader locked region, and guard against spuriouss wakeups.

It won't test what I'm trying to test though, but maybe it's ok.  I added the test for illustrative purposes.

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

PR: https://git.openjdk.org/jdk/pull/10822

From coleenp at openjdk.org  Tue Oct 25 12:25:03 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 25 Oct 2022 12:25:03 GMT
Subject: RFR: 8295713: runtime/ParallelLoad/SuperWait/SuperWaitTest.java
 fails intermittently on Windows [v4]
In-Reply-To: <tk88whD-nXj1I8Ss1VpzWs85bLU162gSZU0RhlBfvYk=.670d0dd4-e891-4a9b-95b9-87716fc6a92e@github.com>
References: <tk88whD-nXj1I8Ss1VpzWs85bLU162gSZU0RhlBfvYk=.670d0dd4-e891-4a9b-95b9-87716fc6a92e@github.com>
Message-ID: <hBut9gB7wzTscarfv-pPeAKgSmI28ZQloltDa7erZZk=.10686a1c-2f43-4697-95f0-d157e963ef5e@github.com>

> I added another semaphore so the test will run in the order I want it to.  Alternate suggestions or corrections welcome.
> Running with GHA, and our tier1 in progress.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  David's fix - allow thread 2 to run first.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10822/files
  - new: https://git.openjdk.org/jdk/pull/10822/files/e24117fc..b2decdf2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10822&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10822&range=02-03

  Stats: 10 lines in 1 file changed: 0 ins; 10 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10822.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10822/head:pull/10822

PR: https://git.openjdk.org/jdk/pull/10822

From dholmes at openjdk.org  Tue Oct 25 12:49:31 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 25 Oct 2022 12:49:31 GMT
Subject: RFR: JDK-8295710 : unify os::dll_file_extension [v3]
In-Reply-To: <Wb39gXKWs7nmunyZoC2JXsnMA9U6SEDO_b3m9A51o6c=.b5111e7b-2ddf-4900-bdcc-d7e5c69aa1c6@github.com>
References: <KIZm_XUGrbE0MHg0g73rv9FTdZXOKPR9CkURVixZ01c=.638be20f-7b02-4c3b-9b11-4ca3bedef125@github.com>
 <Wb39gXKWs7nmunyZoC2JXsnMA9U6SEDO_b3m9A51o6c=.b5111e7b-2ddf-4900-bdcc-d7e5c69aa1c6@github.com>
Message-ID: <QSfL3pSo-11jvtqf4fBnhDdKXR-C5dfXTJVbypKXRnc=.3bffa758-aa76-4748-8291-b9b6069108ab@github.com>

On Tue, 25 Oct 2022 11:35:03 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> The os::dll_file_extension() function could be unified for the different OS platforms.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove dll_file_extension from os.hpp

Looks good.

But could you update the JBS issue/title to indicate it is now removed not unified.

Thanks.

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10782

From dholmes at openjdk.org  Tue Oct 25 13:01:54 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 25 Oct 2022 13:01:54 GMT
Subject: RFR: 8295713: runtime/ParallelLoad/SuperWait/SuperWaitTest.java
 fails intermittently on Windows [v4]
In-Reply-To: <hBut9gB7wzTscarfv-pPeAKgSmI28ZQloltDa7erZZk=.10686a1c-2f43-4697-95f0-d157e963ef5e@github.com>
References: <tk88whD-nXj1I8Ss1VpzWs85bLU162gSZU0RhlBfvYk=.670d0dd4-e891-4a9b-95b9-87716fc6a92e@github.com>
 <hBut9gB7wzTscarfv-pPeAKgSmI28ZQloltDa7erZZk=.10686a1c-2f43-4697-95f0-d157e963ef5e@github.com>
Message-ID: <DuPEhEO8umwtY19OJHHgFENx6pLSVDQfbN285Xp7huo=.096e2cca-b72c-48fb-b335-c1db44a802b0@github.com>

On Tue, 25 Oct 2022 12:25:03 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I added another semaphore so the test will run in the order I want it to.  Alternate suggestions or corrections welcome.
>> Running with GHA, and our tier1 in progress.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   David's fix - allow thread 2 to run first.

Sorry Coleen some of the intermediate changes here confused me. The original use of `mainSync` is slowing down thread1 (loading A) so that it can't proceed until thread 2 starts to load C and has the lock of L2 (which sets up the potential deadlock scenario). That could be added back in conjunction with the `dIsLoaded` usage. In both cases thread 2 could always get to go first and load C and D before thread 1 has a chance to do anything.

test/hotspot/jtreg/runtime/ParallelLoad/SuperWait/SuperWaitTest.java line 39:

> 37: public class SuperWaitTest {
> 38: 
> 39:     private static volatile boolean dIsLoading = false;

This doesn't need to be volatile as it is only accessed under the classloader lock.

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

PR: https://git.openjdk.org/jdk/pull/10822

From coleenp at openjdk.org  Tue Oct 25 13:19:53 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 25 Oct 2022 13:19:53 GMT
Subject: RFR: 8295713: runtime/ParallelLoad/SuperWait/SuperWaitTest.java
 fails intermittently on Windows [v4]
In-Reply-To: <hBut9gB7wzTscarfv-pPeAKgSmI28ZQloltDa7erZZk=.10686a1c-2f43-4697-95f0-d157e963ef5e@github.com>
References: <tk88whD-nXj1I8Ss1VpzWs85bLU162gSZU0RhlBfvYk=.670d0dd4-e891-4a9b-95b9-87716fc6a92e@github.com>
 <hBut9gB7wzTscarfv-pPeAKgSmI28ZQloltDa7erZZk=.10686a1c-2f43-4697-95f0-d157e963ef5e@github.com>
Message-ID: <-8OV0kCYLXy4hsY6_7nMDs45hWlUdlcGi7AYODoYjqs=.1a43c94a-26d5-4a5d-b28b-97a39841ce45@github.com>

On Tue, 25 Oct 2022 12:25:03 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I added another semaphore so the test will run in the order I want it to.  Alternate suggestions or corrections welcome.
>> Running with GHA, and our tier1 in progress.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   David's fix - allow thread 2 to run first.

My n-1 change makes thread 2 wait for loading C and D until thread1 is in the locked region for loading A (which was the deadlock scenario before the wait() is introduced).   It doesn't really matter if thread 2 goes first with the dIsLoading change.  Either way, the test will complete and not miss a notify.

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

PR: https://git.openjdk.org/jdk/pull/10822

From coleenp at openjdk.org  Tue Oct 25 13:23:38 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 25 Oct 2022 13:23:38 GMT
Subject: RFR: 8295713: runtime/ParallelLoad/SuperWait/SuperWaitTest.java
 fails intermittently on Windows [v5]
In-Reply-To: <tk88whD-nXj1I8Ss1VpzWs85bLU162gSZU0RhlBfvYk=.670d0dd4-e891-4a9b-95b9-87716fc6a92e@github.com>
References: <tk88whD-nXj1I8Ss1VpzWs85bLU162gSZU0RhlBfvYk=.670d0dd4-e891-4a9b-95b9-87716fc6a92e@github.com>
Message-ID: <Rro_nEjeoHa51JLf4KCMQTRUpCdEC9ITfqYrJiq1Ewo=.46d8e417-d348-4b9a-ba22-53e1538099f6@github.com>

> I added another semaphore so the test will run in the order I want it to.  Alternate suggestions or corrections welcome.
> Running with GHA, and our tier1 in progress.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  remove volatile

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10822/files
  - new: https://git.openjdk.org/jdk/pull/10822/files/b2decdf2..8278537a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10822&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10822&range=03-04

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

PR: https://git.openjdk.org/jdk/pull/10822

From mdoerr at openjdk.org  Tue Oct 25 16:11:51 2022
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 25 Oct 2022 16:11:51 GMT
Subject: RFR: JDK-8295710 : remove os::dll_file_extension [v3]
In-Reply-To: <Wb39gXKWs7nmunyZoC2JXsnMA9U6SEDO_b3m9A51o6c=.b5111e7b-2ddf-4900-bdcc-d7e5c69aa1c6@github.com>
References: <KIZm_XUGrbE0MHg0g73rv9FTdZXOKPR9CkURVixZ01c=.638be20f-7b02-4c3b-9b11-4ca3bedef125@github.com>
 <Wb39gXKWs7nmunyZoC2JXsnMA9U6SEDO_b3m9A51o6c=.b5111e7b-2ddf-4900-bdcc-d7e5c69aa1c6@github.com>
Message-ID: <FhD-cLJ7dIFJ2AJfgSJ3HGPZvvuwircyW3OamtmzNfE=.3aa8ff33-a2e6-46ac-a3dc-bb29ca14373f@github.com>

On Tue, 25 Oct 2022 11:35:03 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> The os::dll_file_extension() function could be unified for the different OS platforms.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove dll_file_extension from os.hpp

Nice cleanup! LGTM. Yeah, describing that you remove it in the JBS issue makes sense.

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

Marked as reviewed by mdoerr (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10782

From stuefe at openjdk.org  Tue Oct 25 16:24:27 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 25 Oct 2022 16:24:27 GMT
Subject: RFR: JDK-8295889: NMT preinit code does not handle allocation errors
Message-ID: <GyxfmN-u6MoD_yPISj1QSYdGUKDiDkgkq_4aNCJLsXI=.88fbbdec-9088-4f3a-9a0f-6ab7a566209a@github.com>

The NMT preinit allocator (used for os::malloc and friends before the VM is initialized) does not handle malloc errors, nor does it handle overflows due to large sizes (it uses malloc headers too). Both cases need to be handled.

However, we can keep matters very simple. No need to propagate errors up to the caller; we can just fatal out on errors here since, in this phase, there is no alternative for failed allocations.

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

Commit messages:
 - JDK-8295889-NMT-preinit-should-handle-allocation-errors

Changes: https://git.openjdk.org/jdk/pull/10855/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10855&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295889
  Stats: 38 lines in 2 files changed: 38 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10855.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10855/head:pull/10855

PR: https://git.openjdk.org/jdk/pull/10855

From stuefe at openjdk.org  Tue Oct 25 16:24:27 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 25 Oct 2022 16:24:27 GMT
Subject: RFR: JDK-8295889: NMT preinit code does not handle allocation
 errors
In-Reply-To: <GyxfmN-u6MoD_yPISj1QSYdGUKDiDkgkq_4aNCJLsXI=.88fbbdec-9088-4f3a-9a0f-6ab7a566209a@github.com>
References: <GyxfmN-u6MoD_yPISj1QSYdGUKDiDkgkq_4aNCJLsXI=.88fbbdec-9088-4f3a-9a0f-6ab7a566209a@github.com>
Message-ID: <gNF1KFt2WSdv6XoswQ17-1fcBnoZJXYYFJx2mpbpdHE=.9e2b005f-d759-4318-8cf2-6439cca929e8@github.com>

On Tue, 25 Oct 2022 15:18:05 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> The NMT preinit allocator (used for os::malloc and friends before the VM is initialized) does not handle malloc errors, nor does it handle overflows due to large sizes (it uses malloc headers too). Both cases need to be handled.
> 
> However, we can keep matters very simple. No need to propagate errors up to the caller; we can just fatal out on errors here since, in this phase, there is no alternative for failed allocations.

Linux x86 errors unrelated. I did build and test manually 32-bit on Ubuntu, all fine.

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

PR: https://git.openjdk.org/jdk/pull/10855

From coleenp at openjdk.org  Tue Oct 25 16:24:56 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 25 Oct 2022 16:24:56 GMT
Subject: RFR: 8279366: CDS should allow alternative locations for JAR files
 in classpath [v4]
In-Reply-To: <MMhJ6k7YdCD6-jcqEtHBnVrszfDXWKoz5nFPiR95NXk=.31d7a11a-4bc1-47ad-9fd8-0521cdb58ba1@github.com>
References: <gjn5N9Lmavel1A8AHZFHxbp0J2l6XklY_-Pr-N04k7g=.dd8b5ed1-2c55-40cf-88e1-770e16c4c911@github.com>
 <MMhJ6k7YdCD6-jcqEtHBnVrszfDXWKoz5nFPiR95NXk=.31d7a11a-4bc1-47ad-9fd8-0521cdb58ba1@github.com>
Message-ID: <ZKTfTYQrHLcaBuWfcImKcyYGx6j5P5sOZiqIiWf2cjY=.0a312af5-242e-4505-94f2-4f9ed17022d8@github.com>

On Wed, 19 Oct 2022 16:36:56 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Please review this RFE for allowing alternative locations for jar files in the app classpath during runtime.
>> 
>> During dump time, the longest common prefix of the app classpath will be stored in the CDS archive header. During runtime, existing checks of the app classpath will be performed first. Upon failure, the longest common prefix of the runtime app classpath will be computed and another check of the app classpath will be performed ignoring the longest common prefix.
>> 
>> Refer to the [bug report comment](https://bugs.openjdk.org/browse/JDK-8279366?focusedCommentId=14509536&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14509536) for an example.
>> 
>> Passed tiers 1 - 4 testing (including the new tests).
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   merge check_paths_ignoring_common_prefix() into check_paths()

This looks correct to me.

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

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10615

From lucy at openjdk.org  Tue Oct 25 16:43:11 2022
From: lucy at openjdk.org (Lutz Schmidt)
Date: Tue, 25 Oct 2022 16:43:11 GMT
Subject: RFR: JDK-8295710 : remove os::dll_file_extension [v3]
In-Reply-To: <Wb39gXKWs7nmunyZoC2JXsnMA9U6SEDO_b3m9A51o6c=.b5111e7b-2ddf-4900-bdcc-d7e5c69aa1c6@github.com>
References: <KIZm_XUGrbE0MHg0g73rv9FTdZXOKPR9CkURVixZ01c=.638be20f-7b02-4c3b-9b11-4ca3bedef125@github.com>
 <Wb39gXKWs7nmunyZoC2JXsnMA9U6SEDO_b3m9A51o6c=.b5111e7b-2ddf-4900-bdcc-d7e5c69aa1c6@github.com>
Message-ID: <ASVsXiSimLEgLZK4HsedCnpdZX45hZvzdLbGWkGVWoc=.99995490-cd1d-49a5-ba05-070d58a12f57@github.com>

On Tue, 25 Oct 2022 11:35:03 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> The os::dll_file_extension() function could be unified for the different OS platforms.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove dll_file_extension from os.hpp

LGTM.
Thank you for unifying. I like the fact that knowledge about the dynamic library extension is now stored at exactly one place.

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

Marked as reviewed by lucy (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10782

From duke at openjdk.org  Tue Oct 25 17:29:51 2022
From: duke at openjdk.org (Matias Saavedra Silva)
Date: Tue, 25 Oct 2022 17:29:51 GMT
Subject: RFR: 8279366: CDS should allow alternative locations for JAR files
 in classpath [v4]
In-Reply-To: <MMhJ6k7YdCD6-jcqEtHBnVrszfDXWKoz5nFPiR95NXk=.31d7a11a-4bc1-47ad-9fd8-0521cdb58ba1@github.com>
References: <gjn5N9Lmavel1A8AHZFHxbp0J2l6XklY_-Pr-N04k7g=.dd8b5ed1-2c55-40cf-88e1-770e16c4c911@github.com>
 <MMhJ6k7YdCD6-jcqEtHBnVrszfDXWKoz5nFPiR95NXk=.31d7a11a-4bc1-47ad-9fd8-0521cdb58ba1@github.com>
Message-ID: <AeHj4Gj94SJy04fA90SwWowaRN-rR3DGPOijKExMYL8=.782b8202-cefa-4134-9678-cf85d528309a@github.com>

On Wed, 19 Oct 2022 16:36:56 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Please review this RFE for allowing alternative locations for jar files in the app classpath during runtime.
>> 
>> During dump time, the longest common prefix of the app classpath will be stored in the CDS archive header. During runtime, existing checks of the app classpath will be performed first. Upon failure, the longest common prefix of the runtime app classpath will be computed and another check of the app classpath will be performed ignoring the longest common prefix.
>> 
>> Refer to the [bug report comment](https://bugs.openjdk.org/browse/JDK-8279366?focusedCommentId=14509536&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14509536) for an example.
>> 
>> Passed tiers 1 - 4 testing (including the new tests).
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   merge check_paths_ignoring_common_prefix() into check_paths()

lgtm!

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

PR: https://git.openjdk.org/jdk/pull/10615

From duke at openjdk.org  Tue Oct 25 17:34:27 2022
From: duke at openjdk.org (Matias Saavedra Silva)
Date: Tue, 25 Oct 2022 17:34:27 GMT
Subject: RFR: 8279366: CDS should allow alternative locations for JAR files
 in classpath [v4]
In-Reply-To: <MMhJ6k7YdCD6-jcqEtHBnVrszfDXWKoz5nFPiR95NXk=.31d7a11a-4bc1-47ad-9fd8-0521cdb58ba1@github.com>
References: <gjn5N9Lmavel1A8AHZFHxbp0J2l6XklY_-Pr-N04k7g=.dd8b5ed1-2c55-40cf-88e1-770e16c4c911@github.com>
 <MMhJ6k7YdCD6-jcqEtHBnVrszfDXWKoz5nFPiR95NXk=.31d7a11a-4bc1-47ad-9fd8-0521cdb58ba1@github.com>
Message-ID: <_Xf0ZAPfZnb5GHu7MWRDmWIo7eK68njIYTJgixior5U=.e6a773bc-d6a6-4dc0-84ca-4bba650ec358@github.com>

On Wed, 19 Oct 2022 16:36:56 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Please review this RFE for allowing alternative locations for jar files in the app classpath during runtime.
>> 
>> During dump time, the longest common prefix of the app classpath will be stored in the CDS archive header. During runtime, existing checks of the app classpath will be performed first. Upon failure, the longest common prefix of the runtime app classpath will be computed and another check of the app classpath will be performed ignoring the longest common prefix.
>> 
>> Refer to the [bug report comment](https://bugs.openjdk.org/browse/JDK-8279366?focusedCommentId=14509536&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14509536) for an example.
>> 
>> Passed tiers 1 - 4 testing (including the new tests).
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   merge check_paths_ignoring_common_prefix() into check_paths()

The changes look good!

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

Marked as reviewed by matias9927 at github.com (no known OpenJDK username).

PR: https://git.openjdk.org/jdk/pull/10615

From ccheung at openjdk.org  Tue Oct 25 17:52:48 2022
From: ccheung at openjdk.org (Calvin Cheung)
Date: Tue, 25 Oct 2022 17:52:48 GMT
Subject: RFR: 8279366: CDS should allow alternative locations for JAR files
 in classpath [v4]
In-Reply-To: <MMhJ6k7YdCD6-jcqEtHBnVrszfDXWKoz5nFPiR95NXk=.31d7a11a-4bc1-47ad-9fd8-0521cdb58ba1@github.com>
References: <gjn5N9Lmavel1A8AHZFHxbp0J2l6XklY_-Pr-N04k7g=.dd8b5ed1-2c55-40cf-88e1-770e16c4c911@github.com>
 <MMhJ6k7YdCD6-jcqEtHBnVrszfDXWKoz5nFPiR95NXk=.31d7a11a-4bc1-47ad-9fd8-0521cdb58ba1@github.com>
Message-ID: <GJaO_ijdalter44ek7wiPBDYptuqsBzYzPQ3uc5v2K0=.568d570a-e18e-454b-92c4-dbddd2927fe4@github.com>

On Wed, 19 Oct 2022 16:36:56 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Please review this RFE for allowing alternative locations for jar files in the app classpath during runtime.
>> 
>> During dump time, the longest common prefix of the app classpath will be stored in the CDS archive header. During runtime, existing checks of the app classpath will be performed first. Upon failure, the longest common prefix of the runtime app classpath will be computed and another check of the app classpath will be performed ignoring the longest common prefix.
>> 
>> Refer to the [bug report comment](https://bugs.openjdk.org/browse/JDK-8279366?focusedCommentId=14509536&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14509536) for an example.
>> 
>> Passed tiers 1 - 4 testing (including the new tests).
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   merge check_paths_ignoring_common_prefix() into check_paths()

Thanks Ioi, Coleen, Matias for the review!

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

PR: https://git.openjdk.org/jdk/pull/10615

From ccheung at openjdk.org  Tue Oct 25 17:56:04 2022
From: ccheung at openjdk.org (Calvin Cheung)
Date: Tue, 25 Oct 2022 17:56:04 GMT
Subject: Integrated: 8279366: CDS should allow alternative locations for JAR
 files in classpath
In-Reply-To: <gjn5N9Lmavel1A8AHZFHxbp0J2l6XklY_-Pr-N04k7g=.dd8b5ed1-2c55-40cf-88e1-770e16c4c911@github.com>
References: <gjn5N9Lmavel1A8AHZFHxbp0J2l6XklY_-Pr-N04k7g=.dd8b5ed1-2c55-40cf-88e1-770e16c4c911@github.com>
Message-ID: <SwIzmSC0rYT663qJvDt1cP3pXPyMZdTMJ9-Z-Sd4Tjg=.f3eb6884-9f8b-498c-a1a7-c47bf28b041d@github.com>

On Fri, 7 Oct 2022 22:59:09 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> Please review this RFE for allowing alternative locations for jar files in the app classpath during runtime.
> 
> During dump time, the longest common prefix of the app classpath will be stored in the CDS archive header. During runtime, existing checks of the app classpath will be performed first. Upon failure, the longest common prefix of the runtime app classpath will be computed and another check of the app classpath will be performed ignoring the longest common prefix.
> 
> Refer to the [bug report comment](https://bugs.openjdk.org/browse/JDK-8279366?focusedCommentId=14509536&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14509536) for an example.
> 
> Passed tiers 1 - 4 testing (including the new tests).

This pull request has now been integrated.

Changeset: 427f5062
Author:    Calvin Cheung <ccheung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/427f50624f9f60bb3502227fd04a04991986329c
Stats:     493 lines in 10 files changed: 470 ins; 1 del; 22 mod

8279366: CDS should allow alternative locations for JAR files in classpath

Reviewed-by: iklam, coleenp

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

PR: https://git.openjdk.org/jdk/pull/10615

From ccheung at openjdk.org  Tue Oct 25 18:52:23 2022
From: ccheung at openjdk.org (Calvin Cheung)
Date: Tue, 25 Oct 2022 18:52:23 GMT
Subject: RFR: 8295895: build error after JDK-8279366
Message-ID: <Wxmd-4fFapetVWma5vmPLf0-GQ9fZ86PSR9FThd78-U=.4498ad25-3acd-4797-8dea-6b2af93a21a9@github.com>

Fixing a build error caused by JDK-8279366.

Ran some sanity tests locally on linux-x64.

Tier1 testing in progress.

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

Commit messages:
 - 8295895: build error after JDK-8279366

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

PR: https://git.openjdk.org/jdk/pull/10858

From dcubed at openjdk.org  Tue Oct 25 18:52:25 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Tue, 25 Oct 2022 18:52:25 GMT
Subject: RFR: 8295895: build error after JDK-8279366
In-Reply-To: <Wxmd-4fFapetVWma5vmPLf0-GQ9fZ86PSR9FThd78-U=.4498ad25-3acd-4797-8dea-6b2af93a21a9@github.com>
References: <Wxmd-4fFapetVWma5vmPLf0-GQ9fZ86PSR9FThd78-U=.4498ad25-3acd-4797-8dea-6b2af93a21a9@github.com>
Message-ID: <SAe7em0LOzN_WQQV7euAC9RF6hiKppVsSznTwC5zHbA=.3d4f8ffa-aacc-47fe-8e6e-050d7abf5740@github.com>

On Tue, 25 Oct 2022 18:43:52 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> Fixing a build error caused by JDK-8279366.
> 
> Ran some sanity tests locally on linux-x64.
> 
> Tier1 testing in progress.

Marked as reviewed by dcubed (Reviewer).

Thumbs up. This is a trivial fix.

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

PR: https://git.openjdk.org/jdk/pull/10858Marked as reviewed by dcubed (Reviewer).

From ccheung at openjdk.org  Tue Oct 25 18:58:06 2022
From: ccheung at openjdk.org (Calvin Cheung)
Date: Tue, 25 Oct 2022 18:58:06 GMT
Subject: RFR: 8295895: build error after JDK-8279366
In-Reply-To: <Wxmd-4fFapetVWma5vmPLf0-GQ9fZ86PSR9FThd78-U=.4498ad25-3acd-4797-8dea-6b2af93a21a9@github.com>
References: <Wxmd-4fFapetVWma5vmPLf0-GQ9fZ86PSR9FThd78-U=.4498ad25-3acd-4797-8dea-6b2af93a21a9@github.com>
Message-ID: <j-GdzIhYhNAhBz4dVgoqKuRQMJuZbyBv41Wz484mraY=.39545c77-da1a-464c-8a9f-371566711632@github.com>

On Tue, 25 Oct 2022 18:43:52 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> Fixing a build error caused by JDK-8279366.
> 
> Ran some sanity tests locally on linux-x64.
> 
> Tier1 testing in progress.

Thanks Dan for the quick review!

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

PR: https://git.openjdk.org/jdk/pull/10858

From ccheung at openjdk.org  Tue Oct 25 18:58:06 2022
From: ccheung at openjdk.org (Calvin Cheung)
Date: Tue, 25 Oct 2022 18:58:06 GMT
Subject: Integrated: 8295895: build error after JDK-8279366
In-Reply-To: <Wxmd-4fFapetVWma5vmPLf0-GQ9fZ86PSR9FThd78-U=.4498ad25-3acd-4797-8dea-6b2af93a21a9@github.com>
References: <Wxmd-4fFapetVWma5vmPLf0-GQ9fZ86PSR9FThd78-U=.4498ad25-3acd-4797-8dea-6b2af93a21a9@github.com>
Message-ID: <B5eM0v8k4IDVt-HOluK9v1VkD8RXo2xGWwJNAx4pgB8=.22c2e062-8641-455a-818b-14fe0e9dc32f@github.com>

On Tue, 25 Oct 2022 18:43:52 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> Fixing a build error caused by JDK-8279366.
> 
> Ran some sanity tests locally on linux-x64.
> 
> Tier1 testing in progress.

This pull request has now been integrated.

Changeset: 0caea818
Author:    Calvin Cheung <ccheung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0caea818b59f7e2cd60708b1002fba328c5357fe
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8295895: build error after JDK-8279366

Reviewed-by: dcubed

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

PR: https://git.openjdk.org/jdk/pull/10858

From dholmes at openjdk.org  Wed Oct 26 00:33:45 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 26 Oct 2022 00:33:45 GMT
Subject: RFR: 8295713: runtime/ParallelLoad/SuperWait/SuperWaitTest.java
 fails intermittently on Windows [v5]
In-Reply-To: <Rro_nEjeoHa51JLf4KCMQTRUpCdEC9ITfqYrJiq1Ewo=.46d8e417-d348-4b9a-ba22-53e1538099f6@github.com>
References: <tk88whD-nXj1I8Ss1VpzWs85bLU162gSZU0RhlBfvYk=.670d0dd4-e891-4a9b-95b9-87716fc6a92e@github.com>
 <Rro_nEjeoHa51JLf4KCMQTRUpCdEC9ITfqYrJiq1Ewo=.46d8e417-d348-4b9a-ba22-53e1538099f6@github.com>
Message-ID: <w7AHq5FKHDmnrLZFhZci32am3XW0Lh1GaYN07I3tHj0=.4269b355-6ee2-4660-babe-607f738a8aac@github.com>

On Tue, 25 Oct 2022 13:23:38 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I added another semaphore so the test will run in the order I want it to.  Alternate suggestions or corrections welcome.
>> Running with GHA, and our tier1 in progress.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove volatile

Okay this seems fine from a logic perspective. There's one nit below that I missed before but up to you whether to change it.
Thanks.

test/hotspot/jtreg/runtime/ParallelLoad/SuperWait/SuperWaitTest.java line 39:

> 37: public class SuperWaitTest {
> 38: 
> 39:     private static boolean dIsLoading = false;

Nit: sorry just noticed the placement here. This is really an instance field of MyLoaderOne.

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10822

From dholmes at openjdk.org  Wed Oct 26 05:19:41 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 26 Oct 2022 05:19:41 GMT
Subject: RFR: JDK-8295889: NMT preinit code does not handle allocation
 errors
In-Reply-To: <GyxfmN-u6MoD_yPISj1QSYdGUKDiDkgkq_4aNCJLsXI=.88fbbdec-9088-4f3a-9a0f-6ab7a566209a@github.com>
References: <GyxfmN-u6MoD_yPISj1QSYdGUKDiDkgkq_4aNCJLsXI=.88fbbdec-9088-4f3a-9a0f-6ab7a566209a@github.com>
Message-ID: <E7-eHQgYDLbnQfgFKsiR1MSbDovFvRI0KlnekbfgmyM=.452cabfd-6abb-40e6-b285-7fce055a550d@github.com>

On Tue, 25 Oct 2022 15:18:05 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> The NMT preinit allocator (used for os::malloc and friends before the VM is initialized) does not handle malloc errors, nor does it handle overflows due to large sizes (it uses malloc headers too). Both cases need to be handled.
> 
> However, we can keep matters very simple. No need to propagate errors up to the caller; we can just fatal out on errors here since, in this phase, there is no alternative for failed allocations.

Doesn't seem unreasonable to check for OOM even though highly unlikely during VM init. But how would an overflow arise in practice? Seems like something more suited for an assertion.

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

PR: https://git.openjdk.org/jdk/pull/10855

From stuefe at openjdk.org  Wed Oct 26 05:37:24 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 26 Oct 2022 05:37:24 GMT
Subject: RFR: JDK-8295889: NMT preinit code does not handle allocation
 errors
In-Reply-To: <E7-eHQgYDLbnQfgFKsiR1MSbDovFvRI0KlnekbfgmyM=.452cabfd-6abb-40e6-b285-7fce055a550d@github.com>
References: <GyxfmN-u6MoD_yPISj1QSYdGUKDiDkgkq_4aNCJLsXI=.88fbbdec-9088-4f3a-9a0f-6ab7a566209a@github.com>
 <E7-eHQgYDLbnQfgFKsiR1MSbDovFvRI0KlnekbfgmyM=.452cabfd-6abb-40e6-b285-7fce055a550d@github.com>
Message-ID: <mwb2fXemzt2eoLNW3FeMUe8uYXIbTFzH8jWAiVke870=.b0fc0283-21d2-46a5-a0b7-e634f241a298@github.com>

On Wed, 26 Oct 2022 05:15:35 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Doesn't seem unreasonable to check for OOM even though highly unlikely during VM init. But how would an overflow arise in practice? Seems like something more suited for an assertion.

Hi David,

thanks for looking at this. Assert makes sense, I will do that. It can happen only by malpractice, if size is controlled via outside input. I cannot see a path where this would happen in VM preinit time though, so this is just theoretical. 

The issue was inspired by 8286519, where Harold did the same os::malloc. That made me look more closely at some corner cases and how they are handled. Another issue I work on is https://bugs.openjdk.org/browse/JDK-8295865.

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

PR: https://git.openjdk.org/jdk/pull/10855

From stuefe at openjdk.org  Wed Oct 26 05:45:33 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 26 Oct 2022 05:45:33 GMT
Subject: RFR: JDK-8295889: NMT preinit code does not handle allocation
 errors [v2]
In-Reply-To: <GyxfmN-u6MoD_yPISj1QSYdGUKDiDkgkq_4aNCJLsXI=.88fbbdec-9088-4f3a-9a0f-6ab7a566209a@github.com>
References: <GyxfmN-u6MoD_yPISj1QSYdGUKDiDkgkq_4aNCJLsXI=.88fbbdec-9088-4f3a-9a0f-6ab7a566209a@github.com>
Message-ID: <RF19izdycN5ONY_GquT6mxcXVtw9AfXzpCQeJRYamCs=.2fe97993-fc01-49b8-9fa1-5404fbf1a4d8@github.com>

> The NMT preinit allocator (used for os::malloc and friends before the VM is initialized) does not handle malloc errors, nor does it handle overflows due to large sizes (it uses malloc headers too). Both cases need to be handled.
> 
> However, we can keep matters very simple. No need to propagate errors up to the caller; we can just fatal out on errors here since, in this phase, there is no alternative for failed allocations.

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

  assert overflows (debug+release)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10855/files
  - new: https://git.openjdk.org/jdk/pull/10855/files/76d9d5ba..ac9c3365

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10855&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10855&range=00-01

  Stats: 6 lines in 1 file changed: 0 ins; 4 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10855.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10855/head:pull/10855

PR: https://git.openjdk.org/jdk/pull/10855

From dholmes at openjdk.org  Wed Oct 26 05:58:27 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 26 Oct 2022 05:58:27 GMT
Subject: RFR: JDK-8295889: NMT preinit code does not handle allocation
 errors [v2]
In-Reply-To: <RF19izdycN5ONY_GquT6mxcXVtw9AfXzpCQeJRYamCs=.2fe97993-fc01-49b8-9fa1-5404fbf1a4d8@github.com>
References: <GyxfmN-u6MoD_yPISj1QSYdGUKDiDkgkq_4aNCJLsXI=.88fbbdec-9088-4f3a-9a0f-6ab7a566209a@github.com>
 <RF19izdycN5ONY_GquT6mxcXVtw9AfXzpCQeJRYamCs=.2fe97993-fc01-49b8-9fa1-5404fbf1a4d8@github.com>
Message-ID: <qya-g8x8THN0OvzT2ijNtcaOEelxooR8gIP4ILz9bTc=.cc93d95c-a4e6-4903-8476-3b31b3644e8b@github.com>

On Wed, 26 Oct 2022 05:45:33 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> The NMT preinit allocator (used for os::malloc and friends before the VM is initialized) does not handle malloc errors, nor does it handle overflows due to large sizes (it uses malloc headers too). Both cases need to be handled.
>> 
>> However, we can keep matters very simple. No need to propagate errors up to the caller; we can just fatal out on errors here since, in this phase, there is no alternative for failed allocations.
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   assert overflows (debug+release)

Overflow is really only a concern if the incoming value could be user-supplied/influenced. For pure VM code an assert would suffice to guard against accident (mainly via whitebox or other test code that might try to hit edge cases).

src/hotspot/share/services/nmtPreInit.cpp line 55:

> 53: NMTPreInitAllocation* NMTPreInitAllocation::do_alloc(size_t payload_size) {
> 54:   const size_t outer_size = sizeof(NMTPreInitAllocation) + payload_size;
> 55:   guarantee(outer_size > payload_size, "Overflow");

I was suggesting an assertion as this is a VM programming error we should catch during testing in't it?

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

PR: https://git.openjdk.org/jdk/pull/10855

From stuefe at openjdk.org  Wed Oct 26 06:38:30 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 26 Oct 2022 06:38:30 GMT
Subject: RFR: JDK-8295889: NMT preinit code does not handle allocation
 errors [v2]
In-Reply-To: <qya-g8x8THN0OvzT2ijNtcaOEelxooR8gIP4ILz9bTc=.cc93d95c-a4e6-4903-8476-3b31b3644e8b@github.com>
References: <GyxfmN-u6MoD_yPISj1QSYdGUKDiDkgkq_4aNCJLsXI=.88fbbdec-9088-4f3a-9a0f-6ab7a566209a@github.com>
 <RF19izdycN5ONY_GquT6mxcXVtw9AfXzpCQeJRYamCs=.2fe97993-fc01-49b8-9fa1-5404fbf1a4d8@github.com>
 <qya-g8x8THN0OvzT2ijNtcaOEelxooR8gIP4ILz9bTc=.cc93d95c-a4e6-4903-8476-3b31b3644e8b@github.com>
Message-ID: <bOjjYvMd68UjPrATAYGQoy8mB-ZzsSx9pcxpXxQcNvk=.df92007d-0fa7-4c86-b88f-b8c1cf20395a@github.com>

On Wed, 26 Oct 2022 05:54:23 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   assert overflows (debug+release)
>
> src/hotspot/share/services/nmtPreInit.cpp line 55:
> 
>> 53: NMTPreInitAllocation* NMTPreInitAllocation::do_alloc(size_t payload_size) {
>> 54:   const size_t outer_size = sizeof(NMTPreInitAllocation) + payload_size;
>> 55:   guarantee(outer_size > payload_size, "Overflow");
> 
> I was suggesting an assertion as this is a VM programming error we should catch during testing in't it?

Guarantee as a protection against future bitrot. I am not even 100% sure there are not paths today that are controlled via outside input. I am even less sure about the future. Therefore I protect the release version too. Are you concerned about runtime costs? It is just a comparison.

OTOH I have no strong emotions here. If you insist, I can make it debug only.

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

PR: https://git.openjdk.org/jdk/pull/10855

From mbaesken at openjdk.org  Wed Oct 26 06:39:29 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 26 Oct 2022 06:39:29 GMT
Subject: RFR: JDK-8295710 : remove os::dll_file_extension [v3]
In-Reply-To: <Wb39gXKWs7nmunyZoC2JXsnMA9U6SEDO_b3m9A51o6c=.b5111e7b-2ddf-4900-bdcc-d7e5c69aa1c6@github.com>
References: <KIZm_XUGrbE0MHg0g73rv9FTdZXOKPR9CkURVixZ01c=.638be20f-7b02-4c3b-9b11-4ca3bedef125@github.com>
 <Wb39gXKWs7nmunyZoC2JXsnMA9U6SEDO_b3m9A51o6c=.b5111e7b-2ddf-4900-bdcc-d7e5c69aa1c6@github.com>
Message-ID: <BmHvy8srT--YA7gYccFQpjpCmSzdnBdRuJeURUAOhgg=.d55246e9-4b7f-417b-82ac-9101427ce242@github.com>

On Tue, 25 Oct 2022 11:35:03 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> The os::dll_file_extension() function could be unified for the different OS platforms.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove dll_file_extension from os.hpp

Hi David, Lutz and Martin, thanks for the reviews !

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

PR: https://git.openjdk.org/jdk/pull/10782

From mbaesken at openjdk.org  Wed Oct 26 06:39:30 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 26 Oct 2022 06:39:30 GMT
Subject: Integrated: JDK-8295710 : remove os::dll_file_extension
In-Reply-To: <KIZm_XUGrbE0MHg0g73rv9FTdZXOKPR9CkURVixZ01c=.638be20f-7b02-4c3b-9b11-4ca3bedef125@github.com>
References: <KIZm_XUGrbE0MHg0g73rv9FTdZXOKPR9CkURVixZ01c=.638be20f-7b02-4c3b-9b11-4ca3bedef125@github.com>
Message-ID: <494RDnxIIZdXnL7Ol32IopsErpWBW2gdGPXULaEDX-A=.a787450c-32ff-4be0-864a-879d379964cf@github.com>

On Thu, 20 Oct 2022 08:12:04 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The os::dll_file_extension() function could be unified for the different OS platforms.

This pull request has now been integrated.

Changeset: b2878c90
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b2878c904beb971da37b1da50a7294c460d6cef3
Stats:     13 lines in 6 files changed: 0 ins; 12 del; 1 mod

8295710: remove os::dll_file_extension

Reviewed-by: dholmes, mdoerr, lucy

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

PR: https://git.openjdk.org/jdk/pull/10782

From dholmes at openjdk.org  Wed Oct 26 07:34:24 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 26 Oct 2022 07:34:24 GMT
Subject: RFR: JDK-8295889: NMT preinit code does not handle allocation
 errors [v2]
In-Reply-To: <RF19izdycN5ONY_GquT6mxcXVtw9AfXzpCQeJRYamCs=.2fe97993-fc01-49b8-9fa1-5404fbf1a4d8@github.com>
References: <GyxfmN-u6MoD_yPISj1QSYdGUKDiDkgkq_4aNCJLsXI=.88fbbdec-9088-4f3a-9a0f-6ab7a566209a@github.com>
 <RF19izdycN5ONY_GquT6mxcXVtw9AfXzpCQeJRYamCs=.2fe97993-fc01-49b8-9fa1-5404fbf1a4d8@github.com>
Message-ID: <5yrFYfSRngT_FAxvyvDL5YCJnTn3_Nr1q08YvF6w9ms=.a4dd54a3-2997-4a7e-92cf-f25037bcfa69@github.com>

On Wed, 26 Oct 2022 05:45:33 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> The NMT preinit allocator (used for os::malloc and friends before the VM is initialized) does not handle malloc errors, nor does it handle overflows due to large sizes (it uses malloc headers too). Both cases need to be handled.
>> 
>> However, we can keep matters very simple. No need to propagate errors up to the caller; we can just fatal out on errors here since, in this phase, there is no alternative for failed allocations.
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   assert overflows (debug+release)

Marked as reviewed by dholmes (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10855

From dholmes at openjdk.org  Wed Oct 26 07:34:27 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 26 Oct 2022 07:34:27 GMT
Subject: RFR: JDK-8295889: NMT preinit code does not handle allocation
 errors [v2]
In-Reply-To: <bOjjYvMd68UjPrATAYGQoy8mB-ZzsSx9pcxpXxQcNvk=.df92007d-0fa7-4c86-b88f-b8c1cf20395a@github.com>
References: <GyxfmN-u6MoD_yPISj1QSYdGUKDiDkgkq_4aNCJLsXI=.88fbbdec-9088-4f3a-9a0f-6ab7a566209a@github.com>
 <RF19izdycN5ONY_GquT6mxcXVtw9AfXzpCQeJRYamCs=.2fe97993-fc01-49b8-9fa1-5404fbf1a4d8@github.com>
 <qya-g8x8THN0OvzT2ijNtcaOEelxooR8gIP4ILz9bTc=.cc93d95c-a4e6-4903-8476-3b31b3644e8b@github.com>
 <bOjjYvMd68UjPrATAYGQoy8mB-ZzsSx9pcxpXxQcNvk=.df92007d-0fa7-4c86-b88f-b8c1cf20395a@github.com>
Message-ID: <HJw4ljXZlxXbLPUytHehS2BTMh4f5SOK0baAiKPl6q4=.04c3290b-7c4c-4a2e-a0c5-f7dbcd31945d@github.com>

On Wed, 26 Oct 2022 06:35:55 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> src/hotspot/share/services/nmtPreInit.cpp line 55:
>> 
>>> 53: NMTPreInitAllocation* NMTPreInitAllocation::do_alloc(size_t payload_size) {
>>> 54:   const size_t outer_size = sizeof(NMTPreInitAllocation) + payload_size;
>>> 55:   guarantee(outer_size > payload_size, "Overflow");
>> 
>> I was suggesting an assertion as this is a VM programming error we should catch during testing in't it?
>
> Guarantee as a protection against future bitrot. I am not even 100% sure there are not paths today that are controlled via outside input. I am even less sure about the future. Therefore I protect the release version too. Are you concerned about runtime costs? It is just a comparison.
> 
> OTOH I have no strong emotions here. If you insist, I can make it debug only.

I'm more concerned that we don't know if this path may be influenced by external input. :(

These kind of "just in case" checks all add up.

But I won't insist on a change.

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

PR: https://git.openjdk.org/jdk/pull/10855

From stuefe at openjdk.org  Wed Oct 26 07:54:25 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 26 Oct 2022 07:54:25 GMT
Subject: RFR: JDK-8295889: NMT preinit code does not handle allocation
 errors [v2]
In-Reply-To: <RF19izdycN5ONY_GquT6mxcXVtw9AfXzpCQeJRYamCs=.2fe97993-fc01-49b8-9fa1-5404fbf1a4d8@github.com>
References: <GyxfmN-u6MoD_yPISj1QSYdGUKDiDkgkq_4aNCJLsXI=.88fbbdec-9088-4f3a-9a0f-6ab7a566209a@github.com>
 <RF19izdycN5ONY_GquT6mxcXVtw9AfXzpCQeJRYamCs=.2fe97993-fc01-49b8-9fa1-5404fbf1a4d8@github.com>
Message-ID: <2kCAHATs_uLlltA-kpNCIUTMEiYrqUvor22WKxT7cGg=.f68edb8a-d392-400d-9ec8-4f853452607c@github.com>

On Wed, 26 Oct 2022 05:45:33 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> The NMT preinit allocator (used for os::malloc and friends before the VM is initialized) does not handle malloc errors, nor does it handle overflows due to large sizes (it uses malloc headers too). Both cases need to be handled.
>> 
>> However, we can keep matters very simple. No need to propagate errors up to the caller; we can just fatal out on errors here since, in this phase, there is no alternative for failed allocations.
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   assert overflows (debug+release)

> I'm more concerned that we don't know if this path may be influenced by external input. :(

The only randomness source I can think of is arguments. Argument handling is done before parsing and therefore before NMT initialization in preinit time. It influences the number of allocated blocks as well as their size. So if someone were to pass an argument close to size_max to the VM, it would run into overflow :-) but that is not possible, of course.

> These kind of "just in case" checks all add up.

True. But as this is security relevant, I'll leave it in. I rather shave off time somewhere else. E.g. in the real os::malloc, there are some optimizations we can do. E.g. getting rid of the atomic allocation counters in os.cpp since we do have NMT counting and malloc limits now. That is one thing I have on my list.

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

PR: https://git.openjdk.org/jdk/pull/10855

From mbaesken at openjdk.org  Wed Oct 26 08:28:22 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 26 Oct 2022 08:28:22 GMT
Subject: RFR: JDK-8295889: NMT preinit code does not handle allocation
 errors [v2]
In-Reply-To: <RF19izdycN5ONY_GquT6mxcXVtw9AfXzpCQeJRYamCs=.2fe97993-fc01-49b8-9fa1-5404fbf1a4d8@github.com>
References: <GyxfmN-u6MoD_yPISj1QSYdGUKDiDkgkq_4aNCJLsXI=.88fbbdec-9088-4f3a-9a0f-6ab7a566209a@github.com>
 <RF19izdycN5ONY_GquT6mxcXVtw9AfXzpCQeJRYamCs=.2fe97993-fc01-49b8-9fa1-5404fbf1a4d8@github.com>
Message-ID: <A_5tBrQS6E0qIADiS3SSHe6cn_ozYPf-krnH-Nl7DUM=.e5620d7e-5eac-4071-b800-b170dbcc8255@github.com>

On Wed, 26 Oct 2022 05:45:33 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> The NMT preinit allocator (used for os::malloc and friends before the VM is initialized) does not handle malloc errors, nor does it handle overflows due to large sizes (it uses malloc headers too). Both cases need to be handled.
>> 
>> However, we can keep matters very simple. No need to propagate errors up to the caller; we can just fatal out on errors here since, in this phase, there is no alternative for failed allocations.
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   assert overflows (debug+release)

I would prefer more detailed guarantee output like for example
guarantee(outer_size > payload_size, "Overflow - %zu must be larger than payload size %zu", outer_size, payload_size);
But it is okay as it is too, approved.

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

Marked as reviewed by mbaesken (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10855

From stuefe at openjdk.org  Wed Oct 26 08:39:01 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 26 Oct 2022 08:39:01 GMT
Subject: RFR: JDK-8295889: NMT preinit code does not handle allocation
 errors [v2]
In-Reply-To: <A_5tBrQS6E0qIADiS3SSHe6cn_ozYPf-krnH-Nl7DUM=.e5620d7e-5eac-4071-b800-b170dbcc8255@github.com>
References: <GyxfmN-u6MoD_yPISj1QSYdGUKDiDkgkq_4aNCJLsXI=.88fbbdec-9088-4f3a-9a0f-6ab7a566209a@github.com>
 <RF19izdycN5ONY_GquT6mxcXVtw9AfXzpCQeJRYamCs=.2fe97993-fc01-49b8-9fa1-5404fbf1a4d8@github.com>
 <A_5tBrQS6E0qIADiS3SSHe6cn_ozYPf-krnH-Nl7DUM=.e5620d7e-5eac-4071-b800-b170dbcc8255@github.com>
Message-ID: <XIsNfXAyMZE6zJqLPzvLXP3Gfv7zanHk23DBKZdm0HI=.1b52a993-5be1-4e1b-9ac6-eb9265cb42e6@github.com>

On Wed, 26 Oct 2022 08:25:56 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> I would prefer more detailed guarantee output like for example guarantee(outer_size > payload_size, "Overflow - %zu must be larger than payload size %zu", outer_size, payload_size); But it is okay as it is too, approved.

Thanks Matthias! I expect this never to fire, and if it does, someone needs to dive in anyway.

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

PR: https://git.openjdk.org/jdk/pull/10855

From stuefe at openjdk.org  Wed Oct 26 08:39:03 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 26 Oct 2022 08:39:03 GMT
Subject: Integrated: JDK-8295889: NMT preinit code does not handle allocation
 errors
In-Reply-To: <GyxfmN-u6MoD_yPISj1QSYdGUKDiDkgkq_4aNCJLsXI=.88fbbdec-9088-4f3a-9a0f-6ab7a566209a@github.com>
References: <GyxfmN-u6MoD_yPISj1QSYdGUKDiDkgkq_4aNCJLsXI=.88fbbdec-9088-4f3a-9a0f-6ab7a566209a@github.com>
Message-ID: <FxwVBDyfQWKDj6WOTZ4wqolP9GKxFUnGdxy1sdE5vYg=.5a972a6c-ce50-4aaa-86a3-a34edbcea9b3@github.com>

On Tue, 25 Oct 2022 15:18:05 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> The NMT preinit allocator (used for os::malloc and friends before the VM is initialized) does not handle malloc errors, nor does it handle overflows due to large sizes (it uses malloc headers too). Both cases need to be handled.
> 
> However, we can keep matters very simple. No need to propagate errors up to the caller; we can just fatal out on errors here since, in this phase, there is no alternative for failed allocations.

This pull request has now been integrated.

Changeset: cf121df1
Author:    Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cf121df17e60df61a1b8825724c0d735f11e73f6
Stats:     34 lines in 2 files changed: 34 ins; 0 del; 0 mod

8295889: NMT preinit code does not handle allocation errors

Reviewed-by: dholmes, mbaesken

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

PR: https://git.openjdk.org/jdk/pull/10855

From stuefe at openjdk.org  Wed Oct 26 09:59:01 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 26 Oct 2022 09:59:01 GMT
Subject: RFR: JDK-8295865: Several issues with os::realloc
Message-ID: <tyUwv4vp-gfhzLNjZRuVM7aHJ_sXVvgeaRPoKsgxIag=.47ea1c16-2b54-484e-bca6-cae1fcd0fad7@github.com>

There are several issues with os::realloc():

1) If realloc(3) fails, the original block will be left untouched. That is fine, and the caller may expect this continue to use it, and later hand it to os::free(). But NMT has marked the original block as dead already. This will cause a subsequent os::free() or os::realloc() to trigger a false block integrity error. So, if realloc(3) fails, we need to revive the NMT header and re-account the original block.

2) If handed in very large sizes, the size may overflow if the NMT header is added. The result would be that the VM reallocates to a much smaller buffer which would cause subsequent memory corruption if the caller were to use the buffer (same as JDK-8286519, but for realloc).

3) If os::realloc() enlarges a buffer, the newly added memory should be zapped with uinitBlockPad as we do for os::malloc(). Of course we only can do this if NMT is enabled, otherwise we won't know the original block size.

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

The patch fixes all three issues and adds hopefully thorough enough regression gtests for them. Remember that these gtests will run, as part of the jtreg gtest runners, in all NMT modes.

The largest diff hunk is inside os::realloc(). Note that I separated the two cases NMT=summary/detail and NMT=off, since it makes the coding easier to understand and we also run less code in the standard case of NMT==off.

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

Commit messages:
 - Fix various issues with realloc

Changes: https://git.openjdk.org/jdk/pull/10857/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10857&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295865
  Stats: 197 lines in 4 files changed: 186 ins; 2 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/10857.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10857/head:pull/10857

PR: https://git.openjdk.org/jdk/pull/10857

From stuefe at openjdk.org  Wed Oct 26 09:59:02 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 26 Oct 2022 09:59:02 GMT
Subject: RFR: JDK-8295865: Several issues with os::realloc
In-Reply-To: <tyUwv4vp-gfhzLNjZRuVM7aHJ_sXVvgeaRPoKsgxIag=.47ea1c16-2b54-484e-bca6-cae1fcd0fad7@github.com>
References: <tyUwv4vp-gfhzLNjZRuVM7aHJ_sXVvgeaRPoKsgxIag=.47ea1c16-2b54-484e-bca6-cae1fcd0fad7@github.com>
Message-ID: <lp3rvaLkajq8EnVpWO6Kzz5tAJJCIplMQgKqq73Z3rQ=.e65c3777-c6c2-47ff-8b07-d529d2b88afe@github.com>

On Tue, 25 Oct 2022 16:27:37 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> There are several issues with os::realloc():
> 
> 1) If realloc(3) fails, the original block will be left untouched. That is fine, and the caller may expect this continue to use it, and later hand it to os::free(). But NMT has marked the original block as dead already. This will cause a subsequent os::free() or os::realloc() to trigger a false block integrity error. So, if realloc(3) fails, we need to revive the NMT header and re-account the original block.
> 
> 2) If handed in very large sizes, the size may overflow if the NMT header is added. The result would be that the VM reallocates to a much smaller buffer which would cause subsequent memory corruption if the caller were to use the buffer (same as JDK-8286519, but for realloc).
> 
> 3) If os::realloc() enlarges a buffer, the newly added memory should be zapped with uinitBlockPad as we do for os::malloc(). Of course we only can do this if NMT is enabled, otherwise we won't know the original block size.
> 
> ------------------------------
> 
> The patch fixes all three issues and adds hopefully thorough enough regression gtests for them. Remember that these gtests will run, as part of the jtreg gtest runners, in all NMT modes.
> 
> The largest diff hunk is inside os::realloc(). Note that I separated the two cases NMT=summary/detail and NMT=off, since it makes the coding easier to understand and we also run less code in the standard case of NMT==off.

32-bit errors unrelated. To be sure I built 32-bit manually on x86, and ran gtests with and without NMT, all is well.

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

PR: https://git.openjdk.org/jdk/pull/10857

From coleenp at openjdk.org  Wed Oct 26 17:31:20 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 26 Oct 2022 17:31:20 GMT
Subject: RFR: 8295713: runtime/ParallelLoad/SuperWait/SuperWaitTest.java
 fails intermittently on Windows [v6]
In-Reply-To: <tk88whD-nXj1I8Ss1VpzWs85bLU162gSZU0RhlBfvYk=.670d0dd4-e891-4a9b-95b9-87716fc6a92e@github.com>
References: <tk88whD-nXj1I8Ss1VpzWs85bLU162gSZU0RhlBfvYk=.670d0dd4-e891-4a9b-95b9-87716fc6a92e@github.com>
Message-ID: <sqypLs6-oH_56PAbu6_PRjFlcsSww-gktd1rDnA4k_0=.d5571962-6678-4d5c-bdd9-fac09d7b0d71@github.com>

> I added another semaphore so the test will run in the order I want it to.  Alternate suggestions or corrections welcome.
> Running with GHA, and our tier1 in progress.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Fix nit.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10822/files
  - new: https://git.openjdk.org/jdk/pull/10822/files/8278537a..aad3a70f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10822&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10822&range=04-05

  Stats: 4 lines in 1 file changed: 2 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10822.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10822/head:pull/10822

PR: https://git.openjdk.org/jdk/pull/10822

From coleenp at openjdk.org  Wed Oct 26 17:31:22 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 26 Oct 2022 17:31:22 GMT
Subject: RFR: 8295713: runtime/ParallelLoad/SuperWait/SuperWaitTest.java
 fails intermittently on Windows [v5]
In-Reply-To: <Rro_nEjeoHa51JLf4KCMQTRUpCdEC9ITfqYrJiq1Ewo=.46d8e417-d348-4b9a-ba22-53e1538099f6@github.com>
References: <tk88whD-nXj1I8Ss1VpzWs85bLU162gSZU0RhlBfvYk=.670d0dd4-e891-4a9b-95b9-87716fc6a92e@github.com>
 <Rro_nEjeoHa51JLf4KCMQTRUpCdEC9ITfqYrJiq1Ewo=.46d8e417-d348-4b9a-ba22-53e1538099f6@github.com>
Message-ID: <Y9Baz9IVEH_roPB1DtVUyjSI0yGP3rbydli4JKL2G_w=.79919c52-8c52-4dd6-afec-bcc233469172@github.com>

On Tue, 25 Oct 2022 13:23:38 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I added another semaphore so the test will run in the order I want it to.  Alternate suggestions or corrections welcome.
>> Running with GHA, and our tier1 in progress.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove volatile

Thanks for the reviews Patricio and David.

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

PR: https://git.openjdk.org/jdk/pull/10822

From coleenp at openjdk.org  Wed Oct 26 17:31:23 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 26 Oct 2022 17:31:23 GMT
Subject: RFR: 8295713: runtime/ParallelLoad/SuperWait/SuperWaitTest.java
 fails intermittently on Windows [v5]
In-Reply-To: <w7AHq5FKHDmnrLZFhZci32am3XW0Lh1GaYN07I3tHj0=.4269b355-6ee2-4660-babe-607f738a8aac@github.com>
References: <tk88whD-nXj1I8Ss1VpzWs85bLU162gSZU0RhlBfvYk=.670d0dd4-e891-4a9b-95b9-87716fc6a92e@github.com>
 <Rro_nEjeoHa51JLf4KCMQTRUpCdEC9ITfqYrJiq1Ewo=.46d8e417-d348-4b9a-ba22-53e1538099f6@github.com>
 <w7AHq5FKHDmnrLZFhZci32am3XW0Lh1GaYN07I3tHj0=.4269b355-6ee2-4660-babe-607f738a8aac@github.com>
Message-ID: <vyLPk_OJU0-XuRA9alV69Mel02_o01GtIM8HJtf7RVE=.4d64b43a-55eb-43ff-837f-ad3eee88944f@github.com>

On Wed, 26 Oct 2022 00:30:25 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove volatile
>
> test/hotspot/jtreg/runtime/ParallelLoad/SuperWait/SuperWaitTest.java line 39:
> 
>> 37: public class SuperWaitTest {
>> 38: 
>> 39:     private static boolean dIsLoading = false;
> 
> Nit: sorry just noticed the placement here. This is really an instance field of MyLoaderOne.

I fixed it.

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

PR: https://git.openjdk.org/jdk/pull/10822

From coleenp at openjdk.org  Wed Oct 26 17:33:04 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 26 Oct 2022 17:33:04 GMT
Subject: Integrated: 8295713: runtime/ParallelLoad/SuperWait/SuperWaitTest.java
 fails intermittently on Windows
In-Reply-To: <tk88whD-nXj1I8Ss1VpzWs85bLU162gSZU0RhlBfvYk=.670d0dd4-e891-4a9b-95b9-87716fc6a92e@github.com>
References: <tk88whD-nXj1I8Ss1VpzWs85bLU162gSZU0RhlBfvYk=.670d0dd4-e891-4a9b-95b9-87716fc6a92e@github.com>
Message-ID: <ufoUFwdDR9vbCH4JgI1qL_hJLNLKERtVjF1AiNVdIj8=.042fd284-d693-485f-8cbc-e5891d591818@github.com>

On Fri, 21 Oct 2022 18:19:36 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> I added another semaphore so the test will run in the order I want it to.  Alternate suggestions or corrections welcome.
> Running with GHA, and our tier1 in progress.

This pull request has now been integrated.

Changeset: a8450b37
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a8450b37ee6ea83c5354ba0892ac71df19e5a1cc
Stats:     36 lines in 2 files changed: 7 ins; 17 del; 12 mod

8295713: runtime/ParallelLoad/SuperWait/SuperWaitTest.java fails intermittently on Windows

Reviewed-by: pchilanomate, dholmes

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

PR: https://git.openjdk.org/jdk/pull/10822

From iklam at openjdk.org  Thu Oct 27 05:17:27 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 27 Oct 2022 05:17:27 GMT
Subject: RFR: 8286431: Do not use resource array in posix
 mmap_attach_shared() [v3]
In-Reply-To: <ilMQJwSkR-8ZsXHtlFKIXyvKf63185rovLf5l28KBnc=.8cf85ba9-93d3-4ba5-bdda-7de280f1583b@github.com>
References: <ilMQJwSkR-8ZsXHtlFKIXyvKf63185rovLf5l28KBnc=.8cf85ba9-93d3-4ba5-bdda-7de280f1583b@github.com>
Message-ID: <gwZ0-1I7NPOTId-wIa2kmZcUJdcBftv3hO2SIxTkBgU=.6bd7b14b-7023-46a9-ab67-eab741d809d7@github.com>

> Please review this small clean up
> 
> perfMemory_posix.cpp uses a lot of explicit C heap alloc/free because the function may be called during early VM bootstrap, before ResourceMark can be used.
> 
> However, we have a single odd use of resource allocation in this file. It's supposed to work with Java exceptions. However, the code actually makes an explicitly exception check, so there's no need to do the resource alloc at all.
> 
> Also, there's no need to close the fd in case of exception.

Ioi Lam 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 8286431-do-not-use-resource-alloc-in-mmap_attach_shared
 - @dholmes-ora comments
 - 8286431: Do not use resource array in posix mmap_attach_shared()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10686/files
  - new: https://git.openjdk.org/jdk/pull/10686/files/6e99ca65..71c97157

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10686&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10686&range=01-02

  Stats: 161898 lines in 1927 files changed: 92024 ins; 35908 del; 33966 mod
  Patch: https://git.openjdk.org/jdk/pull/10686.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10686/head:pull/10686

PR: https://git.openjdk.org/jdk/pull/10686

From iklam at openjdk.org  Thu Oct 27 05:17:27 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 27 Oct 2022 05:17:27 GMT
Subject: RFR: 8286431: Do not use resource array in posix
 mmap_attach_shared() [v2]
In-Reply-To: <56J8jT541QqmorVIXY5q_hVcDoa4N_sMS2RzbUKpV-0=.40b2b6a3-a4a6-4789-8d9d-7600df99d85d@github.com>
References: <ilMQJwSkR-8ZsXHtlFKIXyvKf63185rovLf5l28KBnc=.8cf85ba9-93d3-4ba5-bdda-7de280f1583b@github.com>
 <NxfDFaKfwF3VckkQaIHw3rkgDQfcT3d4WAwB--lVqyQ=.31494c92-7e8e-4eb1-87a8-5faeb9d2beda@github.com>
 <56J8jT541QqmorVIXY5q_hVcDoa4N_sMS2RzbUKpV-0=.40b2b6a3-a4a6-4789-8d9d-7600df99d85d@github.com>
Message-ID: <VW8ZC2BaOqKgeukuo5x4U9m7mQgNeNk_HCqq1D3BF88=.61477477-07c7-41bc-9401-dc5b0a1ec401@github.com>

On Thu, 13 Oct 2022 23:38:16 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @dholmes-ora comments
>
> Looks good. Thanks

Thanks @dholmes-ora and @jdksjolen for the review.

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

PR: https://git.openjdk.org/jdk/pull/10686

From iklam at openjdk.org  Thu Oct 27 05:19:09 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 27 Oct 2022 05:19:09 GMT
Subject: Integrated: 8286431: Do not use resource array in posix
 mmap_attach_shared()
In-Reply-To: <ilMQJwSkR-8ZsXHtlFKIXyvKf63185rovLf5l28KBnc=.8cf85ba9-93d3-4ba5-bdda-7de280f1583b@github.com>
References: <ilMQJwSkR-8ZsXHtlFKIXyvKf63185rovLf5l28KBnc=.8cf85ba9-93d3-4ba5-bdda-7de280f1583b@github.com>
Message-ID: <s8dFQCrXGBSj6I5OWV4Ew-3eODu431ck0labKcThz18=.66f1ce5f-3e1c-4a61-ba5c-bea5bf647b38@github.com>

On Thu, 13 Oct 2022 03:48:03 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Please review this small clean up
> 
> perfMemory_posix.cpp uses a lot of explicit C heap alloc/free because the function may be called during early VM bootstrap, before ResourceMark can be used.
> 
> However, we have a single odd use of resource allocation in this file. It's supposed to work with Java exceptions. However, the code actually makes an explicitly exception check, so there's no need to do the resource alloc at all.
> 
> Also, there's no need to close the fd in case of exception.

This pull request has now been integrated.

Changeset: 521e7122
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/521e71222a8a01edcffedafb2d57c16aa070545c
Stats:     19 lines in 1 file changed: 1 ins; 14 del; 4 mod

8286431: Do not use resource array in posix mmap_attach_shared()

Reviewed-by: dholmes, jsjolen

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

PR: https://git.openjdk.org/jdk/pull/10686

From stuefe at openjdk.org  Thu Oct 27 05:26:35 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 27 Oct 2022 05:26:35 GMT
Subject: RFR: JDK-8295865: Several issues with os::realloc
In-Reply-To: <tyUwv4vp-gfhzLNjZRuVM7aHJ_sXVvgeaRPoKsgxIag=.47ea1c16-2b54-484e-bca6-cae1fcd0fad7@github.com>
References: <tyUwv4vp-gfhzLNjZRuVM7aHJ_sXVvgeaRPoKsgxIag=.47ea1c16-2b54-484e-bca6-cae1fcd0fad7@github.com>
Message-ID: <soOfiSIuLZTmPm1p47EIDhbnUIZw3v0NgZX2UmKKA-w=.2d97f895-5aed-4872-a1b3-16ed1b3a6db9@github.com>

On Tue, 25 Oct 2022 16:27:37 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> There are several issues with os::realloc():
> 
> 1) If realloc(3) fails, the original block will be left untouched. That is fine, and the caller may expect this continue to use it, and later hand it to os::free(). But NMT has marked the original block as dead already. This will cause a subsequent os::free() or os::realloc() to trigger a false block integrity error. So, if realloc(3) fails, we need to revive the NMT header and re-account the original block.
> 
> 2) If handed in very large sizes, the size may overflow if the NMT header is added. The result would be that the VM reallocates to a much smaller buffer which would cause subsequent memory corruption if the caller were to use the buffer (same as JDK-8286519, but for realloc).
> 
> 3) If os::realloc() enlarges a buffer, the newly added memory should be zapped with uinitBlockPad as we do for os::malloc(). Of course we only can do this if NMT is enabled, otherwise we won't know the original block size.
> 
> ------------------------------
> 
> The patch fixes all three issues and adds hopefully thorough enough regression gtests for them. Remember that these gtests will run, as part of the jtreg gtest runners, in all NMT modes.
> 
> The largest diff hunk is inside os::realloc(). Note that I separated the two cases NMT=summary/detail and NMT=off, since it makes the coding easier to understand and we also run less code in the standard case of NMT==off.

Tested in SAP nightlies on all our platforms, no problems surfaced

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

PR: https://git.openjdk.org/jdk/pull/10857

From xxinliu at amazon.com  Thu Oct 27 07:07:29 2022
From: xxinliu at amazon.com (Liu, Xin)
Date: Thu, 27 Oct 2022 00:07:29 -0700
Subject: BitMap vs VectorSet?
Message-ID: <99f36403-8ac4-7fc0-656d-22305cb1fc40@amazon.com>

hi,

Recently, I extended VectorSet(libadt/vectset.hpp) to support
intersection. Then I found that there is yet another "vector set" called
'BitMap'. From my reading, the data structure of BitMap is same as
VectorSet. BitMap has already supported intersection/union/difference
and it even owns corresponding gtests.

Given that, why does HotSpot still need to maintain both VectorSet and
BitMap? I grep VectorSet and there are still many references. Is that
too troublesome to replace VectorSet with BitMap or there are other
reasons?

I modified VectorSet because Unique_Node_List(node.hpp) uses it. I
hesitate now. Should I invest a new gtest for the new code or I just use
BitMap instead?

thanks,
--lx
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0xB9D934C61E047B0D.asc
Type: application/pgp-keys
Size: 3675 bytes
Desc: OpenPGP public key
URL: <https://mail.openjdk.org/pipermail/hotspot-runtime-dev/attachments/20221027/06c4f354/OpenPGP_0xB9D934C61E047B0D-0001.asc>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/hotspot-runtime-dev/attachments/20221027/06c4f354/OpenPGP_signature-0001.sig>

From john.r.rose at oracle.com  Thu Oct 27 18:07:08 2022
From: john.r.rose at oracle.com (John Rose)
Date: Thu, 27 Oct 2022 11:07:08 -0700
Subject: BitMap vs VectorSet?
In-Reply-To: <99f36403-8ac4-7fc0-656d-22305cb1fc40@amazon.com>
References: <99f36403-8ac4-7fc0-656d-22305cb1fc40@amazon.com>
Message-ID: <85CC51C0-02E2-44A6-9116-F08530546057@oracle.com>

This is a good question, and a reasonable time to engage with it as well.

The code in src/hotspot/share/libadt is very old (~30 years) and has not been vigorously maintained, relative to changes in C++ practice.

BitMap is newer and its code is more modern and actively maintained.  (Thanks Kim B. et al.)  In my opinion, it deserves to be used instead of VectorSet.  Having two classes for the same set of tasks is technical debt.  It is the sort of thing that naturally happens on a large project when two groups settle on different solutions for a common problem.  And the sort of thing a large project has to clean up over time.

So, I support taking steps (reasonable, gradual, limited-impact steps) to retire the classes in libadt, replacing them with more modern ones, in src/hotspot/share/utilities.

As you note, Xin, this is somewhat more urgent as we increase our gtest coverage, since we don?t want to develop two sets of new tests for the same application area.

It?s also more urgent as hardware technology advances:  If we choose to work harder to vectorize bitset operations, we don?t want to do that work twice.

It?s also more urgent as software technology advances.  I?m reminded that there are many new algorithms for bit-twiddling (the name Daniel Lemire comes to mind, for one) and (again: get the pattern?) we don?t want to upgrade the algorithms twice.

People working on HotSpot routinely deal with extremely challenging software problems, specific to optimization, garbage collection, concurrency, platform support, performance, and more.  It?s hard to always, also, select well-tested, well-designed shared libraries to help with these problems; sometimes you just have to roll your own.  But while understandable, that tends to create technical debt.  That sometimes leads to failures (unscheduled payments on technical debt) due to lack of test coverage, simply because some work somewhere didn?t use common code but ?rolled their own? algorithms.

So, yes, let?s double down on BitSet and retire VectorSet.

(And Dict, while we are at it: There are some really nice hash table classes developed recently by the runtime group; surely we are not too far from merging the job of Dict into that group of classes?)

? John

On 27 Oct 2022, at 0:07, Liu, Xin wrote:

> hi,
>
> Recently, I extended VectorSet(libadt/vectset.hpp) to support
> intersection. Then I found that there is yet another "vector set" called
> 'BitMap'. From my reading, the data structure of BitMap is same as
> VectorSet. BitMap has already supported intersection/union/difference
> and it even owns corresponding gtests.
>
> Given that, why does HotSpot still need to maintain both VectorSet and
> BitMap? I grep VectorSet and there are still many references. Is that
> too troublesome to replace VectorSet with BitMap or there are other
> reasons?
>
> I modified VectorSet because Unique_Node_List(node.hpp) uses it. I
> hesitate now. Should I invest a new gtest for the new code or I just use
> BitMap instead?
>
> thanks,
> --lx

From dlong at openjdk.org  Thu Oct 27 21:06:40 2022
From: dlong at openjdk.org (Dean Long)
Date: Thu, 27 Oct 2022 21:06:40 GMT
Subject: RFR: 8296007: crash in runtime/DefineClass/NullClassBytesTest.java
Message-ID: <0kHvtRJawBMOY0qjuqXqZ2VanYDACHcbn_yi-e6jNpk=.0e6da858-d19f-49a8-828e-4243cd02f372@github.com>

This is a simple fix to Java_NullClassBytesTest_nativeDefineClass so that it returns the jclass as expected.

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

Commit messages:
 - return jclass

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

PR: https://git.openjdk.org/jdk/pull/10892

From dcubed at openjdk.org  Thu Oct 27 21:18:28 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 27 Oct 2022 21:18:28 GMT
Subject: RFR: 8296007: crash in runtime/DefineClass/NullClassBytesTest.java
In-Reply-To: <0kHvtRJawBMOY0qjuqXqZ2VanYDACHcbn_yi-e6jNpk=.0e6da858-d19f-49a8-828e-4243cd02f372@github.com>
References: <0kHvtRJawBMOY0qjuqXqZ2VanYDACHcbn_yi-e6jNpk=.0e6da858-d19f-49a8-828e-4243cd02f372@github.com>
Message-ID: <kl1TusRENBrIZEOvZYkcXBktQYmwfJO6o4SMezASR3I=.5d462cb9-8559-46b8-a974-ced922ef1c9b@github.com>

On Thu, 27 Oct 2022 21:00:17 GMT, Dean Long <dlong at openjdk.org> wrote:

> This is a simple fix to Java_NullClassBytesTest_nativeDefineClass so that it returns the jclass as expected.

Thumbs up.

So did the callers of the function just assume there was
a return value? Why didn't this result in a linkage warning
or some other type of warning?

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

Marked as reviewed by dcubed (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10892

From dlong at openjdk.org  Thu Oct 27 21:49:38 2022
From: dlong at openjdk.org (Dean Long)
Date: Thu, 27 Oct 2022 21:49:38 GMT
Subject: RFR: 8296007: crash in runtime/DefineClass/NullClassBytesTest.java
In-Reply-To: <kl1TusRENBrIZEOvZYkcXBktQYmwfJO6o4SMezASR3I=.5d462cb9-8559-46b8-a974-ced922ef1c9b@github.com>
References: <0kHvtRJawBMOY0qjuqXqZ2VanYDACHcbn_yi-e6jNpk=.0e6da858-d19f-49a8-828e-4243cd02f372@github.com>
 <kl1TusRENBrIZEOvZYkcXBktQYmwfJO6o4SMezASR3I=.5d462cb9-8559-46b8-a974-ced922ef1c9b@github.com>
Message-ID: <GdGihX2MEMKrz-JWMwPk1mis2gaFJ_DjSBZG0JXfb3w=.9df19025-6a2b-4994-a4ce-d89ae1f96955@github.com>

On Thu, 27 Oct 2022 21:16:07 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Thumbs up.

Thanks, Dan, for the review.

> So did the callers of the function just assume there was a return value?

Yes, the test creates its own ClassLoader, so the value is needed as part of class loading.

> Why didn't this result in a linkage warning or some other type of warning?

I don't think there is any way to automatically detect this.  The return type of a native method is not part of the symbol name for exported C functions, as far as I know.  We could probably check that the result is a valid oop for native methods that return objects.  That could be something extra that -Xcheck:jni does, perhaps.

How this went undetected is because the native method either throws an exception, so the result is ignored, or it calls DefineClass(), which sets the result register to the right value.  This is the last line of the function, so there is a good chance that the result register will have the right value when it returns.  However I was running a debug build and the function epilogue that gcc generated modified the result register to perform a stack corruption check.

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

PR: https://git.openjdk.org/jdk/pull/10892

From dcubed at openjdk.org  Thu Oct 27 22:33:31 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 27 Oct 2022 22:33:31 GMT
Subject: RFR: 8296007: crash in runtime/DefineClass/NullClassBytesTest.java
In-Reply-To: <0kHvtRJawBMOY0qjuqXqZ2VanYDACHcbn_yi-e6jNpk=.0e6da858-d19f-49a8-828e-4243cd02f372@github.com>
References: <0kHvtRJawBMOY0qjuqXqZ2VanYDACHcbn_yi-e6jNpk=.0e6da858-d19f-49a8-828e-4243cd02f372@github.com>
Message-ID: <oTnulxj-IeS41TuXVYi1bysQ1clAyLQOksdZ4mb5n_0=.f62b0eee-0fb8-42fb-8e09-f0867aed4e51@github.com>

On Thu, 27 Oct 2022 21:00:17 GMT, Dean Long <dlong at openjdk.org> wrote:

> This is a simple fix to Java_NullClassBytesTest_nativeDefineClass so that it returns the jclass as expected.

Thanks for the detailed explanation!

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

PR: https://git.openjdk.org/jdk/pull/10892

From mbaesken at openjdk.org  Fri Oct 28 07:01:14 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 28 Oct 2022 07:01:14 GMT
Subject: RFR: 8295872: [PPC64] JfrGetCallTrace: Need pc == nullptr check
 before frame constructor
In-Reply-To: <U3rHwkyuYs_sOYA23U4WwYyPJYLLj5F9OuWGTiqQIfI=.61f44411-215b-4ca0-9a26-4162fbc4d1cf@github.com>
References: <U3rHwkyuYs_sOYA23U4WwYyPJYLLj5F9OuWGTiqQIfI=.61f44411-215b-4ca0-9a26-4162fbc4d1cf@github.com>
Message-ID: <W_0mRTkbNokFALVM8eOqPggkeE_fxrpL-Peq1t0sL0g=.59b92fe6-9df7-40c4-afbb-d18e966c9d87@github.com>

On Tue, 25 Oct 2022 10:36:34 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> The check pc == nullptr is needed before the frame constructor.

JavaThread::pd_last_frame()  is now unused on the ppc64 platforms, is that correct ? Should there be some guarantee or assertion  in JavaThread::pd_last_frame()  before return frame(sp, pc);  too ?

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

PR: https://git.openjdk.org/jdk/pull/10846

From lucy at openjdk.org  Fri Oct 28 09:28:08 2022
From: lucy at openjdk.org (Lutz Schmidt)
Date: Fri, 28 Oct 2022 09:28:08 GMT
Subject: RFR: 8295872: [PPC64] JfrGetCallTrace: Need pc == nullptr check
 before frame constructor
In-Reply-To: <U3rHwkyuYs_sOYA23U4WwYyPJYLLj5F9OuWGTiqQIfI=.61f44411-215b-4ca0-9a26-4162fbc4d1cf@github.com>
References: <U3rHwkyuYs_sOYA23U4WwYyPJYLLj5F9OuWGTiqQIfI=.61f44411-215b-4ca0-9a26-4162fbc4d1cf@github.com>
Message-ID: <Tv21XT0Cx96FAYfH0qj6jNrNhss7kmCncOojxPcVsHI=.c927fc31-e230-4a59-a95b-e44e8d5bc971@github.com>

On Tue, 25 Oct 2022 10:36:34 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> The check pc == nullptr is needed before the frame constructor.

Changes look good.

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

Marked as reviewed by lucy (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10846

From mbaesken at openjdk.org  Fri Oct 28 12:42:26 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 28 Oct 2022 12:42:26 GMT
Subject: RFR: JDK-8295993 : use K instead of 1024 in a couple of hotspot
 outputs
Message-ID: <xxsobVLvFF5Q6onNdm3GNo9k9lJlB0qiD8R3zOvjHkM=.0e20f85e-fa04-4e78-a557-ef6a30f88bcb@github.com>

There are a couple of outputs of values in k  (e.g. in os_posix.cpp and os_windows.cpp) where the K constant could be used nicely instead of 1024 (this is done already at a number of places but not everywhere).

(This is NOT about replacing all 1024 in the codebase by K because I think this would not be a good idea.)

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

Commit messages:
 - JDK-8295993

Changes: https://git.openjdk.org/jdk/pull/10902/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10902&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295993
  Stats: 13 lines in 4 files changed: 0 ins; 1 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/10902.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10902/head:pull/10902

PR: https://git.openjdk.org/jdk/pull/10902

From lucy at openjdk.org  Fri Oct 28 13:47:27 2022
From: lucy at openjdk.org (Lutz Schmidt)
Date: Fri, 28 Oct 2022 13:47:27 GMT
Subject: RFR: JDK-8295993 : use K instead of 1024 in a couple of hotspot
 outputs
In-Reply-To: <xxsobVLvFF5Q6onNdm3GNo9k9lJlB0qiD8R3zOvjHkM=.0e20f85e-fa04-4e78-a557-ef6a30f88bcb@github.com>
References: <xxsobVLvFF5Q6onNdm3GNo9k9lJlB0qiD8R3zOvjHkM=.0e20f85e-fa04-4e78-a557-ef6a30f88bcb@github.com>
Message-ID: <d5h4h2EkZIdewufS6IsUxguX2XXmgajW-F-oZUU3rdI=.b4752ac6-b921-450f-a31f-3e0839e6bbee@github.com>

On Fri, 28 Oct 2022 12:32:40 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> There are a couple of outputs of values in k  (e.g. in os_posix.cpp and os_windows.cpp) where the K constant could be used nicely instead of 1024 (this is done already at a number of places but not everywhere).
> 
> (This is NOT about replacing all 1024 in the codebase by K because I think this would not be a good idea.)

LGTM. And it looks trivial.
I really prefer the use of a global symbol over writing the literal constant everywhere.

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

Marked as reviewed by lucy (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10902

From mdoerr at openjdk.org  Fri Oct 28 15:02:37 2022
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 28 Oct 2022 15:02:37 GMT
Subject: RFR: 8295872: [PPC64] JfrGetCallTrace: Need pc == nullptr check
 before frame constructor
In-Reply-To: <W_0mRTkbNokFALVM8eOqPggkeE_fxrpL-Peq1t0sL0g=.59b92fe6-9df7-40c4-afbb-d18e966c9d87@github.com>
References: <U3rHwkyuYs_sOYA23U4WwYyPJYLLj5F9OuWGTiqQIfI=.61f44411-215b-4ca0-9a26-4162fbc4d1cf@github.com>
 <W_0mRTkbNokFALVM8eOqPggkeE_fxrpL-Peq1t0sL0g=.59b92fe6-9df7-40c4-afbb-d18e966c9d87@github.com>
Message-ID: <deXcpad2poauukJWc7XKojsqFezhOBefFNMi0B2xOiU=.4a7c2c33-950a-4400-a470-e95881ba3b13@github.com>

On Fri, 28 Oct 2022 06:57:26 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> JavaThread::pd_last_frame() is now unused on the ppc64 platforms, is that correct ? Should there be some guarantee or assertion in JavaThread::pd_last_frame() before return frame(sp, pc); too ?

Good question. `pd_last_frame()` is now only called by `last_frame()` on PPC64. I'll think about if the acquire barrier is still needed there or if the addition from JDK-8290004 could get reverted. Note that `pc != nullptr` is already asserted in the frame constructor.

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

PR: https://git.openjdk.org/jdk/pull/10846

From mdoerr at openjdk.org  Fri Oct 28 15:02:37 2022
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 28 Oct 2022 15:02:37 GMT
Subject: RFR: 8295872: [PPC64] JfrGetCallTrace: Need pc == nullptr check
 before frame constructor
In-Reply-To: <U3rHwkyuYs_sOYA23U4WwYyPJYLLj5F9OuWGTiqQIfI=.61f44411-215b-4ca0-9a26-4162fbc4d1cf@github.com>
References: <U3rHwkyuYs_sOYA23U4WwYyPJYLLj5F9OuWGTiqQIfI=.61f44411-215b-4ca0-9a26-4162fbc4d1cf@github.com>
Message-ID: <qE7ijaCO-mrNoxlulwgZ9EgMX7VPQc7eFoBRXBuBYDo=.5054020e-5cc2-46df-8c37-65dc80077453@github.com>

On Tue, 25 Oct 2022 10:36:34 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> The check pc == nullptr is needed before the frame constructor.

Thanks for the reviews!

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

PR: https://git.openjdk.org/jdk/pull/10846

From kbarrett at openjdk.org  Sat Oct 29 12:19:21 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sat, 29 Oct 2022 12:19:21 GMT
Subject: RFR: 8295125: os::signal should be os specific
In-Reply-To: <DH7P6SqkigS2I09UR4i_7iQ2gmn28rmlTVPeuAWNQPs=.df77c4e1-2291-4633-b33a-6ab489905e09@github.com>
References: <DH7P6SqkigS2I09UR4i_7iQ2gmn28rmlTVPeuAWNQPs=.df77c4e1-2291-4633-b33a-6ab489905e09@github.com>
Message-ID: <TqVvoySORrQxrAo-jgaMMNZrFEuc_SoPYcnWGmFF0g4=.18832b5a-b580-47db-8d16-886ef1e3a78b@github.com>

On Thu, 20 Oct 2022 05:59:33 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This was intended as a significant cleanup RFE but it turned out things were a lot messier than initially envisaged, so the resultant cleanup is quite limited.
> 
> The OS API/namespace was simplified by removing three signal related functions that are not needed in shared code:
>  - signal
>  - user_handler
>  - raise
> The first two were reworked and placed into PosixSignals and os::win32.
> There was no need for a specific XX::raise API as os::raise simply called ::raise.
> 
> On the Posix side we had the basic signal handler installation code in two places:
> 
> 1. Inline in set_signal_handler and used by nearly all the VM signals
> 2. In os::signal which was used by three different "clients"
>   - VM error handler for updating crash handler
>   - VM for installing SIG_BREAK handler
>   - JDK via JVM_RegisterSignal
> 
> This was refactored so that we have:
> 
> 1. PosixSignals::install_sigaction_signal_handler
>   - used by the VM only
>     - set_signal_handler
>     - VM error handler for updating crash handler
>     - VM for installing SIG_BREAK handler
> 
> 2. PosixSignals::install_generic_signal_handler
>   - used by JDK via JVM_RegisterSignal
> 
> The sigaction handlers were all consistently defined as per the posix definition:
>     void func(int signo, siginfo_t *info, void *context);
>   
> 
> On the Windows side we just fixed the incorrect definition of UserHandler and made some consistency changes to use the right signal handler type where possible.
> 
> Thanks.

I'm loath to say "looks good", but looks okay for what it is.

Fixing JDK-8295702 will likely involve some refactoring of what's here. But
that's a problem for the next person who pokes at this tar baby.

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

Marked as reviewed by kbarrett (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10780

From dholmes at openjdk.org  Mon Oct 31 05:56:29 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 31 Oct 2022 05:56:29 GMT
Subject: RFR: 8295125: os::signal should be os specific
In-Reply-To: <TqVvoySORrQxrAo-jgaMMNZrFEuc_SoPYcnWGmFF0g4=.18832b5a-b580-47db-8d16-886ef1e3a78b@github.com>
References: <DH7P6SqkigS2I09UR4i_7iQ2gmn28rmlTVPeuAWNQPs=.df77c4e1-2291-4633-b33a-6ab489905e09@github.com>
 <TqVvoySORrQxrAo-jgaMMNZrFEuc_SoPYcnWGmFF0g4=.18832b5a-b580-47db-8d16-886ef1e3a78b@github.com>
Message-ID: <1KdITeim0E15cQ_b1A969u8QXukEa9v2kfcnddOYJ70=.36e2c28b-fce8-413a-be3c-3bd80f450ea3@github.com>

On Sat, 29 Oct 2022 12:16:58 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> This was intended as a significant cleanup RFE but it turned out things were a lot messier than initially envisaged, so the resultant cleanup is quite limited.
>> 
>> The OS API/namespace was simplified by removing three signal related functions that are not needed in shared code:
>>  - signal
>>  - user_handler
>>  - raise
>> The first two were reworked and placed into PosixSignals and os::win32.
>> There was no need for a specific XX::raise API as os::raise simply called ::raise.
>> 
>> On the Posix side we had the basic signal handler installation code in two places:
>> 
>> 1. Inline in set_signal_handler and used by nearly all the VM signals
>> 2. In os::signal which was used by three different "clients"
>>   - VM error handler for updating crash handler
>>   - VM for installing SIG_BREAK handler
>>   - JDK via JVM_RegisterSignal
>> 
>> This was refactored so that we have:
>> 
>> 1. PosixSignals::install_sigaction_signal_handler
>>   - used by the VM only
>>     - set_signal_handler
>>     - VM error handler for updating crash handler
>>     - VM for installing SIG_BREAK handler
>> 
>> 2. PosixSignals::install_generic_signal_handler
>>   - used by JDK via JVM_RegisterSignal
>> 
>> The sigaction handlers were all consistently defined as per the posix definition:
>>     void func(int signo, siginfo_t *info, void *context);
>>   
>> 
>> On the Windows side we just fixed the incorrect definition of UserHandler and made some consistency changes to use the right signal handler type where possible.
>> 
>> Thanks.
>
> I'm loath to say "looks good", but looks okay for what it is.
> 
> Fixing JDK-8295702 will likely involve some refactoring of what's here. But
> that's a problem for the next person who pokes at this tar baby.

Thanks @kimbarrett !

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

PR: https://git.openjdk.org/jdk/pull/10780

From dholmes at openjdk.org  Mon Oct 31 06:00:16 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 31 Oct 2022 06:00:16 GMT
Subject: Integrated: 8295125: os::signal should be os specific
In-Reply-To: <DH7P6SqkigS2I09UR4i_7iQ2gmn28rmlTVPeuAWNQPs=.df77c4e1-2291-4633-b33a-6ab489905e09@github.com>
References: <DH7P6SqkigS2I09UR4i_7iQ2gmn28rmlTVPeuAWNQPs=.df77c4e1-2291-4633-b33a-6ab489905e09@github.com>
Message-ID: <k9savmj_UaFcvp0SBjHBTBASqRyl5IwfvElcoJG0v9g=.096e45aa-0b67-4962-b5cb-a2d73843733b@github.com>

On Thu, 20 Oct 2022 05:59:33 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This was intended as a significant cleanup RFE but it turned out things were a lot messier than initially envisaged, so the resultant cleanup is quite limited.
> 
> The OS API/namespace was simplified by removing three signal related functions that are not needed in shared code:
>  - signal
>  - user_handler
>  - raise
> The first two were reworked and placed into PosixSignals and os::win32.
> There was no need for a specific XX::raise API as os::raise simply called ::raise.
> 
> On the Posix side we had the basic signal handler installation code in two places:
> 
> 1. Inline in set_signal_handler and used by nearly all the VM signals
> 2. In os::signal which was used by three different "clients"
>   - VM error handler for updating crash handler
>   - VM for installing SIG_BREAK handler
>   - JDK via JVM_RegisterSignal
> 
> This was refactored so that we have:
> 
> 1. PosixSignals::install_sigaction_signal_handler
>   - used by the VM only
>     - set_signal_handler
>     - VM error handler for updating crash handler
>     - VM for installing SIG_BREAK handler
> 
> 2. PosixSignals::install_generic_signal_handler
>   - used by JDK via JVM_RegisterSignal
> 
> The sigaction handlers were all consistently defined as per the posix definition:
>     void func(int signo, siginfo_t *info, void *context);
>   
> 
> On the Windows side we just fixed the incorrect definition of UserHandler and made some consistency changes to use the right signal handler type where possible.
> 
> Thanks.

This pull request has now been integrated.

Changeset: 9b9be88b
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9b9be88bcaa35c89b6915ff0c251e5a04b10b330
Stats:     165 lines in 9 files changed: 81 ins; 33 del; 51 mod

8295125: os::signal should be os specific

Reviewed-by: jsjolen, kbarrett

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

PR: https://git.openjdk.org/jdk/pull/10780

From dholmes at openjdk.org  Mon Oct 31 06:45:56 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 31 Oct 2022 06:45:56 GMT
Subject: RFR: JDK-8295993 : use K instead of 1024 in a couple of hotspot
 outputs
In-Reply-To: <xxsobVLvFF5Q6onNdm3GNo9k9lJlB0qiD8R3zOvjHkM=.0e20f85e-fa04-4e78-a557-ef6a30f88bcb@github.com>
References: <xxsobVLvFF5Q6onNdm3GNo9k9lJlB0qiD8R3zOvjHkM=.0e20f85e-fa04-4e78-a557-ef6a30f88bcb@github.com>
Message-ID: <YG-2Kz6f9BTs4B8gNKA5s3UQu5WxrX83BH40NpGWtOo=.bd6a4d8c-20a4-4252-bf32-12995b4fb4ec@github.com>

On Fri, 28 Oct 2022 12:32:40 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> There are a couple of outputs of values in k  (e.g. in os_posix.cpp and os_windows.cpp) where the K constant could be used nicely instead of 1024 (this is done already at a number of places but not everywhere).
> 
> (This is NOT about replacing all 1024 in the codebase by K because I think this would not be a good idea.)

Seems quite reasonable. The size_t type doesn't seem to cause any issues in those expressions.

Thanks.

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10902

From mbaesken at openjdk.org  Mon Oct 31 09:13:08 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 31 Oct 2022 09:13:08 GMT
Subject: Integrated: JDK-8295993 : use K instead of 1024 in a couple of hotspot
 outputs
In-Reply-To: <xxsobVLvFF5Q6onNdm3GNo9k9lJlB0qiD8R3zOvjHkM=.0e20f85e-fa04-4e78-a557-ef6a30f88bcb@github.com>
References: <xxsobVLvFF5Q6onNdm3GNo9k9lJlB0qiD8R3zOvjHkM=.0e20f85e-fa04-4e78-a557-ef6a30f88bcb@github.com>
Message-ID: <7duoaLq-hqYsfmsVJ0XS6QWNnX_xNTEXHMJOCIGBWeA=.e36031bf-35d9-4498-847e-bd04890a39f5@github.com>

On Fri, 28 Oct 2022 12:32:40 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> There are a couple of outputs of values in k  (e.g. in os_posix.cpp and os_windows.cpp) where the K constant could be used nicely instead of 1024 (this is done already at a number of places but not everywhere).
> 
> (This is NOT about replacing all 1024 in the codebase by K because I think this would not be a good idea.)

This pull request has now been integrated.

Changeset: 274ea1db
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/274ea1db5b248968c1ff1c5c24d75f07fb8a0600
Stats:     13 lines in 4 files changed: 0 ins; 1 del; 12 mod

8295993: use K instead of 1024 in a couple of hotspot outputs

Reviewed-by: lucy, dholmes

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

PR: https://git.openjdk.org/jdk/pull/10902

From dholmes at openjdk.org  Mon Oct 31 09:44:23 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 31 Oct 2022 09:44:23 GMT
Subject: RFR: JDK-8295865: Several issues with os::realloc
In-Reply-To: <tyUwv4vp-gfhzLNjZRuVM7aHJ_sXVvgeaRPoKsgxIag=.47ea1c16-2b54-484e-bca6-cae1fcd0fad7@github.com>
References: <tyUwv4vp-gfhzLNjZRuVM7aHJ_sXVvgeaRPoKsgxIag=.47ea1c16-2b54-484e-bca6-cae1fcd0fad7@github.com>
Message-ID: <1iTKcBebLinvm1eMM9OJ7Oy50unG_EtbwOyTxtcvqdA=.4de47a78-41be-4bae-8efe-b3b344707cd6@github.com>

On Tue, 25 Oct 2022 16:27:37 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> There are several issues with os::realloc():
> 
> 1) If realloc(3) fails, the original block will be left untouched. That is fine, and the caller may expect this and continue to use the old block, including handing it to os::free() later. But NMT has marked the original block as dead already, and subsequent os::free() or os::realloc() will trigger a false fatal block integrity error. Therefore, if realloc(3) fails, we need to revive the NMT header and re-account the original block before returning.
> 
> 2) If handed in very large sizes, the size may overflow if the NMT header is added. The result would be that the VM reallocates to a much smaller buffer which would cause subsequent memory corruption if the caller were to use the buffer (same as JDK-8286519, but for realloc).
> 
> 3) If os::realloc() enlarges a buffer, the newly added memory should be zapped with uinitBlockPad as we do for os::malloc(). Of course we only can do this if NMT is enabled, otherwise we won't know the original block size.
> 
> ------------------------------
> 
> The patch fixes all three issues and adds hopefully thorough enough regression gtests for them. Remember that these gtests will run, as part of the jtreg gtest runners, in all NMT modes.
> 
> The largest diff hunk is inside os::realloc(). Note that I separated the two cases NMT=summary/detail and NMT=off, since it makes the coding easier to understand and we also run less code in the standard case of NMT==off.

This all appears to be quite reasonable.

I have a couple of queries.

Thanks.

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

> 730:       // NMT header then, since we marked it dead already. Otherwise subsequent os::realloc()
> 731:       // or os::free() calls would trigger block integrity asserts.
> 732:       void* p = MemTracker::record_malloc(old_outer_ptr, old_size, memflags, stack);

I'm not familiar with NMT details - are `memflags` and `stack` guaranteed to be the same as the original allocation?

test/hotspot/gtest/testutils.hpp line 57:

> 55: #define ASSERT_NULL(p)      ASSERT_EQ(p2i(p), 0)
> 56: #define EXPECT_NOT_NULL(p)  EXPECT_NE(p2i(p), 0)
> 57: #define EXPECT_NULL(p)      EXPECT_EQ(p2i(p), 0)

These aren't "convenience asserts" - should they be somewhere else? What does EXPECT_NULL actually do?

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

PR: https://git.openjdk.org/jdk/pull/10857

From mdoerr at openjdk.org  Mon Oct 31 11:53:38 2022
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 31 Oct 2022 11:53:38 GMT
Subject: RFR: 8295872: [PPC64] JfrGetCallTrace: Need pc == nullptr check
 before frame constructor [v2]
In-Reply-To: <U3rHwkyuYs_sOYA23U4WwYyPJYLLj5F9OuWGTiqQIfI=.61f44411-215b-4ca0-9a26-4162fbc4d1cf@github.com>
References: <U3rHwkyuYs_sOYA23U4WwYyPJYLLj5F9OuWGTiqQIfI=.61f44411-215b-4ca0-9a26-4162fbc4d1cf@github.com>
Message-ID: <51mbc53VhlzXAI3aouEsHuoQTYqdbys6nhrAa9x31h8=.e03d0750-953d-4135-9bd3-36d203a398eb@github.com>

> The check pc == nullptr is needed before the frame constructor.

Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:

  Remove acquire barrier again. The null check is the clean fix.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10846/files
  - new: https://git.openjdk.org/jdk/pull/10846/files/fe0bfd32..53f5fc06

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10846&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10846&range=00-01

  Stats: 10 lines in 2 files changed: 4 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/10846.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10846/head:pull/10846

PR: https://git.openjdk.org/jdk/pull/10846

From mdoerr at openjdk.org  Mon Oct 31 12:01:24 2022
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 31 Oct 2022 12:01:24 GMT
Subject: RFR: 8295872: [PPC64] JfrGetCallTrace: Need pc == nullptr check
 before frame constructor [v2]
In-Reply-To: <51mbc53VhlzXAI3aouEsHuoQTYqdbys6nhrAa9x31h8=.e03d0750-953d-4135-9bd3-36d203a398eb@github.com>
References: <U3rHwkyuYs_sOYA23U4WwYyPJYLLj5F9OuWGTiqQIfI=.61f44411-215b-4ca0-9a26-4162fbc4d1cf@github.com>
 <51mbc53VhlzXAI3aouEsHuoQTYqdbys6nhrAa9x31h8=.e03d0750-953d-4135-9bd3-36d203a398eb@github.com>
Message-ID: <7fau1vI-JpvPByWdZfUaMI7YmpZ2ZqF_c3hmFHzzcl8=.c8bb2436-66ee-42b9-9562-a62df7948070@github.com>

On Mon, 31 Oct 2022 11:53:38 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> The check pc == nullptr is needed before the frame constructor.
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove acquire barrier again. The null check is the clean fix.

I've spent more time for understanding the memory ordering aspect and I've come to the conclusion, that the acquire barrier from [JDK-8290004](https://bugs.openjdk.org/browse/JDK-8290004) is not really needed. The fields are never read while concurrently modified. They are only read by the current thread or when the thread is suspended (or stopped by a signal).
So, the pc == null check before the frame constructor is a sufficient fix for the profiling usages. An unnecessary acquire barrier may be confusing and I think a comment is helpful.
Please take a 2nd look. Thanks!

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

PR: https://git.openjdk.org/jdk/pull/10846

From xxinliu at amazon.com  Mon Oct 31 17:02:19 2022
From: xxinliu at amazon.com (Liu, Xin)
Date: Mon, 31 Oct 2022 10:02:19 -0700
Subject: BitMap vs VectorSet?
In-Reply-To: <85CC51C0-02E2-44A6-9116-F08530546057@oracle.com>
References: <99f36403-8ac4-7fc0-656d-22305cb1fc40@amazon.com>
 <85CC51C0-02E2-44A6-9116-F08530546057@oracle.com>
Message-ID: <834b6a72-1459-a00e-3fc3-19f3432d4ea5@amazon.com>

hi, John,

Thank you for your pointer. It makes a lot of sense.  I also prefer
BitMap rather than VectorSet. I check who is including 'vectset.hpp'.
They are all from C2 compiler except 'share/ci/bcEscapeAnalyzer.hpp'.

I manage to change VectorSet to BitMap in Unique_Node_List. It's not
drop-in substitution. The interfaces are different. VectorSet is
elastic. eg. VectorSet::test returns false when index is out of range.
It can automatically grow to the specified index in VectorSet::test_set.
 Storage-wise, VectorSet supports both Resource and Arena but
ResourceBitMap and ArenaBitMap are two independent classes in bitMap.hpp.

I will file a JBS to fill the gap first.

Here is what I have done. It doesn't create any trouble after
substitution. of course, we are going to test it thoroughly.

https://github.com/openjdk/jdk/compare/master...navyxliu:jdk:refactor_bitmap

thanks,
--lx


On 10/27/22 11:07 AM, John Rose wrote:
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
> 
> 
> 
> This is a good question, and a reasonable time to engage with it as well.
> 
> The code in src/hotspot/share/libadt is very old (~30 years) and has not been vigorously maintained, relative to changes in C++ practice.
> 
> BitMap is newer and its code is more modern and actively maintained.  (Thanks Kim B. et al.)  In my opinion, it deserves to be used instead of VectorSet.  Having two classes for the same set of tasks is technical debt.  It is the sort of thing that naturally happens on a large project when two groups settle on different solutions for a common problem.  And the sort of thing a large project has to clean up over time.
> 
> So, I support taking steps (reasonable, gradual, limited-impact steps) to retire the classes in libadt, replacing them with more modern ones, in src/hotspot/share/utilities.
> 
> As you note, Xin, this is somewhat more urgent as we increase our gtest coverage, since we don?t want to develop two sets of new tests for the same application area.
> 
> It?s also more urgent as hardware technology advances:  If we choose to work harder to vectorize bitset operations, we don?t want to do that work twice.
> 
> It?s also more urgent as software technology advances.  I?m reminded that there are many new algorithms for bit-twiddling (the name Daniel Lemire comes to mind, for one) and (again: get the pattern?) we don?t want to upgrade the algorithms twice.
> 
> People working on HotSpot routinely deal with extremely challenging software problems, specific to optimization, garbage collection, concurrency, platform support, performance, and more.  It?s hard to always, also, select well-tested, well-designed shared libraries to help with these problems; sometimes you just have to roll your own.  But while understandable, that tends to create technical debt.  That sometimes leads to failures (unscheduled payments on technical debt) due to lack of test coverage, simply because some work somewhere didn?t use common code but ?rolled their own? algorithms.
> 
> So, yes, let?s double down on BitSet and retire VectorSet.
> 
> (And Dict, while we are at it: There are some really nice hash table classes developed recently by the runtime group; surely we are not too far from merging the job of Dict into that group of classes?)
> 
> ? John
> 
> On 27 Oct 2022, at 0:07, Liu, Xin wrote:
> 
>> hi,
>>
>> Recently, I extended VectorSet(libadt/vectset.hpp) to support
>> intersection. Then I found that there is yet another "vector set" called
>> 'BitMap'. From my reading, the data structure of BitMap is same as
>> VectorSet. BitMap has already supported intersection/union/difference
>> and it even owns corresponding gtests.
>>
>> Given that, why does HotSpot still need to maintain both VectorSet and
>> BitMap? I grep VectorSet and there are still many references. Is that
>> too troublesome to replace VectorSet with BitMap or there are other
>> reasons?
>>
>> I modified VectorSet because Unique_Node_List(node.hpp) uses it. I
>> hesitate now. Should I invest a new gtest for the new code or I just use
>> BitMap instead?
>>
>> thanks,
>> --lx
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0xB9D934C61E047B0D.asc
Type: application/pgp-keys
Size: 3675 bytes
Desc: OpenPGP public key
URL: <https://mail.openjdk.org/pipermail/hotspot-runtime-dev/attachments/20221031/edd2f877/OpenPGP_0xB9D934C61E047B0D-0001.asc>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/hotspot-runtime-dev/attachments/20221031/edd2f877/OpenPGP_signature-0001.sig>

From omikhaltcova at openjdk.org  Mon Oct 31 17:53:59 2022
From: omikhaltcova at openjdk.org (Olga Mikhaltsova)
Date: Mon, 31 Oct 2022 17:53:59 GMT
Subject: RFR: 8296125: Add a command line option to set a refresh rate of the
 OS cached metrics in Linux
Message-ID: <vwko7xQPdH2v2RI8i-s0OiMao1_BwWFVwbDUwXvfFso=.b1bbb3c5-2f9a-42e9-b2d0-cb3c09ab8294@github.com>

I would like to add a new command line product option:
-XX:OsCachedMetricsRefreshRate=value, -
where a value is times per second and is in the range [1; 1000000000].

It substitutes the hardcoded timeout of 20 ms between re-readings of the OS cached metrics introduced in [JDK-8232207](https://bugs.openjdk.org/browse/JDK-8232207) and allows to set this timeout (as a refresh rate) by a user at the launch time.

This option will be available only on Linux.

It can be used as followed:
java -XX:OsCachedMetricsRefreshRate=100 MyApp

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

Commit messages:
 - 8296125: Add a command line option to set a refresh rate of the OS cached metrics in Linux

Changes: https://git.openjdk.org/jdk/pull/10918/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10918&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8296125
  Stats: 18 lines in 5 files changed: 12 ins; 3 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/10918.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10918/head:pull/10918

PR: https://git.openjdk.org/jdk/pull/10918

From dlong at openjdk.org  Mon Oct 31 18:40:08 2022
From: dlong at openjdk.org (Dean Long)
Date: Mon, 31 Oct 2022 18:40:08 GMT
Subject: RFR: 8296007: crash in runtime/DefineClass/NullClassBytesTest.java
In-Reply-To: <0kHvtRJawBMOY0qjuqXqZ2VanYDACHcbn_yi-e6jNpk=.0e6da858-d19f-49a8-828e-4243cd02f372@github.com>
References: <0kHvtRJawBMOY0qjuqXqZ2VanYDACHcbn_yi-e6jNpk=.0e6da858-d19f-49a8-828e-4243cd02f372@github.com>
Message-ID: <Re9AuVGfjitouUBc6B4_0oniMD5nIwCxIpCaFWWyPJA=.1e8289cb-1efa-4467-bd20-6b42363bdad3@github.com>

On Thu, 27 Oct 2022 21:00:17 GMT, Dean Long <dlong at openjdk.org> wrote:

> This is a simple fix to Java_NullClassBytesTest_nativeDefineClass so that it returns the jclass as expected.

Do you I need a 2nd review for this change?

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

PR: https://git.openjdk.org/jdk/pull/10892

From omikhaltcova at openjdk.org  Mon Oct 31 21:09:27 2022
From: omikhaltcova at openjdk.org (Olga Mikhaltsova)
Date: Mon, 31 Oct 2022 21:09:27 GMT
Subject: RFR: 8296125: Add a command line option to set a refresh rate of
 the OS cached metrics in Linux
In-Reply-To: <vwko7xQPdH2v2RI8i-s0OiMao1_BwWFVwbDUwXvfFso=.b1bbb3c5-2f9a-42e9-b2d0-cb3c09ab8294@github.com>
References: <vwko7xQPdH2v2RI8i-s0OiMao1_BwWFVwbDUwXvfFso=.b1bbb3c5-2f9a-42e9-b2d0-cb3c09ab8294@github.com>
Message-ID: <dccfEYg4c34tnhtOVUTN4-3R7548OJ524LEPPk20ZNY=.249e252a-1046-4f43-a68d-74211e6f5670@github.com>

On Mon, 31 Oct 2022 13:27:13 GMT, Olga Mikhaltsova <omikhaltcova at openjdk.org> wrote:

> I would like to add a new command line product option:
> -XX:OsCachedMetricsRefreshRate=value, -
> where a value is times per second and is in the range [1; 1000000000].
> 
> It substitutes the hardcoded timeout of 20 ms between re-readings of the OS cached metrics introduced in [JDK-8232207](https://bugs.openjdk.org/browse/JDK-8232207) and allows to set this timeout (as a refresh rate) by a user at the launch time.
> 
> This option will be available only on Linux.
> 
> It can be used as followed:
> java -XX:OsCachedMetricsRefreshRate=100 MyApp

TestVerifyGraphEdges.java fails on linux-x86 due to the previous code changes.
The reason of failure is described in [JDK-8295936](https://bugs.openjdk.org/browse/JDK-8295936), [JDK-8295867](https://bugs.openjdk.org/browse/JDK-8295867).

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

PR: https://git.openjdk.org/jdk/pull/10918

From iklam at openjdk.org  Mon Oct 31 23:02:30 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 31 Oct 2022 23:02:30 GMT
Subject: RFR: 8296155: Simplify CDS heap region address calculation
Message-ID: <y2P_Q9wCDxkprV1leFGi8YoIlseM-2quq0r-cEFABh0=.a583ee78-ac5c-4d2f-aa47-3b2b59f1e52d@github.com>

Rewrite and simplify the convoluted logic used to calculate the runtime location of a CDS heap region. Now it's as simple as:


FileMapRegion::dumptime_base() + ArchiveHeapLoader::runtime_delta();


See `FileMapInfo::heap_region_runtime_start_address` for an example.

Also removed dead code:

- `FileMapInfo::is_in_shared_region`
- `MetaspaceShared::is_in_shared_region`
- `FileMapInfo::stop_sharing_and_unmap`

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

Commit messages:
 - 8296155: Simplify CDS heap region address calculation

Changes: https://git.openjdk.org/jdk/pull/10923/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10923&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8296155
  Stats: 134 lines in 7 files changed: 20 ins; 97 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/10923.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10923/head:pull/10923

PR: https://git.openjdk.org/jdk/pull/10923