From kbarrett at openjdk.org Tue Oct 1 01:23:57 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 1 Oct 2024 01:23:57 GMT
Subject: RFR: 8337389: Parallel: Remove unnecessary forward declarations in
psScavenge.hpp
In-Reply-To: <6pGuQAwh4aO2dyQcgugU0uz9ys8hulq1lyAckrKRDK0=.2f124adb-05d5-4a81-97ed-971a7d8b3a6b@github.com>
References: <6pGuQAwh4aO2dyQcgugU0uz9ys8hulq1lyAckrKRDK0=.2f124adb-05d5-4a81-97ed-971a7d8b3a6b@github.com>
Message-ID: <MWMP237r3fEko0jt0ErO3uM5N7gws3RVZ-UmrYLUmnU=.ec091dce-15a7-4dea-b281-3a360e4bb160@github.com>
On Tue, 30 Jul 2024 18:14:36 GMT, joejackson1993 <duke at openjdk.org> wrote:
> trivial cleanup
Looks good, and trivial.
-------------
Marked as reviewed by kbarrett (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/20393#pullrequestreview-2338952343
From tschatzl at openjdk.org Tue Oct 1 07:32:38 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 1 Oct 2024 07:32:38 GMT
Subject: RFR: 8337389: Parallel: Remove unnecessary forward declarations in
psScavenge.hpp
In-Reply-To: <6pGuQAwh4aO2dyQcgugU0uz9ys8hulq1lyAckrKRDK0=.2f124adb-05d5-4a81-97ed-971a7d8b3a6b@github.com>
References: <6pGuQAwh4aO2dyQcgugU0uz9ys8hulq1lyAckrKRDK0=.2f124adb-05d5-4a81-97ed-971a7d8b3a6b@github.com>
Message-ID: <Kdhf_YYUULPJyUzKa-Jy0i2ISKveMc0rbyndmQHlCKY=.15f0a892-9075-4880-a540-0f039e1290a8@github.com>
On Tue, 30 Jul 2024 18:14:36 GMT, joejackson1993 <duke at openjdk.org> wrote:
> trivial cleanup
trivial
-------------
Marked as reviewed by tschatzl (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/20393#pullrequestreview-2339339563
From rcastanedalo at openjdk.org Tue Oct 1 11:24:52 2024
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Tue, 1 Oct 2024 11:24:52 GMT
Subject: RFR: 8334060: Implementation of Late Barrier Expansion for G1
[v27]
In-Reply-To: <vChwINsCng-QfOUe_LpgAimWHG0xWx0Fcx-HsGssGrg=.fbdffb81-171e-4098-9289-8b2e6a2ac5ec@github.com>
References: <ClHEkY_xzx37VNyLJr9F9eWSjXfdCRQcbmAhomsY7kU=.f4c3c125-caed-467f-b9fa-213d14f7908a@github.com>
<YYVkTHSwqRigZMpp3wjVjULgwfhawfXCszR2iKEPazA=.a7b37dee-07cd-45e9-aeed-0f90cba1268a@github.com>
<vChwINsCng-QfOUe_LpgAimWHG0xWx0Fcx-HsGssGrg=.fbdffb81-171e-4098-9289-8b2e6a2ac5ec@github.com>
Message-ID: <czNh2deqytw1bmBVIC_6NpHrKcfW71VjcnDQTxTNphM=.daf26e36-e210-4162-93c8-59e0d1983a59@github.com>
On Mon, 30 Sep 2024 16:56:30 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:
> Good.
Thanks, Vladimir!
-------------
PR Comment: https://git.openjdk.org/jdk/pull/19746#issuecomment-2385515540
From shade at openjdk.org Tue Oct 1 13:32:41 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 1 Oct 2024 13:32:41 GMT
Subject: Integrated: 8341242: Shenandoah: LRB node is not matched as GC barrier
after JDK-8340183
In-Reply-To: <QIPZMJIfweyc5taFSjRc3R1zPjHd6_xAvtyli0jW1iU=.c8dbf4eb-ca88-4f46-8703-55358599ab3c@github.com>
References: <QIPZMJIfweyc5taFSjRc3R1zPjHd6_xAvtyli0jW1iU=.c8dbf4eb-ca88-4f46-8703-55358599ab3c@github.com>
Message-ID: <joqwH3wTgPB43c-6ECcmtMaS_PUZgZlhIScOO36myB8=.174756ea-8b36-467e-859a-359304cc1fbc@github.com>
On Mon, 30 Sep 2024 14:54:30 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:
> [JDK-8340183](https://bugs.openjdk.org/browse/JDK-8340183) introduced a regression: `ShenandoahBarrierSetC2::is_gc_barrier_node` is now answering `false` for the actual `ShenandoahLoadReferenceBarrierNode`. The fix reinstates the check for LRB node.
>
> Additional testing:
> - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`
> - [x] Linux x86_64 server fastdebug, `jdk/jfr/api/consumer/ ` (100x) -- used to fail intermittently, now it does not
This pull request has now been integrated.
Changeset: 684d246c
Author: Aleksey Shipilev <shade at openjdk.org>
URL: https://git.openjdk.org/jdk/commit/684d246ccf497f599ffcd498f2fbe4b1b2357e27
Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
8341242: Shenandoah: LRB node is not matched as GC barrier after JDK-8340183
Reviewed-by: rkennke, phh
-------------
PR: https://git.openjdk.org/jdk/pull/21266
From duke at openjdk.org Tue Oct 1 14:05:43 2024
From: duke at openjdk.org (joejackson1993)
Date: Tue, 1 Oct 2024 14:05:43 GMT
Subject: Integrated: 8337389: Parallel: Remove unnecessary forward declarations
in psScavenge.hpp
In-Reply-To: <6pGuQAwh4aO2dyQcgugU0uz9ys8hulq1lyAckrKRDK0=.2f124adb-05d5-4a81-97ed-971a7d8b3a6b@github.com>
References: <6pGuQAwh4aO2dyQcgugU0uz9ys8hulq1lyAckrKRDK0=.2f124adb-05d5-4a81-97ed-971a7d8b3a6b@github.com>
Message-ID: <S-KNCiElSjeXP8xM7ubGB-SCcwSsw1P1zt9swNa4Ess=.6738c47f-68d0-46ad-a89f-9623792fb522@github.com>
On Tue, 30 Jul 2024 18:14:36 GMT, joejackson1993 <duke at openjdk.org> wrote:
> trivial cleanup
This pull request has now been integrated.
Changeset: 7b1e6f8e
Author: joseph.jackson <joseph.jackson at servicenow.com>
Committer: Zhengyu Gu <zgu at openjdk.org>
URL: https://git.openjdk.org/jdk/commit/7b1e6f8ed9dbc07158717a32d341393afaa54b66
Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
8337389: Parallel: Remove unnecessary forward declarations in psScavenge.hpp
Reviewed-by: kbarrett, tschatzl
-------------
PR: https://git.openjdk.org/jdk/pull/20393
From tschatzl at openjdk.org Tue Oct 1 14:57:36 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 1 Oct 2024 14:57:36 GMT
Subject: RFR: 8339668: Parallel: Adopt PartialArrayState to consolidate
marking stack in compact GC
In-Reply-To: <SpLKo44sGBtJ8p0qZGh6NCl2ABe0ezh8l645vr6R3xM=.6615b830-f3aa-4c25-a0b4-1ab94a66b3d9@github.com>
References: <SpLKo44sGBtJ8p0qZGh6NCl2ABe0ezh8l645vr6R3xM=.6615b830-f3aa-4c25-a0b4-1ab94a66b3d9@github.com>
Message-ID: <S9zZqt6yRZp1ELyjf9LfhU4CLWHiqafojYBJkiChliQ=.6cac8d1f-9168-40ed-bffa-ed54f52ae5f3@github.com>
On Thu, 19 Sep 2024 14:01:39 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:
> Please review this patch that adopts `PartialArrayState`introduced by [JDK-8337709](https://bugs.openjdk.org/browse/JDK-8337709) to consolidate `_oop_task_queues` and `_objarray_task_queues` into single `_marking_stacks`.
>
> The change mirrors Kim's [JDK-8311163](https://bugs.openjdk.org/browse/JDK-8311163) work, therefore, there are methods can be consolidated and simplified, but I would like defer to a followup CR.
Changes requested by tschatzl (Reviewer).
src/hotspot/share/gc/parallel/psCompactionManager.cpp line 33:
> 31: #include "gc/parallel/psParallelCompact.inline.hpp"
> 32: #include "gc/shared/partialArrayState.hpp"
> 33:
Suggestion:
Unnecessary newline.
src/hotspot/share/gc/parallel/psCompactionManager.hpp line 90:
> 88: bool is_partial_array_state() const { return ((uintptr_t)_holder & PartialArrayStateBit) != 0; }
> 89: };
> 90:
Please use `ScannerTask` instead; it seems to be completely serviceable for that purpose. In fact, a search&replace seems just fine.
https://github.com/openjdk/jdk/compare/pr/21089...tschatzl:jdk:pull/21089-recommendations?expand=1
I am going to experiment with refactoring the other duplicated (statistics) code
src/hotspot/share/gc/parallel/psCompactionManager.hpp line 122:
> 120: size_t _arrays_chunked;
> 121: size_t _array_chunks_processed;
> 122: #endif // TASKQUEUE_STATS
This is a separate issue, but we did not add these counters when doing this change for g1 young gen. Filed [JDK-8341331](https://bugs.openjdk.org/browse/JDK-8341331) for that.
There is a fair amount of code duplication (definition of members, management and printing) which is not great (but you mentioned it). For now I filed [JDK-8341332](https://bugs.openjdk.org/browse/JDK-8341332) for this, but I would really prefer some refactoring in this area in _this_ change.
Initially I was kind of okay to do that separately, but the copy&paste seems too much.
-------------
PR Review: https://git.openjdk.org/jdk/pull/21089#pullrequestreview-2339670822
PR Review Comment: https://git.openjdk.org/jdk/pull/21089#discussion_r1782454836
PR Review Comment: https://git.openjdk.org/jdk/pull/21089#discussion_r1782794766
PR Review Comment: https://git.openjdk.org/jdk/pull/21089#discussion_r1782710439
From rkennke at openjdk.org Tue Oct 1 15:48:54 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 1 Oct 2024 15:48:54 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v11]
In-Reply-To: <TBZCkcFNNnEvat7TBnRkqUPo4Y5TEe1L0iUZ9loD7DI=.39c0249c-f6b2-45c8-b7c8-9e2c9c1b7a99@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<DUgk6HT_Zk5KnbmAd_HzrJi4B8D1J-uuoAGzReWyI8s=.6c04f90a-bf1d-49af-a31d-5224973952d4@github.com>
<YTte6oY9EeAPHxzzOndL8M202wY91SbeaYC4hPva0W0=.caf00270-89c7-44b0-ab88-a970fb8e840d@github.com>
<kzodWwxj5qdAqPYcP2s4k2QTXqjju2H6Iftu7dojezk=.1f72fc31-94ba-4017-b330-c8688a8d39a4@github.com>
<hkGaBWSugvpV0PgoR9rnutHCgQzkeXv1ctH7QwV3zK0=.204737d5-fadb-410a-8891-7db59d36830f@github.com>
<shoDPnL4nQyaYX4xy-WyzQ7CwsoCbAeCE3c755CkE1o=.caf940aa-5fbb-4cb5-a4a2-68a2452ffe1b@github.com>
<TBZCkcFNNnEvat7TBnRkqUPo4Y5TEe1L0iUZ9loD7DI=.39c0249c-f6b2-45c8-b7c8-9e2c9c1b7a99@github.com>
Message-ID: <toUdNzwkdDAQDltc4_t6wI06bCE-EHzpIs_t-arIwNY=.7d9ef348-0033-4268-9ed1-7c183855521f@github.com>
On Mon, 30 Sep 2024 12:38:03 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:
> test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationNotRun.java:
I think I would disable the tests for now. Is there a good way to say 'run this when UCOH is off OR UseSSE>3?
-------------
PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2386370790
From kbarrett at openjdk.org Tue Oct 1 16:42:35 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 1 Oct 2024 16:42:35 GMT
Subject: RFR: 8339668: Parallel: Adopt PartialArrayState to consolidate
marking stack in compact GC
In-Reply-To: <S9zZqt6yRZp1ELyjf9LfhU4CLWHiqafojYBJkiChliQ=.6cac8d1f-9168-40ed-bffa-ed54f52ae5f3@github.com>
References: <SpLKo44sGBtJ8p0qZGh6NCl2ABe0ezh8l645vr6R3xM=.6615b830-f3aa-4c25-a0b4-1ab94a66b3d9@github.com>
<S9zZqt6yRZp1ELyjf9LfhU4CLWHiqafojYBJkiChliQ=.6cac8d1f-9168-40ed-bffa-ed54f52ae5f3@github.com>
Message-ID: <a378hYVJW-YoibWk9eeGPjdXw_ckAYOnKTJYJkA14fk=.6159375a-cb70-4204-8bc0-a849e091f9a3@github.com>
On Tue, 1 Oct 2024 13:22:52 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:
>> Please review this patch that adopts `PartialArrayState`introduced by [JDK-8337709](https://bugs.openjdk.org/browse/JDK-8337709) to consolidate `_oop_task_queues` and `_objarray_task_queues` into single `_marking_stacks`.
>>
>> The change mirrors Kim's [JDK-8311163](https://bugs.openjdk.org/browse/JDK-8311163) work, therefore, there are methods can be consolidated and simplified, but I would like defer to a followup CR.
>
> src/hotspot/share/gc/parallel/psCompactionManager.hpp line 90:
>
>> 88: bool is_partial_array_state() const { return ((uintptr_t)_holder & PartialArrayStateBit) != 0; }
>> 89: };
>> 90:
>
> Please use `ScannerTask` instead; it seems to be completely serviceable for that purpose. In fact, a search&replace seems just fine.
>
> https://github.com/openjdk/jdk/compare/pr/21089...tschatzl:jdk:pull/21089-recommendations?expand=1
>
> I am going to experiment with refactoring the other duplicated (statistics) code
I ran into the same problem for G1 Full GC that @zhengyu123 has run into here. ScannerTask deals in
_pointers_ to `oop` (and `narrowOop`). For the separate marking cases we have `oop`s in the tasks.
I added a class just like this one in my work, except I put mine in gc/shared and gave it a different name
(OopScannerTask, which I don't love). Clearly some coalescing is needed there.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/21089#discussion_r1783181344
From zgu at openjdk.org Tue Oct 1 17:04:39 2024
From: zgu at openjdk.org (Zhengyu Gu)
Date: Tue, 1 Oct 2024 17:04:39 GMT
Subject: RFR: 8339668: Parallel: Adopt PartialArrayState to consolidate
marking stack in compact GC
In-Reply-To: <a378hYVJW-YoibWk9eeGPjdXw_ckAYOnKTJYJkA14fk=.6159375a-cb70-4204-8bc0-a849e091f9a3@github.com>
References: <SpLKo44sGBtJ8p0qZGh6NCl2ABe0ezh8l645vr6R3xM=.6615b830-f3aa-4c25-a0b4-1ab94a66b3d9@github.com>
<S9zZqt6yRZp1ELyjf9LfhU4CLWHiqafojYBJkiChliQ=.6cac8d1f-9168-40ed-bffa-ed54f52ae5f3@github.com>
<a378hYVJW-YoibWk9eeGPjdXw_ckAYOnKTJYJkA14fk=.6159375a-cb70-4204-8bc0-a849e091f9a3@github.com>
Message-ID: <C3EW0Ia7GVPWV32ul-43NnoRNiyx8_4xV8aLvyDVxZY=.0f94fbe1-f808-4417-947c-87c437ab2783@github.com>
On Tue, 1 Oct 2024 16:40:13 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:
> OopScannerTask
I certainly can adopt your implementation once it is integrated.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/21089#discussion_r1783207830
From zgu at openjdk.org Tue Oct 1 19:23:35 2024
From: zgu at openjdk.org (Zhengyu Gu)
Date: Tue, 1 Oct 2024 19:23:35 GMT
Subject: RFR: 8339668: Parallel: Adopt PartialArrayState to consolidate
marking stack in Full GC
In-Reply-To: <C3EW0Ia7GVPWV32ul-43NnoRNiyx8_4xV8aLvyDVxZY=.0f94fbe1-f808-4417-947c-87c437ab2783@github.com>
References: <SpLKo44sGBtJ8p0qZGh6NCl2ABe0ezh8l645vr6R3xM=.6615b830-f3aa-4c25-a0b4-1ab94a66b3d9@github.com>
<S9zZqt6yRZp1ELyjf9LfhU4CLWHiqafojYBJkiChliQ=.6cac8d1f-9168-40ed-bffa-ed54f52ae5f3@github.com>
<a378hYVJW-YoibWk9eeGPjdXw_ckAYOnKTJYJkA14fk=.6159375a-cb70-4204-8bc0-a849e091f9a3@github.com>
<C3EW0Ia7GVPWV32ul-43NnoRNiyx8_4xV8aLvyDVxZY=.0f94fbe1-f808-4417-947c-87c437ab2783@github.com>
Message-ID: <7ZdrpVVGG1hRYudHG_8VA8-lFIJGhSHy0YzmUgtFB9w=.246a5c89-7fb0-402d-92e8-3930c8d430cd@github.com>
On Tue, 1 Oct 2024 17:02:19 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:
>> I ran into the same problem for G1 Full GC that @zhengyu123 has run into here. ScannerTask deals in
>> _pointers_ to `oop` (and `narrowOop`). For the separate marking cases we have `oop`s in the tasks.
>> I added a class just like this one in my work, except I put mine in gc/shared and gave it a different name
>> (OopScannerTask, which I don't love). Clearly some coalescing is needed there.
>
>> OopScannerTask
>
> I certainly can adopt your implementation once it is integrated.
> Please use `ScannerTask` instead; it seems to be completely serviceable for that purpose. In fact, a search&replace seems just fine.
>
> https://github.com/openjdk/jdk/compare/pr/21089...tschatzl:jdk:pull/21089-recommendations?expand=1
>
> I am going to experiment with refactoring the other duplicated (statistics) code
I believe I ran into alignment assertion failure with `ScannerTask`
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/21089#discussion_r1783371791
From zgu at openjdk.org Tue Oct 1 19:37:07 2024
From: zgu at openjdk.org (Zhengyu Gu)
Date: Tue, 1 Oct 2024 19:37:07 GMT
Subject: RFR: 8339668: Parallel: Adopt PartialArrayState to consolidate
marking stack in Full GC [v2]
In-Reply-To: <SpLKo44sGBtJ8p0qZGh6NCl2ABe0ezh8l645vr6R3xM=.6615b830-f3aa-4c25-a0b4-1ab94a66b3d9@github.com>
References: <SpLKo44sGBtJ8p0qZGh6NCl2ABe0ezh8l645vr6R3xM=.6615b830-f3aa-4c25-a0b4-1ab94a66b3d9@github.com>
Message-ID: <e2IUY817VWGkp88WflkPEuFSkNH7xYZME9-CSZMT7pI=.b234fac6-1c4a-4f8b-a30f-825b9eb16ee4@github.com>
> Please review this patch that adopts `PartialArrayState`introduced by [JDK-8337709](https://bugs.openjdk.org/browse/JDK-8337709) to consolidate `_oop_task_queues` and `_objarray_task_queues` into single `_marking_stacks`.
>
> The change mirrors Kim's [JDK-8311163](https://bugs.openjdk.org/browse/JDK-8311163) work, therefore, there are methods can be consolidated and simplified, but I would like defer to a followup CR.
Zhengyu Gu has updated the pull request incrementally with two additional commits since the last revision:
- @tschatzl's comment
- v8
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/21089/files
- new: https://git.openjdk.org/jdk/pull/21089/files/732cf8f7..15b998f6
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=21089&range=01
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=21089&range=00-01
Stats: 5 lines in 2 files changed: 2 ins; 1 del; 2 mod
Patch: https://git.openjdk.org/jdk/pull/21089.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/21089/head:pull/21089
PR: https://git.openjdk.org/jdk/pull/21089
From wkemper at openjdk.org Tue Oct 1 21:44:48 2024
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 1 Oct 2024 21:44:48 GMT
Subject: RFR: 8332697: ubsan: shenandoahSimpleBitMap.inline.hpp:68:23:
runtime error: signed integer overflow: -9223372036854775808 - 1 cannot be
represented in type 'long int' [v4]
In-Reply-To: <I8sOa0g-PbjrI3R9yuuosgg83kNah0m0wiLbsNN8IFM=.495943c2-9206-44c5-abb1-4f68cd98b0c5@github.com>
References: <I8sOa0g-PbjrI3R9yuuosgg83kNah0m0wiLbsNN8IFM=.495943c2-9206-44c5-abb1-4f68cd98b0c5@github.com>
Message-ID: <YpHRzYhZ--JxHSZd8AewEqqPNp_Y1NPW4AYunaPOSYE=.29f4c9d6-1a58-4728-9f1b-1cec4fbf38c8@github.com>
> Use a template version of `right_n_bits` to use the same type for minuend and subtrahend.
William Kemper has updated the pull request incrementally with one additional commit since the last revision:
Inline unnecessary usages of right_n_bits
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/21236/files
- new: https://git.openjdk.org/jdk/pull/21236/files/97d1272b..fdff7d68
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=21236&range=03
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=21236&range=02-03
Stats: 37 lines in 3 files changed: 7 ins; 4 del; 26 mod
Patch: https://git.openjdk.org/jdk/pull/21236.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/21236/head:pull/21236
PR: https://git.openjdk.org/jdk/pull/21236
From wkemper at openjdk.org Tue Oct 1 21:55:36 2024
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 1 Oct 2024 21:55:36 GMT
Subject: RFR: 8332697: ubsan: shenandoahSimpleBitMap.inline.hpp:68:23:
runtime error: signed integer overflow: -9223372036854775808 - 1 cannot be
represented in type 'long int' [v4]
In-Reply-To: <YpHRzYhZ--JxHSZd8AewEqqPNp_Y1NPW4AYunaPOSYE=.29f4c9d6-1a58-4728-9f1b-1cec4fbf38c8@github.com>
References: <I8sOa0g-PbjrI3R9yuuosgg83kNah0m0wiLbsNN8IFM=.495943c2-9206-44c5-abb1-4f68cd98b0c5@github.com>
<YpHRzYhZ--JxHSZd8AewEqqPNp_Y1NPW4AYunaPOSYE=.29f4c9d6-1a58-4728-9f1b-1cec4fbf38c8@github.com>
Message-ID: <KR5hHY_TVNijBf-reA0t01GBMmso9Gv-x7ZqfhF1xV4=.5bf733f1-41d9-45c3-8645-9bd1e92e1d81@github.com>
On Tue, 1 Oct 2024 21:44:48 GMT, William Kemper <wkemper at openjdk.org> wrote:
>> Use a template version of `right_n_bits` to use the same type for minuend and subtrahend.
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
>
> Inline unnecessary usages of right_n_bits
I'd prefer to keep the scope of these changes limited to this file. This is the only place where this seems to be a problem in the JDK and I think it's just because we abused a macro we shouldn't have.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/21236#issuecomment-2387142276
From kdnilsen at openjdk.org Wed Oct 2 00:54:53 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 2 Oct 2024 00:54:53 GMT
Subject: RFR: 8341379: Shenandoah: Improve lock contention during cleanup
Message-ID: <5GMjFWaMjkSuxhPJ8TYJyw_LYdFfhJWrySSaRUjSNq4=.0ee7f896-35b2-43aa-a243-418b1ffb50b0@github.com>
This change improves the efficiency of cleaning up (recycling) regions that have been trashed by GC effort. The affected code runs at the end of FinalMark to reclaim immediate garbage. It runs at the end of FinalUpdateRefs to reclaim the regions that comprised the collection set, from which all live objects have now been evacuated.
Efficiency improvements include:
1. Rather than invoking the os (while holding the Heap lock) to obtain the time twice for every region recycled, we invoke the os only once for each batch of 32 regions that are to be processed.
2. Rather than enforcing that the loop runs no longer than 30 us, we refrain from starting a second batch of regions if more than 8 us has passed since the preceding batch was processed.
Below, each trial runs for 1 hour, processing 28,000 transactions per second.
Without this change, latency for 4 un-named business services is represented by the following chart:
With this change, latency for the same services is much better:
A comparison of the two is provided by the following:
-------------
Commit messages:
- Respond to reviewer feedback
- Tidy up comments and remove debug instrumentation
- Recycle multiple regions before checking deadline
- Merge branch 'openjdk:master' into master
- Merge branch 'openjdk:master' into master
- Merge branch 'openjdk:master' into master
- Merge branch 'openjdk:master' into master
- Revert "Make GC logging less verbose"
- Make GC logging less verbose
- Merge branch 'openjdk:master' into master
- ... and 15 more: https://git.openjdk.org/jdk/compare/5d062e24...acf517f5
Changes: https://git.openjdk.org/jdk/pull/21211/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21211&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8341379
Stats: 28 lines in 1 file changed: 22 ins; 3 del; 3 mod
Patch: https://git.openjdk.org/jdk/pull/21211.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/21211/head:pull/21211
PR: https://git.openjdk.org/jdk/pull/21211
From wkemper at openjdk.org Wed Oct 2 00:54:53 2024
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 2 Oct 2024 00:54:53 GMT
Subject: RFR: 8341379: Shenandoah: Improve lock contention during cleanup
In-Reply-To: <5GMjFWaMjkSuxhPJ8TYJyw_LYdFfhJWrySSaRUjSNq4=.0ee7f896-35b2-43aa-a243-418b1ffb50b0@github.com>
References: <5GMjFWaMjkSuxhPJ8TYJyw_LYdFfhJWrySSaRUjSNq4=.0ee7f896-35b2-43aa-a243-418b1ffb50b0@github.com>
Message-ID: <_lvg95UW7HqXx5iAkndxKUNGHTmsXCLj7Ee5t-0SRCE=.47af2a9e-80b3-40d6-9348-407ee1518442@github.com>
On Thu, 26 Sep 2024 21:08:11 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:
> This change improves the efficiency of cleaning up (recycling) regions that have been trashed by GC effort. The affected code runs at the end of FinalMark to reclaim immediate garbage. It runs at the end of FinalUpdateRefs to reclaim the regions that comprised the collection set, from which all live objects have now been evacuated.
>
> Efficiency improvements include:
> 1. Rather than invoking the os (while holding the Heap lock) to obtain the time twice for every region recycled, we invoke the os only once for each batch of 32 regions that are to be processed.
> 2. Rather than enforcing that the loop runs no longer than 30 us, we refrain from starting a second batch of regions if more than 8 us has passed since the preceding batch was processed.
>
> Below, each trial runs for 1 hour, processing 28,000 transactions per second.
>
> Without this change, latency for 4 un-named business services is represented by the following chart:
> 
>
> With this change, latency for the same services is much better:
> 
>
> A comparison of the two is provided by the following:
> 
src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 944:
> 942: // yields. Yielding more frequently when there is heavy contention for the heap lock or for CPU cores is considered the
> 943: // right thing to do.
> 944: const size_t REGION_STRIDE = 32;
Maybe call this `REGIONS_PER_BATCH`? When I see `stride` I think how far the loop index moves on each iteration.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/21211#discussion_r1783520423
From kdnilsen at openjdk.org Wed Oct 2 00:54:53 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 2 Oct 2024 00:54:53 GMT
Subject: RFR: 8341379: Shenandoah: Improve lock contention during cleanup
In-Reply-To: <_lvg95UW7HqXx5iAkndxKUNGHTmsXCLj7Ee5t-0SRCE=.47af2a9e-80b3-40d6-9348-407ee1518442@github.com>
References: <5GMjFWaMjkSuxhPJ8TYJyw_LYdFfhJWrySSaRUjSNq4=.0ee7f896-35b2-43aa-a243-418b1ffb50b0@github.com>
<_lvg95UW7HqXx5iAkndxKUNGHTmsXCLj7Ee5t-0SRCE=.47af2a9e-80b3-40d6-9348-407ee1518442@github.com>
Message-ID: <ZYFlU1Ar7iARpbKqCXw33_hxezKblCdeRV_vrm5kFxs=.61fbc5d3-02ad-42c0-b824-ad656da94e45@github.com>
On Tue, 1 Oct 2024 20:53:01 GMT, William Kemper <wkemper at openjdk.org> wrote:
>> This change improves the efficiency of cleaning up (recycling) regions that have been trashed by GC effort. The affected code runs at the end of FinalMark to reclaim immediate garbage. It runs at the end of FinalUpdateRefs to reclaim the regions that comprised the collection set, from which all live objects have now been evacuated.
>>
>> Efficiency improvements include:
>> 1. Rather than invoking the os (while holding the Heap lock) to obtain the time twice for every region recycled, we invoke the os only once for each batch of 32 regions that are to be processed.
>> 2. Rather than enforcing that the loop runs no longer than 30 us, we refrain from starting a second batch of regions if more than 8 us has passed since the preceding batch was processed.
>>
>> Below, each trial runs for 1 hour, processing 28,000 transactions per second.
>>
>> Without this change, latency for 4 un-named business services is represented by the following chart:
>> 
>>
>> With this change, latency for the same services is much better:
>> 
>>
>> A comparison of the two is provided by the following:
>> 
>
> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 944:
>
>> 942: // yields. Yielding more frequently when there is heavy contention for the heap lock or for CPU cores is considered the
>> 943: // right thing to do.
>> 944: const size_t REGION_STRIDE = 32;
>
> Maybe call this `REGIONS_PER_BATCH`? When I see `stride` I think how far the loop index moves on each iteration.
Good suggestion.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/21211#discussion_r1783668735
From kdnilsen at openjdk.org Wed Oct 2 00:54:53 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 2 Oct 2024 00:54:53 GMT
Subject: RFR: 8341379: Shenandoah: Improve lock contention during cleanup
In-Reply-To: <ZYFlU1Ar7iARpbKqCXw33_hxezKblCdeRV_vrm5kFxs=.61fbc5d3-02ad-42c0-b824-ad656da94e45@github.com>
References: <5GMjFWaMjkSuxhPJ8TYJyw_LYdFfhJWrySSaRUjSNq4=.0ee7f896-35b2-43aa-a243-418b1ffb50b0@github.com>
<_lvg95UW7HqXx5iAkndxKUNGHTmsXCLj7Ee5t-0SRCE=.47af2a9e-80b3-40d6-9348-407ee1518442@github.com>
<ZYFlU1Ar7iARpbKqCXw33_hxezKblCdeRV_vrm5kFxs=.61fbc5d3-02ad-42c0-b824-ad656da94e45@github.com>
Message-ID: <L5ylS-C5nLOeaEwpNog3WFTlgLKHJshOfWYgnIdr9yY=.8b61c54a-d3b9-4889-a0fd-ee6552ec1c0f@github.com>
On Wed, 2 Oct 2024 00:24:00 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:
>> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 944:
>>
>>> 942: // yields. Yielding more frequently when there is heavy contention for the heap lock or for CPU cores is considered the
>>> 943: // right thing to do.
>>> 944: const size_t REGION_STRIDE = 32;
>>
>> Maybe call this `REGIONS_PER_BATCH`? When I see `stride` I think how far the loop index moves on each iteration.
>
> Good suggestion.
Thanks. I've made this change.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/21211#discussion_r1783698490
From thomas.schatzl at oracle.com Wed Oct 2 06:47:52 2024
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 2 Oct 2024 08:47:52 +0200
Subject: Aligning the Serial collector with ZGC
In-Reply-To: <C14C1F49-71BB-49DB-8A9D-E8993E324958@kodewerk.com>
References: <49D0FB58-94AB-46B6-A8A6-F9F08773770E@kodewerk.com>
<44230e90-d8bc-491f-a5c4-2c483646fc3e@oracle.com>
<C14C1F49-71BB-49DB-8A9D-E8993E324958@kodewerk.com>
Message-ID: <712c118e-642e-4bb7-a48b-b0b11ba3a4f2@oracle.com>
Hi,
On 28.09.24 00:55, Kirk Pepperdine wrote:
> Hi Thomas,
>
> I wanted to respond to all of your comments but I thought better of it
> given one response deserves it?s own email. The focus is mostly on that
> one question.
>
>> >
>> > - Introduce an adaptive size policy that takes into account memory and
>> > CPU pressure along with global memory pressure.
>> > ????- Heap should be large enough to minimize GC overhead but not
>> > large enough to trigger OOM.
>>
>> (probably meant "small enough" the second time)
>
> I actually did mean large but in the context of OOM killer?. But to your
> point, smaller but avoid OOME is also a concern.
>
>>
>> > ????- Introduce -XX:SerialPressure=[0-100] to support this work.
>>
>> (Fwiw, regards to the other discussion, I agree that if we have a flag
>> with the same "meaning" across collectors it might be useful to use
>> the same name).
>
> I think we have deadly agreement on this one.
>
>>
>> > ????- introduce a smoothing algorythm to avoid excessive small
>> > resizes.
>>
>> One option is to split this further into parts:
>>
>> * list what actions Serial GC could do in reaction to memory pressure
>> on an abstract level, and which make sense; from that see what
>> functionality is needed.
>
> I built a chart some time ago and this is an expanded version of it.
>
[...]
>
> Some of my thoughts used to construct the table.
>
[...]
> All of the resizing decisions need to be moderated by the availability
> of (global) memory. If global memory is scarce, then the decision should
> favour releasing (uncommitting) memory. This may come at the expense of
> higher GC overhead. Resizing to smaller pool sizes is not without risk
> and in the case of young, both high global memory pressure and high
> allocation pressure add to the risk.
>
Thank you for sharing your detailed thoughts.
>
>
>>
>> * provide functionality that tries to keep some kind of GC/mutator
>> time ratio; I would start with looking at G1 does because Serial GC's
>> behaviour is probably closer to G1 than ZGC, but ymmv.
>> (Obviously improvements are welcome :))
>
> I would agree.
Here's some old code for implementing
https://bugs.openjdk.org/browse/JDK-8238687: Uncommit at every GC that
improves a bit on the current G1 policy which implements both signalling
for under/over-cpu usage ratio, which is maybe better (documented) than
the existing code.
https://github.com/openjdk/jdk/compare/master...tschatzl:jdk:investigate-memory-uncommit-every-gc-only
[...]
>> > - Introduce manageable flag SoftMaxHeapSize to define a target heap
>> > size nd set the default max heap size to 100% of available.
>>
>> I am a bit torn about SoftMaxHeapSize in Serial GC. What do you
>> envision that Serial GC would do when the SoftMaxHeapSize has been
>> reached, and what if old gen occupancy permanently stays above that value?
>
> At the moment, SoftMaxHeapSize is an implementation in Z. I?d first like
> to pull a (rough) spec out of the implementation and then try to answer
> your question. It?s currently not clear to me how this should work with
> any collector.
>>
>> The usefulness of SoftMaxHeapSize kind of relies on having a minimally
>> invasive old gen collection that tries to get old gen usage back below
>> that value.
>
> Well, the LDS is what it is and running a speculative collection would
> likely clean up (prematurely) promoted transients? but that?s about it.
> Whereas it would clean both transients and floating garbage for the
> concurrent collectors. I?m not at fan of speculative collections given
> all of the time I?ve spent getting rid of them :-) IMO, a DGC triggered
> full collections was rarely necessary (all overhead with very little
> return). This also applied to the G1 patch that speculatively ran to
> counter to-space overflows and it also applied to running a young gen
> prior to remark with CMS collector. Long story sort, loads of extra
> overhead with very little to no payback.
SoftMaxHeapSize is a bit different as it is non-speculative but
supposedly based on the users intent.
>> Serial GC has no "minimally invasive" way to collect old generation.
>> It is either Full GC or nothing. This is the only option for Serial,
>> but always doing Full collections after reaching that threshold seems
>> very heavy handed, expensive and undesirable to me (ymmv).
>>
>> That reaction would follow the spirit of the flag though.
>>
>> Maybe at the small heaps Serial GC targets, this makes sense, and full
>> gc is not that costly anyway.
>
> Yeah, for small heap this shouldn?t be a big deal. But this is one of
> the reasons why I believe we should treat young and old separately. We
> can cheaply and safely return memory from young gen and leave the sizing
> of tenured to when a full is really needed. I grant you that this may
> not be very timely but I?m not sure that we need this to happen on
> demand? I think we can wait for natural cycles to take their course.
> But, maybe I?m wrong on this point. We plan to experiment with this.
Please do and report back.
>>
>> It might be useful to enumerate what actions could be performed on
>> global pressure.
>
> That?s in the table?
>
>>
>> > - Add in the ability to uncommit memory (to reduce global memory
>> > pressure).
>> >
>>
>> The following imo outlines a compdoneletely separate idea, and should
>> be discussed separately:
>>
>> >
>> > While working through the details of this work I noted that there
>> > appear ?to opportunities to offer new defaults for other settings. For
>> > example, [...]
>>
>> That seems to be some more elaborate way of finding "optimal"
>> generation size for a given heap size (which may follow from what the
>> gc/mutator time ratio algorithm gives you).
>
> I?m trying to apply my years of experience tuning 100s of collectors
> across 100s of applications.
>
Very much appreciated.
Hth,
Thomas
From tschatzl at openjdk.org Wed Oct 2 07:22:37 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 2 Oct 2024 07:22:37 GMT
Subject: RFR: 8339668: Parallel: Adopt PartialArrayState to consolidate
marking stack in Full GC [v2]
In-Reply-To: <7ZdrpVVGG1hRYudHG_8VA8-lFIJGhSHy0YzmUgtFB9w=.246a5c89-7fb0-402d-92e8-3930c8d430cd@github.com>
References: <SpLKo44sGBtJ8p0qZGh6NCl2ABe0ezh8l645vr6R3xM=.6615b830-f3aa-4c25-a0b4-1ab94a66b3d9@github.com>
<S9zZqt6yRZp1ELyjf9LfhU4CLWHiqafojYBJkiChliQ=.6cac8d1f-9168-40ed-bffa-ed54f52ae5f3@github.com>
<a378hYVJW-YoibWk9eeGPjdXw_ckAYOnKTJYJkA14fk=.6159375a-cb70-4204-8bc0-a849e091f9a3@github.com>
<C3EW0Ia7GVPWV32ul-43NnoRNiyx8_4xV8aLvyDVxZY=.0f94fbe1-f808-4417-947c-87c437ab2783@github.com>
<7ZdrpVVGG1hRYudHG_8VA8-lFIJGhSHy0YzmUgtFB9w=.246a5c89-7fb0-402d-92e8-3930c8d430cd@github.com>
Message-ID: <U8mUQUzQDuZC7JmaMvl_1JmUPStliL2B4w-EZulwRfg=.dfc89a5e-3a22-4c1d-8084-16f2b6ab1b52@github.com>
On Tue, 1 Oct 2024 19:21:11 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:
>>> OopScannerTask
>>
>> I certainly can adopt your implementation once it is integrated.
>
>> Please use `ScannerTask` instead; it seems to be completely serviceable for that purpose. In fact, a search&replace seems just fine.
>>
>> https://github.com/openjdk/jdk/compare/pr/21089...tschatzl:jdk:pull/21089-recommendations?expand=1
>>
>> I am going to experiment with refactoring the other duplicated (statistics) code
>
> I believe I ran into alignment assertion failure with `ScannerTask`
>I ran into the same problem for G1 Full GC that @zhengyu123 has run into here. ScannerTask deals in
pointers to oop (and narrowOop). For the separate marking cases we have oops in the tasks.
I added a class just like this one in my work, except I put mine in gc/shared and gave it a different name
(OopScannerTask, which I don't love). Clearly some coalescing is needed there.
The suggested patch just adds constructor to allow a regular `oop` and the associated getter. Internally `ScannerTask` uses a `void*` anyway.
Probably I am overlooking something trivial here why having an interface to store and retrieve an `oop` is not possible.... seems to pass very basic testing though.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/21089#discussion_r1783940286
From rcastanedalo at openjdk.org Wed Oct 2 08:29:55 2024
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Wed, 2 Oct 2024 08:29:55 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v11]
In-Reply-To: <toUdNzwkdDAQDltc4_t6wI06bCE-EHzpIs_t-arIwNY=.7d9ef348-0033-4268-9ed1-7c183855521f@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<DUgk6HT_Zk5KnbmAd_HzrJi4B8D1J-uuoAGzReWyI8s=.6c04f90a-bf1d-49af-a31d-5224973952d4@github.com>
<YTte6oY9EeAPHxzzOndL8M202wY91SbeaYC4hPva0W0=.caf00270-89c7-44b0-ab88-a970fb8e840d@github.com>
<kzodWwxj5qdAqPYcP2s4k2QTXqjju2H6Iftu7dojezk=.1f72fc31-94ba-4017-b330-c8688a8d39a4@github.com>
<hkGaBWSugvpV0PgoR9rnutHCgQzkeXv1ctH7QwV3zK0=.204737d5-fadb-410a-8891-7db59d36830f@github.com>
<shoDPnL4nQyaYX4xy-WyzQ7CwsoCbAeCE3c755CkE1o=.caf940aa-5fbb-4cb5-a4a2-68a2452ffe1b@github.com>
<TBZCkcFNNnEvat7TBnRkqUPo4Y5TEe1L0iUZ9loD7DI=.39c0249c-f6b2-45c8-b7c8-9e2c9c1b7a99@github.com>
<toUdNzwkdDAQDltc4_t6wI06bCE-EHzpIs_t-arIwNY=.7d9ef348-0033-4268-9ed1-7c183855521f@github.com>
Message-ID: <ES5Lj2Kg_a8L48WTpysLoDGS8TMHLMTbscJd3QVnAXA=.3eff8632-c747-40d1-a956-342cc45baca4@github.com>
On Tue, 1 Oct 2024 15:46:01 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
> > test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationNotRun.java:
>
> I think I would disable the tests for now. Is there a good way to say 'run this when UCOH is off OR UseSSE>3?
I don't think so, due to a [limitation in the IR framework precondition language](https://bugs.openjdk.org/browse/JDK-8294279): `UseCompactObjectHeaders` can only appear within a ["flag precondition"](https://github.com/openjdk/jdk/blob/efe3573b9b4ecec0630fdc1c61c765713a5b68e6/test/hotspot/jtreg/compiler/lib/ir_framework/IR.java#L109) whereas `UseSSE>3` needs to be expressed as a ["CPU feature precondition"](https://github.com/openjdk/jdk/blob/efe3573b9b4ecec0630fdc1c61c765713a5b68e6/test/hotspot/jtreg/compiler/lib/ir_framework/IR.java#L137C14-L137C31) for portability (`UseSSE` is not defined for aarch64), and these two cannot be combined with logical operators.
I suggest to disable the IR checks of the failing tests using `applyIf = {"UseCompactObjectHeaders", "false"}` as you did for other similar tests (e.g. `TestMulAddS2I.java`), and document it in [JDK-8340010](https://bugs.openjdk.org/browse/JDK-8340010). Maybe also comment in the tests that the failure happens only with `-XX:UseSSE<=3`.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2387906401
From tschatzl at openjdk.org Wed Oct 2 09:29:40 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 2 Oct 2024 09:29:40 GMT
Subject: RFR: 8339668: Parallel: Adopt PartialArrayState to consolidate
marking stack in Full GC [v2]
In-Reply-To: <U8mUQUzQDuZC7JmaMvl_1JmUPStliL2B4w-EZulwRfg=.dfc89a5e-3a22-4c1d-8084-16f2b6ab1b52@github.com>
References: <SpLKo44sGBtJ8p0qZGh6NCl2ABe0ezh8l645vr6R3xM=.6615b830-f3aa-4c25-a0b4-1ab94a66b3d9@github.com>
<S9zZqt6yRZp1ELyjf9LfhU4CLWHiqafojYBJkiChliQ=.6cac8d1f-9168-40ed-bffa-ed54f52ae5f3@github.com>
<a378hYVJW-YoibWk9eeGPjdXw_ckAYOnKTJYJkA14fk=.6159375a-cb70-4204-8bc0-a849e091f9a3@github.com>
<C3EW0Ia7GVPWV32ul-43NnoRNiyx8_4xV8aLvyDVxZY=.0f94fbe1-f808-4417-947c-87c437ab2783@github.com>
<7ZdrpVVGG1hRYudHG_8VA8-lFIJGhSHy0YzmUgtFB9w=.246a5c89-7fb0-402d-92e8-3930c8d430cd@github.com>
<U8mUQUzQDuZC7JmaMvl_1JmUPStliL2B4w-EZulwRfg=.dfc89a5e-3a22-4c1d-8084-16f2b6ab1b52@github.com>
Message-ID: <LcZYTU9GhTLKT5M7qP2aaSNTkvwtiHUomO_iXOF2lcI=.32fe8ae9-e216-4cbf-88e3-75f9a7846adc@github.com>
On Wed, 2 Oct 2024 07:18:49 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:
>>> Please use `ScannerTask` instead; it seems to be completely serviceable for that purpose. In fact, a search&replace seems just fine.
>>>
>>> https://github.com/openjdk/jdk/compare/pr/21089...tschatzl:jdk:pull/21089-recommendations?expand=1
>>>
>>> I am going to experiment with refactoring the other duplicated (statistics) code
>>
>> I believe I ran into alignment assertion failure with `ScannerTask`
>
>>I ran into the same problem for G1 Full GC that @zhengyu123 has run into here. ScannerTask deals in
> pointers to oop (and narrowOop). For the separate marking cases we have oops in the tasks.
> I added a class just like this one in my work, except I put mine in gc/shared and gave it a different name
> (OopScannerTask, which I don't love). Clearly some coalescing is needed there.
>
> The suggested patch just adds constructor to allow a regular `oop` and the associated getter. Internally `ScannerTask` uses a `void*` anyway.
> Probably I am overlooking something trivial here why having an interface to store and retrieve an `oop` is not possible.... seems to pass very basic testing though.
(Fwiw, https://github.com/tschatzl/jdk/tree/submit/pull/21089-recommendations-test with the suggested changes seems to pass GHA....)
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/21089#discussion_r1784114619
From tschatzl at openjdk.org Wed Oct 2 09:29:42 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 2 Oct 2024 09:29:42 GMT
Subject: RFR: 8339668: Parallel: Adopt PartialArrayState to consolidate
marking stack in Full GC [v2]
In-Reply-To: <S9zZqt6yRZp1ELyjf9LfhU4CLWHiqafojYBJkiChliQ=.6cac8d1f-9168-40ed-bffa-ed54f52ae5f3@github.com>
References: <SpLKo44sGBtJ8p0qZGh6NCl2ABe0ezh8l645vr6R3xM=.6615b830-f3aa-4c25-a0b4-1ab94a66b3d9@github.com>
<S9zZqt6yRZp1ELyjf9LfhU4CLWHiqafojYBJkiChliQ=.6cac8d1f-9168-40ed-bffa-ed54f52ae5f3@github.com>
Message-ID: <J4aWJzB1XaehGjIvi9W0b0HEKvBSufLZsHQ6j7cxpNs=.c2f0303a-502c-4d6b-9555-c355002ed9c9@github.com>
On Tue, 1 Oct 2024 12:48:40 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:
>> Zhengyu Gu has updated the pull request incrementally with two additional commits since the last revision:
>>
>> - @tschatzl's comment
>> - v8
>
> src/hotspot/share/gc/parallel/psCompactionManager.hpp line 122:
>
>> 120: size_t _arrays_chunked;
>> 121: size_t _array_chunks_processed;
>> 122: #endif // TASKQUEUE_STATS
>
> This is a separate issue, but we did not add these counters when doing this change for g1 young gen. Filed [JDK-8341331](https://bugs.openjdk.org/browse/JDK-8341331) for that.
>
> There is a fair amount of code duplication (definition of members, management and printing) which is not great (but you mentioned it). For now I filed [JDK-8341332](https://bugs.openjdk.org/browse/JDK-8341332) for this, but I would really prefer some refactoring in this area in _this_ change.
>
> Initially I was kind of okay to do that separately, but the copy&paste seems too much.
Here's a commit that only touches up the worst issues in this change: https://github.com/openjdk/jdk/commit/ab6e77ed909c13458a24e9663e830cfac9c4f18e
(branch including the other suggestions so far: https://github.com/openjdk/jdk/compare/master...tschatzl:jdk:pull/21089-taskqueue-refactor)
This makes the change a lot more readable imo (and in total reduces LOC count).
The only missing improvement is to have the array statistics in the same log lines as the other statistics; that could be achieved by specializing the queues/queue set, but that requires the unified `ScannerTask` in the other change and more work.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/21089#discussion_r1784112754
From mli at openjdk.org Wed Oct 2 10:15:54 2024
From: mli at openjdk.org (Hamlin Li)
Date: Wed, 2 Oct 2024 10:15:54 GMT
Subject: RFR: 8334060: Implementation of Late Barrier Expansion for G1
[v27]
In-Reply-To: <YYVkTHSwqRigZMpp3wjVjULgwfhawfXCszR2iKEPazA=.a7b37dee-07cd-45e9-aeed-0f90cba1268a@github.com>
References: <ClHEkY_xzx37VNyLJr9F9eWSjXfdCRQcbmAhomsY7kU=.f4c3c125-caed-467f-b9fa-213d14f7908a@github.com>
<YYVkTHSwqRigZMpp3wjVjULgwfhawfXCszR2iKEPazA=.a7b37dee-07cd-45e9-aeed-0f90cba1268a@github.com>
Message-ID: <vb76mbxerbCHN5fmVs9ERapN0W1XeTdBzu8ncwCINLY=.89a1a645-8a60-44bd-aed3-3a18c6c378ab@github.com>
On Mon, 30 Sep 2024 05:02:12 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:
>> This changeset implements JEP 475 (Late Barrier Expansion for G1), including support for the x64 and aarch64 platforms. See the [JEP description](https://openjdk.org/jeps/475) for further detail.
>>
>> We aim to integrate this work in JDK 24. The purpose of this pull request is double-fold:
>>
>> - to allow maintainers of the arm (32-bit), ppc, riscv, s390, and x86 (32-bit) ports to contribute a port of these platforms in time for JDK 24; and
>> - to allow reviewers to review the platform-independent, x64 and aarch64, and test changes in parallel with the porting work.
>>
>> ## Summary of the Changes
>>
>> ### Platform-Independent Changes (`src/hotspot/share`)
>>
>> These consist mainly of:
>>
>> - a complete rewrite of `G1BarrierSetC2`, to instruct C2 to expand G1 barriers late instead of early;
>> - a few minor changes to C2 itself, to support removal of redundant decompression operations and to address an OopMap construction issue triggered by this JEP's increased usage of ADL `TEMP` operands; and
>> - temporary support for porting the JEP to the remaining platforms.
>>
>> The temporary support code (guarded by the pre-processor flag `G1_LATE_BARRIER_MIGRATION_SUPPORT`) will **not** be part of the final pull request, and hence does not need to be reviewed.
>>
>> ### Platform-Dependent Changes (`src/hotspot/cpu`)
>>
>> These include changes to the ADL instruction definitions and the `G1BarrierSetAssembler` class of the x64 and aarch64 platforms.
>>
>> #### ADL Changes
>>
>> The changeset uses ADL predicates to force C2 to implement memory accesses tagged with barrier information using G1-specific, barrier-aware instruction versions (e.g. `g1StoreP` instead of the GC-agnostic `storeP`). These new instruction versions generate machine code accordingly to the corresponding tagged barrier information, relying on the G1 barrier implementations provided by the `G1BarrierSetAssembler` class. In the aarch64 platform, the bulk of the ADL code is generated from a higher-level version using m4, to reduce redundancy.
>>
>> #### `G1BarrierSetAssembler` Changes
>>
>> Both platforms basically reuse the barrier implementation for the bytecode interpreter, with the different barrier tests and operations refactored into dedicated functions. Besides this, `G1BarrierSetAssembler` is extended with assembly-stub routines that implement the out-of-line, slow path of the barriers. These routines include calls from the barrier into the JVM, which require support for saving and restoring live ...
>
> Roberto Casta?eda Lozano 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 53 additional commits since the last revision:
>
> - Merge remote-tracking branch 'feilongjiang/JEP-475-RISC-V' into JDK-8334060-g1-late-barrier-expansion
> - riscv port refactor
> - Remove temporary support code
> - Merge jdk-24+17
> - Relax 'must match' assertion in ppc's g1StoreN after limiting pinning bypass optimization
> - Remove unnecessary reg-to-reg moves in aarch64's g1CompareAndX instructions
> - Reintroduce matcher assert and limit pinning bypass optimization to non-shared EncodeP nodes
> - Merge jdk-24+16
> - Ensure that detected encode-and-store patterns are matched
> - Merge remote-tracking branch 'snazarkin/arm32-JDK-8334060-g1-late-barrier-expansion' into JDK-8334060-g1-late-barrier-expansion
> - ... and 43 more: https://git.openjdk.org/jdk/compare/9566d51f...14483b83
Hi, have some comments on riscv part code.
I'm not sure if the same comments also apply to other code, please have a look if necessary.
src/hotspot/cpu/riscv/gc/g1/g1_riscv.ad line 55:
> 53: }
> 54: for (RegSetIterator<Register> reg = no_preserve.begin(); *reg != noreg; ++reg) {
> 55: stub->dont_preserve(*reg);
Could `no_preserve` and `preserve` overlap?
If false, then seems it's not necessary to do `dont_preserve` for `no_preserve`
If true, seems it's not safe to `dont_preserve` these regs? I'm not sure.
src/hotspot/cpu/riscv/gc/g1/g1_riscv.ad line 169:
> 167: predicate(UseG1GC && n->as_LoadStore()->barrier_data() != 0);
> 168: match(Set res (CompareAndExchangeP mem (Binary oldval newval)));
> 169: effect(TEMP res, TEMP tmp1, TEMP tmp2);
should `res` be `TEMP_DEF`?
src/hotspot/cpu/riscv/gc/g1/g1_riscv.ad line 201:
> 199: predicate(UseG1GC && needs_acquiring_load_reserved(n) && n->as_LoadStore()->barrier_data() != 0);
> 200: match(Set res (CompareAndExchangeP mem (Binary oldval newval)));
> 201: effect(TEMP res, TEMP tmp1, TEMP tmp2);
should `res` be `TEMP_DEF`?
src/hotspot/cpu/riscv/gc/g1/g1_riscv.ad line 233:
> 231: predicate(UseG1GC && n->as_LoadStore()->barrier_data() != 0);
> 232: match(Set res (CompareAndExchangeN mem (Binary oldval newval)));
> 233: effect(TEMP res, TEMP tmp1, TEMP tmp2, TEMP tmp3);
should `res` be `TEMP_DEF`?
src/hotspot/cpu/riscv/gc/g1/g1_riscv.ad line 263:
> 261: predicate(UseG1GC && needs_acquiring_load_reserved(n) && n->as_LoadStore()->barrier_data() != 0);
> 262: match(Set res (CompareAndExchangeN mem (Binary oldval newval)));
> 263: effect(TEMP res, TEMP tmp1, TEMP tmp2, TEMP tmp3);
should `res` be `TEMP_DEF`?
And same comment for following instructs?
-------------
PR Review: https://git.openjdk.org/jdk/pull/19746#pullrequestreview-2342455263
PR Review Comment: https://git.openjdk.org/jdk/pull/19746#discussion_r1784240549
PR Review Comment: https://git.openjdk.org/jdk/pull/19746#discussion_r1784209154
PR Review Comment: https://git.openjdk.org/jdk/pull/19746#discussion_r1784210589
PR Review Comment: https://git.openjdk.org/jdk/pull/19746#discussion_r1784211728
PR Review Comment: https://git.openjdk.org/jdk/pull/19746#discussion_r1784212185
From rcastanedalo at openjdk.org Wed Oct 2 11:42:52 2024
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Wed, 2 Oct 2024 11:42:52 GMT
Subject: RFR: 8334060: Implementation of Late Barrier Expansion for G1
[v27]
In-Reply-To: <vb76mbxerbCHN5fmVs9ERapN0W1XeTdBzu8ncwCINLY=.89a1a645-8a60-44bd-aed3-3a18c6c378ab@github.com>
References: <ClHEkY_xzx37VNyLJr9F9eWSjXfdCRQcbmAhomsY7kU=.f4c3c125-caed-467f-b9fa-213d14f7908a@github.com>
<YYVkTHSwqRigZMpp3wjVjULgwfhawfXCszR2iKEPazA=.a7b37dee-07cd-45e9-aeed-0f90cba1268a@github.com>
<vb76mbxerbCHN5fmVs9ERapN0W1XeTdBzu8ncwCINLY=.89a1a645-8a60-44bd-aed3-3a18c6c378ab@github.com>
Message-ID: <7L7jYDlFa0WnVvgiyNHI9KZrcffYwNnBB899AuMS56Q=.40b031e7-07b8-4a15-b319-c53b38a17a49@github.com>
On Wed, 2 Oct 2024 10:10:12 GMT, Hamlin Li <mli at openjdk.org> wrote:
>> Roberto Casta?eda Lozano 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 53 additional commits since the last revision:
>>
>> - Merge remote-tracking branch 'feilongjiang/JEP-475-RISC-V' into JDK-8334060-g1-late-barrier-expansion
>> - riscv port refactor
>> - Remove temporary support code
>> - Merge jdk-24+17
>> - Relax 'must match' assertion in ppc's g1StoreN after limiting pinning bypass optimization
>> - Remove unnecessary reg-to-reg moves in aarch64's g1CompareAndX instructions
>> - Reintroduce matcher assert and limit pinning bypass optimization to non-shared EncodeP nodes
>> - Merge jdk-24+16
>> - Ensure that detected encode-and-store patterns are matched
>> - Merge remote-tracking branch 'snazarkin/arm32-JDK-8334060-g1-late-barrier-expansion' into JDK-8334060-g1-late-barrier-expansion
>> - ... and 43 more: https://git.openjdk.org/jdk/compare/486c5b0d...14483b83
>
> src/hotspot/cpu/riscv/gc/g1/g1_riscv.ad line 55:
>
>> 53: }
>> 54: for (RegSetIterator<Register> reg = no_preserve.begin(); *reg != noreg; ++reg) {
>> 55: stub->dont_preserve(*reg);
>
> Could `no_preserve` and `preserve` overlap?
> If false, then seems it's not necessary to do `dont_preserve` for `no_preserve`
> If true, seems it's not safe to `dont_preserve` these regs? I'm not sure.
In the G1 case, the use of `dont_preserve` is an optimization to avoid spilling and reloading, in the slow path of the pre-barrier, registers (`res`) that are not live at that point. It is not necessary for correctness, but saves a few bytes in the generated code. If `res` was not marked as `dont_preserve`, it would be included in the pre-barrier stub's preserve set (`BarrierStubC2::preserve_set()`) because it is live out of the entire AD instruction (as computed by `BarrierSetC2::compute_liveness_at_stubs()`).
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/19746#discussion_r1784346898
From rcastanedalo at openjdk.org Wed Oct 2 11:53:52 2024
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Wed, 2 Oct 2024 11:53:52 GMT
Subject: RFR: 8334060: Implementation of Late Barrier Expansion for G1
[v27]
In-Reply-To: <vb76mbxerbCHN5fmVs9ERapN0W1XeTdBzu8ncwCINLY=.89a1a645-8a60-44bd-aed3-3a18c6c378ab@github.com>
References: <ClHEkY_xzx37VNyLJr9F9eWSjXfdCRQcbmAhomsY7kU=.f4c3c125-caed-467f-b9fa-213d14f7908a@github.com>
<YYVkTHSwqRigZMpp3wjVjULgwfhawfXCszR2iKEPazA=.a7b37dee-07cd-45e9-aeed-0f90cba1268a@github.com>
<vb76mbxerbCHN5fmVs9ERapN0W1XeTdBzu8ncwCINLY=.89a1a645-8a60-44bd-aed3-3a18c6c378ab@github.com>
Message-ID: <Hb8hg-u4fHx_vjZg67WH5BGCDasejxy6fpFEvrUSiLQ=.bf419701-c4fa-4167-8662-c711bb2ff93a@github.com>
On Wed, 2 Oct 2024 09:58:29 GMT, Hamlin Li <mli at openjdk.org> wrote:
>> Roberto Casta?eda Lozano 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 53 additional commits since the last revision:
>>
>> - Merge remote-tracking branch 'feilongjiang/JEP-475-RISC-V' into JDK-8334060-g1-late-barrier-expansion
>> - riscv port refactor
>> - Remove temporary support code
>> - Merge jdk-24+17
>> - Relax 'must match' assertion in ppc's g1StoreN after limiting pinning bypass optimization
>> - Remove unnecessary reg-to-reg moves in aarch64's g1CompareAndX instructions
>> - Reintroduce matcher assert and limit pinning bypass optimization to non-shared EncodeP nodes
>> - Merge jdk-24+16
>> - Ensure that detected encode-and-store patterns are matched
>> - Merge remote-tracking branch 'snazarkin/arm32-JDK-8334060-g1-late-barrier-expansion' into JDK-8334060-g1-late-barrier-expansion
>> - ... and 43 more: https://git.openjdk.org/jdk/compare/0dc16d16...14483b83
>
> src/hotspot/cpu/riscv/gc/g1/g1_riscv.ad line 169:
>
>> 167: predicate(UseG1GC && n->as_LoadStore()->barrier_data() != 0);
>> 168: match(Set res (CompareAndExchangeP mem (Binary oldval newval)));
>> 169: effect(TEMP res, TEMP tmp1, TEMP tmp2);
>
> should `res` be `TEMP_DEF`?
It could, but the effect would be the same (see [JDK-8058880](https://bugs.openjdk.org/browse/JDK-8058880)). I went with `TEMP` for the x64 and aarch64 platforms for consistency with the analogous ZGC ADL code, see e.g. https://github.com/openjdk/jdk/blob/855c8a7def21025bc2fc47594f7285a55924c213/src/hotspot/cpu/aarch64/gc/z/z_aarch64.ad#L182-L204.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/19746#discussion_r1784358586
From mbaesken at openjdk.org Wed Oct 2 12:05:05 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 2 Oct 2024 12:05:05 GMT
Subject: RFR: 8336911: ZGC: Division by zero in heuristics after JDK-8332717
Message-ID: <rByxhEm3b3JZQVvugNz4KezLFPWc2NH_vOPaAl9Je2A=.703a5530-a302-43b2-a6bf-37f100c8bc79@github.com>
When running with ubsan enabled binaries, the following issue is reported,
e.g. in test
compiler/uncommontrap/TestDeoptOOM_ZGenerational.jtr
also in gc/z/TestSmallHeap.jtr
jdk/src/hotspot/share/gc/z/zDirector.cpp:537:84: runtime error: division by zero
#0 0x7f422495bd1f in calculate_young_to_old_worker_ratio src/hotspot/share/gc/z/zDirector.cpp:537
#1 0x7f422495bd1f in select_worker_threads src/hotspot/share/gc/z/zDirector.cpp:694
#2 0x7f42282a0d97 in select_worker_threads src/hotspot/share/gc/z/zDirector.cpp:689
#3 0x7f42282a0d97 in initial_workers src/hotspot/share/gc/z/zDirector.cpp:784
#4 0x7f42282a2485 in initial_workers src/hotspot/share/gc/z/zDirector.cpp:795
#5 0x7f42282a2485 in start_minor_gc src/hotspot/share/gc/z/zDirector.cpp:797
#6 0x7f42282a2485 in start_gc src/hotspot/share/gc/z/zDirector.cpp:826
#7 0x7f42282a2485 in ZDirector::run_thread() src/hotspot/share/gc/z/zDirector.cpp:912
#8 0x7f422840bdd8 in ZThread::run_service() src/hotspot/share/gc/z/zThread.cpp:29
#9 0x7f4225ab6979 in ConcurrentGCThread::run() src/hotspot/share/gc/shared/concurrentGCThread.cpp:48
#10 0x7f4227e1137a in Thread::call_run() src/hotspot/share/runtime/thread.cpp:225
#11 0x7f42274619b1 in thread_native_entry src/hotspot/os/linux/os_linux.cpp:858
#12 0x7f422c8d36e9 in start_thread (/lib64/libpthread.so.0+0xa6e9) (BuildId: 9a146bd267419cb6a8cf08d7c602953a0f2e12c5)
#13 0x7f422c1dc58e in clone (/lib64/libc.so.6+0x11858e) (BuildId: f2d1cb1ef49f8c47d43a4053910ba6137673ccce)
The division by 0 leads to 'infinity' on most of our platforms. So instead of relying on this behavior, we can add a small check and set 'infinity' for divisor == 0.
-------------
Commit messages:
- JDK-8336911
Changes: https://git.openjdk.org/jdk/pull/21304/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21304&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8336911
Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
Patch: https://git.openjdk.org/jdk/pull/21304.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/21304/head:pull/21304
PR: https://git.openjdk.org/jdk/pull/21304
From mli at openjdk.org Wed Oct 2 12:57:48 2024
From: mli at openjdk.org (Hamlin Li)
Date: Wed, 2 Oct 2024 12:57:48 GMT
Subject: RFR: 8334060: Implementation of Late Barrier Expansion for G1
[v27]
In-Reply-To: <7L7jYDlFa0WnVvgiyNHI9KZrcffYwNnBB899AuMS56Q=.40b031e7-07b8-4a15-b319-c53b38a17a49@github.com>
References: <ClHEkY_xzx37VNyLJr9F9eWSjXfdCRQcbmAhomsY7kU=.f4c3c125-caed-467f-b9fa-213d14f7908a@github.com>
<YYVkTHSwqRigZMpp3wjVjULgwfhawfXCszR2iKEPazA=.a7b37dee-07cd-45e9-aeed-0f90cba1268a@github.com>
<vb76mbxerbCHN5fmVs9ERapN0W1XeTdBzu8ncwCINLY=.89a1a645-8a60-44bd-aed3-3a18c6c378ab@github.com>
<7L7jYDlFa0WnVvgiyNHI9KZrcffYwNnBB899AuMS56Q=.40b031e7-07b8-4a15-b319-c53b38a17a49@github.com>
Message-ID: <StzxvdFi4HQirGwYzWf_0rUr0a75ANIZv_oUiNXs9-s=.1c4cc9c3-a02b-4328-b877-868bbd92b140@github.com>
On Wed, 2 Oct 2024 11:40:18 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:
> If `res` was not marked as `dont_preserve`, it would be included in the pre-barrier stub's preserve set (`BarrierStubC2::preserve_set()`) because it is live out of the entire AD instruction (as computed by `BarrierSetC2::compute_liveness_at_stubs()`).
Thanks for explanation!
I did not realize this, if that's the case, then it's good.
>> src/hotspot/cpu/riscv/gc/g1/g1_riscv.ad line 169:
>>
>>> 167: predicate(UseG1GC && n->as_LoadStore()->barrier_data() != 0);
>>> 168: match(Set res (CompareAndExchangeP mem (Binary oldval newval)));
>>> 169: effect(TEMP res, TEMP tmp1, TEMP tmp2);
>>
>> should `res` be `TEMP_DEF`?
>
> It could, but the effect would be the same (see [JDK-8058880](https://bugs.openjdk.org/browse/JDK-8058880)). I went with `TEMP` for the x64 and aarch64 platforms for consistency with the analogous ZGC ADL code, see e.g. https://github.com/openjdk/jdk/blob/855c8a7def21025bc2fc47594f7285a55924c213/src/hotspot/cpu/aarch64/gc/z/z_aarch64.ad#L182-L204.
I saw the riscv one in z_riscv.ad is: `effect(TEMP oldval_tmp, TEMP newval_tmp, TEMP tmp1, TEMP_DEF res);`, maybe it's good to change riscv one?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/19746#discussion_r1784479784
PR Review Comment: https://git.openjdk.org/jdk/pull/19746#discussion_r1784479526
From zgu at openjdk.org Wed Oct 2 14:26:15 2024
From: zgu at openjdk.org (Zhengyu Gu)
Date: Wed, 2 Oct 2024 14:26:15 GMT
Subject: RFR: 8339668: Parallel: Adopt PartialArrayState to consolidate
marking stack in Full GC [v3]
In-Reply-To: <SpLKo44sGBtJ8p0qZGh6NCl2ABe0ezh8l645vr6R3xM=.6615b830-f3aa-4c25-a0b4-1ab94a66b3d9@github.com>
References: <SpLKo44sGBtJ8p0qZGh6NCl2ABe0ezh8l645vr6R3xM=.6615b830-f3aa-4c25-a0b4-1ab94a66b3d9@github.com>
Message-ID: <nSAReHAx39zRmsqzYnOigXhW2ym0Undj-wXLHRdOhFs=.5b5d815b-1586-4553-91e9-ee1c96692c8a@github.com>
> Please review this patch that adopts `PartialArrayState`introduced by [JDK-8337709](https://bugs.openjdk.org/browse/JDK-8337709) to consolidate `_oop_task_queues` and `_objarray_task_queues` into single `_marking_stacks`.
>
> The change mirrors Kim's [JDK-8311163](https://bugs.openjdk.org/browse/JDK-8311163) work, therefore, there are methods can be consolidated and simplified, but I would like defer to a followup CR.
Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:
@tschatzl's ScannerTask changes
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/21089/files
- new: https://git.openjdk.org/jdk/pull/21089/files/15b998f6..fd756b3b
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=21089&range=02
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=21089&range=01-02
Stats: 55 lines in 5 files changed: 8 ins; 33 del; 14 mod
Patch: https://git.openjdk.org/jdk/pull/21089.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/21089/head:pull/21089
PR: https://git.openjdk.org/jdk/pull/21089
From zgu at openjdk.org Wed Oct 2 14:26:15 2024
From: zgu at openjdk.org (Zhengyu Gu)
Date: Wed, 2 Oct 2024 14:26:15 GMT
Subject: RFR: 8339668: Parallel: Adopt PartialArrayState to consolidate
marking stack in Full GC [v3]
In-Reply-To: <LcZYTU9GhTLKT5M7qP2aaSNTkvwtiHUomO_iXOF2lcI=.32fe8ae9-e216-4cbf-88e3-75f9a7846adc@github.com>
References: <SpLKo44sGBtJ8p0qZGh6NCl2ABe0ezh8l645vr6R3xM=.6615b830-f3aa-4c25-a0b4-1ab94a66b3d9@github.com>
<S9zZqt6yRZp1ELyjf9LfhU4CLWHiqafojYBJkiChliQ=.6cac8d1f-9168-40ed-bffa-ed54f52ae5f3@github.com>
<a378hYVJW-YoibWk9eeGPjdXw_ckAYOnKTJYJkA14fk=.6159375a-cb70-4204-8bc0-a849e091f9a3@github.com>
<C3EW0Ia7GVPWV32ul-43NnoRNiyx8_4xV8aLvyDVxZY=.0f94fbe1-f808-4417-947c-87c437ab2783@github.com>
<7ZdrpVVGG1hRYudHG_8VA8-lFIJGhSHy0YzmUgtFB9w=.246a5c89-7fb0-402d-92e8-3930c8d430cd@github.com>
<U8mUQUzQDuZC7JmaMvl_1JmUPStliL2B4w-EZulwRfg=.dfc89a5e-3a22-4c1d-8084-16f2b6ab1b52@github.com>
<LcZYTU9GhTLKT5M7qP2aaSNTkvwtiHUomO_iXOF2lcI=.32fe8ae9-e216-4cbf-88e3-75f9a7846adc@github.com>
Message-ID: <9lFtFPURRs-aTb2yCDbogZdvJnLd8bnH86SkWnY2WBw=.f5ef2cfe-3799-40ad-befc-5d8b532a2d4e@github.com>
On Wed, 2 Oct 2024 09:26:48 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:
>>>I ran into the same problem for G1 Full GC that @zhengyu123 has run into here. ScannerTask deals in
>> pointers to oop (and narrowOop). For the separate marking cases we have oops in the tasks.
>> I added a class just like this one in my work, except I put mine in gc/shared and gave it a different name
>> (OopScannerTask, which I don't love). Clearly some coalescing is needed there.
>>
>> The suggested patch just adds constructor to allow a regular `oop` and the associated getter. Internally `ScannerTask` uses a `void*` anyway.
>> Probably I am overlooking something trivial here why having an interface to store and retrieve an `oop` is not possible.... seems to pass very basic testing though.
>
> (Fwiw, https://github.com/tschatzl/jdk/tree/submit/pull/21089-recommendations-test with the suggested changes seems to pass GHA....)
I missed `ScannerTask` constructor change :-( the suggested changes also passed tier1 with Parallel GC.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/21089#discussion_r1784622909
From zgu at openjdk.org Wed Oct 2 14:34:36 2024
From: zgu at openjdk.org (Zhengyu Gu)
Date: Wed, 2 Oct 2024 14:34:36 GMT
Subject: RFR: 8339668: Parallel: Adopt PartialArrayState to consolidate
marking stack in Full GC [v3]
In-Reply-To: <J4aWJzB1XaehGjIvi9W0b0HEKvBSufLZsHQ6j7cxpNs=.c2f0303a-502c-4d6b-9555-c355002ed9c9@github.com>
References: <SpLKo44sGBtJ8p0qZGh6NCl2ABe0ezh8l645vr6R3xM=.6615b830-f3aa-4c25-a0b4-1ab94a66b3d9@github.com>
<S9zZqt6yRZp1ELyjf9LfhU4CLWHiqafojYBJkiChliQ=.6cac8d1f-9168-40ed-bffa-ed54f52ae5f3@github.com>
<J4aWJzB1XaehGjIvi9W0b0HEKvBSufLZsHQ6j7cxpNs=.c2f0303a-502c-4d6b-9555-c355002ed9c9@github.com>
Message-ID: <90BJHj19LxcGg3LnDvZWKeNwkToEBcKuC9TfHo8BQkY=.cca23a09-b629-4a63-a506-0a28506bd6c1@github.com>
On Wed, 2 Oct 2024 09:25:18 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:
>> src/hotspot/share/gc/parallel/psCompactionManager.hpp line 122:
>>
>>> 120: size_t _arrays_chunked;
>>> 121: size_t _array_chunks_processed;
>>> 122: #endif // TASKQUEUE_STATS
>>
>> This is a separate issue, but we did not add these counters when doing this change for g1 young gen. Filed [JDK-8341331](https://bugs.openjdk.org/browse/JDK-8341331) for that.
>>
>> There is a fair amount of code duplication (definition of members, management and printing) which is not great (but you mentioned it). For now I filed [JDK-8341332](https://bugs.openjdk.org/browse/JDK-8341332) for this, but I would really prefer some refactoring in this area in _this_ change.
>>
>> Initially I was kind of okay to do that separately, but the copy&paste seems too much.
>
> Here's a commit that only touches up the worst issues in this change: https://github.com/openjdk/jdk/commit/ab6e77ed909c13458a24e9663e830cfac9c4f18e
>
> (branch including the other suggestions so far: https://github.com/openjdk/jdk/compare/master...tschatzl:jdk:pull/21089-taskqueue-refactor)
>
> This makes the change a lot more readable imo (and in total reduces LOC count).
>
> The only missing improvement is to have the array statistics in the same log lines as the other statistics; that could be achieved by specializing the queues/queue set, but that requires the unified `ScannerTask` in the other change and more work.
I will take a shot of [JDK-8341332](https://bugs.openjdk.org/browse/JDK-8341332)
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/21089#discussion_r1784643598
From rkennke at openjdk.org Wed Oct 2 15:37:40 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 2 Oct 2024 15:37:40 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v29]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <migFoRhtd3kovSs2fRSGXzdh7vCpbyazoT5Gwzeu8ks=.4bd5afae-9598-4ab3-a7d8-737281236a4e@github.com>
> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>
> Main changes:
> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
> - Arrays will now store their length at offset 8.
> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...
Roman Kennke has updated the pull request incrementally with three additional commits since the last revision:
- Revert "Disable TestSplitPacks::test4a, failing on aarch64"
This reverts commit 059b1573db26d1d2902ca6dadc8413f445234c2a.
- Simplify object init code in interpreter
- Disable some vectorization tests that fail with +UCOH and UseSSE<=3
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/20677/files
- new: https://git.openjdk.org/jdk/pull/20677/files/059b1573..aea8f00c
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=28
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=27-28
Stats: 47 lines in 6 files changed: 18 ins; 13 del; 16 mod
Patch: https://git.openjdk.org/jdk/pull/20677.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677
PR: https://git.openjdk.org/jdk/pull/20677
From aboldtch at openjdk.org Wed Oct 2 15:52:41 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 2 Oct 2024 15:52:41 GMT
Subject: RFR: 8336911: ZGC: Division by zero in heuristics after
JDK-8332717
In-Reply-To: <rByxhEm3b3JZQVvugNz4KezLFPWc2NH_vOPaAl9Je2A=.703a5530-a302-43b2-a6bf-37f100c8bc79@github.com>
References: <rByxhEm3b3JZQVvugNz4KezLFPWc2NH_vOPaAl9Je2A=.703a5530-a302-43b2-a6bf-37f100c8bc79@github.com>
Message-ID: <TVdAZ6lUVILfil1wDSKBU-VcFyGEMuE0tWu1zIiL88Y=.80b704c2-8edf-4d15-af55-260a3a1e5a85@github.com>
On Wed, 2 Oct 2024 12:00:19 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:
> When running with ubsan enabled binaries, the following issue is reported,
> e.g. in test
> compiler/uncommontrap/TestDeoptOOM_ZGenerational.jtr
> also in gc/z/TestSmallHeap.jtr
>
>
> jdk/src/hotspot/share/gc/z/zDirector.cpp:537:84: runtime error: division by zero
> #0 0x7f422495bd1f in calculate_young_to_old_worker_ratio src/hotspot/share/gc/z/zDirector.cpp:537
> #1 0x7f422495bd1f in select_worker_threads src/hotspot/share/gc/z/zDirector.cpp:694
> #2 0x7f42282a0d97 in select_worker_threads src/hotspot/share/gc/z/zDirector.cpp:689
> #3 0x7f42282a0d97 in initial_workers src/hotspot/share/gc/z/zDirector.cpp:784
> #4 0x7f42282a2485 in initial_workers src/hotspot/share/gc/z/zDirector.cpp:795
> #5 0x7f42282a2485 in start_minor_gc src/hotspot/share/gc/z/zDirector.cpp:797
> #6 0x7f42282a2485 in start_gc src/hotspot/share/gc/z/zDirector.cpp:826
> #7 0x7f42282a2485 in ZDirector::run_thread() src/hotspot/share/gc/z/zDirector.cpp:912
> #8 0x7f422840bdd8 in ZThread::run_service() src/hotspot/share/gc/z/zThread.cpp:29
> #9 0x7f4225ab6979 in ConcurrentGCThread::run() src/hotspot/share/gc/shared/concurrentGCThread.cpp:48
> #10 0x7f4227e1137a in Thread::call_run() src/hotspot/share/runtime/thread.cpp:225
> #11 0x7f42274619b1 in thread_native_entry src/hotspot/os/linux/os_linux.cpp:858
> #12 0x7f422c8d36e9 in start_thread (/lib64/libpthread.so.0+0xa6e9) (BuildId: 9a146bd267419cb6a8cf08d7c602953a0f2e12c5)
> #13 0x7f422c1dc58e in clone (/lib64/libc.so.6+0x11858e) (BuildId: f2d1cb1ef49f8c47d43a4053910ba6137673ccce)
>
>
> The division by 0 leads to 'infinity' on most of our platforms. So instead of relying on this behavior, we can add a small check and set 'infinity' for divisor == 0.
I do not think `infinity` is the solution here. There are more problems with the heuristics when no young collection has reclaimed any memory.
I added a comment about this in an earlier PR (JDK-8339648 / #20888) https://github.com/openjdk/jdk/pull/20888#discussion_r1758502503.
I proposed a solution to this specific issue that makes more sense to me, and avoid the NaN issues here. But will have to talk it over.
Regardless I think we need to do an overhaul of this code to handle the extreme case of no GC having reclaimed any memory.
_Also this must have been an issue before JDK-8332717 as well?_
src/hotspot/share/gc/z/zDirector.cpp line 539:
> 537: const double current_old_bytes_freed_per_gc_time = double(reclaimed_per_old_gc) / double(old_gc_time);
> 538: const double old_vs_young_efficiency_ratio = current_young_bytes_freed_per_gc_time == 0 ? std::numeric_limits<double>::infinity()
> 539: : current_old_bytes_freed_per_gc_time / current_young_bytes_freed_per_gc_time;
I think returning infinity here will cause problems with NaN down the line. It is also unclear what this means if both are `0`. To me something like the following makes sense. But I will discus this with my team.
Suggestion:
if (current_young_bytes_freed_per_gc_time == 0.0) {
if (current_old_bytes_freed_per_gc_time == 0.0) {
// Neither young nor old collections have reclaimed any memory.
// Give them equal priority.
return 1.0;
}
// Only old collections have reclaimed memory.
// Prioritize old.
return ZOldGCThreads;
}
-------------
Changes requested by aboldtch (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/21304#pullrequestreview-2343363648
PR Review Comment: https://git.openjdk.org/jdk/pull/21304#discussion_r1784803080
From kdnilsen at openjdk.org Wed Oct 2 16:47:37 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 2 Oct 2024 16:47:37 GMT
Subject: RFR: 8341379: Shenandoah: Improve lock contention during cleanup
In-Reply-To: <5GMjFWaMjkSuxhPJ8TYJyw_LYdFfhJWrySSaRUjSNq4=.0ee7f896-35b2-43aa-a243-418b1ffb50b0@github.com>
References: <5GMjFWaMjkSuxhPJ8TYJyw_LYdFfhJWrySSaRUjSNq4=.0ee7f896-35b2-43aa-a243-418b1ffb50b0@github.com>
Message-ID: <_V337A0U9_TeBPs26Q6QyOfvmYoaqxOxl3MaRrhI16s=.dc7e86a3-a8ff-4617-995c-1417cac18bb8@github.com>
On Thu, 26 Sep 2024 21:08:11 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:
> This change improves the efficiency of cleaning up (recycling) regions that have been trashed by GC effort. The affected code runs at the end of FinalMark to reclaim immediate garbage. It runs at the end of FinalUpdateRefs to reclaim the regions that comprised the collection set, from which all live objects have now been evacuated.
>
> Efficiency improvements include:
> 1. Rather than invoking the os (while holding the Heap lock) to obtain the time twice for every region recycled, we invoke the os only once for each batch of 32 regions that are to be processed.
> 2. Rather than enforcing that the loop runs no longer than 30 us, we refrain from starting a second batch of regions if more than 8 us has passed since the preceding batch was processed.
>
> Below, each trial runs for 1 hour, processing 28,000 transactions per second.
>
> Without this change, latency for 4 un-named business services is represented by the following chart:
> 
>
> With this change, latency for the same services is much better:
> 
>
> A comparison of the two is provided by the following:
> 
I've got a bit more information about the differences in behavior between no-batch trial 1 and trial 2:
1. Note that trial2 has much worse p9999 latency than trial1
2. The difference is NOT safepoint behavior. Trial 1 actually had more safepoints that lasted longer than 1 ms, with the longest lasting 5.658220ms. The longest safepoint in trial 2 was 3.420009 ms.
3. There is evidence to suggest that the difference stems from concurrent cleanup: trial1 had 1 concurrent cleanup event taking more than 1 ms, with time of 1.142 ms, average cleanup time of 85.1 us; trial 3 had 3 concurrent cleanup events taking more than 1 ms, with the max of 1.377 ms, average cleanup time of 85.8 us.
4. For comparison, the three runs with this fix had an average concurrent cleanup event time of 69.8 us.
Qualitative assessment:
This fix allows concurrent cleanup to happen on average in 18.3% less time. This means it is less likely to collide with a mutator thread in access to the shared heap lock.
When a collision does occur, it is resolved more quickly, allowing the the mutator to proceed in no more than 8 us plus the time to process one batch of 32 regions rather than having to wait a max of 30 us.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/21211#issuecomment-2389135297
From coleenp at openjdk.org Wed Oct 2 17:37:54 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 2 Oct 2024 17:37:54 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v29]
In-Reply-To: <migFoRhtd3kovSs2fRSGXzdh7vCpbyazoT5Gwzeu8ks=.4bd5afae-9598-4ab3-a7d8-737281236a4e@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<migFoRhtd3kovSs2fRSGXzdh7vCpbyazoT5Gwzeu8ks=.4bd5afae-9598-4ab3-a7d8-737281236a4e@github.com>
Message-ID: <b0uXxDtd9PwrZvPhuZyn24UTaA8G4icxiQ5pX7qL4Bo=.c6c662fa-cae9-4f4c-885d-62ae9d3fe697@github.com>
On Wed, 2 Oct 2024 15:37:40 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>>
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>>
>> Main changes:
>> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>> - Arrays will now store their length at offset 8.
>> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with three additional commits since the last revision:
>
> - Revert "Disable TestSplitPacks::test4a, failing on aarch64"
>
> This reverts commit 059b1573db26d1d2902ca6dadc8413f445234c2a.
> - Simplify object init code in interpreter
> - Disable some vectorization tests that fail with +UCOH and UseSSE<=3
Thanks for making this change. I've reviewed runtime, oops and metaspace code. It looks good.
-------------
Marked as reviewed by coleenp (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/20677#pullrequestreview-2343632318
From wkemper at openjdk.org Wed Oct 2 18:26:35 2024
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 2 Oct 2024 18:26:35 GMT
Subject: RFR: 8341379: Shenandoah: Improve lock contention during cleanup
In-Reply-To: <5GMjFWaMjkSuxhPJ8TYJyw_LYdFfhJWrySSaRUjSNq4=.0ee7f896-35b2-43aa-a243-418b1ffb50b0@github.com>
References: <5GMjFWaMjkSuxhPJ8TYJyw_LYdFfhJWrySSaRUjSNq4=.0ee7f896-35b2-43aa-a243-418b1ffb50b0@github.com>
Message-ID: <LFYBkILEH4Hgox_fIxyXWvN-RQO2Lbvcn1N7CENSluw=.17b563cf-c328-46a6-8dff-dfdfae0a3c02@github.com>
On Thu, 26 Sep 2024 21:08:11 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:
> This change improves the efficiency of cleaning up (recycling) regions that have been trashed by GC effort. The affected code runs at the end of FinalMark to reclaim immediate garbage. It runs at the end of FinalUpdateRefs to reclaim the regions that comprised the collection set, from which all live objects have now been evacuated.
>
> Efficiency improvements include:
> 1. Rather than invoking the os (while holding the Heap lock) to obtain the time twice for every region recycled, we invoke the os only once for each batch of 32 regions that are to be processed.
> 2. Rather than enforcing that the loop runs no longer than 30 us, we refrain from starting a second batch of regions if more than 8 us has passed since the preceding batch was processed.
>
> Below, each trial runs for 1 hour, processing 28,000 transactions per second.
>
> Without this change, latency for 4 un-named business services is represented by the following chart:
> 
>
> With this change, latency for the same services is much better:
> 
>
> A comparison of the two is provided by the following:
> 
Looks good. Appreciate the comprehensive analysis.
-------------
Marked as reviewed by wkemper (Committer).
PR Review: https://git.openjdk.org/jdk/pull/21211#pullrequestreview-2343780503
From rcastanedalo at openjdk.org Wed Oct 2 19:43:50 2024
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Wed, 2 Oct 2024 19:43:50 GMT
Subject: RFR: 8334060: Implementation of Late Barrier Expansion for G1
[v27]
In-Reply-To: <StzxvdFi4HQirGwYzWf_0rUr0a75ANIZv_oUiNXs9-s=.1c4cc9c3-a02b-4328-b877-868bbd92b140@github.com>
References: <ClHEkY_xzx37VNyLJr9F9eWSjXfdCRQcbmAhomsY7kU=.f4c3c125-caed-467f-b9fa-213d14f7908a@github.com>
<YYVkTHSwqRigZMpp3wjVjULgwfhawfXCszR2iKEPazA=.a7b37dee-07cd-45e9-aeed-0f90cba1268a@github.com>
<vb76mbxerbCHN5fmVs9ERapN0W1XeTdBzu8ncwCINLY=.89a1a645-8a60-44bd-aed3-3a18c6c378ab@github.com>
<7L7jYDlFa0WnVvgiyNHI9KZrcffYwNnBB899AuMS56Q=.40b031e7-07b8-4a15-b319-c53b38a17a49@github.com>
<StzxvdFi4HQirGwYzWf_0rUr0a75ANIZv_oUiNXs9-s=.1c4cc9c3-a02b-4328-b877-868bbd92b140@github.com>
Message-ID: <N4ocPHd0KbEF_VZngD6KkfUgDx6PH0I5IwT09MHfiyU=.955d49c1-f633-4734-8d6b-3a272076d8be@github.com>
On Wed, 2 Oct 2024 12:55:13 GMT, Hamlin Li <mli at openjdk.org> wrote:
>> It could, but the effect would be the same (see [JDK-8058880](https://bugs.openjdk.org/browse/JDK-8058880)). I went with `TEMP` for the x64 and aarch64 platforms for consistency with the analogous ZGC ADL code, see e.g. https://github.com/openjdk/jdk/blob/855c8a7def21025bc2fc47594f7285a55924c213/src/hotspot/cpu/aarch64/gc/z/z_aarch64.ad#L182-L204.
>
> I saw the riscv one in z_riscv.ad is: `effect(TEMP oldval_tmp, TEMP newval_tmp, TEMP tmp1, TEMP_DEF res);`, maybe it's good to change riscv one?
I suggest to postpone these types of refactorings to follow-up enhancements, given that the pull request in its current form is stable, thoroughly tested, and approved by reviewers. I intend to integrate it within the following 24 hours, provided final test results look good.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/19746#discussion_r1785135652
From xpeng at openjdk.org Wed Oct 2 19:47:34 2024
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Wed, 2 Oct 2024 19:47:34 GMT
Subject: RFR: 8341379: Shenandoah: Improve lock contention during cleanup
In-Reply-To: <5GMjFWaMjkSuxhPJ8TYJyw_LYdFfhJWrySSaRUjSNq4=.0ee7f896-35b2-43aa-a243-418b1ffb50b0@github.com>
References: <5GMjFWaMjkSuxhPJ8TYJyw_LYdFfhJWrySSaRUjSNq4=.0ee7f896-35b2-43aa-a243-418b1ffb50b0@github.com>
Message-ID: <zq_j_unmN8FkRruxA_NbfzeHi-XI28-EzWLQRNDNTtw=.f2d78be8-416f-46c7-9585-c7dae80806b4@github.com>
On Thu, 26 Sep 2024 21:08:11 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:
> This change improves the efficiency of cleaning up (recycling) regions that have been trashed by GC effort. The affected code runs at the end of FinalMark to reclaim immediate garbage. It runs at the end of FinalUpdateRefs to reclaim the regions that comprised the collection set, from which all live objects have now been evacuated.
>
> Efficiency improvements include:
> 1. Rather than invoking the os (while holding the Heap lock) to obtain the time twice for every region recycled, we invoke the os only once for each batch of 32 regions that are to be processed.
> 2. Rather than enforcing that the loop runs no longer than 30 us, we refrain from starting a second batch of regions if more than 8 us has passed since the preceding batch was processed.
>
> Below, each trial runs for 1 hour, processing 28,000 transactions per second.
>
> Without this change, latency for 4 un-named business services is represented by the following chart:
> 
>
> With this change, latency for the same services is much better:
> 
>
> A comparison of the two is provided by the following:
> 
Marked as reviewed by xpeng (Author).
Looks good to me, thanks for the detailed analysis!
My understanding: the major benefits from this PR:
1. Minimize the cost on system call os::javaTimeNanos()
2. Not to start next batch if next it has hold the heap lock over 8us when current batch finishes.
Maybe we should calculate the next batch size based on the reminding time and speed after a batch, the assumption 200ns/region is unlikely to be true for all hardwares, in the worse case, it may hold the lock for up to 15us~16us,
-------------
PR Review: https://git.openjdk.org/jdk/pull/21211#pullrequestreview-2343932607
PR Comment: https://git.openjdk.org/jdk/pull/21211#issuecomment-2389542138
From kdnilsen at openjdk.org Wed Oct 2 19:55:35 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 2 Oct 2024 19:55:35 GMT
Subject: RFR: 8341379: Shenandoah: Improve lock contention during cleanup
In-Reply-To: <5GMjFWaMjkSuxhPJ8TYJyw_LYdFfhJWrySSaRUjSNq4=.0ee7f896-35b2-43aa-a243-418b1ffb50b0@github.com>
References: <5GMjFWaMjkSuxhPJ8TYJyw_LYdFfhJWrySSaRUjSNq4=.0ee7f896-35b2-43aa-a243-418b1ffb50b0@github.com>
Message-ID: <V37pp-DnpiMtgXG9CboWMuh29cWEUOm5xKj6mMxb2pQ=.fe5f74f0-a452-4ca1-b8af-39fd8509efb8@github.com>
On Thu, 26 Sep 2024 21:08:11 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:
> This change improves the efficiency of cleaning up (recycling) regions that have been trashed by GC effort. The affected code runs at the end of FinalMark to reclaim immediate garbage. It runs at the end of FinalUpdateRefs to reclaim the regions that comprised the collection set, from which all live objects have now been evacuated.
>
> Efficiency improvements include:
> 1. Rather than invoking the os (while holding the Heap lock) to obtain the time twice for every region recycled, we invoke the os only once for each batch of 32 regions that are to be processed.
> 2. Rather than enforcing that the loop runs no longer than 30 us, we refrain from starting a second batch of regions if more than 8 us has passed since the preceding batch was processed.
>
> Below, each trial runs for 1 hour, processing 28,000 transactions per second.
>
> Without this change, latency for 4 un-named business services is represented by the following chart:
> 
>
> With this change, latency for the same services is much better:
> 
>
> A comparison of the two is provided by the following:
> 
It's hard to "predict" the cost of the next batch. It depends on how many of the regions within the batch might have already been recycled by on-demand actions of mutator threads. In general, its seems the cost of a batch is typically less than 4 us, because I gathered some stats with instrumentation (no longer present) that says typical number of batches processed between yield is 3. The first two batches, including the time to yield and acquire lock, must have completed in less than 8 us, or we would not have allowed ourself to start another batch.
True, a different hardware might take more or less time to process batch, but I don't think the behavior will be too sensitive to this. If it takes less than 2.66 us, then we might get an average of 4 batches processed between yields. If it takes longer than 8 us, we'll only get 1 batch processed between yields. But we'll still be making good progress on recycling the trashed regions while remaining very responsive to mutator needs to access the heap lock.
Thanks for reviews.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/21211#issuecomment-2389557309
PR Comment: https://git.openjdk.org/jdk/pull/21211#issuecomment-2389559197
From phh at openjdk.org Wed Oct 2 19:56:36 2024
From: phh at openjdk.org (Paul Hohensee)
Date: Wed, 2 Oct 2024 19:56:36 GMT
Subject: RFR: 8332697: ubsan: shenandoahSimpleBitMap.inline.hpp:68:23:
runtime error: signed integer overflow: -9223372036854775808 - 1 cannot be
represented in type 'long int' [v4]
In-Reply-To: <YpHRzYhZ--JxHSZd8AewEqqPNp_Y1NPW4AYunaPOSYE=.29f4c9d6-1a58-4728-9f1b-1cec4fbf38c8@github.com>
References: <I8sOa0g-PbjrI3R9yuuosgg83kNah0m0wiLbsNN8IFM=.495943c2-9206-44c5-abb1-4f68cd98b0c5@github.com>
<YpHRzYhZ--JxHSZd8AewEqqPNp_Y1NPW4AYunaPOSYE=.29f4c9d6-1a58-4728-9f1b-1cec4fbf38c8@github.com>
Message-ID: <BZ2VMlFF2hi7waSqhiuskV9xFtJokL8HF7tGY0VviA8=.a6fc0f98-a243-4159-b87a-927d79e9aaf9@github.com>
On Tue, 1 Oct 2024 21:44:48 GMT, William Kemper <wkemper at openjdk.org> wrote:
>> Use a template version of `right_n_bits` to use the same type for minuend and subtrahend.
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
>
> Inline unnecessary usages of right_n_bits
Not using right_n_bits() at works for me.
-------------
Marked as reviewed by phh (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/21236#pullrequestreview-2343946776
From kdnilsen at openjdk.org Wed Oct 2 20:09:38 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 2 Oct 2024 20:09:38 GMT
Subject: RFR: 8332697: ubsan: shenandoahSimpleBitMap.inline.hpp:68:23:
runtime error: signed integer overflow: -9223372036854775808 - 1 cannot be
represented in type 'long int' [v4]
In-Reply-To: <YpHRzYhZ--JxHSZd8AewEqqPNp_Y1NPW4AYunaPOSYE=.29f4c9d6-1a58-4728-9f1b-1cec4fbf38c8@github.com>
References: <I8sOa0g-PbjrI3R9yuuosgg83kNah0m0wiLbsNN8IFM=.495943c2-9206-44c5-abb1-4f68cd98b0c5@github.com>
<YpHRzYhZ--JxHSZd8AewEqqPNp_Y1NPW4AYunaPOSYE=.29f4c9d6-1a58-4728-9f1b-1cec4fbf38c8@github.com>
Message-ID: <55A-Hu86kNPGpQ24KiuIeefJ8ewqt2AJQXt-rYZTxbA=.6e61a005-4511-41fb-ace4-84fec3875cf9@github.com>
On Tue, 1 Oct 2024 21:44:48 GMT, William Kemper <wkemper at openjdk.org> wrote:
>> Use a template version of `right_n_bits` to use the same type for minuend and subtrahend.
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
>
> Inline unnecessary usages of right_n_bits
Thanks.
-------------
Marked as reviewed by kdnilsen (Author).
PR Review: https://git.openjdk.org/jdk/pull/21236#pullrequestreview-2343969312
From ysr at openjdk.org Wed Oct 2 21:03:36 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 2 Oct 2024 21:03:36 GMT
Subject: RFR: 8332697: ubsan: shenandoahSimpleBitMap.inline.hpp:68:23:
runtime error: signed integer overflow: -9223372036854775808 - 1 cannot be
represented in type 'long int' [v4]
In-Reply-To: <YpHRzYhZ--JxHSZd8AewEqqPNp_Y1NPW4AYunaPOSYE=.29f4c9d6-1a58-4728-9f1b-1cec4fbf38c8@github.com>
References: <I8sOa0g-PbjrI3R9yuuosgg83kNah0m0wiLbsNN8IFM=.495943c2-9206-44c5-abb1-4f68cd98b0c5@github.com>
<YpHRzYhZ--JxHSZd8AewEqqPNp_Y1NPW4AYunaPOSYE=.29f4c9d6-1a58-4728-9f1b-1cec4fbf38c8@github.com>
Message-ID: <f92cOuiD0vvA52S1PP3JTiy0hn_B1HaFDd_0wtbRx4o=.6c239716-4ebb-4889-ad49-c9820248b0d5@github.com>
On Tue, 1 Oct 2024 21:44:48 GMT, William Kemper <wkemper at openjdk.org> wrote:
>> Use a template version of `right_n_bits` to use the same type for minuend and subtrahend.
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
>
> Inline unnecessary usages of right_n_bits
src/hotspot/share/gc/shenandoah/shenandoahSimpleBitMap.inline.hpp line 33:
> 31: if (bit_number >= BitsPerWord) {
> 32: return -1;
> 33: }
When would we call here with `bit_number >= BitsPerWord` ? If never, may be we assert that?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/21236#discussion_r1785246043
From wkemper at openjdk.org Wed Oct 2 21:15:39 2024
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 2 Oct 2024 21:15:39 GMT
Subject: RFR: 8332697: ubsan: shenandoahSimpleBitMap.inline.hpp:68:23:
runtime error: signed integer overflow: -9223372036854775808 - 1 cannot be
represented in type 'long int' [v4]
In-Reply-To: <f92cOuiD0vvA52S1PP3JTiy0hn_B1HaFDd_0wtbRx4o=.6c239716-4ebb-4889-ad49-c9820248b0d5@github.com>
References: <I8sOa0g-PbjrI3R9yuuosgg83kNah0m0wiLbsNN8IFM=.495943c2-9206-44c5-abb1-4f68cd98b0c5@github.com>
<YpHRzYhZ--JxHSZd8AewEqqPNp_Y1NPW4AYunaPOSYE=.29f4c9d6-1a58-4728-9f1b-1cec4fbf38c8@github.com>
<f92cOuiD0vvA52S1PP3JTiy0hn_B1HaFDd_0wtbRx4o=.6c239716-4ebb-4889-ad49-c9820248b0d5@github.com>
Message-ID: <pjKaTG08MVdZLGvIc_AmG6rg9arm5-n56B_ArDhGFOI=.b2110700-87e5-4c35-9d73-f25d913e2c00@github.com>
On Wed, 2 Oct 2024 21:01:20 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:
>> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
>>
>> Inline unnecessary usages of right_n_bits
>
> src/hotspot/share/gc/shenandoah/shenandoahSimpleBitMap.inline.hpp line 33:
>
>> 31: if (bit_number >= BitsPerWord) {
>> 32: return -1;
>> 33: }
>
> When would we call here with `bit_number >= BitsPerWord` ? If never, may be we assert that?
It's called with `bit_number == BitsPerWord` (I tried an assertion first).
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/21236#discussion_r1785256564
From phh at openjdk.org Wed Oct 2 21:16:37 2024
From: phh at openjdk.org (Paul Hohensee)
Date: Wed, 2 Oct 2024 21:16:37 GMT
Subject: RFR: 8341379: Shenandoah: Improve lock contention during cleanup
In-Reply-To: <5GMjFWaMjkSuxhPJ8TYJyw_LYdFfhJWrySSaRUjSNq4=.0ee7f896-35b2-43aa-a243-418b1ffb50b0@github.com>
References: <5GMjFWaMjkSuxhPJ8TYJyw_LYdFfhJWrySSaRUjSNq4=.0ee7f896-35b2-43aa-a243-418b1ffb50b0@github.com>
Message-ID: <LWzg5a5i_FvDV2vXbx586FJT53LmkgyE4sszTf1RExU=.5d8f5959-8bdd-4a64-a515-fa6aa5ae06d6@github.com>
On Thu, 26 Sep 2024 21:08:11 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:
> This change improves the efficiency of cleaning up (recycling) regions that have been trashed by GC effort. The affected code runs at the end of FinalMark to reclaim immediate garbage. It runs at the end of FinalUpdateRefs to reclaim the regions that comprised the collection set, from which all live objects have now been evacuated.
>
> Efficiency improvements include:
> 1. Rather than invoking the os (while holding the Heap lock) to obtain the time twice for every region recycled, we invoke the os only once for each batch of 32 regions that are to be processed.
> 2. Rather than enforcing that the loop runs no longer than 30 us, we refrain from starting a second batch of regions if more than 8 us has passed since the preceding batch was processed.
>
> Below, each trial runs for 1 hour, processing 28,000 transactions per second.
>
> Without this change, latency for 4 un-named business services is represented by the following chart:
> 
>
> With this change, latency for the same services is much better:
> 
>
> A comparison of the two is provided by the following:
> 
I worry that we're hard-coding assumed task durations. I'm ok with this PR as it is, but I suggest we add a facility to GC initialization that does dummy tasks such as this in order to get somewhat-realistic times for use in this kind of situation.
-------------
Marked as reviewed by phh (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/21211#pullrequestreview-2344117544
From xpeng at openjdk.org Wed Oct 2 21:29:35 2024
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Wed, 2 Oct 2024 21:29:35 GMT
Subject: RFR: 8341379: Shenandoah: Improve lock contention during cleanup
In-Reply-To: <5GMjFWaMjkSuxhPJ8TYJyw_LYdFfhJWrySSaRUjSNq4=.0ee7f896-35b2-43aa-a243-418b1ffb50b0@github.com>
References: <5GMjFWaMjkSuxhPJ8TYJyw_LYdFfhJWrySSaRUjSNq4=.0ee7f896-35b2-43aa-a243-418b1ffb50b0@github.com>
Message-ID: <HQ4qL0ad8aby-eBgvvW122kEX7jRBskQxdGW2L7sLmg=.707d57f7-80a0-4227-800d-6ce5597f3878@github.com>
On Thu, 26 Sep 2024 21:08:11 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:
> This change improves the efficiency of cleaning up (recycling) regions that have been trashed by GC effort. The affected code runs at the end of FinalMark to reclaim immediate garbage. It runs at the end of FinalUpdateRefs to reclaim the regions that comprised the collection set, from which all live objects have now been evacuated.
>
> Efficiency improvements include:
> 1. Rather than invoking the os (while holding the Heap lock) to obtain the time twice for every region recycled, we invoke the os only once for each batch of 32 regions that are to be processed.
> 2. Rather than enforcing that the loop runs no longer than 30 us, we refrain from starting a second batch of regions if more than 8 us has passed since the preceding batch was processed.
>
> Below, each trial runs for 1 hour, processing 28,000 transactions per second.
>
> Without this change, latency for 4 un-named business services is represented by the following chart:
> 
>
> With this change, latency for the same services is much better:
> 
>
> A comparison of the two is provided by the following:
> 
src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 935:
> 933: // Avoid another call to javaTimeNanos() if we already know time at which last batch ended
> 934: batch_start_time = batch_end_time;
> 935: const jlong deadline = batch_start_time + deadline_ns;
Nit: Maybe before taking the heap lock?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/21211#discussion_r1785267490
From sviswanathan at openjdk.org Wed Oct 2 21:31:52 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Wed, 2 Oct 2024 21:31:52 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v26]
In-Reply-To: <TSxYcKKfAdx7SsVcq6iwiySCLlkoVbXQO7a25vsiG4k=.29e59a6c-b8e0-42e9-8bdd-cc8ca23df146@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<fEpfi4CzTFr1Pl-IyOAVyHNXWlVz33lHKQyzVY0kBc8=.cc39355b-ee7a-4118-952a-28e4184eec84@github.com>
<DKuidQyyiiJOsrerLCeziselVyG9Ztpzsyc64ZNjlI4=.722fc4f7-d7cc-49df-9d82-5c1094508f74@github.com>
<hdttC4LhHE6y6Nbq0jjJwxxF4W0hTfJLK_siODDCBkM=.1667f495-fcd9-4b7f-8d58-24e27665eeb3@github.com>
<fWSdSqQfhOrGpFoExiaO4L-UDtR90_t0gRxp9YBO3_c=.0173618e-f392-4921-8fae-39d44b24de08@github.com>
<6PTWMepIDuZDdPfN3xNKV1vqUyO_R4yCSeiSTpYIyyQ=.61a5b462-7114-4385-a6d7-40e5c7b0005d@github.com>
<C5LwWrsa-VO87kdm_sYuisTGMsHoxv4Eoe0QikdkusE=.63b0993c-86c8-4ef6-a3cf-bc8a67e10815@github.com>
<WOlTJMNHCr_Kk69sEIUwCVI3ZbiRlckY4TSBRfL7zoA=.1a4c59f1-a000-4d9f-abbc-36b24ed5105e@github.com>
<UjwpWz9Y3W8WRzYHZmDk9EvoiLSCZG1aai5oASGtDKA=.68cab6dd-e67d-4651-a9c9-75dccf42d85f@github.com>
<l_7f8gGpIdG9H3Ini5vHWruIa0oDi7fkn2Lz5thDI5c=.969b804f-bae2-48e1-9c44-e631d90037e7@github.com>
<BtvwMUG5tcy_zU4tRG3Q5VVw08qE_3gSE35
wCxlDnj4=.954353e5-cab2-48f4-b0f2-5852e586ba20@github.com>
<zi8MM6qUWhvxPSyb3ewa3baXWhmDIDlut2uYUQmWvcw=.7b32fa42-7a3f-43bb-8f15-fe6b8e66c49b@github.com>
<TSxYcKKfAdx7SsVcq6iwiySCLlkoVbXQO7a25vsiG4k=.29e59a6c-b8e0-42e9-8bdd-cc8ca23df146@github.com>
Message-ID: <YpG7vj6W3LnbhvvRhaeLmLeBzc_vlzlzmD74xVu1FQY=.14a57f09-74c1-4b2f-962c-c923961c067c@github.com>
On Mon, 30 Sep 2024 17:48:13 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
>> Wait a second, I've probably not been clear. `UseCompactObjectHeaders` is slated to become *on by default* and then slated to go away. That means that array base offets <= 16 bytes will become the default. The generated code will be something like:
>>
>>
>> if (haystack_len <= 8) {
>> // Copy 8 bytes onto stack
>> } else if (haystack_len <= 16) {
>> // Copy 16 bytes onto stack
>> } else {
>> // Copy 32 bytes onto stack
>> }
>>
>>
>> So that is 2 branches in this prologue code instead of originally 1.
>>
>> However, I just noticed that what I proposed is not enough. Consider what happens when haystack_len is 17. This would take the last case and copy 32 bytes. But we only have 17+8=25 bytes that we can guarantee to be available for copying. If this happens to be the array at the very beginning of the heap (very rare/unlikely), this would segfault.
>>
>> I think I need to mull over it some more to come up with a correct fix.
>
> I changed the header<16 version to be a small loop: https://github.com/rkennke/jdk/commit/bcba264ea5c15581647933db1163ca1dae39b6c5
>
> The idea is the same as before, except it's made as a small loop with a maximum of 4 iterations (backward-branches), and it copies 8 bytes at a time, such that 1. it may copy up to 7 bytes that precede the array and 2. doesn't run over the end of the array (which would potentially crash).
>
> I am not sure if using XMM_TMP1 and XMM_TMP2 there is ok, or if it would encode better to use one of the regular registers.?
>
> Also, this new implementation could simply replace the old one, instead of being an alternative. I am not sure if if would make any difference performance-wise.
@rkennke The small loop looks to me that it will run over the end of the array.
Say the haystack_len is 7, the index below would be 0 after the shrq instruction, and the movq(XMM_TMP1, Address(haystack, index, Address::times_8)) in the loop will read 8 bytes i.e. one byte past the end of the array:
// num_words (zero-based) = (haystack_len - 1) / 8;
__ movq(index, haystack_len);
__ subq(index, 1);
__ shrq(index, LogBytesPerWord);
__ bind(L_loop);
__ movq(XMM_TMP1, Address(haystack, index, Address::times_8));
__ movq(Address(rsp, index, Address::times_8), XMM_TMP1);
__ subq(index, 1);
__ jcc(Assembler::positive, L_loop);
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1785269849
From wkemper at openjdk.org Wed Oct 2 22:56:42 2024
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 2 Oct 2024 22:56:42 GMT
Subject: Integrated: 8332697: ubsan: shenandoahSimpleBitMap.inline.hpp:68:23:
runtime error: signed integer overflow: -9223372036854775808 - 1
cannot be represented in type 'long int'
In-Reply-To: <I8sOa0g-PbjrI3R9yuuosgg83kNah0m0wiLbsNN8IFM=.495943c2-9206-44c5-abb1-4f68cd98b0c5@github.com>
References: <I8sOa0g-PbjrI3R9yuuosgg83kNah0m0wiLbsNN8IFM=.495943c2-9206-44c5-abb1-4f68cd98b0c5@github.com>
Message-ID: <LhxGzmvIeoFbGRegpst5fOTg08cXgU4uKhhxqrbi5jE=.ca1a57b8-d28e-4d92-8d79-8734682e395b@github.com>
On Fri, 27 Sep 2024 21:29:37 GMT, William Kemper <wkemper at openjdk.org> wrote:
> Use a template version of `right_n_bits` to use the same type for minuend and subtrahend.
This pull request has now been integrated.
Changeset: 57c1db58
Author: William Kemper <wkemper at openjdk.org>
URL: https://git.openjdk.org/jdk/commit/57c1db5843db5f2c864318f3234767f436a836e3
Stats: 34 lines in 3 files changed: 7 ins; 0 del; 27 mod
8332697: ubsan: shenandoahSimpleBitMap.inline.hpp:68:23: runtime error: signed integer overflow: -9223372036854775808 - 1 cannot be represented in type 'long int'
Reviewed-by: phh, kdnilsen
-------------
PR: https://git.openjdk.org/jdk/pull/21236
From kdnilsen at openjdk.org Wed Oct 2 23:09:36 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 2 Oct 2024 23:09:36 GMT
Subject: RFR: 8341379: Shenandoah: Improve lock contention during cleanup
In-Reply-To: <5GMjFWaMjkSuxhPJ8TYJyw_LYdFfhJWrySSaRUjSNq4=.0ee7f896-35b2-43aa-a243-418b1ffb50b0@github.com>
References: <5GMjFWaMjkSuxhPJ8TYJyw_LYdFfhJWrySSaRUjSNq4=.0ee7f896-35b2-43aa-a243-418b1ffb50b0@github.com>
Message-ID: <hfnUgczQ2rq-W0oc6P9cFGwy9p65BgAk5HNfQCy8-oc=.fef39e73-22e3-48f7-bc6b-60f9214879c3@github.com>
On Thu, 26 Sep 2024 21:08:11 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:
> This change improves the efficiency of cleaning up (recycling) regions that have been trashed by GC effort. The affected code runs at the end of FinalMark to reclaim immediate garbage. It runs at the end of FinalUpdateRefs to reclaim the regions that comprised the collection set, from which all live objects have now been evacuated.
>
> Efficiency improvements include:
> 1. Rather than invoking the os (while holding the Heap lock) to obtain the time twice for every region recycled, we invoke the os only once for each batch of 32 regions that are to be processed.
> 2. Rather than enforcing that the loop runs no longer than 30 us, we refrain from starting a second batch of regions if more than 8 us has passed since the preceding batch was processed.
>
> Below, each trial runs for 1 hour, processing 28,000 transactions per second.
>
> Without this change, latency for 4 un-named business services is represented by the following chart:
> 
>
> With this change, latency for the same services is much better:
> 
>
> A comparison of the two is provided by the following:
> 
I'll modify the code to adjust for current localized behavior of the host computer. (e.g. not hard-code assumptions about task durations.)
-------------
PR Comment: https://git.openjdk.org/jdk/pull/21211#issuecomment-2389933286
From kdnilsen at openjdk.org Wed Oct 2 23:09:37 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 2 Oct 2024 23:09:37 GMT
Subject: RFR: 8341379: Shenandoah: Improve lock contention during cleanup
In-Reply-To: <HQ4qL0ad8aby-eBgvvW122kEX7jRBskQxdGW2L7sLmg=.707d57f7-80a0-4227-800d-6ce5597f3878@github.com>
References: <5GMjFWaMjkSuxhPJ8TYJyw_LYdFfhJWrySSaRUjSNq4=.0ee7f896-35b2-43aa-a243-418b1ffb50b0@github.com>
<HQ4qL0ad8aby-eBgvvW122kEX7jRBskQxdGW2L7sLmg=.707d57f7-80a0-4227-800d-6ce5597f3878@github.com>
Message-ID: <zXUtp8Vdp9LG_POgkoJ5WzdxsdY4m0QQFL6giMg7bKQ=.c3375095-2f6d-45d5-baea-0b20142bbf11@github.com>
On Wed, 2 Oct 2024 21:26:28 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:
>> This change improves the efficiency of cleaning up (recycling) regions that have been trashed by GC effort. The affected code runs at the end of FinalMark to reclaim immediate garbage. It runs at the end of FinalUpdateRefs to reclaim the regions that comprised the collection set, from which all live objects have now been evacuated.
>>
>> Efficiency improvements include:
>> 1. Rather than invoking the os (while holding the Heap lock) to obtain the time twice for every region recycled, we invoke the os only once for each batch of 32 regions that are to be processed.
>> 2. Rather than enforcing that the loop runs no longer than 30 us, we refrain from starting a second batch of regions if more than 8 us has passed since the preceding batch was processed.
>>
>> Below, each trial runs for 1 hour, processing 28,000 transactions per second.
>>
>> Without this change, latency for 4 un-named business services is represented by the following chart:
>> 
>>
>> With this change, latency for the same services is much better:
>> 
>>
>> A comparison of the two is provided by the following:
>> 
>
> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 935:
>
>> 933: // Avoid another call to javaTimeNanos() if we already know time at which last batch ended
>> 934: batch_start_time = batch_end_time;
>> 935: const jlong deadline = batch_start_time + deadline_ns;
>
> Nit: Maybe before taking the heap lock?
I'll adjust this.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/21211#discussion_r1785368950
From mli at openjdk.org Thu Oct 3 06:50:48 2024
From: mli at openjdk.org (Hamlin Li)
Date: Thu, 3 Oct 2024 06:50:48 GMT
Subject: RFR: 8334060: Implementation of Late Barrier Expansion for G1
[v27]
In-Reply-To: <N4ocPHd0KbEF_VZngD6KkfUgDx6PH0I5IwT09MHfiyU=.955d49c1-f633-4734-8d6b-3a272076d8be@github.com>
References: <ClHEkY_xzx37VNyLJr9F9eWSjXfdCRQcbmAhomsY7kU=.f4c3c125-caed-467f-b9fa-213d14f7908a@github.com>
<YYVkTHSwqRigZMpp3wjVjULgwfhawfXCszR2iKEPazA=.a7b37dee-07cd-45e9-aeed-0f90cba1268a@github.com>
<vb76mbxerbCHN5fmVs9ERapN0W1XeTdBzu8ncwCINLY=.89a1a645-8a60-44bd-aed3-3a18c6c378ab@github.com>
<7L7jYDlFa0WnVvgiyNHI9KZrcffYwNnBB899AuMS56Q=.40b031e7-07b8-4a15-b319-c53b38a17a49@github.com>
<StzxvdFi4HQirGwYzWf_0rUr0a75ANIZv_oUiNXs9-s=.1c4cc9c3-a02b-4328-b877-868bbd92b140@github.com>
<N4ocPHd0KbEF_VZngD6KkfUgDx6PH0I5IwT09MHfiyU=.955d49c1-f633-4734-8d6b-3a272076d8be@github.com>
Message-ID: <4S2raWNwXSaEN1p2bAXEUKlHdqSY9AqrR7cBZDhs2QI=.e6ecddb3-be2b-4bda-88ac-8cd9fcb1301b@github.com>
On Wed, 2 Oct 2024 19:41:26 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:
>> I saw the riscv one in z_riscv.ad is: `effect(TEMP oldval_tmp, TEMP newval_tmp, TEMP tmp1, TEMP_DEF res);`, maybe it's good to change riscv one?
>
> I suggest to postpone these types of refactorings to follow-up enhancements, given that the pull request in its current form is stable, thoroughly tested, and approved by reviewers. I intend to integrate it within the following 24 hours, provided final test results look good.
Sounds good too. Thanks!
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/19746#discussion_r1785711504
From rcastanedalo at openjdk.org Thu Oct 3 08:35:54 2024
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Thu, 3 Oct 2024 08:35:54 GMT
Subject: RFR: 8334060: Implementation of Late Barrier Expansion for G1
[v27]
In-Reply-To: <YYVkTHSwqRigZMpp3wjVjULgwfhawfXCszR2iKEPazA=.a7b37dee-07cd-45e9-aeed-0f90cba1268a@github.com>
References: <ClHEkY_xzx37VNyLJr9F9eWSjXfdCRQcbmAhomsY7kU=.f4c3c125-caed-467f-b9fa-213d14f7908a@github.com>
<YYVkTHSwqRigZMpp3wjVjULgwfhawfXCszR2iKEPazA=.a7b37dee-07cd-45e9-aeed-0f90cba1268a@github.com>
Message-ID: <BA5FZjbH5fmoijj5zqLr63CB5OwXGTPXQqMZ6tLJDQI=.1346fda3-a2a0-4b91-9296-66888ae86303@github.com>
On Mon, 30 Sep 2024 05:02:12 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:
>> This changeset implements JEP 475 (Late Barrier Expansion for G1), including support for the x64 and aarch64 platforms. See the [JEP description](https://openjdk.org/jeps/475) for further detail.
>>
>> We aim to integrate this work in JDK 24. The purpose of this pull request is double-fold:
>>
>> - to allow maintainers of the arm (32-bit), ppc, riscv, s390, and x86 (32-bit) ports to contribute a port of these platforms in time for JDK 24; and
>> - to allow reviewers to review the platform-independent, x64 and aarch64, and test changes in parallel with the porting work.
>>
>> ## Summary of the Changes
>>
>> ### Platform-Independent Changes (`src/hotspot/share`)
>>
>> These consist mainly of:
>>
>> - a complete rewrite of `G1BarrierSetC2`, to instruct C2 to expand G1 barriers late instead of early;
>> - a few minor changes to C2 itself, to support removal of redundant decompression operations and to address an OopMap construction issue triggered by this JEP's increased usage of ADL `TEMP` operands; and
>> - temporary support for porting the JEP to the remaining platforms.
>>
>> The temporary support code (guarded by the pre-processor flag `G1_LATE_BARRIER_MIGRATION_SUPPORT`) will **not** be part of the final pull request, and hence does not need to be reviewed.
>>
>> ### Platform-Dependent Changes (`src/hotspot/cpu`)
>>
>> These include changes to the ADL instruction definitions and the `G1BarrierSetAssembler` class of the x64 and aarch64 platforms.
>>
>> #### ADL Changes
>>
>> The changeset uses ADL predicates to force C2 to implement memory accesses tagged with barrier information using G1-specific, barrier-aware instruction versions (e.g. `g1StoreP` instead of the GC-agnostic `storeP`). These new instruction versions generate machine code accordingly to the corresponding tagged barrier information, relying on the G1 barrier implementations provided by the `G1BarrierSetAssembler` class. In the aarch64 platform, the bulk of the ADL code is generated from a higher-level version using m4, to reduce redundancy.
>>
>> #### `G1BarrierSetAssembler` Changes
>>
>> Both platforms basically reuse the barrier implementation for the bytecode interpreter, with the different barrier tests and operations refactored into dedicated functions. Besides this, `G1BarrierSetAssembler` is extended with assembly-stub routines that implement the out-of-line, slow path of the barriers. These routines include calls from the barrier into the JVM, which require support for saving and restoring live ...
>
> Roberto Casta?eda Lozano 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 53 additional commits since the last revision:
>
> - Merge remote-tracking branch 'feilongjiang/JEP-475-RISC-V' into JDK-8334060-g1-late-barrier-expansion
> - riscv port refactor
> - Remove temporary support code
> - Merge jdk-24+17
> - Relax 'must match' assertion in ppc's g1StoreN after limiting pinning bypass optimization
> - Remove unnecessary reg-to-reg moves in aarch64's g1CompareAndX instructions
> - Reintroduce matcher assert and limit pinning bypass optimization to non-shared EncodeP nodes
> - Merge jdk-24+16
> - Ensure that detected encode-and-store patterns are matched
> - Merge remote-tracking branch 'snazarkin/arm32-JDK-8334060-g1-late-barrier-expansion' into JDK-8334060-g1-late-barrier-expansion
> - ... and 43 more: https://git.openjdk.org/jdk/compare/0cf6df31...14483b83
Thanks to everyone who contributed to this JEP, integrating now.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/19746#issuecomment-2390833194
From rcastanedalo at openjdk.org Thu Oct 3 08:39:57 2024
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Thu, 3 Oct 2024 08:39:57 GMT
Subject: Integrated: 8334060: Implementation of Late Barrier Expansion for G1
In-Reply-To: <ClHEkY_xzx37VNyLJr9F9eWSjXfdCRQcbmAhomsY7kU=.f4c3c125-caed-467f-b9fa-213d14f7908a@github.com>
References: <ClHEkY_xzx37VNyLJr9F9eWSjXfdCRQcbmAhomsY7kU=.f4c3c125-caed-467f-b9fa-213d14f7908a@github.com>
Message-ID: <mXBgyAGkMlBgbgtmzRdxQLV9F54iVY6Fx5T7yPZvSzw=.2649ab50-a845-455c-be82-922e721fddfc@github.com>
On Mon, 17 Jun 2024 09:49:25 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:
> This changeset implements JEP 475 (Late Barrier Expansion for G1), including support for the x64 and aarch64 platforms. See the [JEP description](https://openjdk.org/jeps/475) for further detail.
>
> We aim to integrate this work in JDK 24. The purpose of this pull request is double-fold:
>
> - to allow maintainers of the arm (32-bit), ppc, riscv, s390, and x86 (32-bit) ports to contribute a port of these platforms in time for JDK 24; and
> - to allow reviewers to review the platform-independent, x64 and aarch64, and test changes in parallel with the porting work.
>
> ## Summary of the Changes
>
> ### Platform-Independent Changes (`src/hotspot/share`)
>
> These consist mainly of:
>
> - a complete rewrite of `G1BarrierSetC2`, to instruct C2 to expand G1 barriers late instead of early;
> - a few minor changes to C2 itself, to support removal of redundant decompression operations and to address an OopMap construction issue triggered by this JEP's increased usage of ADL `TEMP` operands; and
> - temporary support for porting the JEP to the remaining platforms.
>
> The temporary support code (guarded by the pre-processor flag `G1_LATE_BARRIER_MIGRATION_SUPPORT`) will **not** be part of the final pull request, and hence does not need to be reviewed.
>
> ### Platform-Dependent Changes (`src/hotspot/cpu`)
>
> These include changes to the ADL instruction definitions and the `G1BarrierSetAssembler` class of the x64 and aarch64 platforms.
>
> #### ADL Changes
>
> The changeset uses ADL predicates to force C2 to implement memory accesses tagged with barrier information using G1-specific, barrier-aware instruction versions (e.g. `g1StoreP` instead of the GC-agnostic `storeP`). These new instruction versions generate machine code accordingly to the corresponding tagged barrier information, relying on the G1 barrier implementations provided by the `G1BarrierSetAssembler` class. In the aarch64 platform, the bulk of the ADL code is generated from a higher-level version using m4, to reduce redundancy.
>
> #### `G1BarrierSetAssembler` Changes
>
> Both platforms basically reuse the barrier implementation for the bytecode interpreter, with the different barrier tests and operations refactored into dedicated functions. Besides this, `G1BarrierSetAssembler` is extended with assembly-stub routines that implement the out-of-line, slow path of the barriers. These routines include calls from the barrier into the JVM, which require support for saving and restoring live registers, provided by the `SaveLiveRegisters` class. This c...
This pull request has now been integrated.
Changeset: 0b467e90
Author: Roberto Casta?eda Lozano <rcastanedalo at openjdk.org>
URL: https://git.openjdk.org/jdk/commit/0b467e902d591ae9feeec1669918d1588987cd1c
Stats: 7372 lines in 58 files changed: 5924 ins; 985 del; 463 mod
8334060: Implementation of Late Barrier Expansion for G1
Co-authored-by: Roberto Casta?eda Lozano <rcastanedalo at openjdk.org>
Co-authored-by: Erik ?sterlund <eosterlund at openjdk.org>
Co-authored-by: Siyao Liu <siyao.l.liu at oracle.com>
Co-authored-by: Kim Barrett <kbarrett at openjdk.org>
Co-authored-by: Amit Kumar <amitkumar at openjdk.org>
Co-authored-by: Martin Doerr <mdoerr at openjdk.org>
Co-authored-by: Feilong Jiang <fjiang at openjdk.org>
Co-authored-by: Sergey Nazarkin <snazarki at openjdk.org>
Reviewed-by: kvn, tschatzl, fyang, ayang, kbarrett
-------------
PR: https://git.openjdk.org/jdk/pull/19746
From kdnilsen at openjdk.org Thu Oct 3 16:19:53 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 3 Oct 2024 16:19:53 GMT
Subject: RFR: 8341379: Shenandoah: Improve lock contention during cleanup
[v2]
In-Reply-To: <5GMjFWaMjkSuxhPJ8TYJyw_LYdFfhJWrySSaRUjSNq4=.0ee7f896-35b2-43aa-a243-418b1ffb50b0@github.com>
References: <5GMjFWaMjkSuxhPJ8TYJyw_LYdFfhJWrySSaRUjSNq4=.0ee7f896-35b2-43aa-a243-418b1ffb50b0@github.com>
Message-ID: <qnUYv4gHanvcqlgax0xXO9frymnVrgj2eR5oxXbnnf0=.c4648064-4531-4033-bc05-22e19cf538e7@github.com>
> This change improves the efficiency of cleaning up (recycling) regions that have been trashed by GC effort. The affected code runs at the end of FinalMark to reclaim immediate garbage. It runs at the end of FinalUpdateRefs to reclaim the regions that comprised the collection set, from which all live objects have now been evacuated.
>
> Efficiency improvements include:
> 1. Rather than invoking the os (while holding the Heap lock) to obtain the time twice for every region recycled, we invoke the os only once for each batch of 32 regions that are to be processed.
> 2. Rather than enforcing that the loop runs no longer than 30 us, we refrain from starting a second batch of regions if more than 8 us has passed since the preceding batch was processed.
>
> Below, each trial runs for 1 hour, processing 28,000 transactions per second.
>
> Without this change, latency for 4 un-named business services is represented by the following chart:
> 
>
> With this change, latency for the same services is much better:
> 
>
> A comparison of the two is provided by the following:
> 
Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
Predict next batch time and enforce predictive deadline
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/21211/files
- new: https://git.openjdk.org/jdk/pull/21211/files/acf517f5..c3f1b080
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=21211&range=01
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=21211&range=00-01
Stats: 20 lines in 1 file changed: 11 ins; 2 del; 7 mod
Patch: https://git.openjdk.org/jdk/pull/21211.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/21211/head:pull/21211
PR: https://git.openjdk.org/jdk/pull/21211
From xpeng at openjdk.org Thu Oct 3 16:51:37 2024
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Thu, 3 Oct 2024 16:51:37 GMT
Subject: RFR: 8341379: Shenandoah: Improve lock contention during cleanup
[v2]
In-Reply-To: <qnUYv4gHanvcqlgax0xXO9frymnVrgj2eR5oxXbnnf0=.c4648064-4531-4033-bc05-22e19cf538e7@github.com>
References: <5GMjFWaMjkSuxhPJ8TYJyw_LYdFfhJWrySSaRUjSNq4=.0ee7f896-35b2-43aa-a243-418b1ffb50b0@github.com>
<qnUYv4gHanvcqlgax0xXO9frymnVrgj2eR5oxXbnnf0=.c4648064-4531-4033-bc05-22e19cf538e7@github.com>
Message-ID: <l8QzgE8cyAEPy7hCGafiQxUiv0bUUIFZyuEixZ4dhW4=.381dbc2e-87b4-44d6-856b-818c63eab31d@github.com>
On Thu, 3 Oct 2024 16:19:53 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:
>> This change improves the efficiency of cleaning up (recycling) regions that have been trashed by GC effort. The affected code runs at the end of FinalMark to reclaim immediate garbage. It runs at the end of FinalUpdateRefs to reclaim the regions that comprised the collection set, from which all live objects have now been evacuated.
>>
>> Efficiency improvements include:
>> 1. Rather than invoking the os (while holding the Heap lock) to obtain the time twice for every region recycled, we invoke the os only once for each batch of 32 regions that are to be processed.
>> 2. Rather than enforcing that the loop runs no longer than 30 us, we refrain from starting a second batch of regions if more than 8 us has passed since the preceding batch was processed.
>>
>> Below, each trial runs for 1 hour, processing 28,000 transactions per second.
>>
>> Without this change, latency for 4 un-named business services is represented by the following chart:
>> 
>>
>> With this change, latency for the same services is much better:
>> 
>>
>> A comparison of the two is provided by the following:
>> 
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>
> Predict next batch time and enforce predictive deadline
Marked as reviewed by xpeng (Author).
src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 957:
> 955: batch_end_time = os::javaTimeNanos();
> 956: // Estimate includes historic combination of yield times and heap lock acquisition times.
> 957: batch_process_time_estimate = (batch_end_time - recycle_trash_start_time) / total_batches;;
Nit: double semicolons
-------------
PR Review: https://git.openjdk.org/jdk/pull/21211#pullrequestreview-2346133650
PR Review Comment: https://git.openjdk.org/jdk/pull/21211#discussion_r1786541498
From shade at openjdk.org Thu Oct 3 17:15:03 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 3 Oct 2024 17:15:03 GMT
Subject: RFR: 8334060: Implementation of Late Barrier Expansion for G1
[v27]
In-Reply-To: <YYVkTHSwqRigZMpp3wjVjULgwfhawfXCszR2iKEPazA=.a7b37dee-07cd-45e9-aeed-0f90cba1268a@github.com>
References: <ClHEkY_xzx37VNyLJr9F9eWSjXfdCRQcbmAhomsY7kU=.f4c3c125-caed-467f-b9fa-213d14f7908a@github.com>
<YYVkTHSwqRigZMpp3wjVjULgwfhawfXCszR2iKEPazA=.a7b37dee-07cd-45e9-aeed-0f90cba1268a@github.com>
Message-ID: <vz_qfsQGfiikePNlQj8Wae9rSr8qGA8Or4_oincOBmY=.a477b15b-73cd-433d-acbc-ccda765a166a@github.com>
On Mon, 30 Sep 2024 05:02:12 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:
>> This changeset implements JEP 475 (Late Barrier Expansion for G1), including support for the x64 and aarch64 platforms. See the [JEP description](https://openjdk.org/jeps/475) for further detail.
>>
>> We aim to integrate this work in JDK 24. The purpose of this pull request is double-fold:
>>
>> - to allow maintainers of the arm (32-bit), ppc, riscv, s390, and x86 (32-bit) ports to contribute a port of these platforms in time for JDK 24; and
>> - to allow reviewers to review the platform-independent, x64 and aarch64, and test changes in parallel with the porting work.
>>
>> ## Summary of the Changes
>>
>> ### Platform-Independent Changes (`src/hotspot/share`)
>>
>> These consist mainly of:
>>
>> - a complete rewrite of `G1BarrierSetC2`, to instruct C2 to expand G1 barriers late instead of early;
>> - a few minor changes to C2 itself, to support removal of redundant decompression operations and to address an OopMap construction issue triggered by this JEP's increased usage of ADL `TEMP` operands; and
>> - temporary support for porting the JEP to the remaining platforms.
>>
>> The temporary support code (guarded by the pre-processor flag `G1_LATE_BARRIER_MIGRATION_SUPPORT`) will **not** be part of the final pull request, and hence does not need to be reviewed.
>>
>> ### Platform-Dependent Changes (`src/hotspot/cpu`)
>>
>> These include changes to the ADL instruction definitions and the `G1BarrierSetAssembler` class of the x64 and aarch64 platforms.
>>
>> #### ADL Changes
>>
>> The changeset uses ADL predicates to force C2 to implement memory accesses tagged with barrier information using G1-specific, barrier-aware instruction versions (e.g. `g1StoreP` instead of the GC-agnostic `storeP`). These new instruction versions generate machine code accordingly to the corresponding tagged barrier information, relying on the G1 barrier implementations provided by the `G1BarrierSetAssembler` class. In the aarch64 platform, the bulk of the ADL code is generated from a higher-level version using m4, to reduce redundancy.
>>
>> #### `G1BarrierSetAssembler` Changes
>>
>> Both platforms basically reuse the barrier implementation for the bytecode interpreter, with the different barrier tests and operations refactored into dedicated functions. Besides this, `G1BarrierSetAssembler` is extended with assembly-stub routines that implement the out-of-line, slow path of the barriers. These routines include calls from the barrier into the JVM, which require support for saving and restoring live ...
>
> Roberto Casta?eda Lozano 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 53 additional commits since the last revision:
>
> - Merge remote-tracking branch 'feilongjiang/JEP-475-RISC-V' into JDK-8334060-g1-late-barrier-expansion
> - riscv port refactor
> - Remove temporary support code
> - Merge jdk-24+17
> - Relax 'must match' assertion in ppc's g1StoreN after limiting pinning bypass optimization
> - Remove unnecessary reg-to-reg moves in aarch64's g1CompareAndX instructions
> - Reintroduce matcher assert and limit pinning bypass optimization to non-shared EncodeP nodes
> - Merge jdk-24+16
> - Ensure that detected encode-and-store patterns are matched
> - Merge remote-tracking branch 'snazarkin/arm32-JDK-8334060-g1-late-barrier-expansion' into JDK-8334060-g1-late-barrier-expansion
> - ... and 43 more: https://git.openjdk.org/jdk/compare/9bb3ef4e...14483b83
src/hotspot/share/gc/g1/c2/g1BarrierSetC2.cpp line 335:
> 333: assert(!use_ReduceInitialCardMarks(),
> 334: "post-barriers are only needed for tightly-coupled initialization stores when ReduceInitialCardMarks is disabled");
> 335: access.set_barrier_data(access.barrier_data() ^ G1C2BarrierPre);
I have been looking at this code after integration, and I wonder if `^` is really correct here? Was the intend to remove `G1C2BarrierPre` from the barrier data? What happens if `get_store_barrier` does not actually set it? Do we flip the bit back?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/19746#discussion_r1786573527
From coleenp at openjdk.org Thu Oct 3 20:30:56 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 3 Oct 2024 20:30:56 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v29]
In-Reply-To: <migFoRhtd3kovSs2fRSGXzdh7vCpbyazoT5Gwzeu8ks=.4bd5afae-9598-4ab3-a7d8-737281236a4e@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<migFoRhtd3kovSs2fRSGXzdh7vCpbyazoT5Gwzeu8ks=.4bd5afae-9598-4ab3-a7d8-737281236a4e@github.com>
Message-ID: <GqmziZEDXAdRD3_7_SwIQoRphkc_Vk3jR_16rNnV1_8=.57f3b695-549d-472a-9b04-2bb34e9d22d6@github.com>
On Wed, 2 Oct 2024 15:37:40 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>>
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>>
>> Main changes:
>> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>> - Arrays will now store their length at offset 8.
>> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with three additional commits since the last revision:
>
> - Revert "Disable TestSplitPacks::test4a, failing on aarch64"
>
> This reverts commit 059b1573db26d1d2902ca6dadc8413f445234c2a.
> - Simplify object init code in interpreter
> - Disable some vectorization tests that fail with +UCOH and UseSSE<=3
I posted a patch for JDK-8341044 for CDSPluginTest.java that was failing in our testing with the Lilliput patch.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2392273233
From kdnilsen at openjdk.org Thu Oct 3 21:30:12 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 3 Oct 2024 21:30:12 GMT
Subject: RFR: 8341379: Shenandoah: Improve lock contention during cleanup
[v3]
In-Reply-To: <5GMjFWaMjkSuxhPJ8TYJyw_LYdFfhJWrySSaRUjSNq4=.0ee7f896-35b2-43aa-a243-418b1ffb50b0@github.com>
References: <5GMjFWaMjkSuxhPJ8TYJyw_LYdFfhJWrySSaRUjSNq4=.0ee7f896-35b2-43aa-a243-418b1ffb50b0@github.com>
Message-ID: <2QJqfhzQfJk9ZDN1AI3QR2KpLvGA-djz8U-Cv7OeKGo=.708970da-45e6-41db-a3cd-86ca272d8a14@github.com>
> This change improves the efficiency of cleaning up (recycling) regions that have been trashed by GC effort. The affected code runs at the end of FinalMark to reclaim immediate garbage. It runs at the end of FinalUpdateRefs to reclaim the regions that comprised the collection set, from which all live objects have now been evacuated.
>
> Efficiency improvements include:
> 1. Rather than invoking the os (while holding the Heap lock) to obtain the time twice for every region recycled, we invoke the os only once for each batch of 32 regions that are to be processed.
> 2. Rather than enforcing that the loop runs no longer than 30 us, we refrain from starting a second batch of regions if more than 8 us has passed since the preceding batch was processed.
>
> Below, each trial runs for 1 hour, processing 28,000 transactions per second.
>
> Without this change, latency for 4 un-named business services is represented by the following chart:
> 
>
> With this change, latency for the same services is much better:
> 
>
> A comparison of the two is provided by the following:
> 
Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
fix typo
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/21211/files
- new: https://git.openjdk.org/jdk/pull/21211/files/c3f1b080..055ad411
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=21211&range=02
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=21211&range=01-02
Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
Patch: https://git.openjdk.org/jdk/pull/21211.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/21211/head:pull/21211
PR: https://git.openjdk.org/jdk/pull/21211
From kdnilsen at openjdk.org Thu Oct 3 21:30:12 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 3 Oct 2024 21:30:12 GMT
Subject: RFR: 8341379: Shenandoah: Improve lock contention during cleanup
[v2]
In-Reply-To: <l8QzgE8cyAEPy7hCGafiQxUiv0bUUIFZyuEixZ4dhW4=.381dbc2e-87b4-44d6-856b-818c63eab31d@github.com>
References: <5GMjFWaMjkSuxhPJ8TYJyw_LYdFfhJWrySSaRUjSNq4=.0ee7f896-35b2-43aa-a243-418b1ffb50b0@github.com>
<qnUYv4gHanvcqlgax0xXO9frymnVrgj2eR5oxXbnnf0=.c4648064-4531-4033-bc05-22e19cf538e7@github.com>
<l8QzgE8cyAEPy7hCGafiQxUiv0bUUIFZyuEixZ4dhW4=.381dbc2e-87b4-44d6-856b-818c63eab31d@github.com>
Message-ID: <WtQ0cTd2b8pgDkCHtMY0h07SSdpXRE5Qv0EtfGcHoQs=.50d55173-0399-4a44-afb7-7eba210a87c5@github.com>
On Thu, 3 Oct 2024 16:48:52 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:
>> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>>
>> Predict next batch time and enforce predictive deadline
>
> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 957:
>
>> 955: batch_end_time = os::javaTimeNanos();
>> 956: // Estimate includes historic combination of yield times and heap lock acquisition times.
>> 957: batch_process_time_estimate = (batch_end_time - recycle_trash_start_time) / total_batches;;
>
> Nit: double semicolons
Thanks. Fixed.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/21211#discussion_r1786862316
From kdnilsen at openjdk.org Thu Oct 3 21:46:36 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 3 Oct 2024 21:46:36 GMT
Subject: RFR: 8341379: Shenandoah: Improve lock contention during cleanup
[v3]
In-Reply-To: <2QJqfhzQfJk9ZDN1AI3QR2KpLvGA-djz8U-Cv7OeKGo=.708970da-45e6-41db-a3cd-86ca272d8a14@github.com>
References: <5GMjFWaMjkSuxhPJ8TYJyw_LYdFfhJWrySSaRUjSNq4=.0ee7f896-35b2-43aa-a243-418b1ffb50b0@github.com>
<2QJqfhzQfJk9ZDN1AI3QR2KpLvGA-djz8U-Cv7OeKGo=.708970da-45e6-41db-a3cd-86ca272d8a14@github.com>
Message-ID: <LOiuJi3b3a7C925tL91pol-4bHN3oIRguVH-W5ctEh4=.6497226d-0c3a-456b-bac7-7319829a9f67@github.com>
On Thu, 3 Oct 2024 21:30:12 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:
>> This change improves the efficiency of cleaning up (recycling) regions that have been trashed by GC effort. The affected code runs at the end of FinalMark to reclaim immediate garbage. It runs at the end of FinalUpdateRefs to reclaim the regions that comprised the collection set, from which all live objects have now been evacuated.
>>
>> Efficiency improvements include:
>> 1. Rather than invoking the os (while holding the Heap lock) to obtain the time twice for every region recycled, we invoke the os only once for each batch of 32 regions that are to be processed.
>> 2. Rather than enforcing that the loop runs no longer than 30 us, we refrain from starting a second batch of regions if more than 8 us has passed since the preceding batch was processed.
>>
>> Below, each trial runs for 1 hour, processing 28,000 transactions per second.
>>
>> Without this change, latency for 4 un-named business services is represented by the following chart:
>> 
>>
>> With this change, latency for the same services is much better:
>> 
>>
>> A comparison of the two is provided by the following:
>> 
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>
> fix typo
I restructured the mechanism that decides whether to start processing another batch of regions. In the code as originally structured, we would start another batch whenever the time since previous yield is less than 8 us. In this new version of the code, we start another batch whenever the time since previous yield plus the predicted time to process another batch is less than 10 us. Prediction of how long a batch will take to process is based on most recent history. Note that this is highly dependent on the state of the application. If the application has lots of mutator threads that are urgently allocating, there will be contention for the global heap lock and there will be contention for CPU cores, and both of these will cause the batch processing time to increase.
As expected, this new version does a better job of constraining the amount of time between yields. With this new code, we will never start processing another batch unless we have some confidence that the new batch will complete on schedule. Previously, we might have completed processing a first batch at time 7.5 us. Then, we would have immediately started to process a second patch, even though a prediction of batch processing time would have allowed us to predict that this second batch would not finish until time 15 us.
The new version of the code will sometimes cause mutators to wait slightly longer for yield and the heap lock when the system is "lightly loaded". This is shown to effect p50 latencies. When the system is lightly loaded, the time to process a batch (on current hardware) is approximately 1.5 us. Suppose we finish processing a batch at time 8.25 us. In the original implementation, we would have immediately yielded. However, in this new version of the code, we'll take the next batch, because this is predicted to complete at time 9.75 us, which is less than deadline 10 us. Making this choice allows the GC thread that is recycling trash regions to have higher throughput.
Here are the results of testing this new version of the code:
and this is how this new version compares to mainline without this PR:
Most of the p99.99 percentile latencies are considerably improved. There is a slight degradation of p50 latencies.
Which would be considered the preferred solution? I'll vote for the new code, but can be persuaded either way.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/21211#issuecomment-2392391683
From xpeng at openjdk.org Thu Oct 3 22:14:36 2024
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Thu, 3 Oct 2024 22:14:36 GMT
Subject: RFR: 8341379: Shenandoah: Improve lock contention during cleanup
[v3]
In-Reply-To: <2QJqfhzQfJk9ZDN1AI3QR2KpLvGA-djz8U-Cv7OeKGo=.708970da-45e6-41db-a3cd-86ca272d8a14@github.com>
References: <5GMjFWaMjkSuxhPJ8TYJyw_LYdFfhJWrySSaRUjSNq4=.0ee7f896-35b2-43aa-a243-418b1ffb50b0@github.com>
<2QJqfhzQfJk9ZDN1AI3QR2KpLvGA-djz8U-Cv7OeKGo=.708970da-45e6-41db-a3cd-86ca272d8a14@github.com>
Message-ID: <zyL6i1VSmINE_BGftXBINUGThKK9n0dazp3fHUqJjZg=.d71e8a33-744f-47fc-a657-0976213a2b43@github.com>
On Thu, 3 Oct 2024 21:30:12 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:
>> This change improves the efficiency of cleaning up (recycling) regions that have been trashed by GC effort. The affected code runs at the end of FinalMark to reclaim immediate garbage. It runs at the end of FinalUpdateRefs to reclaim the regions that comprised the collection set, from which all live objects have now been evacuated.
>>
>> Efficiency improvements include:
>> 1. Rather than invoking the os (while holding the Heap lock) to obtain the time twice for every region recycled, we invoke the os only once for each batch of 32 regions that are to be processed.
>> 2. Rather than enforcing that the loop runs no longer than 30 us, we refrain from starting a second batch of regions if more than 8 us has passed since the preceding batch was processed.
>>
>> Below, each trial runs for 1 hour, processing 28,000 transactions per second.
>>
>> Without this change, latency for 4 un-named business services is represented by the following chart:
>> 
>>
>> With this change, latency for the same services is much better:
>> 
>>
>> A comparison of the two is provided by the following:
>> 
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>
> fix typo
Marked as reviewed by xpeng (Author).
-------------
PR Review: https://git.openjdk.org/jdk/pull/21211#pullrequestreview-2346777439
From xpeng at openjdk.org Thu Oct 3 22:14:37 2024
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Thu, 3 Oct 2024 22:14:37 GMT
Subject: RFR: 8341379: Shenandoah: Improve lock contention during cleanup
[v3]
In-Reply-To: <LOiuJi3b3a7C925tL91pol-4bHN3oIRguVH-W5ctEh4=.6497226d-0c3a-456b-bac7-7319829a9f67@github.com>
References: <5GMjFWaMjkSuxhPJ8TYJyw_LYdFfhJWrySSaRUjSNq4=.0ee7f896-35b2-43aa-a243-418b1ffb50b0@github.com>
<2QJqfhzQfJk9ZDN1AI3QR2KpLvGA-djz8U-Cv7OeKGo=.708970da-45e6-41db-a3cd-86ca272d8a14@github.com>
<LOiuJi3b3a7C925tL91pol-4bHN3oIRguVH-W5ctEh4=.6497226d-0c3a-456b-bac7-7319829a9f67@github.com>
Message-ID: <jXV48wXi0T5UwkXO3ABs1shz7xwZm8K4VsvJQHsM0QE=.c960354e-f1ff-4eca-9423-c43693368251@github.com>
On Thu, 3 Oct 2024 21:42:51 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:
> Which would be considered the preferred solution? I'll vote for the new code, but can be persuaded either way.
New code looks good to me, the test result also looks pretty good.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/21211#issuecomment-2392428849
From mbaesken at openjdk.org Fri Oct 4 07:35:34 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 4 Oct 2024 07:35:34 GMT
Subject: RFR: 8336911: ZGC: Division by zero in heuristics after
JDK-8332717
In-Reply-To: <TVdAZ6lUVILfil1wDSKBU-VcFyGEMuE0tWu1zIiL88Y=.80b704c2-8edf-4d15-af55-260a3a1e5a85@github.com>
References: <rByxhEm3b3JZQVvugNz4KezLFPWc2NH_vOPaAl9Je2A=.703a5530-a302-43b2-a6bf-37f100c8bc79@github.com>
<TVdAZ6lUVILfil1wDSKBU-VcFyGEMuE0tWu1zIiL88Y=.80b704c2-8edf-4d15-af55-260a3a1e5a85@github.com>
Message-ID: <eUrp0LFMiszFVtg0ny3iu8udO7KKdkEU6PNTHiwz7Lo=.8d57efc4-3977-4f8a-94bc-e5d177f17579@github.com>
On Wed, 2 Oct 2024 15:42:12 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:
>> When running with ubsan enabled binaries, the following issue is reported,
>> e.g. in test
>> compiler/uncommontrap/TestDeoptOOM_ZGenerational.jtr
>> also in gc/z/TestSmallHeap.jtr
>>
>>
>> jdk/src/hotspot/share/gc/z/zDirector.cpp:537:84: runtime error: division by zero
>> #0 0x7f422495bd1f in calculate_young_to_old_worker_ratio src/hotspot/share/gc/z/zDirector.cpp:537
>> #1 0x7f422495bd1f in select_worker_threads src/hotspot/share/gc/z/zDirector.cpp:694
>> #2 0x7f42282a0d97 in select_worker_threads src/hotspot/share/gc/z/zDirector.cpp:689
>> #3 0x7f42282a0d97 in initial_workers src/hotspot/share/gc/z/zDirector.cpp:784
>> #4 0x7f42282a2485 in initial_workers src/hotspot/share/gc/z/zDirector.cpp:795
>> #5 0x7f42282a2485 in start_minor_gc src/hotspot/share/gc/z/zDirector.cpp:797
>> #6 0x7f42282a2485 in start_gc src/hotspot/share/gc/z/zDirector.cpp:826
>> #7 0x7f42282a2485 in ZDirector::run_thread() src/hotspot/share/gc/z/zDirector.cpp:912
>> #8 0x7f422840bdd8 in ZThread::run_service() src/hotspot/share/gc/z/zThread.cpp:29
>> #9 0x7f4225ab6979 in ConcurrentGCThread::run() src/hotspot/share/gc/shared/concurrentGCThread.cpp:48
>> #10 0x7f4227e1137a in Thread::call_run() src/hotspot/share/runtime/thread.cpp:225
>> #11 0x7f42274619b1 in thread_native_entry src/hotspot/os/linux/os_linux.cpp:858
>> #12 0x7f422c8d36e9 in start_thread (/lib64/libpthread.so.0+0xa6e9) (BuildId: 9a146bd267419cb6a8cf08d7c602953a0f2e12c5)
>> #13 0x7f422c1dc58e in clone (/lib64/libc.so.6+0x11858e) (BuildId: f2d1cb1ef49f8c47d43a4053910ba6137673ccce)
>>
>>
>> The division by 0 leads to 'infinity' on most of our platforms. So instead of relying on this behavior, we can add a small check and set 'infinity' for divisor == 0.
>
> src/hotspot/share/gc/z/zDirector.cpp line 539:
>
>> 537: const double current_old_bytes_freed_per_gc_time = double(reclaimed_per_old_gc) / double(old_gc_time);
>> 538: const double old_vs_young_efficiency_ratio = current_young_bytes_freed_per_gc_time == 0 ? std::numeric_limits<double>::infinity()
>> 539: : current_old_bytes_freed_per_gc_time / current_young_bytes_freed_per_gc_time;
>
> I think returning infinity here will cause problems with NaN down the line. It is also unclear what this means if both are `0`. To me something like the following makes sense. But I will discus this with my team.
> Suggestion:
>
>
> if (current_young_bytes_freed_per_gc_time == 0.0) {
> if (current_old_bytes_freed_per_gc_time == 0.0) {
> // Neither young nor old collections have reclaimed any memory.
> // Give them equal priority.
> return 1.0;
> }
>
> // Only old collections have reclaimed memory.
> // Prioritize old.
> return ZOldGCThreads;
> }
>
> const double old_vs_young_efficiency_ratio = current_old_bytes_freed_per_gc_time / current_young_bytes_freed_per_gc_time;
Hi Axel, thanks for the suggestion.
Please discuss it in your team and tell me the outcome :-) !
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/21304#discussion_r1787287674
From jsikstro at openjdk.org Fri Oct 4 08:03:36 2024
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Fri, 4 Oct 2024 08:03:36 GMT
Subject: RFR: 8340426: ZGC: Move defragment out of the allocation path [v2]
In-Reply-To: <RkDIWQFzEdyHWQ1xpR07f6DA9_SxxkSAAfvk9Ch30TM=.e89d0c5d-833f-405c-9303-e50a380e7cb7@github.com>
References: <iOWgd4xauN7tO8BWxLOov7sev7p1xi6_XCneWtFU-Ew=.b5afdc71-aae4-419f-8fd4-86eed815daf4@github.com>
<RkDIWQFzEdyHWQ1xpR07f6DA9_SxxkSAAfvk9Ch30TM=.e89d0c5d-833f-405c-9303-e50a380e7cb7@github.com>
Message-ID: <BZ9IeY-K4X74VaSi4ugZeOY3L1kMj90fd9f_6rb9rp0=.ef59adf6-8415-476e-af4e-45b023c5a9f0@github.com>
On Fri, 27 Sep 2024 08:34:19 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:
>> Please review this change to move defragmentation of small pages out of the allocation path,
>>
>> **Summary**
>> In ZGC small pages are allocated at lower addresses while medium and large pages are allocated at higher addresses. Sometimes when memory usage is high or the distribution of pages in the cache demand it, small pages can be split out from medium or large pages. When this happens the small page is defragmented by remapping it to a lower address if it resides at a too high address. This is done to avoid fragmentation, but doing it in the allocation path comes with a cost since the remapping involves system calls.
>>
>> This change moves the remapping away from the allocation path to when the pages are freed after being garbage collected. This can increase the fragmentation a bit, since small pages are allowed to reside at higher addresses for a period time. The expectation is that since small pages are frequently collected the period should be short enough to not cause any problems.
>>
>> I've done detailed experiments with temporary JFR events to look at the cost of doing the defrag/remapping of pages. One problem is that by default we don't get a lot of defrags (unless we run out of memory), and to better investigate this I also altered the allocation path to force more defragmentation. These tests showed that moving defrag out of the allocation path not only have the positive effect of reducing the time spent allocating, but also spaced out the defragmentation a bit more. The reason for this is that now we will defrag when a page is freed by the GC, instead of when the page is allocated and the tests show that often many threads allocate at the same time (and then also defrag at the same time). This in turn leads to many concurrent calls down to the system to remap the memory, and this increases the cost of the actual mapping (seen by adding JFR events).
>>
>> **Additional testing**
>>
>> - Functional testing in mach5 tier1-7
>> - Sanity performance testing in aurora
>
> Stefan Johansson has updated the pull request incrementally with two additional commits since the last revision:
>
> - Additional changes
> - StefanK review
Marked as reviewed by jsikstro (Author).
-------------
PR Review: https://git.openjdk.org/jdk/pull/21191#pullrequestreview-2347395445
From iwalulya at openjdk.org Fri Oct 4 08:16:06 2024
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Fri, 4 Oct 2024 08:16:06 GMT
Subject: RFR: 8341238: G1: Refactor G1Policy to move collection set selection
methods into G1CollectionSet
Message-ID: <w8WhIXs7wxxicEK9S6UgxptkWYK5s96o7eco1leJe9I=.16087a7e-5a75-49de-9694-fb8980eb7ef7@github.com>
Hi,
Please review this code migration patch to move collection set candidate selection methods out of G1Policy into G1CollectionSet. By relocating these methods, we can simplify the method signatures and reduce the interdependency between the classes.
Testing: Tier 1
-------------
Commit messages:
- move
Changes: https://git.openjdk.org/jdk/pull/21347/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21347&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8341238
Stats: 475 lines in 4 files changed: 226 ins; 239 del; 10 mod
Patch: https://git.openjdk.org/jdk/pull/21347.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/21347/head:pull/21347
PR: https://git.openjdk.org/jdk/pull/21347
From eosterlund at openjdk.org Fri Oct 4 08:29:41 2024
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 4 Oct 2024 08:29:41 GMT
Subject: RFR: 8340426: ZGC: Move defragment out of the allocation path [v2]
In-Reply-To: <RkDIWQFzEdyHWQ1xpR07f6DA9_SxxkSAAfvk9Ch30TM=.e89d0c5d-833f-405c-9303-e50a380e7cb7@github.com>
References: <iOWgd4xauN7tO8BWxLOov7sev7p1xi6_XCneWtFU-Ew=.b5afdc71-aae4-419f-8fd4-86eed815daf4@github.com>
<RkDIWQFzEdyHWQ1xpR07f6DA9_SxxkSAAfvk9Ch30TM=.e89d0c5d-833f-405c-9303-e50a380e7cb7@github.com>
Message-ID: <koV5TsRFLTpgx6OtS-7fe-4WDjo0cgiuBgoJuQboPnc=.94c4ca9e-a887-4801-b301-20b36c163bcc@github.com>
On Fri, 27 Sep 2024 08:34:19 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:
>> Please review this change to move defragmentation of small pages out of the allocation path,
>>
>> **Summary**
>> In ZGC small pages are allocated at lower addresses while medium and large pages are allocated at higher addresses. Sometimes when memory usage is high or the distribution of pages in the cache demand it, small pages can be split out from medium or large pages. When this happens the small page is defragmented by remapping it to a lower address if it resides at a too high address. This is done to avoid fragmentation, but doing it in the allocation path comes with a cost since the remapping involves system calls.
>>
>> This change moves the remapping away from the allocation path to when the pages are freed after being garbage collected. This can increase the fragmentation a bit, since small pages are allowed to reside at higher addresses for a period time. The expectation is that since small pages are frequently collected the period should be short enough to not cause any problems.
>>
>> I've done detailed experiments with temporary JFR events to look at the cost of doing the defrag/remapping of pages. One problem is that by default we don't get a lot of defrags (unless we run out of memory), and to better investigate this I also altered the allocation path to force more defragmentation. These tests showed that moving defrag out of the allocation path not only have the positive effect of reducing the time spent allocating, but also spaced out the defragmentation a bit more. The reason for this is that now we will defrag when a page is freed by the GC, instead of when the page is allocated and the tests show that often many threads allocate at the same time (and then also defrag at the same time). This in turn leads to many concurrent calls down to the system to remap the memory, and this increases the cost of the actual mapping (seen by adding JFR events).
>>
>> **Additional testing**
>>
>> - Functional testing in mach5 tier1-7
>> - Sanity performance testing in aurora
>
> Stefan Johansson has updated the pull request incrementally with two additional commits since the last revision:
>
> - Additional changes
> - StefanK review
Looks good.
-------------
Marked as reviewed by eosterlund (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/21191#pullrequestreview-2347441445
From sjohanss at openjdk.org Fri Oct 4 08:29:41 2024
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Fri, 4 Oct 2024 08:29:41 GMT
Subject: RFR: 8340426: ZGC: Move defragment out of the allocation path [v2]
In-Reply-To: <RkDIWQFzEdyHWQ1xpR07f6DA9_SxxkSAAfvk9Ch30TM=.e89d0c5d-833f-405c-9303-e50a380e7cb7@github.com>
References: <iOWgd4xauN7tO8BWxLOov7sev7p1xi6_XCneWtFU-Ew=.b5afdc71-aae4-419f-8fd4-86eed815daf4@github.com>
<RkDIWQFzEdyHWQ1xpR07f6DA9_SxxkSAAfvk9Ch30TM=.e89d0c5d-833f-405c-9303-e50a380e7cb7@github.com>
Message-ID: <bFyqB05Se4aBsqIzQaiN4SeGxx3ztjTk4CrMCav_aBA=.dead16b9-b7e9-4646-b845-9ea97cc22d1e@github.com>
On Fri, 27 Sep 2024 08:34:19 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:
>> Please review this change to move defragmentation of small pages out of the allocation path,
>>
>> **Summary**
>> In ZGC small pages are allocated at lower addresses while medium and large pages are allocated at higher addresses. Sometimes when memory usage is high or the distribution of pages in the cache demand it, small pages can be split out from medium or large pages. When this happens the small page is defragmented by remapping it to a lower address if it resides at a too high address. This is done to avoid fragmentation, but doing it in the allocation path comes with a cost since the remapping involves system calls.
>>
>> This change moves the remapping away from the allocation path to when the pages are freed after being garbage collected. This can increase the fragmentation a bit, since small pages are allowed to reside at higher addresses for a period time. The expectation is that since small pages are frequently collected the period should be short enough to not cause any problems.
>>
>> I've done detailed experiments with temporary JFR events to look at the cost of doing the defrag/remapping of pages. One problem is that by default we don't get a lot of defrags (unless we run out of memory), and to better investigate this I also altered the allocation path to force more defragmentation. These tests showed that moving defrag out of the allocation path not only have the positive effect of reducing the time spent allocating, but also spaced out the defragmentation a bit more. The reason for this is that now we will defrag when a page is freed by the GC, instead of when the page is allocated and the tests show that often many threads allocate at the same time (and then also defrag at the same time). This in turn leads to many concurrent calls down to the system to remap the memory, and this increases the cost of the actual mapping (seen by adding JFR events).
>>
>> **Additional testing**
>>
>> - Functional testing in mach5 tier1-7
>> - Sanity performance testing in aurora
>
> Stefan Johansson has updated the pull request incrementally with two additional commits since the last revision:
>
> - Additional changes
> - StefanK review
Thanks for the reviews!
-------------
PR Comment: https://git.openjdk.org/jdk/pull/21191#issuecomment-2393129646
From sjohanss at openjdk.org Fri Oct 4 08:29:42 2024
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Fri, 4 Oct 2024 08:29:42 GMT
Subject: Integrated: 8340426: ZGC: Move defragment out of the allocation path
In-Reply-To: <iOWgd4xauN7tO8BWxLOov7sev7p1xi6_XCneWtFU-Ew=.b5afdc71-aae4-419f-8fd4-86eed815daf4@github.com>
References: <iOWgd4xauN7tO8BWxLOov7sev7p1xi6_XCneWtFU-Ew=.b5afdc71-aae4-419f-8fd4-86eed815daf4@github.com>
Message-ID: <L2SA1Na73q14COjFE0jhv1fwBrCfxTzwSInPx6BDcvo=.fc51a8f3-cf47-45bd-9a34-0e0e654e091b@github.com>
On Wed, 25 Sep 2024 20:05:17 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:
> Please review this change to move defragmentation of small pages out of the allocation path,
>
> **Summary**
> In ZGC small pages are allocated at lower addresses while medium and large pages are allocated at higher addresses. Sometimes when memory usage is high or the distribution of pages in the cache demand it, small pages can be split out from medium or large pages. When this happens the small page is defragmented by remapping it to a lower address if it resides at a too high address. This is done to avoid fragmentation, but doing it in the allocation path comes with a cost since the remapping involves system calls.
>
> This change moves the remapping away from the allocation path to when the pages are freed after being garbage collected. This can increase the fragmentation a bit, since small pages are allowed to reside at higher addresses for a period time. The expectation is that since small pages are frequently collected the period should be short enough to not cause any problems.
>
> I've done detailed experiments with temporary JFR events to look at the cost of doing the defrag/remapping of pages. One problem is that by default we don't get a lot of defrags (unless we run out of memory), and to better investigate this I also altered the allocation path to force more defragmentation. These tests showed that moving defrag out of the allocation path not only have the positive effect of reducing the time spent allocating, but also spaced out the defragmentation a bit more. The reason for this is that now we will defrag when a page is freed by the GC, instead of when the page is allocated and the tests show that often many threads allocate at the same time (and then also defrag at the same time). This in turn leads to many concurrent calls down to the system to remap the memory, and this increases the cost of the actual mapping (seen by adding JFR events).
>
> **Additional testing**
>
> - Functional testing in mach5 tier1-7
> - Sanity performance testing in aurora
This pull request has now been integrated.
Changeset: ec020f3f
Author: Stefan Johansson <sjohanss at openjdk.org>
URL: https://git.openjdk.org/jdk/commit/ec020f3fc988553ad1eda460d889b5ba24e76e8e
Stats: 94 lines in 5 files changed: 61 ins; 17 del; 16 mod
8340426: ZGC: Move defragment out of the allocation path
Reviewed-by: aboldtch, jsikstro, eosterlund
-------------
PR: https://git.openjdk.org/jdk/pull/21191
From rcastanedalo at openjdk.org Fri Oct 4 09:20:59 2024
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Fri, 4 Oct 2024 09:20:59 GMT
Subject: RFR: 8334060: Implementation of Late Barrier Expansion for G1
[v27]
In-Reply-To: <vz_qfsQGfiikePNlQj8Wae9rSr8qGA8Or4_oincOBmY=.a477b15b-73cd-433d-acbc-ccda765a166a@github.com>
References: <ClHEkY_xzx37VNyLJr9F9eWSjXfdCRQcbmAhomsY7kU=.f4c3c125-caed-467f-b9fa-213d14f7908a@github.com>
<YYVkTHSwqRigZMpp3wjVjULgwfhawfXCszR2iKEPazA=.a7b37dee-07cd-45e9-aeed-0f90cba1268a@github.com>
<vz_qfsQGfiikePNlQj8Wae9rSr8qGA8Or4_oincOBmY=.a477b15b-73cd-433d-acbc-ccda765a166a@github.com>
Message-ID: <Ow8TBwe8NiA77jJ34JUCHwSsVyPlGyrlAeKFKGTigQI=.f1b250ed-6dae-438d-a862-b0164767a8f1@github.com>
On Thu, 3 Oct 2024 17:12:04 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:
>> Roberto Casta?eda Lozano 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 53 additional commits since the last revision:
>>
>> - Merge remote-tracking branch 'feilongjiang/JEP-475-RISC-V' into JDK-8334060-g1-late-barrier-expansion
>> - riscv port refactor
>> - Remove temporary support code
>> - Merge jdk-24+17
>> - Relax 'must match' assertion in ppc's g1StoreN after limiting pinning bypass optimization
>> - Remove unnecessary reg-to-reg moves in aarch64's g1CompareAndX instructions
>> - Reintroduce matcher assert and limit pinning bypass optimization to non-shared EncodeP nodes
>> - Merge jdk-24+16
>> - Ensure that detected encode-and-store patterns are matched
>> - Merge remote-tracking branch 'snazarkin/arm32-JDK-8334060-g1-late-barrier-expansion' into JDK-8334060-g1-late-barrier-expansion
>> - ... and 43 more: https://git.openjdk.org/jdk/compare/0165cb32...14483b83
>
> src/hotspot/share/gc/g1/c2/g1BarrierSetC2.cpp line 335:
>
>> 333: assert(!use_ReduceInitialCardMarks(),
>> 334: "post-barriers are only needed for tightly-coupled initialization stores when ReduceInitialCardMarks is disabled");
>> 335: access.set_barrier_data(access.barrier_data() ^ G1C2BarrierPre);
>
> I have been looking at this code after integration, and I wonder if `^` is really correct here? Was the intend to remove `G1C2BarrierPre` from the barrier data? What happens if `get_store_barrier` does not actually set it? Do we flip the bit back?
Yes, the intend (and actual effect) is to remove `G1C2BarrierPre` from the barrier data. Using an XOR (`^`) is correct because at that program point `G1C2BarrierPre` is guaranteed to be set. This is because an `access` corresponding to a tightly-coupled initialization store is always of type `C2OptAccess`, hence `!access.is_parse_access()` and `get_store_barrier(access)` trivially returns `G1C2BarrierPre | G1C2BarrierPost`. Having said this, it would be clearly less convoluted to simply clear `G1C2BarrierPre` instead of flipping it. I will file a RFE, thanks.
As a side note, this complexity is necessary to handle `!ReduceInitialCardMarks`. I keep wondering if the benefit of being able to disable `ReduceInitialCardMarks` [1,2,3] is worth the significant complexity required in the GC-C2 interface to deal with it.
[1] https://docs.oracle.com/en/java/javase/23/gctuning/garbage-first-garbage-collector-tuning.html
[2] https://bugs.openjdk.org/browse/JDK-8166899
[3] https://bugs.openjdk.org/browse/JDK-8167077
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/19746#discussion_r1787425169
From rcastanedalo at openjdk.org Fri Oct 4 09:37:53 2024
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Fri, 4 Oct 2024 09:37:53 GMT
Subject: RFR: 8334060: Implementation of Late Barrier Expansion for G1
[v27]
In-Reply-To: <Ow8TBwe8NiA77jJ34JUCHwSsVyPlGyrlAeKFKGTigQI=.f1b250ed-6dae-438d-a862-b0164767a8f1@github.com>
References: <ClHEkY_xzx37VNyLJr9F9eWSjXfdCRQcbmAhomsY7kU=.f4c3c125-caed-467f-b9fa-213d14f7908a@github.com>
<YYVkTHSwqRigZMpp3wjVjULgwfhawfXCszR2iKEPazA=.a7b37dee-07cd-45e9-aeed-0f90cba1268a@github.com>
<vz_qfsQGfiikePNlQj8Wae9rSr8qGA8Or4_oincOBmY=.a477b15b-73cd-433d-acbc-ccda765a166a@github.com>
<Ow8TBwe8NiA77jJ34JUCHwSsVyPlGyrlAeKFKGTigQI=.f1b250ed-6dae-438d-a862-b0164767a8f1@github.com>
Message-ID: <DsrNX6ZGnVuKeparyk9sLtruBnL_FqBNSQctnRrYXgs=.7f1385ab-431d-42b9-9883-d8f5b6c98a18@github.com>
On Fri, 4 Oct 2024 09:17:47 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:
>> src/hotspot/share/gc/g1/c2/g1BarrierSetC2.cpp line 335:
>>
>>> 333: assert(!use_ReduceInitialCardMarks(),
>>> 334: "post-barriers are only needed for tightly-coupled initialization stores when ReduceInitialCardMarks is disabled");
>>> 335: access.set_barrier_data(access.barrier_data() ^ G1C2BarrierPre);
>>
>> I have been looking at this code after integration, and I wonder if `^` is really correct here? Was the intend to remove `G1C2BarrierPre` from the barrier data? What happens if `get_store_barrier` does not actually set it? Do we flip the bit back?
>
> Yes, the intend (and actual effect) is to remove `G1C2BarrierPre` from the barrier data. Using an XOR (`^`) is correct because at that program point `G1C2BarrierPre` is guaranteed to be set. This is because an `access` corresponding to a tightly-coupled initialization store is always of type `C2OptAccess`, hence `!access.is_parse_access()` and `get_store_barrier(access)` trivially returns `G1C2BarrierPre | G1C2BarrierPost`. Having said this, it would be clearly less convoluted to simply clear `G1C2BarrierPre` instead of flipping it. I will file a RFE, thanks.
>
> As a side note, this complexity is necessary to handle `!ReduceInitialCardMarks`. I keep wondering if the benefit of being able to disable `ReduceInitialCardMarks` [1,2,3] is worth the significant complexity required in the GC-C2 interface to deal with it.
>
> [1] https://docs.oracle.com/en/java/javase/23/gctuning/garbage-first-garbage-collector-tuning.html
> [2] https://bugs.openjdk.org/browse/JDK-8166899
> [3] https://bugs.openjdk.org/browse/JDK-8167077
Reported here: [JDK-8341525](https://bugs.openjdk.org/browse/JDK-8341525).
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/19746#discussion_r1787448241
From rkennke at openjdk.org Fri Oct 4 10:44:53 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 4 Oct 2024 10:44:53 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v26]
In-Reply-To: <YpG7vj6W3LnbhvvRhaeLmLeBzc_vlzlzmD74xVu1FQY=.14a57f09-74c1-4b2f-962c-c923961c067c@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<fEpfi4CzTFr1Pl-IyOAVyHNXWlVz33lHKQyzVY0kBc8=.cc39355b-ee7a-4118-952a-28e4184eec84@github.com>
<DKuidQyyiiJOsrerLCeziselVyG9Ztpzsyc64ZNjlI4=.722fc4f7-d7cc-49df-9d82-5c1094508f74@github.com>
<hdttC4LhHE6y6Nbq0jjJwxxF4W0hTfJLK_siODDCBkM=.1667f495-fcd9-4b7f-8d58-24e27665eeb3@github.com>
<fWSdSqQfhOrGpFoExiaO4L-UDtR90_t0gRxp9YBO3_c=.0173618e-f392-4921-8fae-39d44b24de08@github.com>
<6PTWMepIDuZDdPfN3xNKV1vqUyO_R4yCSeiSTpYIyyQ=.61a5b462-7114-4385-a6d7-40e5c7b0005d@github.com>
<C5LwWrsa-VO87kdm_sYuisTGMsHoxv4Eoe0QikdkusE=.63b0993c-86c8-4ef6-a3cf-bc8a67e10815@github.com>
<WOlTJMNHCr_Kk69sEIUwCVI3ZbiRlckY4TSBRfL7zoA=.1a4c59f1-a000-4d9f-abbc-36b24ed5105e@github.com>
<UjwpWz9Y3W8WRzYHZmDk9EvoiLSCZG1aai5oASGtDKA=.68cab6dd-e67d-4651-a9c9-75dccf42d85f@github.com>
<l_7f8gGpIdG9H3Ini5vHWruIa0oDi7fkn2Lz5thDI5c=.969b804f-bae2-48e1-9c44-e631d90037e7@github.com>
<BtvwMUG5tcy_zU4tRG3Q5VVw08qE_3gSE35
wCxlDnj4=.954353e5-cab2-48f4-b0f2-5852e586ba20@github.com>
<zi8MM6qUWhvxPSyb3ewa3baXWhmDIDlut2uYUQmWvcw=.7b32fa42-7a3f-43bb-8f15-fe6b8e66c49b@github.com>
<TSxYcKKfAdx7SsVcq6iwiySCLlkoVbXQO7a25vsiG4k=.29e59a6c-b8e0-42e9-8bdd-cc8ca23df146@github.com>
<YpG7vj6W3LnbhvvRhaeLmLeBzc_vlzlzmD74xVu1FQY=.14a57f09-74c1-4b2f-962c-c923961c067c@github.com>
Message-ID: <YrOurf-ql2uciTYRjGDnvVIb3r9K1pYphx2yRism6SQ=.f5b2510c-d384-4e78-906b-08267a218185@github.com>
On Wed, 2 Oct 2024 21:29:28 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:
>> I changed the header<16 version to be a small loop: https://github.com/rkennke/jdk/commit/bcba264ea5c15581647933db1163ca1dae39b6c5
>>
>> The idea is the same as before, except it's made as a small loop with a maximum of 4 iterations (backward-branches), and it copies 8 bytes at a time, such that 1. it may copy up to 7 bytes that precede the array and 2. doesn't run over the end of the array (which would potentially crash).
>>
>> I am not sure if using XMM_TMP1 and XMM_TMP2 there is ok, or if it would encode better to use one of the regular registers.?
>>
>> Also, this new implementation could simply replace the old one, instead of being an alternative. I am not sure if if would make any difference performance-wise.
>
> @rkennke The small loop looks to me that it will run over the end of the array.
> Say the haystack_len is 7, the index below would be 0 after the shrq instruction, and the movq(XMM_TMP1, Address(haystack, index, Address::times_8)) in the loop will read 8 bytes i.e. one byte past the end of the array:
> // num_words (zero-based) = (haystack_len - 1) / 8;
> __ movq(index, haystack_len);
> __ subq(index, 1);
> __ shrq(index, LogBytesPerWord);
>
> __ bind(L_loop);
> __ movq(XMM_TMP1, Address(haystack, index, Address::times_8));
> __ movq(Address(rsp, index, Address::times_8), XMM_TMP1);
> __ subq(index, 1);
> __ jcc(Assembler::positive, L_loop);
Yes, and that is intentional.
Say, haystack_len is 7, then the first block computes the adjustment of the haystack, which is 8 - (7 % 8) = 1. We adjust the haystack pointer one byte down, so that when we copy (multiple of) 8 bytes, we land on the last byte. We do copy a few bytes that are preceding the array, which is part of the object header and guaranteed to be >= 8 bytes.
Then we compute the number of words to copy, but make it 0-based. That is '0' is 1 word, '1' is 2 words, etc. It makes the loop nicer. In this example we get 0, which means we copy one word from the adjusted haystack, which is correct.
Then comes the actual loop.
Afterwards we adjust the haystack pointer so that it points to the first array element that we just copied onto the stack, ignoring the few garbage bytes that we also copied.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1787528501
From rkennke at openjdk.org Fri Oct 4 11:15:37 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 4 Oct 2024 11:15:37 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v30]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <aU7Oq51P0gFTm6hW7hQW_fmAYCdLG6JlqW6lBOkaRKE=.e30fa902-dc09-4944-8983-2c14ad068cf1@github.com>
> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>
> Main changes:
> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
> - Arrays will now store their length at offset 8.
> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...
Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 76 commits:
- Merge remote-tracking branch 'rkennke/JDK-8305895-v4' into JDK-8305895-v4
- Revert "Disable TestSplitPacks::test4a, failing on aarch64"
This reverts commit 059b1573db26d1d2902ca6dadc8413f445234c2a.
- Simplify object init code in interpreter
- Disable some vectorization tests that fail with +UCOH and UseSSE<=3
- Fix for CDSPluginTest.java
- Merge tag 'jdk-24+18' into JDK-8305895-v4
Added tag jdk-24+18 for changeset 19642bd3
- Disable TestSplitPacks::test4a, failing on aarch64
- @robcasloz review comments
- Improve CollectedHeap::is_oop()
- Allow LM_MONITOR on 32-bit platforms
- ... and 66 more: https://git.openjdk.org/jdk/compare/19642bd3...8742f3c1
-------------
Changes: https://git.openjdk.org/jdk/pull/20677/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=29
Stats: 4560 lines in 196 files changed: 3207 ins; 724 del; 629 mod
Patch: https://git.openjdk.org/jdk/pull/20677.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677
PR: https://git.openjdk.org/jdk/pull/20677
From mbaesken at openjdk.org Fri Oct 4 11:49:37 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 4 Oct 2024 11:49:37 GMT
Subject: RFR: 8340945: Ubsan: oopStorage.cpp:374:8: runtime error: applying
non-zero offset 18446744073709551168 to null pointer
In-Reply-To: <1uTdfa0c-Nrk1-6t0IPbYRmwy9URAHyz7-V4YHx5hDo=.377970e5-1b31-4658-94fc-e232bfbdec3b@github.com>
References: <1uTdfa0c-Nrk1-6t0IPbYRmwy9URAHyz7-V4YHx5hDo=.377970e5-1b31-4658-94fc-e232bfbdec3b@github.com>
Message-ID: <9zmxxLvVwPj0HZF0wbCB1MZ3zNuBzhDGJlw1GYBSxcE=.183e74d7-6a16-44f7-b65c-253eee196368@github.com>
On Sat, 28 Sep 2024 05:20:23 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:
> Please review this change to the OopStorage handling of storage block lookup,
> now being more careful about pointer arithmetic to avoid UB.
>
> As an initial cleanup, renamed OopStorage::find_block_or_null to
> block_for_ptr, for consistency with the Block function that implements it.
> Also moved the precondition assert that the argument is non-null into the
> Block function, where the requirement is located.
>
> Changed OopStorage::Block::block_for_ptr to avoid pointer arithmetic that
> might invoke UB, instead converting the pointer argument to uintptr_t and
> performing arithmetic on it. Also fixed its description in the header file.
>
> Similarly changed OopStorage::Block::active_index_safe to avoid pointer
> arithmetic, instead converting to uintptr_t for arithmetic. This avoids
> potential problems when the Block argument is a "false positive" from
> block_for_ptr.
>
> Changed OopStorage::allocation_status to check up front for a null argument,
> immediately returning INVALID_ENTRY in that case. This avoids voilating
> block_for_ptr's precondition that the argument is non-null. Added a gtest for
> this. Also added a gtest for the potential false-positive case.
>
> While updating gtests, removed #ifndef DISABLE_GARBAGE_ALLOCATION_STATUS_TESTS.
> That macro was included when these tests were first added, because some tests
> needed to be disabled on Windows, due to SafeFetchN in gtest context not working
> on that platform. That was later fixed by JDK-8185734. The conditional #define
> of that macro in test_oopStorage.cpp was removed, but the no longer needed
> #ifndef was inadvertently not removed.
>
> Testing: mach5 tier1-5
> Locally (linux-x64) reproduced the reported ubsan failure, and verified it no
> longer reproduces with these changes.
>
> While working on this change I noticed a related issue. The recently added
> OopStorage::print_containing doesn't verify the block is not a false positive
> before using it as a block. I'll file a JBS issue for this.
Marked as reviewed by mbaesken (Reviewer).
-------------
PR Review: https://git.openjdk.org/jdk/pull/21240#pullrequestreview-2347863489
From coleenp at openjdk.org Fri Oct 4 12:53:53 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 4 Oct 2024 12:53:53 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v30]
In-Reply-To: <aU7Oq51P0gFTm6hW7hQW_fmAYCdLG6JlqW6lBOkaRKE=.e30fa902-dc09-4944-8983-2c14ad068cf1@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<aU7Oq51P0gFTm6hW7hQW_fmAYCdLG6JlqW6lBOkaRKE=.e30fa902-dc09-4944-8983-2c14ad068cf1@github.com>
Message-ID: <lHkEF3XJ_h4c3dOro7V35aYk154SucAB8p7Px-2eLyI=.e4680e9a-1df7-47d1-adbc-203e85861035@github.com>
On Fri, 4 Oct 2024 11:15:37 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>>
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>>
>> Main changes:
>> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>> - Arrays will now store their length at offset 8.
>> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 76 commits:
>
> - Merge remote-tracking branch 'rkennke/JDK-8305895-v4' into JDK-8305895-v4
> - Revert "Disable TestSplitPacks::test4a, failing on aarch64"
>
> This reverts commit 059b1573db26d1d2902ca6dadc8413f445234c2a.
> - Simplify object init code in interpreter
> - Disable some vectorization tests that fail with +UCOH and UseSSE<=3
> - Fix for CDSPluginTest.java
> - Merge tag 'jdk-24+18' into JDK-8305895-v4
>
> Added tag jdk-24+18 for changeset 19642bd3
> - Disable TestSplitPacks::test4a, failing on aarch64
> - @robcasloz review comments
> - Improve CollectedHeap::is_oop()
> - Allow LM_MONITOR on 32-bit platforms
> - ... and 66 more: https://git.openjdk.org/jdk/compare/19642bd3...8742f3c1
There's another test failure that we're seeing that's similar to this bug in mainline when running with -XX:+UseCompactObjectHeaders on aarch64: https://bugs.openjdk.org/browse/JDK-8340212
-------------
PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2393637283
From zgu at openjdk.org Fri Oct 4 14:42:15 2024
From: zgu at openjdk.org (Zhengyu Gu)
Date: Fri, 4 Oct 2024 14:42:15 GMT
Subject: RFR: 8341332: Refactor array chunking statistics counters
Message-ID: <M0BH81KIMD9ma5OX2bSlzpXCQUQceQiG4KacOe0-w-E=.f9711efa-b255-4515-9286-2c8e46fd1235@github.com>
Please review this patch that consolidates array chunking statistics counting and reporting inside task queue and task queue set. Also consolidating partial array chunking and processing into `PartialArrayProcessor` to reduce duplicate code.
-------------
Commit messages:
- remove empty line
- Cleanup
- Cleanup
- v2
- v1
- add new files
- v0
Changes: https://git.openjdk.org/jdk/pull/21343/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21343&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8341332
Stats: 448 lines in 10 files changed: 277 ins; 116 del; 55 mod
Patch: https://git.openjdk.org/jdk/pull/21343.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/21343/head:pull/21343
PR: https://git.openjdk.org/jdk/pull/21343
From kbarrett at openjdk.org Fri Oct 4 16:01:38 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 4 Oct 2024 16:01:38 GMT
Subject: RFR: 8340945: Ubsan: oopStorage.cpp:374:8: runtime error: applying
non-zero offset 18446744073709551168 to null pointer
In-Reply-To: <GXtisYQsJzRmKg4XjtDl6uPHjAYSltJkd-3JfmmdBK0=.490a65c5-5957-4821-96d9-2c6fdbc059d8@github.com>
References: <1uTdfa0c-Nrk1-6t0IPbYRmwy9URAHyz7-V4YHx5hDo=.377970e5-1b31-4658-94fc-e232bfbdec3b@github.com>
<GXtisYQsJzRmKg4XjtDl6uPHjAYSltJkd-3JfmmdBK0=.490a65c5-5957-4821-96d9-2c6fdbc059d8@github.com>
Message-ID: <AnQGakww7S_4r5VXL603hurPlGvsIpljJMFZC_501JM=.a08b58a7-c79e-4f2e-93d3-7624b0fffe7c@github.com>
On Mon, 30 Sep 2024 08:29:17 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:
>> Please review this change to the OopStorage handling of storage block lookup,
>> now being more careful about pointer arithmetic to avoid UB.
>>
>> As an initial cleanup, renamed OopStorage::find_block_or_null to
>> block_for_ptr, for consistency with the Block function that implements it.
>> Also moved the precondition assert that the argument is non-null into the
>> Block function, where the requirement is located.
>>
>> Changed OopStorage::Block::block_for_ptr to avoid pointer arithmetic that
>> might invoke UB, instead converting the pointer argument to uintptr_t and
>> performing arithmetic on it. Also fixed its description in the header file.
>>
>> Similarly changed OopStorage::Block::active_index_safe to avoid pointer
>> arithmetic, instead converting to uintptr_t for arithmetic. This avoids
>> potential problems when the Block argument is a "false positive" from
>> block_for_ptr.
>>
>> Changed OopStorage::allocation_status to check up front for a null argument,
>> immediately returning INVALID_ENTRY in that case. This avoids voilating
>> block_for_ptr's precondition that the argument is non-null. Added a gtest for
>> this. Also added a gtest for the potential false-positive case.
>>
>> While updating gtests, removed #ifndef DISABLE_GARBAGE_ALLOCATION_STATUS_TESTS.
>> That macro was included when these tests were first added, because some tests
>> needed to be disabled on Windows, due to SafeFetchN in gtest context not working
>> on that platform. That was later fixed by JDK-8185734. The conditional #define
>> of that macro in test_oopStorage.cpp was removed, but the no longer needed
>> #ifndef was inadvertently not removed.
>>
>> Testing: mach5 tier1-5
>> Locally (linux-x64) reproduced the reported ubsan failure, and verified it no
>> longer reproduces with these changes.
>>
>> While working on this change I noticed a related issue. The recently added
>> OopStorage::print_containing doesn't verify the block is not a false positive
>> before using it as a block. I'll file a JBS issue for this.
>
> Marked as reviewed by tschatzl (Reviewer).
Thanks for reviews @tschatzl and @MBaesken .
-------------
PR Comment: https://git.openjdk.org/jdk/pull/21240#issuecomment-2394012889
From kbarrett at openjdk.org Fri Oct 4 16:01:39 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 4 Oct 2024 16:01:39 GMT
Subject: Integrated: 8340945: Ubsan: oopStorage.cpp:374:8: runtime error:
applying non-zero offset 18446744073709551168 to null pointer
In-Reply-To: <1uTdfa0c-Nrk1-6t0IPbYRmwy9URAHyz7-V4YHx5hDo=.377970e5-1b31-4658-94fc-e232bfbdec3b@github.com>
References: <1uTdfa0c-Nrk1-6t0IPbYRmwy9URAHyz7-V4YHx5hDo=.377970e5-1b31-4658-94fc-e232bfbdec3b@github.com>
Message-ID: <AZjhIMA9Tbfl7boPvEJqSm7kc3EwdY6WPq0YCriJ3yk=.48cc212f-fe3c-4bff-9c6c-9eb3cfad86be@github.com>
On Sat, 28 Sep 2024 05:20:23 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:
> Please review this change to the OopStorage handling of storage block lookup,
> now being more careful about pointer arithmetic to avoid UB.
>
> As an initial cleanup, renamed OopStorage::find_block_or_null to
> block_for_ptr, for consistency with the Block function that implements it.
> Also moved the precondition assert that the argument is non-null into the
> Block function, where the requirement is located.
>
> Changed OopStorage::Block::block_for_ptr to avoid pointer arithmetic that
> might invoke UB, instead converting the pointer argument to uintptr_t and
> performing arithmetic on it. Also fixed its description in the header file.
>
> Similarly changed OopStorage::Block::active_index_safe to avoid pointer
> arithmetic, instead converting to uintptr_t for arithmetic. This avoids
> potential problems when the Block argument is a "false positive" from
> block_for_ptr.
>
> Changed OopStorage::allocation_status to check up front for a null argument,
> immediately returning INVALID_ENTRY in that case. This avoids voilating
> block_for_ptr's precondition that the argument is non-null. Added a gtest for
> this. Also added a gtest for the potential false-positive case.
>
> While updating gtests, removed #ifndef DISABLE_GARBAGE_ALLOCATION_STATUS_TESTS.
> That macro was included when these tests were first added, because some tests
> needed to be disabled on Windows, due to SafeFetchN in gtest context not working
> on that platform. That was later fixed by JDK-8185734. The conditional #define
> of that macro in test_oopStorage.cpp was removed, but the no longer needed
> #ifndef was inadvertently not removed.
>
> Testing: mach5 tier1-5
> Locally (linux-x64) reproduced the reported ubsan failure, and verified it no
> longer reproduces with these changes.
>
> While working on this change I noticed a related issue. The recently added
> OopStorage::print_containing doesn't verify the block is not a false positive
> before using it as a block. I'll file a JBS issue for this.
This pull request has now been integrated.
Changeset: feb6a830
Author: Kim Barrett <kbarrett at openjdk.org>
URL: https://git.openjdk.org/jdk/commit/feb6a830e291ff71e2803e37be6c35c237f7c1cf
Stats: 69 lines in 4 files changed: 37 ins; 4 del; 28 mod
8340945: Ubsan: oopStorage.cpp:374:8: runtime error: applying non-zero offset 18446744073709551168 to null pointer
Reviewed-by: tschatzl, mbaesken
-------------
PR: https://git.openjdk.org/jdk/pull/21240
From phh at openjdk.org Fri Oct 4 16:39:41 2024
From: phh at openjdk.org (Paul Hohensee)
Date: Fri, 4 Oct 2024 16:39:41 GMT
Subject: RFR: 8341379: Shenandoah: Improve lock contention during cleanup
[v3]
In-Reply-To: <2QJqfhzQfJk9ZDN1AI3QR2KpLvGA-djz8U-Cv7OeKGo=.708970da-45e6-41db-a3cd-86ca272d8a14@github.com>
References: <5GMjFWaMjkSuxhPJ8TYJyw_LYdFfhJWrySSaRUjSNq4=.0ee7f896-35b2-43aa-a243-418b1ffb50b0@github.com>
<2QJqfhzQfJk9ZDN1AI3QR2KpLvGA-djz8U-Cv7OeKGo=.708970da-45e6-41db-a3cd-86ca272d8a14@github.com>
Message-ID: <CRSXXAVFyg8jhZtpIA2MBbzteRUjhCPYjbLZzPazBkk=.6b1f8e9e-9e7f-41bd-ab47-6d08f83726a2@github.com>
On Thu, 3 Oct 2024 21:30:12 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:
>> This change improves the efficiency of cleaning up (recycling) regions that have been trashed by GC effort. The affected code runs at the end of FinalMark to reclaim immediate garbage. It runs at the end of FinalUpdateRefs to reclaim the regions that comprised the collection set, from which all live objects have now been evacuated.
>>
>> Efficiency improvements include:
>> 1. Rather than invoking the os (while holding the Heap lock) to obtain the time twice for every region recycled, we invoke the os only once for each batch of 32 regions that are to be processed.
>> 2. Rather than enforcing that the loop runs no longer than 30 us, we refrain from starting a second batch of regions if more than 8 us has passed since the preceding batch was processed.
>>
>> Below, each trial runs for 1 hour, processing 28,000 transactions per second.
>>
>> Without this change, latency for 4 un-named business services is represented by the following chart:
>> 
>>
>> With this change, latency for the same services is much better:
>> 
>>
>> A comparison of the two is provided by the following:
>> 
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>
> fix typo
Marked as reviewed by phh (Reviewer).
-------------
PR Review: https://git.openjdk.org/jdk/pull/21211#pullrequestreview-2348488078
From duke at openjdk.org Fri Oct 4 17:13:40 2024
From: duke at openjdk.org (duke)
Date: Fri, 4 Oct 2024 17:13:40 GMT
Subject: RFR: 8341379: Shenandoah: Improve lock contention during cleanup
[v3]
In-Reply-To: <2QJqfhzQfJk9ZDN1AI3QR2KpLvGA-djz8U-Cv7OeKGo=.708970da-45e6-41db-a3cd-86ca272d8a14@github.com>
References: <5GMjFWaMjkSuxhPJ8TYJyw_LYdFfhJWrySSaRUjSNq4=.0ee7f896-35b2-43aa-a243-418b1ffb50b0@github.com>
<2QJqfhzQfJk9ZDN1AI3QR2KpLvGA-djz8U-Cv7OeKGo=.708970da-45e6-41db-a3cd-86ca272d8a14@github.com>
Message-ID: <p8nkwxtDn0dLyJtZ1KfMdyen3y_wr6lewJxnIZpbu4Q=.22b18078-31c1-47fc-bdfe-278e6e722f82@github.com>
On Thu, 3 Oct 2024 21:30:12 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:
>> This change improves the efficiency of cleaning up (recycling) regions that have been trashed by GC effort. The affected code runs at the end of FinalMark to reclaim immediate garbage. It runs at the end of FinalUpdateRefs to reclaim the regions that comprised the collection set, from which all live objects have now been evacuated.
>>
>> Efficiency improvements include:
>> 1. Rather than invoking the os (while holding the Heap lock) to obtain the time twice for every region recycled, we invoke the os only once for each batch of 32 regions that are to be processed.
>> 2. Rather than enforcing that the loop runs no longer than 30 us, we refrain from starting a second batch of regions if more than 8 us has passed since the preceding batch was processed.
>>
>> Below, each trial runs for 1 hour, processing 28,000 transactions per second.
>>
>> Without this change, latency for 4 un-named business services is represented by the following chart:
>> 
>>
>> With this change, latency for the same services is much better:
>> 
>>
>> A comparison of the two is provided by the following:
>> 
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>
> fix typo
@kdnilsen
Your change (at version 055ad41109b303ab474c2510cc496a3cf87135b8) is now ready to be sponsored by a Committer.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/21211#issuecomment-2394174956
From kbarrett at openjdk.org Fri Oct 4 17:32:38 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 4 Oct 2024 17:32:38 GMT
Subject: RFR: 8341332: Refactor array chunking statistics counters
In-Reply-To: <M0BH81KIMD9ma5OX2bSlzpXCQUQceQiG4KacOe0-w-E=.f9711efa-b255-4515-9286-2c8e46fd1235@github.com>
References: <M0BH81KIMD9ma5OX2bSlzpXCQUQceQiG4KacOe0-w-E=.f9711efa-b255-4515-9286-2c8e46fd1235@github.com>
Message-ID: <YIZCU_MiT_Y5l-DlGH5B9U1qI2EgBQLgkltZWW5_zv4=.a4af4e75-17b0-440b-ae43-cb5d1533b322@github.com>
On Fri, 4 Oct 2024 01:41:50 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:
> Please review this patch that consolidates array chunking statistics counting and reporting inside task queue and task queue set. Also consolidating partial array chunking and processing into `PartialArrayProcessor` to reduce duplicate code.
I hadn't noticed the associated JBS issue and that you'd started working on it.
I've also started working on the same problem, but taking a different approach.
I think the approach being taken in this PR is continuing a problematic design
approach already present in the existing code. I'd rather we didn't do that.
Virtual functions tend to combine poorly with class templates. I think there's
not actually any need for runtime polymorphism in the taskqueue stuff. Adding
more is not appealing to me.
I think the basic taskqueue and its associated statistics form a generic utility
that could be used anywhere one needs parallel task queues with work stealing
(so long as the tasks can meet the necessary requirements - see the discussion
with the implementation of pop_global). I don't think inheritance is the best
way to augment them. I think the existing use of inheritance for overflow
queues, and inclusion of overflow stats in TaskQueueStats, are design errors.
This PR proposes to do more of that.
I think task specifics ought to be kept separate from the generic taskqueue,
which doesn't really need to know anything about them. So I think, for example,
that the various task types ought not be in the taskqueue files, but should be
in their own files.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/21343#issuecomment-2394206125
From ysr at openjdk.org Fri Oct 4 17:32:42 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 4 Oct 2024 17:32:42 GMT
Subject: RFR: 8341379: Shenandoah: Improve lock contention during cleanup
[v3]
In-Reply-To: <2QJqfhzQfJk9ZDN1AI3QR2KpLvGA-djz8U-Cv7OeKGo=.708970da-45e6-41db-a3cd-86ca272d8a14@github.com>
References: <5GMjFWaMjkSuxhPJ8TYJyw_LYdFfhJWrySSaRUjSNq4=.0ee7f896-35b2-43aa-a243-418b1ffb50b0@github.com>
<2QJqfhzQfJk9ZDN1AI3QR2KpLvGA-djz8U-Cv7OeKGo=.708970da-45e6-41db-a3cd-86ca272d8a14@github.com>
Message-ID: <b33_eUu9ko2CcVdR5wDtUYVQ5k2cFD8R3tZtuWXpFI0=.4c8e8abb-9571-4f4d-a83b-ebf1c298b881@github.com>
On Thu, 3 Oct 2024 21:30:12 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:
>> This change improves the efficiency of cleaning up (recycling) regions that have been trashed by GC effort. The affected code runs at the end of FinalMark to reclaim immediate garbage. It runs at the end of FinalUpdateRefs to reclaim the regions that comprised the collection set, from which all live objects have now been evacuated.
>>
>> Efficiency improvements include:
>> 1. Rather than invoking the os (while holding the Heap lock) to obtain the time twice for every region recycled, we invoke the os only once for each batch of 32 regions that are to be processed.
>> 2. Rather than enforcing that the loop runs no longer than 30 us, we refrain from starting a second batch of regions if more than 8 us has passed since the preceding batch was processed.
>>
>> Below, each trial runs for 1 hour, processing 28,000 transactions per second.
>>
>> Without this change, latency for 4 un-named business services is represented by the following chart:
>> 
>>
>> With this change, latency for the same services is much better:
>> 
>>
>> A comparison of the two is provided by the following:
>> 
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>
> fix typo
Nice!
-------------
PR Comment: https://git.openjdk.org/jdk/pull/21211#issuecomment-2394202215
From kdnilsen at openjdk.org Fri Oct 4 17:32:43 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 4 Oct 2024 17:32:43 GMT
Subject: Integrated: 8341379: Shenandoah: Improve lock contention during
cleanup
In-Reply-To: <5GMjFWaMjkSuxhPJ8TYJyw_LYdFfhJWrySSaRUjSNq4=.0ee7f896-35b2-43aa-a243-418b1ffb50b0@github.com>
References: <5GMjFWaMjkSuxhPJ8TYJyw_LYdFfhJWrySSaRUjSNq4=.0ee7f896-35b2-43aa-a243-418b1ffb50b0@github.com>
Message-ID: <fkUWzeN7YdmpBB-J4faKA3RblauD8WghXOIjuWcUjsE=.78cb25df-d82e-4236-9984-9bad9f4b151b@github.com>
On Thu, 26 Sep 2024 21:08:11 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:
> This change improves the efficiency of cleaning up (recycling) regions that have been trashed by GC effort. The affected code runs at the end of FinalMark to reclaim immediate garbage. It runs at the end of FinalUpdateRefs to reclaim the regions that comprised the collection set, from which all live objects have now been evacuated.
>
> Efficiency improvements include:
> 1. Rather than invoking the os (while holding the Heap lock) to obtain the time twice for every region recycled, we invoke the os only once for each batch of 32 regions that are to be processed.
> 2. Rather than enforcing that the loop runs no longer than 30 us, we refrain from starting a second batch of regions if more than 8 us has passed since the preceding batch was processed.
>
> Below, each trial runs for 1 hour, processing 28,000 transactions per second.
>
> Without this change, latency for 4 un-named business services is represented by the following chart:
> 
>
> With this change, latency for the same services is much better:
> 
>
> A comparison of the two is provided by the following:
> 
This pull request has now been integrated.
Changeset: f5f0852f
Author: Kelvin Nilsen <kdnilsen at openjdk.org>
URL: https://git.openjdk.org/jdk/commit/f5f0852f51d3dc1001bf3d68b89f4aab31e05e61
Stats: 40 lines in 1 file changed: 32 ins; 4 del; 4 mod
8341379: Shenandoah: Improve lock contention during cleanup
Reviewed-by: xpeng, phh, wkemper
-------------
PR: https://git.openjdk.org/jdk/pull/21211
From wkemper at openjdk.org Fri Oct 4 19:28:08 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 4 Oct 2024 19:28:08 GMT
Subject: RFR: 8341554: Shenandoah: Missing heap lock when updating usage for
soft ref policy
Message-ID: <vzett0HDc9woTK5zUQh5ISrxCdpMpixxeeGIv0XqvmU=.305f3e59-f893-46d8-b073-f897ff85da7a@github.com>
A recent change to avoid checking the log level under the lock inadvertently removed the lock from an operation that needs it.
-------------
Commit messages:
- Restore missing heap lock when updating usage at last gc
Changes: https://git.openjdk.org/jdk/pull/21362/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21362&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8341554
Stats: 7 lines in 1 file changed: 3 ins; 0 del; 4 mod
Patch: https://git.openjdk.org/jdk/pull/21362.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/21362/head:pull/21362
PR: https://git.openjdk.org/jdk/pull/21362
From kdnilsen at openjdk.org Fri Oct 4 19:28:08 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 4 Oct 2024 19:28:08 GMT
Subject: RFR: 8341554: Shenandoah: Missing heap lock when updating usage
for soft ref policy
In-Reply-To: <vzett0HDc9woTK5zUQh5ISrxCdpMpixxeeGIv0XqvmU=.305f3e59-f893-46d8-b073-f897ff85da7a@github.com>
References: <vzett0HDc9woTK5zUQh5ISrxCdpMpixxeeGIv0XqvmU=.305f3e59-f893-46d8-b073-f897ff85da7a@github.com>
Message-ID: <8olxAEXHXd9rybQFElBljiWNI2pfyAk-jnsKptCDwsw=.8963ecb2-8d1c-444f-a7a2-417232a1690e@github.com>
On Fri, 4 Oct 2024 19:18:42 GMT, William Kemper <wkemper at openjdk.org> wrote:
> A recent change to avoid checking the log level under the lock inadvertently removed the lock from an operation that needs it.
Marked as reviewed by kdnilsen (Author).
-------------
PR Review: https://git.openjdk.org/jdk/pull/21362#pullrequestreview-2348975142
From ysr at openjdk.org Fri Oct 4 20:43:36 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 4 Oct 2024 20:43:36 GMT
Subject: RFR: 8341554: Shenandoah: Missing heap lock when updating usage
for soft ref policy
In-Reply-To: <vzett0HDc9woTK5zUQh5ISrxCdpMpixxeeGIv0XqvmU=.305f3e59-f893-46d8-b073-f897ff85da7a@github.com>
References: <vzett0HDc9woTK5zUQh5ISrxCdpMpixxeeGIv0XqvmU=.305f3e59-f893-46d8-b073-f897ff85da7a@github.com>
Message-ID: <M2hTMrbAtzVJ-baCCUC1BtW6PJbp8okg4TSbsUhHF5E=.2091bc72-2ca0-4bf2-b604-401552beeb0a@github.com>
On Fri, 4 Oct 2024 19:18:42 GMT, William Kemper <wkemper at openjdk.org> wrote:
> A recent change to avoid checking the log level under the lock inadvertently removed the lock from an operation that needs it.
Good catch by @kdnilsen !
Sorry for missing this in the previous review at https://github.com/openjdk/jdk/pull/19915 for @pengxiaolong.
src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp line 186:
> 184: ShenandoahHeapLocker locker(heap->lock());
> 185: heap->update_capacity_and_used_at_gc();
> 186: }
If free set logging is enabled this does a lock/unlock for logging and then another lock/unlock for updating capacity.
But I guess it's unavoidable, and it likely won't be the case that we have free set logging enabled in performance critical production situations, so not worth wasting too much sleep over.
Reviewed!
-------------
Marked as reviewed by ysr (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/21362#pullrequestreview-2349091755
PR Review Comment: https://git.openjdk.org/jdk/pull/21362#discussion_r1788281685
From ysr at openjdk.org Fri Oct 4 20:52:37 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 4 Oct 2024 20:52:37 GMT
Subject: RFR: 8341554: Shenandoah: Missing heap lock when updating usage
for soft ref policy
In-Reply-To: <M2hTMrbAtzVJ-baCCUC1BtW6PJbp8okg4TSbsUhHF5E=.2091bc72-2ca0-4bf2-b604-401552beeb0a@github.com>
References: <vzett0HDc9woTK5zUQh5ISrxCdpMpixxeeGIv0XqvmU=.305f3e59-f893-46d8-b073-f897ff85da7a@github.com>
<M2hTMrbAtzVJ-baCCUC1BtW6PJbp8okg4TSbsUhHF5E=.2091bc72-2ca0-4bf2-b604-401552beeb0a@github.com>
Message-ID: <KOjMvQy3Nx-aK8pTUaAw_8tB6lCHiZZsZYGQKtWupRY=.225ec9be-91cf-4fc1-af9c-5603a2b08db4@github.com>
On Fri, 4 Oct 2024 20:34:58 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:
>> A recent change to avoid checking the log level under the lock inadvertently removed the lock from an operation that needs it.
>
> src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp line 186:
>
>> 184: ShenandoahHeapLocker locker(heap->lock());
>> 185: heap->update_capacity_and_used_at_gc();
>> 186: }
>
> If free set logging is enabled this does a lock/unlock for logging and then another lock/unlock for updating capacity.
>
> But I guess it's unavoidable, and it likely won't be the case that we have free set logging enabled in performance critical production situations, so not worth wasting too much sleep over.
>
> Reviewed!
@earthling-amzn : I'd suggest leaving a comment either in the ticket or in the PR (or here in the code?) stating the race that we are vulnerable to if we don't hold the lock, namely the potential skew between used & capacity, and why it's important not to have that skew for consumers of these fields. I imagine that we can demonstrate the issue with a targeted regression test.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/21362#discussion_r1788297486
From wkemper at openjdk.org Fri Oct 4 21:58:44 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 4 Oct 2024 21:58:44 GMT
Subject: Integrated: 8341554: Shenandoah: Missing heap lock when updating usage
for soft ref policy
In-Reply-To: <vzett0HDc9woTK5zUQh5ISrxCdpMpixxeeGIv0XqvmU=.305f3e59-f893-46d8-b073-f897ff85da7a@github.com>
References: <vzett0HDc9woTK5zUQh5ISrxCdpMpixxeeGIv0XqvmU=.305f3e59-f893-46d8-b073-f897ff85da7a@github.com>
Message-ID: <rHHWeuYO_r6yRwlsAJLIuv_Gyu_l6nDV7pGUC2eyZRs=.dcd76a04-6956-49fd-b6bf-13cc1e89b72d@github.com>
On Fri, 4 Oct 2024 19:18:42 GMT, William Kemper <wkemper at openjdk.org> wrote:
> A recent change to avoid checking the log level under the lock inadvertently removed the lock from an operation that needs it.
This pull request has now been integrated.
Changeset: bade041d
Author: William Kemper <wkemper at openjdk.org>
URL: https://git.openjdk.org/jdk/commit/bade041db82a09cf33d4dbcc849f5784b3851f3d
Stats: 7 lines in 1 file changed: 3 ins; 0 del; 4 mod
8341554: Shenandoah: Missing heap lock when updating usage for soft ref policy
Reviewed-by: kdnilsen, ysr
-------------
PR: https://git.openjdk.org/jdk/pull/21362
From wkemper at openjdk.org Fri Oct 4 21:58:44 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 4 Oct 2024 21:58:44 GMT
Subject: RFR: 8341554: Shenandoah: Missing heap lock when updating usage
for soft ref policy
In-Reply-To: <KOjMvQy3Nx-aK8pTUaAw_8tB6lCHiZZsZYGQKtWupRY=.225ec9be-91cf-4fc1-af9c-5603a2b08db4@github.com>
References: <vzett0HDc9woTK5zUQh5ISrxCdpMpixxeeGIv0XqvmU=.305f3e59-f893-46d8-b073-f897ff85da7a@github.com>
<M2hTMrbAtzVJ-baCCUC1BtW6PJbp8okg4TSbsUhHF5E=.2091bc72-2ca0-4bf2-b604-401552beeb0a@github.com>
<KOjMvQy3Nx-aK8pTUaAw_8tB6lCHiZZsZYGQKtWupRY=.225ec9be-91cf-4fc1-af9c-5603a2b08db4@github.com>
Message-ID: <aI3SFLLPbbc3Qh5D5-zRI0T7yQ8085E3Yhh4Ry0kaxw=.2e3c6223-d93b-4230-80d1-f44c74cbfd39@github.com>
On Fri, 4 Oct 2024 20:48:35 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:
>> src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp line 186:
>>
>>> 184: ShenandoahHeapLocker locker(heap->lock());
>>> 185: heap->update_capacity_and_used_at_gc();
>>> 186: }
>>
>> If free set logging is enabled this does a lock/unlock for logging and then another lock/unlock for updating capacity.
>>
>> But I guess it's unavoidable, and it likely won't be the case that we have free set logging enabled in performance critical production situations, so not worth wasting too much sleep over.
>>
>> Reviewed!
>
> @earthling-amzn : I'd suggest leaving a comment either in the ticket or in the PR (or here in the code?) stating the race that we are vulnerable to if we don't hold the lock, namely the potential skew between used & capacity, and why it's important not to have that skew for consumers of these fields. I imagine that we can demonstrate the issue with a targeted regression test.
Yeah, I think coupling the lock with the logging and `update_capacity_and_used` is what led us into trouble to begin with.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/21362#discussion_r1788371332
From jonathanjoo at google.com Fri Oct 4 22:39:56 2024
From: jonathanjoo at google.com (Jonathan Joo)
Date: Fri, 4 Oct 2024 15:39:56 -0700
Subject: Further discussion on Adaptable Heap Sizing with G1
Message-ID: <CACz-JM5_UjhLj2Yng83y9G5VUkfPT2kiLDSdUe+2u9J=dG5UvQ@mail.gmail.com>
Hi All,
As Kirk mentioned in his email "Aligning the Serial collector with ZGC
<https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-September/049616.html>",
we are also working on adding Adaptable Heap Sizing (AHS) to G1.
I created a draft Pull Request <https://github.com/openjdk/jdk/pull/20783> and
received some comments on it already, including the following points:
1.
I should Convert CurrentMaxExpansionSize to CurrentMaxHeapSize.
2.
SoftMaxHeapSize, as implemented in the PR, is different from the
original intent.
3.
We need some sort of global memory pressure to enforce heap shrinkage.
The first point I already addressed on the pull request, and I agree that
CurrentMaxHeapSize works well :)
Regarding the second point, we had some discussions already outside of this
mailing list, but if I were to summarize the main ideas, they are:
1.
The intent of SoftMaxHeapSize initially was for the GC to use this value
as a guide for when to start concurrent GC.
2.
Our implementation of SoftMaxHeapSize (in the PR) currently behaves more
like a ProposedHeapSize, where whenever we shrink and expand the heap, we
try to set the heap size to ProposedHeapSize, regardless of the value of
MinHeapSize.
3.
We need to ensure that the heap regularly approaches the value of
ProposedHeapSize by introducing some sort of periodic GC, which we have a
Google-internal patch for, and is not yet present in the PR. If we are in
alignment that this makes sense, I can try adding this as a separate PR.
For the third point, Similar to ZGC's -XX:ZGCPressure, we use
target_gc_cpu_overhead (along with periodic GC) to control heap shrinkage
by adjusting ProposedHeapSize. This allows users to balance RAM and CPU
usage. Note that this isn't yet present in the PR, since the PR only
includes the JVM changes introducing the CurrentMaxHeapSize and
ProposedHeapSize flags. The logic to actually dynamically calculate the
value of ProposedHeapSize would be a separate change, and can be iterated
on.
As a separate point - Kirk mentioned in his email that he aims to introduce
an adaptive size policy where "Heap should be large enough to minimize GC
overhead but not large enough to trigger OOM". I think from our experience
in G1, we don't actively try to minimize GC overhead, as we find that
maintaining a higher GC overhead often results in overall RAM savings >>
CPU usage.
I think as a general summary - the way I see it, there's value in creating
a simplified system where we control the majority of JVM behavior simply
with two flags - the maximum heap size (to prevent OOMs), and a target heap
size, which is our calculation of an "optimal" size based on our
understanding of the environment. The exact calculations for this optimal
size may change depending on workload/preference, but what we are trying to
do at this point in time is allow for a way to pass in some calculation for
"optimal heap size" and have G1 react to it in a meaningful way. I
acknowledge that the current JVM behavior (as implemented in my PR) may be
suboptimal in terms of getting the heap to get to and stay at this "optimal
heap size". However, even with the basic implementation of passing this
value to shrinks/expands and only triggering resizes on Remarks/Full GCs,
we've seen dramatic improvements in heap behavior at Google, compared to
the current G1.
I know there was some disagreement about the addition of this new "optimal
heap size" flag, and I agree that SoftMaxHeapSize is probably not the right
flag to represent this value. But I'd like to get some thoughts on whether
the above summary seems like a reasonable way of reasoning about G1 AHS. If
we agree, then we can always iteratively improve the JVM logic to better
adhere to the optimal heap size. But it's not yet clear to me whether
people are onboard the idea of having this "optimal heap size" calculation
at all, since perhaps this functionality could be covered in other,
existing ways.
Thank you!
~ Jonathan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20241004/4404d378/attachment-0001.htm>
From tschatzl at openjdk.org Mon Oct 7 08:27:41 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 7 Oct 2024 08:27:41 GMT
Subject: RFR: 8341238: G1: Refactor G1Policy to move collection set
selection methods into G1CollectionSet
In-Reply-To: <w8WhIXs7wxxicEK9S6UgxptkWYK5s96o7eco1leJe9I=.16087a7e-5a75-49de-9694-fb8980eb7ef7@github.com>
References: <w8WhIXs7wxxicEK9S6UgxptkWYK5s96o7eco1leJe9I=.16087a7e-5a75-49de-9694-fb8980eb7ef7@github.com>
Message-ID: <ruXg_8L-r2tQcqp9Zs0dUyQGVFPk29H12BGUjGl_ack=.f6bf14ad-bac0-4ea2-9812-6e9ed451b728@github.com>
On Fri, 4 Oct 2024 07:25:32 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:
> Hi,
>
> Please review this code migration patch to move collection set candidate selection methods out of G1Policy into G1CollectionSet. By relocating these methods, we can simplify the method signatures and reduce the interdependency between the classes.
>
> Testing: Tier 1
Marked as reviewed by tschatzl (Reviewer).
-------------
PR Review: https://git.openjdk.org/jdk/pull/21347#pullrequestreview-2351254930
From stefank at openjdk.org Mon Oct 7 08:55:59 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 7 Oct 2024 08:55:59 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v30]
In-Reply-To: <aU7Oq51P0gFTm6hW7hQW_fmAYCdLG6JlqW6lBOkaRKE=.e30fa902-dc09-4944-8983-2c14ad068cf1@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<aU7Oq51P0gFTm6hW7hQW_fmAYCdLG6JlqW6lBOkaRKE=.e30fa902-dc09-4944-8983-2c14ad068cf1@github.com>
Message-ID: <NtlirWYS-adgUWyhc0RA52WzClmcbtRuk3ykReYfsDg=.db48cc39-e30d-49e2-8a61-df4f40ecf73b@github.com>
On Fri, 4 Oct 2024 11:15:37 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>>
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>>
>> Main changes:
>> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>> - Arrays will now store their length at offset 8.
>> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 76 commits:
>
> - Merge remote-tracking branch 'rkennke/JDK-8305895-v4' into JDK-8305895-v4
> - Revert "Disable TestSplitPacks::test4a, failing on aarch64"
>
> This reverts commit 059b1573db26d1d2902ca6dadc8413f445234c2a.
> - Simplify object init code in interpreter
> - Disable some vectorization tests that fail with +UCOH and UseSSE<=3
> - Fix for CDSPluginTest.java
> - Merge tag 'jdk-24+18' into JDK-8305895-v4
>
> Added tag jdk-24+18 for changeset 19642bd3
> - Disable TestSplitPacks::test4a, failing on aarch64
> - @robcasloz review comments
> - Improve CollectedHeap::is_oop()
> - Allow LM_MONITOR on 32-bit platforms
> - ... and 66 more: https://git.openjdk.org/jdk/compare/19642bd3...8742f3c1
I realize that some of my comments was stuck as drafts and had not been published. I took an extra pass over the gc/ and most of oops/ with the intention to approve those parts. However, I see that the comment about `fill_dense_prefix_end` and `MinObjectAlignment` has not been addressed. I don't know if that change is correct, so it would be good to get that scrutinized.
src/hotspot/share/gc/shared/collectedHeap.cpp line 223:
> 221: }
> 222:
> 223: bool klass_is_sane(oop object) {
Should at least be static. We might also want to keep reporting errors if a klass pointer is null when we don't have a forwarded object:
static bool klass_is_sane(oop object) {
if (UseCompactObjectHeaders) {
// With compact headers, we can't safely access the Klass* when
// the object has been forwarded, because non-full-GC-forwarding
// distinction between Full-GC and regular GC forwarding.
markWord mark = object->mark();
if (mark.is_forwarded()) {
// We can't access the Klass*. We optimistically assume that
// it is ok. This happens very rarely.
return true;
}
return Metaspace::contains(mark.klass_without_asserts());
}
return Metaspace::contains(object->klass_without_asserts());
}
src/hotspot/share/oops/compressedKlass.cpp line 28:
> 26: #include "logging/log.hpp"
> 27: #include "memory/metaspace.hpp"
> 28: #include "oops/klass.hpp"
Is this include really needed or could this be reverted klass.hpp? If it is needed is should be moved to after compressedKlass.inline.hpp.
src/hotspot/share/oops/compressedKlass.cpp line 31:
> 29: #include "oops/compressedKlass.inline.hpp"
> 30: #include "runtime/globals.hpp"
> 31: #include "runtime/java.hpp"
Do you remember why this was added?
src/hotspot/share/oops/markWord.cpp line 35:
> 33: STATIC_ASSERT(markWord::klass_shift + markWord::klass_bits == 64);
> 34: // The hash (preceding nKlass) shall be a direct neighbor but not interleave
> 35: STATIC_ASSERT(markWord::klass_shift == markWord::hash_bits + markWord::hash_shift);
The code is not consistent in it usage of the name for the klass bits. Here it says `nKlass` in the comment, but the fields are named `klass`. Maybe just change the comment to says `(preceding klass bits)`.
Note that the term `nklass` is not prevalent in the code base, but with this patch its starting to get a foot hold. It might be good to figure out what we do want to call these in field names and variables to at least a little bit more consistency in the code base. Currently we have `nklass`, `nKlass` `nk`, `narrow_klass`.
In other places we have functions that are named `set_narrow_klass`, but the field is called `nklass` and other places call it `nk`. It would be good to stay consistent with the naming. FWIW, nklass has very little precedence in the code, so cleaning that away might be easiest.thing is to clean out all usages of nklass, because it isn't a
src/hotspot/share/oops/markWord.inline.hpp line 35:
> 33: assert(UseCompactObjectHeaders, "only used with compact object headers");
> 34: const narrowKlass nk = value() >> klass_shift;
> 35: return narrowKlass(value() >> klass_shift);
This sets up an unused variable.
```suggestion
const narrowKlass nk = value() >> klass_shift;
return narrowKlass(value() >> klass_shift);
-------------
PR Review: https://git.openjdk.org/jdk/pull/20677#pullrequestreview-2331450326
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1777180846
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1789757910
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1789759027
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1789787634
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1789790323
From stefank at openjdk.org Mon Oct 7 08:55:59 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 7 Oct 2024 08:55:59 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v21]
In-Reply-To: <-UEFgAIQjGBginN0JRoyuwwJLmDssUEQGE_tCP-tRkw=.01ef3f37-01fa-4931-b4f3-571d21252bbd@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<TCFshDmOrJjN0zTh1X9BGEa_rczyMqRbyDIiYsFr_5I=.ea051371-4c86-461e-8721-83b32caf808f@github.com>
<qPL-XuWVkfNYFmfYatyQZwbHismNzW_jXdvkDvIiVNc=.d4fd26a8-f509-494a-bd3d-0c6f37ba5269@github.com>
<-UEFgAIQjGBginN0JRoyuwwJLmDssUEQGE_tCP-tRkw=.01ef3f37-01fa-4931-b4f3-571d21252bbd@github.com>
Message-ID: <jj6GEQDn7YAPHbFlHtE6Hqx4BwCAUh2XEFLTJ1gBmeY=.faa0d50c-9e26-4dec-aeb9-15d3ca11b1b2@github.com>
On Thu, 19 Sep 2024 05:36:41 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:
>> src/hotspot/share/gc/parallel/psParallelCompact.cpp line 787:
>>
>>> 785: // The gap is always equal to min-fill-size, so nothing to do.
>>> 786: return;
>>> 787: }
>>
>> Reading the comment, it is not obvious that this is correct if you set MinObjectAlignment to something larger than the default value:
>>
>> void PSParallelCompact::fill_dense_prefix_end(SpaceId id) {
>> // Comparing two sizes to decide if filling is required:
>> //
>> // The size of the filler (min-obj-size) is 2 heap words with the default
>> // MinObjAlignment, since both markword and klass take 1 heap word.
>> //
>> // The size of the gap (if any) right before dense-prefix-end is
>> // MinObjAlignment.
>> //
>> // Need to fill in the gap only if it's smaller than min-obj-size, and the
>> // filler obj will extend to next region.
>>
>> // Note: If min-fill-size decreases to 1, this whole method becomes redundant.
>> if (UseCompactObjectHeaders) {
>> // The gap is always equal to min-fill-size, so nothing to do.
>> return;
>> }
>> assert(CollectedHeap::min_fill_size() >= 2, "inv");
>
> Style note: The added code is inserted between a comment and the code that the comment refers to. It would be nice to tidy this up.
Did you figure out if the code above is correct w.r.t. `MinObjectAlignment=16`?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1789797050
From stefank at openjdk.org Mon Oct 7 08:55:59 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 7 Oct 2024 08:55:59 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v9]
In-Reply-To: <CKaxMvoxrt7YLGw6Zee_SW8uBb8tg3j94mw-Mcf5u0I=.78240440-cee1-413b-ae49-1b85592d5ba7@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<6Rant6SjxpFIHHWNthWc_plOdnGpWPvqj3rxRe144po=.bcdbad7a-e93a-41a3-b958-6ae602c7e083@github.com>
<NR6CKOtdUaVarB7hiAUIAsIMe03qiTQr5VcEOWGt8mA=.164efc10-f0ff-4ddf-80b8-c56599c0ba7d@github.com>
<BNQiyA0NCBO-oFZU4Nz3yvaMxDzICFxfqDKWt4wCL_U=.9405414d-f961-4168-8d26-ef5f58069161@github.com>
<igBchd3diNsHdnQwZS2sj4tjaKejOq4f4EZovOmpmRQ=.abf79fee-9592-4555-ac01-de0170665ae4@github.com>
<BkuKSFHleaF8I2tWCDIC-rGlWnfGhbK1zQ6CLlB-rVE=.9c7976e3-b0e9-4356-8d4b-d880aa30bffa@github.com>
<ubcY5Q-aPRCLmhZV9MjBfzzbs84FegDvNkHx8nwPUd0=.46503fd8-d274-4558-bd0f-cc0c4f199667@github.com>
<2w9H6VAbxm7BgSGRwKAxbI56bG-k4bE_ZDviGrBF36o=.3d4cb47f-0f84-479a-a809-6d0186dfad2d@github.com>
<CKaxMvoxrt7YLGw6Zee_SW8uBb8tg3j94mw-Mcf5u0I=.78240440-cee1-413b-ae49-1b85592d5ba7@github.com>
Message-ID: <Hp2zrxh4JHI6OyCJY-KW30h6Tjxj5JeGAinxVNrE8wc=.abaa66fc-cfa8-429a-a179-d6e8075a55ac@github.com>
On Fri, 27 Sep 2024 16:31:55 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:
>> This is my current work-in-progress code:
>> https://github.com/stefank/jdk/compare/pull/20677...stefank:jdk:lilliput_remove_prototype_header_wip_2
>>
>> I've made some large rewrites and I'm currently running it through functional testing.
>
> If @stefank 's patch does not go in this PR, could you please export `Klass::_prototype_header` to JVMCI? Thanks!
>
> diff --git a/src/hotspot/share/jvmci/vmStructs_jvmci.cpp b/src/hotspot/share/jvmci/vmStructs_jvmci.cpp
> index 9d1b8a1cb9f..e462025074f 100644
> --- a/src/hotspot/share/jvmci/vmStructs_jvmci.cpp
> +++ b/src/hotspot/share/jvmci/vmStructs_jvmci.cpp
> @@ -278,6 +278,7 @@
> nonstatic_field(Klass, _bitmap, uintx) \
> nonstatic_field(Klass, _hash_slot, uint8_t) \
> nonstatic_field(Klass, _misc_flags._flags, u1) \
> + nonstatic_field(Klass, _prototype_header, markWord) \
> \
> nonstatic_field(LocalVariableTableElement, start_bci, u2) \
> nonstatic_field(LocalVariableTableElement, length, u2) \
My patch will not be included in this PR. After JEP 450 has been delivered we'll reconsider if we want that patch or not.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1778950736
From mli at openjdk.org Mon Oct 7 10:32:35 2024
From: mli at openjdk.org (Hamlin Li)
Date: Mon, 7 Oct 2024 10:32:35 GMT
Subject: RFR: 8341238: G1: Refactor G1Policy to move collection set
selection methods into G1CollectionSet
In-Reply-To: <w8WhIXs7wxxicEK9S6UgxptkWYK5s96o7eco1leJe9I=.16087a7e-5a75-49de-9694-fb8980eb7ef7@github.com>
References: <w8WhIXs7wxxicEK9S6UgxptkWYK5s96o7eco1leJe9I=.16087a7e-5a75-49de-9694-fb8980eb7ef7@github.com>
Message-ID: <CJIN12bX61w3HgWVqDeXBzXqFdSccz4TiAfMPHCcunY=.902b9a1e-6899-497b-83fc-845ffda714b3@github.com>
On Fri, 4 Oct 2024 07:25:32 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:
> Hi,
>
> Please review this code migration patch to move collection set candidate selection methods out of G1Policy into G1CollectionSet. By relocating these methods, we can simplify the method signatures and reduce the interdependency between the classes.
>
> Testing: Tier 1
Marked as reviewed by mli (Reviewer).
-------------
PR Review: https://git.openjdk.org/jdk/pull/21347#pullrequestreview-2351542265
From rkennke at openjdk.org Mon Oct 7 10:52:53 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 7 Oct 2024 10:52:53 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v21]
In-Reply-To: <jj6GEQDn7YAPHbFlHtE6Hqx4BwCAUh2XEFLTJ1gBmeY=.faa0d50c-9e26-4dec-aeb9-15d3ca11b1b2@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<TCFshDmOrJjN0zTh1X9BGEa_rczyMqRbyDIiYsFr_5I=.ea051371-4c86-461e-8721-83b32caf808f@github.com>
<qPL-XuWVkfNYFmfYatyQZwbHismNzW_jXdvkDvIiVNc=.d4fd26a8-f509-494a-bd3d-0c6f37ba5269@github.com>
<-UEFgAIQjGBginN0JRoyuwwJLmDssUEQGE_tCP-tRkw=.01ef3f37-01fa-4931-b4f3-571d21252bbd@github.com>
<jj6GEQDn7YAPHbFlHtE6Hqx4BwCAUh2XEFLTJ1gBmeY=.faa0d50c-9e26-4dec-aeb9-15d3ca11b1b2@github.com>
Message-ID: <twhuRW8mlXjzlobkiklKNV0IUCWxzM0tu48uX-4rVeQ=.d98ae5da-502c-4f20-8bba-b9ff963dc53b@github.com>
On Mon, 7 Oct 2024 08:49:58 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:
>> Style note: The added code is inserted between a comment and the code that the comment refers to. It would be nice to tidy this up.
>
> Did you figure out if the code above is correct w.r.t. `MinObjectAlignment=16`?
When MinObjectAlignment=16, then that method does nothing anyway:
if (MinObjAlignment > 1) {
return;
}
I think what it really means to say is
if (MinObjAlignment >= CollectedHeap::min_fill_size()) {
return;
}
That's also what the comment says: "The size of the gap (if any) right before dense-prefix-end is MinObjAlignment. Need to fill in the gap only if it's smaller than min-obj-size, and the filler obj will extend to next region."
If I interpret that correctly, we need to deal with the situation only when MinObjAlignment < min_fill_size, because the filler object would extend to the next region, and we need to adjust the next region and mark-bitmap for that extra word. @albertnetymk might want to confirm.
I'll move the if (UCOH) block down a little bit to right before if (MinObjAlignment) block.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1789983561
From rkennke at openjdk.org Mon Oct 7 11:03:55 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 7 Oct 2024 11:03:55 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v30]
In-Reply-To: <NtlirWYS-adgUWyhc0RA52WzClmcbtRuk3ykReYfsDg=.db48cc39-e30d-49e2-8a61-df4f40ecf73b@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<aU7Oq51P0gFTm6hW7hQW_fmAYCdLG6JlqW6lBOkaRKE=.e30fa902-dc09-4944-8983-2c14ad068cf1@github.com>
<NtlirWYS-adgUWyhc0RA52WzClmcbtRuk3ykReYfsDg=.db48cc39-e30d-49e2-8a61-df4f40ecf73b@github.com>
Message-ID: <wZQvls5Bmb1p4U0LFvXishmbr_J18_Il1tDQVbiAolk=.d26b761e-3201-44b8-8b62-aa0cf4dd32ed@github.com>
On Mon, 7 Oct 2024 08:25:55 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:
>> Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 76 commits:
>>
>> - Merge remote-tracking branch 'rkennke/JDK-8305895-v4' into JDK-8305895-v4
>> - Revert "Disable TestSplitPacks::test4a, failing on aarch64"
>>
>> This reverts commit 059b1573db26d1d2902ca6dadc8413f445234c2a.
>> - Simplify object init code in interpreter
>> - Disable some vectorization tests that fail with +UCOH and UseSSE<=3
>> - Fix for CDSPluginTest.java
>> - Merge tag 'jdk-24+18' into JDK-8305895-v4
>>
>> Added tag jdk-24+18 for changeset 19642bd3
>> - Disable TestSplitPacks::test4a, failing on aarch64
>> - @robcasloz review comments
>> - Improve CollectedHeap::is_oop()
>> - Allow LM_MONITOR on 32-bit platforms
>> - ... and 66 more: https://git.openjdk.org/jdk/compare/19642bd3...8742f3c1
>
> src/hotspot/share/oops/compressedKlass.cpp line 28:
>
>> 26: #include "logging/log.hpp"
>> 27: #include "memory/metaspace.hpp"
>> 28: #include "oops/klass.hpp"
>
> Is this include really needed or could this be reverted klass.hpp? If it is needed is should be moved to after compressedKlass.inline.hpp.
I don't think it's needed. I'll remove it.
> src/hotspot/share/oops/compressedKlass.cpp line 31:
>
>> 29: #include "oops/compressedKlass.inline.hpp"
>> 30: #include "runtime/globals.hpp"
>> 31: #include "runtime/java.hpp"
>
> Do you remember why this was added?
Looks like this is for vm_exit_during_initialization().
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1789996985
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1789999402
From stefank at openjdk.org Mon Oct 7 11:43:00 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 7 Oct 2024 11:43:00 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v30]
In-Reply-To: <wZQvls5Bmb1p4U0LFvXishmbr_J18_Il1tDQVbiAolk=.d26b761e-3201-44b8-8b62-aa0cf4dd32ed@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<aU7Oq51P0gFTm6hW7hQW_fmAYCdLG6JlqW6lBOkaRKE=.e30fa902-dc09-4944-8983-2c14ad068cf1@github.com>
<NtlirWYS-adgUWyhc0RA52WzClmcbtRuk3ykReYfsDg=.db48cc39-e30d-49e2-8a61-df4f40ecf73b@github.com>
<wZQvls5Bmb1p4U0LFvXishmbr_J18_Il1tDQVbiAolk=.d26b761e-3201-44b8-8b62-aa0cf4dd32ed@github.com>
Message-ID: <xkj4iPPqe3T_nJxW_IE59EF806ZEA4cbXZNphRCmYLQ=.5e23dced-9aa6-418c-bfd5-2aad3b727a68@github.com>
On Mon, 7 Oct 2024 11:00:54 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
>> src/hotspot/share/oops/compressedKlass.cpp line 31:
>>
>>> 29: #include "oops/compressedKlass.inline.hpp"
>>> 30: #include "runtime/globals.hpp"
>>> 31: #include "runtime/java.hpp"
>>
>> Do you remember why this was added?
>
> Looks like this is for vm_exit_during_initialization().
I see. Thanks. (What a funny header file that is)
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1790060417
From stefank at openjdk.org Mon Oct 7 11:51:54 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 7 Oct 2024 11:51:54 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v21]
In-Reply-To: <twhuRW8mlXjzlobkiklKNV0IUCWxzM0tu48uX-4rVeQ=.d98ae5da-502c-4f20-8bba-b9ff963dc53b@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<TCFshDmOrJjN0zTh1X9BGEa_rczyMqRbyDIiYsFr_5I=.ea051371-4c86-461e-8721-83b32caf808f@github.com>
<qPL-XuWVkfNYFmfYatyQZwbHismNzW_jXdvkDvIiVNc=.d4fd26a8-f509-494a-bd3d-0c6f37ba5269@github.com>
<-UEFgAIQjGBginN0JRoyuwwJLmDssUEQGE_tCP-tRkw=.01ef3f37-01fa-4931-b4f3-571d21252bbd@github.com>
<jj6GEQDn7YAPHbFlHtE6Hqx4BwCAUh2XEFLTJ1gBmeY=.faa0d50c-9e26-4dec-aeb9-15d3ca11b1b2@github.com>
<twhuRW8mlXjzlobkiklKNV0IUCWxzM0tu48uX-4rVeQ=.d98ae5da-502c-4f20-8bba-b9ff963dc53b@github.com>
Message-ID: <z1P1My8MgsUMZ6wFP1Ia0aMFzTkD8oxrGwDI4o4mHrY=.d4c22978-7190-432d-9206-dfbbb1a66a9b@github.com>
On Mon, 7 Oct 2024 10:49:39 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
>> Did you figure out if the code above is correct w.r.t. `MinObjectAlignment=16`?
>
> When MinObjectAlignment=16, then that method does nothing anyway:
>
>
> if (MinObjAlignment > 1) {
> return;
> }
>
>
>
> I think what it really means to say is
>
> if (MinObjAlignment >= CollectedHeap::min_fill_size()) {
> return;
> }
>
>
>
> That's also what the comment says: "The size of the gap (if any) right before dense-prefix-end is MinObjAlignment. Need to fill in the gap only if it's smaller than min-obj-size, and the filler obj will extend to next region."
>
> If I interpret that correctly, we need to deal with the situation only when MinObjAlignment < min_fill_size, because the filler object would extend to the next region, and we need to adjust the next region and mark-bitmap for that extra word. @albertnetymk might want to confirm.
>
> I'll move the if (UCOH) block down a little bit to right before if (MinObjAlignment) block.
After re-reading this again I agree with what you're writing. If you make the change to use:
if (MinObjAlignment >= CollectedHeap::min_fill_size()) {
return;
}
do you even have to check for UCOH in this function?
I also wonder if you could tweak the comment now that this is not true when UCOH is on:
// The size of the filler (min-obj-size) is 2 heap words with the default
// MinObjAlignment, since both markword and klass take 1 heap word.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1790074043
From rkennke at openjdk.org Mon Oct 7 12:48:43 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 7 Oct 2024 12:48:43 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v31]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <zFKBeHSnUUhfCv95M3aVKEFRTEcEn_m5iS69tohiAsE=.b652f8fd-9da1-4428-8488-57c06f275da9@github.com>
> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>
> Main changes:
> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
> - Arrays will now store their length at offset 8.
> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...
Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
@stefank review comments
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/20677/files
- new: https://git.openjdk.org/jdk/pull/20677/files/8742f3c1..572f1ac0
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=30
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=29-30
Stats: 20 lines in 6 files changed: 4 ins; 8 del; 8 mod
Patch: https://git.openjdk.org/jdk/pull/20677.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677
PR: https://git.openjdk.org/jdk/pull/20677
From rkennke at openjdk.org Mon Oct 7 13:24:26 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 7 Oct 2024 13:24:26 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v32]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <XdTIEoeBMhkUPVI42RfZLH-PP6QszZ66_FeCrqDtxs0=.3da42b45-52af-4c75-a01e-6df7c81ab9db@github.com>
> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>
> Main changes:
> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
> - Arrays will now store their length at offset 8.
> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...
Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
Remove unused variable
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/20677/files
- new: https://git.openjdk.org/jdk/pull/20677/files/572f1ac0..60401086
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=31
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=30-31
Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
Patch: https://git.openjdk.org/jdk/pull/20677.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677
PR: https://git.openjdk.org/jdk/pull/20677
From iwalulya at openjdk.org Mon Oct 7 13:26:37 2024
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Mon, 7 Oct 2024 13:26:37 GMT
Subject: RFR: 8341238: G1: Refactor G1Policy to move collection set
selection methods into G1CollectionSet
In-Reply-To: <CJIN12bX61w3HgWVqDeXBzXqFdSccz4TiAfMPHCcunY=.902b9a1e-6899-497b-83fc-845ffda714b3@github.com>
References: <w8WhIXs7wxxicEK9S6UgxptkWYK5s96o7eco1leJe9I=.16087a7e-5a75-49de-9694-fb8980eb7ef7@github.com>
<CJIN12bX61w3HgWVqDeXBzXqFdSccz4TiAfMPHCcunY=.902b9a1e-6899-497b-83fc-845ffda714b3@github.com>
Message-ID: <wbiiGvGEAdgdNEk7UYB1VBw988iwYTCtArwfwMCKmpQ=.04a07cc9-2bca-4916-80cd-67e41408bf28@github.com>
On Mon, 7 Oct 2024 10:29:42 GMT, Hamlin Li <mli at openjdk.org> wrote:
>> Hi,
>>
>> Please review this code migration patch to move collection set candidate selection methods out of G1Policy into G1CollectionSet. By relocating these methods, we can simplify the method signatures and reduce the interdependency between the classes.
>>
>> Testing: Tier 1
>
> Marked as reviewed by mli (Reviewer).
Thanks @Hamlin-Li and @tschatzl for the reviews!
-------------
PR Comment: https://git.openjdk.org/jdk/pull/21347#issuecomment-2396926825
From iwalulya at openjdk.org Mon Oct 7 13:29:42 2024
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Mon, 7 Oct 2024 13:29:42 GMT
Subject: Integrated: 8341238: G1: Refactor G1Policy to move collection set
selection methods into G1CollectionSet
In-Reply-To: <w8WhIXs7wxxicEK9S6UgxptkWYK5s96o7eco1leJe9I=.16087a7e-5a75-49de-9694-fb8980eb7ef7@github.com>
References: <w8WhIXs7wxxicEK9S6UgxptkWYK5s96o7eco1leJe9I=.16087a7e-5a75-49de-9694-fb8980eb7ef7@github.com>
Message-ID: <kRw3rJ5RxrThjeZB76gUXK--lLjIOxV4W7DXVq2DiN0=.b4cbfa98-9c6e-4837-b90c-7114b2ccdfda@github.com>
On Fri, 4 Oct 2024 07:25:32 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:
> Hi,
>
> Please review this code migration patch to move collection set candidate selection methods out of G1Policy into G1CollectionSet. By relocating these methods, we can simplify the method signatures and reduce the interdependency between the classes.
>
> Testing: Tier 1
This pull request has now been integrated.
Changeset: a2372c60
Author: Ivan Walulya <iwalulya at openjdk.org>
URL: https://git.openjdk.org/jdk/commit/a2372c607c940589f239d4e59b675d3b2e626fd9
Stats: 475 lines in 4 files changed: 226 ins; 239 del; 10 mod
8341238: G1: Refactor G1Policy to move collection set selection methods into G1CollectionSet
Reviewed-by: tschatzl, mli
-------------
PR: https://git.openjdk.org/jdk/pull/21347
From tschatzl at openjdk.org Mon Oct 7 13:48:12 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 7 Oct 2024 13:48:12 GMT
Subject: RFR: 8341643: G1: Merged cards counter skewed by merge cards cache
Message-ID: <YQ3btIxJtFpLGZaRn67gJ7fhelzV3D42XTOntYGfCZ8=.a9b12900-5125-4f3b-884f-a458f70ec584@github.com>
Hi all,
please review this change that subtracts the dummy cards from the merge cards counter at the end of the phase to keep its value correct.
E.g. previously log output with no actual cards being merged looks as follows:
[0.991s][debug][gc,phases ] GC(11) Remembered Sets (ms): Min: 0.03, Avg: 0.03, Max: 0.03, Diff: 0.01, Sum: 0.11, Workers: 4
[0.991s][debug][gc,phases ] GC(11) Eager Reclaim (ms): skipped
[0.991s][debug][gc,phases ] GC(11) Merged Inline: Min: 0, Avg: 0.0, Max: 0, Diff: 0, Sum: 0, Workers: 4
[0.991s][debug][gc,phases ] GC(11) Merged ArrayOfCards: Min: 0, Avg: 0.0, Max: 0, Diff: 0, Sum: 0, Workers: 4
[0.991s][debug][gc,phases ] GC(11) Merged Howl: Min: 0, Avg: 0.0, Max: 0, Diff: 0, Sum: 0, Workers: 4
[0.991s][debug][gc,phases ] GC(11) Merged Full: Min: 0, Avg: 0.0, Max: 0, Diff: 0, Sum: 0, Workers: 4
[0.991s][debug][gc,phases ] GC(11) Merged Howl Inline: Min: 0, Avg: 0.0, Max: 0, Diff: 0, Sum: 0, Workers: 4
[0.991s][debug][gc,phases ] GC(11) Merged Howl ArrayOfCards: Min: 0, Avg: 0.0, Max: 0, Diff: 0, Sum: 0, Workers: 4
[0.991s][debug][gc,phases ] GC(11) Merged Howl BitMap: Min: 0, Avg: 0.0, Max: 0, Diff: 0, Sum: 0, Workers: 4
[0.991s][debug][gc,phases ] GC(11) Merged Howl Full: Min: 0, Avg: 0.0, Max: 0, Diff: 0, Sum: 0, Workers: 4
[0.991s][debug][gc,phases ] GC(11) Merged Cards: Min: 8, Avg: 8.0, Max: 8, Diff: 0, Sum: 32, Workers: 4
(Note that none of the other categories have non-zero values)
to
[0.991s][debug][gc,phases ] GC(11) Merged Cards: Min: 0, Avg: 0.0, Max: 0, Diff: 0, Sum: 0, Workers: 4
For the same test (gcbasher in this case).
Testing: gha, log messages
Thanks,
Thomas
-------------
Commit messages:
- 8341643
Changes: https://git.openjdk.org/jdk/pull/21390/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21390&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8341643
Stats: 10 lines in 1 file changed: 10 ins; 0 del; 0 mod
Patch: https://git.openjdk.org/jdk/pull/21390.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/21390/head:pull/21390
PR: https://git.openjdk.org/jdk/pull/21390
From rkennke at openjdk.org Mon Oct 7 13:55:17 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 7 Oct 2024 13:55:17 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v33]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <VWBPrwk40VzajxZ4gNqUF-w3-XkNWyCK1ayQ7TFYxNs=.1e941ed0-5dad-4321-bcd5-1c87517f3aa6@github.com>
> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>
> Main changes:
> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
> - Arrays will now store their length at offset 8.
> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...
Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
Rename nklass/nKlass
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/20677/files
- new: https://git.openjdk.org/jdk/pull/20677/files/60401086..1ab20774
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=32
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=31-32
Stats: 14 lines in 6 files changed: 0 ins; 0 del; 14 mod
Patch: https://git.openjdk.org/jdk/pull/20677.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677
PR: https://git.openjdk.org/jdk/pull/20677
From rkennke at openjdk.org Mon Oct 7 13:55:18 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 7 Oct 2024 13:55:18 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v30]
In-Reply-To: <NtlirWYS-adgUWyhc0RA52WzClmcbtRuk3ykReYfsDg=.db48cc39-e30d-49e2-8a61-df4f40ecf73b@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<aU7Oq51P0gFTm6hW7hQW_fmAYCdLG6JlqW6lBOkaRKE=.e30fa902-dc09-4944-8983-2c14ad068cf1@github.com>
<NtlirWYS-adgUWyhc0RA52WzClmcbtRuk3ykReYfsDg=.db48cc39-e30d-49e2-8a61-df4f40ecf73b@github.com>
Message-ID: <gW425l3Fk9V3WAGejgKf-PunT7yc2abszhJiU7L1jJw=.6704865f-b06e-4f0d-8637-08d66422c8b9@github.com>
On Mon, 7 Oct 2024 08:44:16 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:
>> Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 76 commits:
>>
>> - Merge remote-tracking branch 'rkennke/JDK-8305895-v4' into JDK-8305895-v4
>> - Revert "Disable TestSplitPacks::test4a, failing on aarch64"
>>
>> This reverts commit 059b1573db26d1d2902ca6dadc8413f445234c2a.
>> - Simplify object init code in interpreter
>> - Disable some vectorization tests that fail with +UCOH and UseSSE<=3
>> - Fix for CDSPluginTest.java
>> - Merge tag 'jdk-24+18' into JDK-8305895-v4
>>
>> Added tag jdk-24+18 for changeset 19642bd3
>> - Disable TestSplitPacks::test4a, failing on aarch64
>> - @robcasloz review comments
>> - Improve CollectedHeap::is_oop()
>> - Allow LM_MONITOR on 32-bit platforms
>> - ... and 66 more: https://git.openjdk.org/jdk/compare/19642bd3...8742f3c1
>
> src/hotspot/share/oops/markWord.cpp line 35:
>
>> 33: STATIC_ASSERT(markWord::klass_shift + markWord::klass_bits == 64);
>> 34: // The hash (preceding nKlass) shall be a direct neighbor but not interleave
>> 35: STATIC_ASSERT(markWord::klass_shift == markWord::hash_bits + markWord::hash_shift);
>
> The code is not consistent in it usage of the name for the klass bits. Here it says `nKlass` in the comment, but the fields are named `klass`. Maybe just change the comment to says `(preceding klass bits)`.
>
> Note that the term `nklass` is not prevalent in the code base, but with this patch its starting to get a foot hold. It might be good to figure out what we do want to call these in field names and variables to at least a little bit more consistency in the code base. Currently we have `nklass`, `nKlass` `nk`, `narrow_klass`.
>
> In other places we have functions that are named `set_narrow_klass`, but the field is called `nklass` and other places call it `nk`. It would be good to stay consistent with the naming. FWIW, nklass has very little precedence in the code, so cleaning that away might be easiest.thing is to clean out all usages of nklass, because it isn't a
I renamed all occurrences of nklass and nKlass in shared code to something more useful. I left load_nklass* stuff in aarch64 and x86 code alone for now. Let me know if that addresses your concern.
https://github.com/openjdk/jdk/pull/20677/commits/1ab207746e4c4baaa6da162d7c1535c75342fa2e
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1790270819
From zgu at openjdk.org Mon Oct 7 14:08:38 2024
From: zgu at openjdk.org (Zhengyu Gu)
Date: Mon, 7 Oct 2024 14:08:38 GMT
Subject: RFR: 8341332: Refactor array chunking statistics counters
In-Reply-To: <YIZCU_MiT_Y5l-DlGH5B9U1qI2EgBQLgkltZWW5_zv4=.a4af4e75-17b0-440b-ae43-cb5d1533b322@github.com>
References: <M0BH81KIMD9ma5OX2bSlzpXCQUQceQiG4KacOe0-w-E=.f9711efa-b255-4515-9286-2c8e46fd1235@github.com>
<YIZCU_MiT_Y5l-DlGH5B9U1qI2EgBQLgkltZWW5_zv4=.a4af4e75-17b0-440b-ae43-cb5d1533b322@github.com>
Message-ID: <mpETS2WP4ZoYuihVF7A4Mu3L8hMt-dWd2SCaGkLL3Cs=.c0e363a5-8c92-4c94-ada7-fb3be453e3e1@github.com>
On Fri, 4 Oct 2024 17:29:43 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:
> I hadn't noticed the associated JBS issue and that you'd started working on it. I've also started working on the same problem, but taking a different approach.
>
> I think the approach being taken in this PR is continuing a problematic design approach already present in the existing code. I'd rather we didn't do that.
>
> Virtual functions tend to combine poorly with class templates. I think there's not actually any need for runtime polymorphism in the taskqueue stuff. Adding more is not appealing to me.
>
> I think the basic taskqueue and its associated statistics form a generic utility that could be used anywhere one needs parallel task queues with work stealing (so long as the tasks can meet the necessary requirements - see the discussion with the implementation of pop_global). I don't think inheritance is the best way to augment them. I think the existing use of inheritance for overflow queues, and inclusion of overflow stats in TaskQueueStats, are design errors. This PR proposes to do more of that.
>
> I think task specifics ought to be kept separate from the generic taskqueue, which doesn't really need to know anything about them. So I think, for example, that the various task types ought not be in the taskqueue files, but should be in their own files.
Okay, my intention was to consolidate partial array stats collecting/reporting so that I can deduplicate code for consolidating task queues. Glad to hear that you are working on refactoring task queue, it is the area that is very hard to make changes.
Please feel free to take over this CR.
@kimbarrett is working on the same issue with different approach.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/21343#issuecomment-2397031956
PR Comment: https://git.openjdk.org/jdk/pull/21343#issuecomment-2397033465
From zgu at openjdk.org Mon Oct 7 14:08:39 2024
From: zgu at openjdk.org (Zhengyu Gu)
Date: Mon, 7 Oct 2024 14:08:39 GMT
Subject: Withdrawn: 8341332: Refactor array chunking statistics counters
In-Reply-To: <M0BH81KIMD9ma5OX2bSlzpXCQUQceQiG4KacOe0-w-E=.f9711efa-b255-4515-9286-2c8e46fd1235@github.com>
References: <M0BH81KIMD9ma5OX2bSlzpXCQUQceQiG4KacOe0-w-E=.f9711efa-b255-4515-9286-2c8e46fd1235@github.com>
Message-ID: <By_mY9eChOLiUzSXuRJFt4fseKSK6IjlZKuuyc8owMk=.c2869a4b-b04e-47a1-95af-2c9337414958@github.com>
On Fri, 4 Oct 2024 01:41:50 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:
> Please review this patch that consolidates array chunking statistics counting and reporting inside task queue and task queue set. Also consolidating partial array chunking and processing into `PartialArrayProcessor` to reduce duplicate code.
This pull request has been closed without being integrated.
-------------
PR: https://git.openjdk.org/jdk/pull/21343
From rkennke at openjdk.org Mon Oct 7 14:28:40 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 7 Oct 2024 14:28:40 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v34]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <jg_gzL1xUQxh6Isj-q5ceTJf4r9UM7CvHWlyoT3H_Ok=.314a0607-2bbe-42c8-b9c3-b5e8c8efb110@github.com>
> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>
> Main changes:
> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
> - Arrays will now store their length at offset 8.
> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...
Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
Some more review comments/cleanups
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/20677/files
- new: https://git.openjdk.org/jdk/pull/20677/files/1ab20774..17f8eb54
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=33
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=32-33
Stats: 8 lines in 5 files changed: 3 ins; 3 del; 2 mod
Patch: https://git.openjdk.org/jdk/pull/20677.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677
PR: https://git.openjdk.org/jdk/pull/20677
From tschatzl at openjdk.org Mon Oct 7 14:53:11 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 7 Oct 2024 14:53:11 GMT
Subject: RFR: 8341643: G1: Merged cards counter skewed by merge cards cache
[v2]
In-Reply-To: <YQ3btIxJtFpLGZaRn67gJ7fhelzV3D42XTOntYGfCZ8=.a9b12900-5125-4f3b-884f-a458f70ec584@github.com>
References: <YQ3btIxJtFpLGZaRn67gJ7fhelzV3D42XTOntYGfCZ8=.a9b12900-5125-4f3b-884f-a458f70ec584@github.com>
Message-ID: <77db893xQRpdQXGKwUa0IBOxdbID6rhjGJ6C1RZLQv4=.7eac6d60-5ce9-484f-85c0-39826052c037@github.com>
> Hi all,
>
> please review this change that subtracts the dummy cards from the merge cards counter at the end of the phase to keep its value correct.
>
> E.g. previously log output with no actual cards being merged looks as follows:
>
> [0.991s][debug][gc,phases ] GC(11) Remembered Sets (ms): Min: 0.03, Avg: 0.03, Max: 0.03, Diff: 0.01, Sum: 0.11, Workers: 4
> [0.991s][debug][gc,phases ] GC(11) Eager Reclaim (ms): skipped
> [0.991s][debug][gc,phases ] GC(11) Merged Inline: Min: 0, Avg: 0.0, Max: 0, Diff: 0, Sum: 0, Workers: 4
> [0.991s][debug][gc,phases ] GC(11) Merged ArrayOfCards: Min: 0, Avg: 0.0, Max: 0, Diff: 0, Sum: 0, Workers: 4
> [0.991s][debug][gc,phases ] GC(11) Merged Howl: Min: 0, Avg: 0.0, Max: 0, Diff: 0, Sum: 0, Workers: 4
> [0.991s][debug][gc,phases ] GC(11) Merged Full: Min: 0, Avg: 0.0, Max: 0, Diff: 0, Sum: 0, Workers: 4
> [0.991s][debug][gc,phases ] GC(11) Merged Howl Inline: Min: 0, Avg: 0.0, Max: 0, Diff: 0, Sum: 0, Workers: 4
> [0.991s][debug][gc,phases ] GC(11) Merged Howl ArrayOfCards: Min: 0, Avg: 0.0, Max: 0, Diff: 0, Sum: 0, Workers: 4
> [0.991s][debug][gc,phases ] GC(11) Merged Howl BitMap: Min: 0, Avg: 0.0, Max: 0, Diff: 0, Sum: 0, Workers: 4
> [0.991s][debug][gc,phases ] GC(11) Merged Howl Full: Min: 0, Avg: 0.0, Max: 0, Diff: 0, Sum: 0, Workers: 4
> [0.991s][debug][gc,phases ] GC(11) Merged Cards: Min: 8, Avg: 8.0, Max: 8, Diff: 0, Sum: 32, Workers: 4
>
> (Note that none of the other categories have non-zero values)
> to
>
> [0.991s][debug][gc,phases ] GC(11) Merged Cards: Min: 0, Avg: 0.0, Max: 0, Diff: 0, Sum: 0, Workers: 4
>
>
> For the same test (gcbasher in this case).
>
> Testing: gha, log messages
>
> Thanks,
> Thomas
Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
* fix documentation
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/21390/files
- new: https://git.openjdk.org/jdk/pull/21390/files/de1277fb..b1dc6faa
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=21390&range=01
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=21390&range=00-01
Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod
Patch: https://git.openjdk.org/jdk/pull/21390.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/21390/head:pull/21390
PR: https://git.openjdk.org/jdk/pull/21390
From iwalulya at openjdk.org Mon Oct 7 15:15:35 2024
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Mon, 7 Oct 2024 15:15:35 GMT
Subject: RFR: 8341643: G1: Merged cards counter skewed by merge cards cache
[v2]
In-Reply-To: <77db893xQRpdQXGKwUa0IBOxdbID6rhjGJ6C1RZLQv4=.7eac6d60-5ce9-484f-85c0-39826052c037@github.com>
References: <YQ3btIxJtFpLGZaRn67gJ7fhelzV3D42XTOntYGfCZ8=.a9b12900-5125-4f3b-884f-a458f70ec584@github.com>
<77db893xQRpdQXGKwUa0IBOxdbID6rhjGJ6C1RZLQv4=.7eac6d60-5ce9-484f-85c0-39826052c037@github.com>
Message-ID: <dppUxkCmJ5-fPoMugxFux9nR0cN4pN-7PB243uKvvFo=.2770bc83-5938-419e-a966-d9b650800f8c@github.com>
On Mon, 7 Oct 2024 14:53:11 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:
>> Hi all,
>>
>> please review this change that subtracts the dummy cards from the merge cards counter at the end of the phase to keep its value correct.
>>
>> E.g. previously log output with no actual cards being merged looks as follows:
>>
>> [0.991s][debug][gc,phases ] GC(11) Remembered Sets (ms): Min: 0.03, Avg: 0.03, Max: 0.03, Diff: 0.01, Sum: 0.11, Workers: 4
>> [0.991s][debug][gc,phases ] GC(11) Eager Reclaim (ms): skipped
>> [0.991s][debug][gc,phases ] GC(11) Merged Inline: Min: 0, Avg: 0.0, Max: 0, Diff: 0, Sum: 0, Workers: 4
>> [0.991s][debug][gc,phases ] GC(11) Merged ArrayOfCards: Min: 0, Avg: 0.0, Max: 0, Diff: 0, Sum: 0, Workers: 4
>> [0.991s][debug][gc,phases ] GC(11) Merged Howl: Min: 0, Avg: 0.0, Max: 0, Diff: 0, Sum: 0, Workers: 4
>> [0.991s][debug][gc,phases ] GC(11) Merged Full: Min: 0, Avg: 0.0, Max: 0, Diff: 0, Sum: 0, Workers: 4
>> [0.991s][debug][gc,phases ] GC(11) Merged Howl Inline: Min: 0, Avg: 0.0, Max: 0, Diff: 0, Sum: 0, Workers: 4
>> [0.991s][debug][gc,phases ] GC(11) Merged Howl ArrayOfCards: Min: 0, Avg: 0.0, Max: 0, Diff: 0, Sum: 0, Workers: 4
>> [0.991s][debug][gc,phases ] GC(11) Merged Howl BitMap: Min: 0, Avg: 0.0, Max: 0, Diff: 0, Sum: 0, Workers: 4
>> [0.991s][debug][gc,phases ] GC(11) Merged Howl Full: Min: 0, Avg: 0.0, Max: 0, Diff: 0, Sum: 0, Workers: 4
>> [0.991s][debug][gc,phases ] GC(11) Merged Cards: Min: 8, Avg: 8.0, Max: 8, Diff: 0, Sum: 32, Workers: 4
>>
>> (Note that none of the other categories have non-zero values)
>> to
>>
>> [0.991s][debug][gc,phases ] GC(11) Merged Cards: Min: 0, Avg: 0.0, Max: 0, Diff: 0, Sum: 0, Workers: 4
>>
>>
>> For the same test (gcbasher in this case).
>>
>> Testing: gha, log messages
>>
>> Thanks,
>> Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
>
> * fix documentation
Marked as reviewed by iwalulya (Reviewer).
-------------
PR Review: https://git.openjdk.org/jdk/pull/21390#pullrequestreview-2352257384
From mark.reinhold at oracle.com Mon Oct 7 17:49:58 2024
From: mark.reinhold at oracle.com (Mark Reinhold)
Date: Mon, 7 Oct 2024 17:49:58 +0000
Subject: New candidate JEP: 490: ZGC: Remove the Non-Generational Mode
Message-ID: <20241007174955.B40B777D540@eggemoggin.niobe.net>
https://openjdk.org/jeps/490
Summary: Remove the non-generational mode of the Z Garbage Collector
(ZGC).
- Mark
From wkemper at openjdk.org Mon Oct 7 18:48:45 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 7 Oct 2024 18:48:45 GMT
Subject: RFR: 8341668: Shenandoah: assert(tail_bits < (idx_t)BitsPerWord)
failed: precondition
Message-ID: <8pCGlrqneW3yypyIwVkzoET45NOw8jKNJQ1x8-nm2PM=.a95b4c84-0fa7-4f44-9ddb-4af73e16a16b@github.com>
`tail_mask` function should not be in the global scope.
-------------
Commit messages:
- Fix name collision for tail_mask function
Changes: https://git.openjdk.org/jdk/pull/21395/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21395&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8341668
Stats: 3 lines in 2 files changed: 2 ins; 0 del; 1 mod
Patch: https://git.openjdk.org/jdk/pull/21395.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/21395/head:pull/21395
PR: https://git.openjdk.org/jdk/pull/21395
From ysr at openjdk.org Mon Oct 7 22:00:57 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Mon, 7 Oct 2024 22:00:57 GMT
Subject: RFR: 8341668: Shenandoah: assert(tail_bits < (idx_t)BitsPerWord)
failed: precondition
In-Reply-To: <8pCGlrqneW3yypyIwVkzoET45NOw8jKNJQ1x8-nm2PM=.a95b4c84-0fa7-4f44-9ddb-4af73e16a16b@github.com>
References: <8pCGlrqneW3yypyIwVkzoET45NOw8jKNJQ1x8-nm2PM=.a95b4c84-0fa7-4f44-9ddb-4af73e16a16b@github.com>
Message-ID: <06i89f-JrIQDdhGoIYetADvIq7k3uoynfBTzKfDJ5kc=.102a685c-3302-4e71-84c5-315f68d1e773@github.com>
On Mon, 7 Oct 2024 18:44:13 GMT, William Kemper <wkemper at openjdk.org> wrote:
> `tail_mask` function should not be in the global scope.
Change looks good to me. Reviewed!
In either this PR or, preferably, in the ticket, please include the test and the stack retrace associated with this assertion. Thanks!
-------------
Marked as reviewed by ysr (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/21395#pullrequestreview-2353007726
From sviswanathan at openjdk.org Mon Oct 7 22:43:15 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Mon, 7 Oct 2024 22:43:15 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v26]
In-Reply-To: <YrOurf-ql2uciTYRjGDnvVIb3r9K1pYphx2yRism6SQ=.f5b2510c-d384-4e78-906b-08267a218185@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<fEpfi4CzTFr1Pl-IyOAVyHNXWlVz33lHKQyzVY0kBc8=.cc39355b-ee7a-4118-952a-28e4184eec84@github.com>
<DKuidQyyiiJOsrerLCeziselVyG9Ztpzsyc64ZNjlI4=.722fc4f7-d7cc-49df-9d82-5c1094508f74@github.com>
<hdttC4LhHE6y6Nbq0jjJwxxF4W0hTfJLK_siODDCBkM=.1667f495-fcd9-4b7f-8d58-24e27665eeb3@github.com>
<fWSdSqQfhOrGpFoExiaO4L-UDtR90_t0gRxp9YBO3_c=.0173618e-f392-4921-8fae-39d44b24de08@github.com>
<6PTWMepIDuZDdPfN3xNKV1vqUyO_R4yCSeiSTpYIyyQ=.61a5b462-7114-4385-a6d7-40e5c7b0005d@github.com>
<C5LwWrsa-VO87kdm_sYuisTGMsHoxv4Eoe0QikdkusE=.63b0993c-86c8-4ef6-a3cf-bc8a67e10815@github.com>
<WOlTJMNHCr_Kk69sEIUwCVI3ZbiRlckY4TSBRfL7zoA=.1a4c59f1-a000-4d9f-abbc-36b24ed5105e@github.com>
<UjwpWz9Y3W8WRzYHZmDk9EvoiLSCZG1aai5oASGtDKA=.68cab6dd-e67d-4651-a9c9-75dccf42d85f@github.com>
<l_7f8gGpIdG9H3Ini5vHWruIa0oDi7fkn2Lz5thDI5c=.969b804f-bae2-48e1-9c44-e631d90037e7@github.com>
<BtvwMUG5tcy_zU4tRG3Q5VVw08qE_3gSE35
wCxlDnj4=.954353e5-cab2-48f4-b0f2-5852e586ba20@github.com>
<zi8MM6qUWhvxPSyb3ewa3baXWhmDIDlut2uYUQmWvcw=.7b32fa42-7a3f-43bb-8f15-fe6b8e66c49b@github.com>
<TSxYcKKfAdx7SsVcq6iwiySCLlkoVbXQO7a25vsiG4k=.29e59a6c-b8e0-42e9-8bdd-cc8ca23df146@github.com>
<YpG7vj6W3LnbhvvRhaeLmLeBzc_vlzlzmD74xVu1FQY=.14a57f09-74c1-4b2f-962c-c923961c067c@github.com>
<YrOurf-ql2uciTYRjGDnvVIb3r9K1pYphx2yRism6SQ=.f5b2510c-d384-4e78-906b-08267a218185@github.com>
Message-ID: <YqRmzdVypPfgEUFG9TqiQvD846aTd9SE9pU746Ed3HU=.a0349ab7-aabc-471c-9375-ef432a187caa@github.com>
On Fri, 4 Oct 2024 10:41:46 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
>> @rkennke The small loop looks to me that it will run over the end of the array.
>> Say the haystack_len is 7, the index below would be 0 after the shrq instruction, and the movq(XMM_TMP1, Address(haystack, index, Address::times_8)) in the loop will read 8 bytes i.e. one byte past the end of the array:
>> // num_words (zero-based) = (haystack_len - 1) / 8;
>> __ movq(index, haystack_len);
>> __ subq(index, 1);
>> __ shrq(index, LogBytesPerWord);
>>
>> __ bind(L_loop);
>> __ movq(XMM_TMP1, Address(haystack, index, Address::times_8));
>> __ movq(Address(rsp, index, Address::times_8), XMM_TMP1);
>> __ subq(index, 1);
>> __ jcc(Assembler::positive, L_loop);
>
> Yes, and that is intentional.
>
> Say, haystack_len is 7, then the first block computes the adjustment of the haystack, which is 8 - (7 % 8) = 1. We adjust the haystack pointer one byte down, so that when we copy (multiple of) 8 bytes, we land on the last byte. We do copy a few bytes that are preceding the array, which is part of the object header and guaranteed to be >= 8 bytes.
>
> Then we compute the number of words to copy, but make it 0-based. That is '0' is 1 word, '1' is 2 words, etc. It makes the loop nicer. In this example we get 0, which means we copy one word from the adjusted haystack, which is correct.
>
> Then comes the actual loop.
>
> Afterwards we adjust the haystack pointer so that it points to the first array element that we just copied onto the stack, ignoring the few garbage bytes that we also copied.
@rkennke Thanks for the explanation. I attach here a fix which is an extension of existing way of copying while taking care of the smaller object header. Also there are two instances of this in the intrinsic so I have factored the new code into a method and call it from both the places.
[indexof_fix.patch](https://github.com/user-attachments/files/17285239/indexof_fix.patch)
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1790967275
From wkemper at openjdk.org Tue Oct 8 01:29:03 2024
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 8 Oct 2024 01:29:03 GMT
Subject: Integrated: 8341668: Shenandoah: assert(tail_bits <
(idx_t)BitsPerWord) failed: precondition
In-Reply-To: <8pCGlrqneW3yypyIwVkzoET45NOw8jKNJQ1x8-nm2PM=.a95b4c84-0fa7-4f44-9ddb-4af73e16a16b@github.com>
References: <8pCGlrqneW3yypyIwVkzoET45NOw8jKNJQ1x8-nm2PM=.a95b4c84-0fa7-4f44-9ddb-4af73e16a16b@github.com>
Message-ID: <km83LvZvt2R2ZYyWCp8Jg0cghVwXYQYoKhccDXfU7-4=.5a2c71b5-bf62-489e-aa71-cb825a5cf7ca@github.com>
On Mon, 7 Oct 2024 18:44:13 GMT, William Kemper <wkemper at openjdk.org> wrote:
> `tail_mask` function should not be in the global scope. Stack traces in incremental build shows `shenandoahSimpleBitMap` calling a function with the same name defined in `bitMap.cpp`:
>
>
> #8 0x7f5e08a2c4d4 in tail_mask(unsigned long) src/hotspot/share/utilities/bitMap.cpp:431
> #9 0x7f5e0a951144 in ShenandoahSimpleBitMap::count_trailing_ones(long) const src/hotspot/share/gc/shenandoah/shenandoahSimpleBitMap.cpp:75
> #10 0x7f5e0a951b42 in ShenandoahSimpleBitMap::find_first_consecutive_set_bits(long, long, unsigned long) const src/hotspot/share/gc/shenandoah/shenandoahSimpleBitMap.cpp:215
This pull request has now been integrated.
Changeset: 45a63595
Author: William Kemper <wkemper at openjdk.org>
URL: https://git.openjdk.org/jdk/commit/45a6359588996d25e5e8dadebdcd8d6a00ef786f
Stats: 3 lines in 2 files changed: 2 ins; 0 del; 1 mod
8341668: Shenandoah: assert(tail_bits < (idx_t)BitsPerWord) failed: precondition
Reviewed-by: ysr
-------------
PR: https://git.openjdk.org/jdk/pull/21395
From rkennke at openjdk.org Tue Oct 8 07:08:52 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 8 Oct 2024 07:08:52 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v35]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <0ahBmcWCHqMMxr9RxUlOPgEJy4WSs7lQgRnxtEonZaY=.28275c5d-2d5f-490c-bf39-b0bb6817d6be@github.com>
> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>
> Main changes:
> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
> - Arrays will now store their length at offset 8.
> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...
Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
- Rename nklass in x86 code
- Fix header < 16 bytes in indexOf intrinsic, by @sviswa7
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/20677/files
- new: https://git.openjdk.org/jdk/pull/20677/files/17f8eb54..4d7228e0
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=34
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=33-34
Stats: 148 lines in 6 files changed: 84 ins; 47 del; 17 mod
Patch: https://git.openjdk.org/jdk/pull/20677.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677
PR: https://git.openjdk.org/jdk/pull/20677
From rkennke at openjdk.org Tue Oct 8 07:21:09 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 8 Oct 2024 07:21:09 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v36]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <mPNm6oxqHzUbpQMEvipfe8R-BgbFjrLQm3eXsSHxPxc=.32a33c8f-21bf-4226-8282-352234755d8e@github.com>
> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>
> Main changes:
> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
> - Arrays will now store their length at offset 8.
> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...
Roman Kennke has updated the pull request incrementally with three additional commits since the last revision:
- Re-enable indexOf intrinsic for compact headers
- Rename nklass in aarch64
- Fix comment
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/20677/files
- new: https://git.openjdk.org/jdk/pull/20677/files/4d7228e0..0be2fc40
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=35
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=34-35
Stats: 15 lines in 8 files changed: 0 ins; 1 del; 14 mod
Patch: https://git.openjdk.org/jdk/pull/20677.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677
PR: https://git.openjdk.org/jdk/pull/20677
From rkennke at openjdk.org Tue Oct 8 07:21:09 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 8 Oct 2024 07:21:09 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v26]
In-Reply-To: <YqRmzdVypPfgEUFG9TqiQvD846aTd9SE9pU746Ed3HU=.a0349ab7-aabc-471c-9375-ef432a187caa@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<fEpfi4CzTFr1Pl-IyOAVyHNXWlVz33lHKQyzVY0kBc8=.cc39355b-ee7a-4118-952a-28e4184eec84@github.com>
<DKuidQyyiiJOsrerLCeziselVyG9Ztpzsyc64ZNjlI4=.722fc4f7-d7cc-49df-9d82-5c1094508f74@github.com>
<hdttC4LhHE6y6Nbq0jjJwxxF4W0hTfJLK_siODDCBkM=.1667f495-fcd9-4b7f-8d58-24e27665eeb3@github.com>
<fWSdSqQfhOrGpFoExiaO4L-UDtR90_t0gRxp9YBO3_c=.0173618e-f392-4921-8fae-39d44b24de08@github.com>
<6PTWMepIDuZDdPfN3xNKV1vqUyO_R4yCSeiSTpYIyyQ=.61a5b462-7114-4385-a6d7-40e5c7b0005d@github.com>
<C5LwWrsa-VO87kdm_sYuisTGMsHoxv4Eoe0QikdkusE=.63b0993c-86c8-4ef6-a3cf-bc8a67e10815@github.com>
<WOlTJMNHCr_Kk69sEIUwCVI3ZbiRlckY4TSBRfL7zoA=.1a4c59f1-a000-4d9f-abbc-36b24ed5105e@github.com>
<UjwpWz9Y3W8WRzYHZmDk9EvoiLSCZG1aai5oASGtDKA=.68cab6dd-e67d-4651-a9c9-75dccf42d85f@github.com>
<l_7f8gGpIdG9H3Ini5vHWruIa0oDi7fkn2Lz5thDI5c=.969b804f-bae2-48e1-9c44-e631d90037e7@github.com>
<BtvwMUG5tcy_zU4tRG3Q5VVw08qE_3gSE35
wCxlDnj4=.954353e5-cab2-48f4-b0f2-5852e586ba20@github.com>
<zi8MM6qUWhvxPSyb3ewa3baXWhmDIDlut2uYUQmWvcw=.7b32fa42-7a3f-43bb-8f15-fe6b8e66c49b@github.com>
<TSxYcKKfAdx7SsVcq6iwiySCLlkoVbXQO7a25vsiG4k=.29e59a6c-b8e0-42e9-8bdd-cc8ca23df146@github.com>
<YpG7vj6W3LnbhvvRhaeLmLeBzc_vlzlzmD74xVu1FQY=.14a57f09-74c1-4b2f-962c-c923961c067c@github.com>
<YrOurf-ql2uciTYRjGDnvVIb3r9K1pYphx2yRism6SQ=.f5b2510c-d384-4e78-906b-08267a218185@github.com>
<YqRmzdVypPfgEUFG9TqiQvD846aTd9SE9pU746Ed3HU=.a0349ab7-aabc-471c-9375-ef432a187caa@github.com>
Message-ID: <6yrLSIp1cwJXxYVoMfSLxhbFA9Qdc9P3ML25QW0sfL4=.aa8bedac-1faa-4148-bcfc-a1434ddc9bac@github.com>
On Mon, 7 Oct 2024 22:40:37 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:
>> Yes, and that is intentional.
>>
>> Say, haystack_len is 7, then the first block computes the adjustment of the haystack, which is 8 - (7 % 8) = 1. We adjust the haystack pointer one byte down, so that when we copy (multiple of) 8 bytes, we land on the last byte. We do copy a few bytes that are preceding the array, which is part of the object header and guaranteed to be >= 8 bytes.
>>
>> Then we compute the number of words to copy, but make it 0-based. That is '0' is 1 word, '1' is 2 words, etc. It makes the loop nicer. In this example we get 0, which means we copy one word from the adjusted haystack, which is correct.
>>
>> Then comes the actual loop.
>>
>> Afterwards we adjust the haystack pointer so that it points to the first array element that we just copied onto the stack, ignoring the few garbage bytes that we also copied.
>
> @rkennke Thanks for the explanation. I attach here a fix which is an extension of existing way of copying while taking care of the smaller object header. Also there are two instances of this in the intrinsic so I have factored the new code into a method and call it from both the places.
> [indexof_fix.patch](https://github.com/user-attachments/files/17285239/indexof_fix.patch)
Thank you, @sviswa7! Yes this fix looks correct. I've intergrated it into this PR and re-enabled the indexOf intrinsic for compact headers.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1791328427
From ayang at openjdk.org Tue Oct 8 07:43:18 2024
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 8 Oct 2024 07:43:18 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v21]
In-Reply-To: <z1P1My8MgsUMZ6wFP1Ia0aMFzTkD8oxrGwDI4o4mHrY=.d4c22978-7190-432d-9206-dfbbb1a66a9b@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<TCFshDmOrJjN0zTh1X9BGEa_rczyMqRbyDIiYsFr_5I=.ea051371-4c86-461e-8721-83b32caf808f@github.com>
<qPL-XuWVkfNYFmfYatyQZwbHismNzW_jXdvkDvIiVNc=.d4fd26a8-f509-494a-bd3d-0c6f37ba5269@github.com>
<-UEFgAIQjGBginN0JRoyuwwJLmDssUEQGE_tCP-tRkw=.01ef3f37-01fa-4931-b4f3-571d21252bbd@github.com>
<jj6GEQDn7YAPHbFlHtE6Hqx4BwCAUh2XEFLTJ1gBmeY=.faa0d50c-9e26-4dec-aeb9-15d3ca11b1b2@github.com>
<twhuRW8mlXjzlobkiklKNV0IUCWxzM0tu48uX-4rVeQ=.d98ae5da-502c-4f20-8bba-b9ff963dc53b@github.com>
<z1P1My8MgsUMZ6wFP1Ia0aMFzTkD8oxrGwDI4o4mHrY=.d4c22978-7190-432d-9206-dfbbb1a66a9b@github.com>
Message-ID: <PnedT3gP8uCpKbCKzXB5s6-KCwWVz1Yx7dHk7r42Tgk=.d4e87b94-058c-49f3-be69-9c4271d04117@github.com>
On Mon, 7 Oct 2024 11:49:21 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:
>> When MinObjectAlignment=16, then that method does nothing anyway:
>>
>>
>> if (MinObjAlignment > 1) {
>> return;
>> }
>>
>>
>>
>> I think what it really means to say is
>>
>> if (MinObjAlignment >= CollectedHeap::min_fill_size()) {
>> return;
>> }
>>
>>
>>
>> That's also what the comment says: "The size of the gap (if any) right before dense-prefix-end is MinObjAlignment. Need to fill in the gap only if it's smaller than min-obj-size, and the filler obj will extend to next region."
>>
>> If I interpret that correctly, we need to deal with the situation only when MinObjAlignment < min_fill_size, because the filler object would extend to the next region, and we need to adjust the next region and mark-bitmap for that extra word. @albertnetymk might want to confirm.
>>
>> I'll move the if (UCOH) block down a little bit to right before if (MinObjAlignment) block.
>
> After re-reading this again I agree with what you're writing. If you make the change to use:
>
> if (MinObjAlignment >= CollectedHeap::min_fill_size()) {
> return;
> }
>
>
> do you even have to check for UCOH in this function?
>
> I also wonder if you could tweak the comment now that this is not true when UCOH is on:
>
> // The size of the filler (min-obj-size) is 2 heap words with the default
> // MinObjAlignment, since both markword and klass take 1 heap word.
I took UCOH into account when this code was written -- the current version of PR would fail the following assert.
// Note: If min-fill-size decreases to 1, this whole method becomes redundant.
assert(CollectedHeap::min_fill_size() >= 2, "inv");
The least intrusive way, IMO, is to put `if (UCOH) { return; }` right before `// Note: ...`, kind of like what Roman originally put it. I believe the advantage of this style is that when UCOH before always-true, it's obvious this whole method essentially becomes `return`and can be removed right away.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1791362310
From stefank at openjdk.org Tue Oct 8 08:15:18 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 8 Oct 2024 08:15:18 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v21]
In-Reply-To: <PnedT3gP8uCpKbCKzXB5s6-KCwWVz1Yx7dHk7r42Tgk=.d4e87b94-058c-49f3-be69-9c4271d04117@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<TCFshDmOrJjN0zTh1X9BGEa_rczyMqRbyDIiYsFr_5I=.ea051371-4c86-461e-8721-83b32caf808f@github.com>
<qPL-XuWVkfNYFmfYatyQZwbHismNzW_jXdvkDvIiVNc=.d4fd26a8-f509-494a-bd3d-0c6f37ba5269@github.com>
<-UEFgAIQjGBginN0JRoyuwwJLmDssUEQGE_tCP-tRkw=.01ef3f37-01fa-4931-b4f3-571d21252bbd@github.com>
<jj6GEQDn7YAPHbFlHtE6Hqx4BwCAUh2XEFLTJ1gBmeY=.faa0d50c-9e26-4dec-aeb9-15d3ca11b1b2@github.com>
<twhuRW8mlXjzlobkiklKNV0IUCWxzM0tu48uX-4rVeQ=.d98ae5da-502c-4f20-8bba-b9ff963dc53b@github.com>
<z1P1My8MgsUMZ6wFP1Ia0aMFzTkD8oxrGwDI4o4mHrY=.d4c22978-7190-432d-9206-dfbbb1a66a9b@github.com>
<PnedT3gP8uCpKbCKzXB5s6-KCwWVz1Yx7dHk7r42Tgk=.d4e87b94-058c-49f3-be69-9c4271d04117@github.com>
Message-ID: <UNtxTRNZWBU2tOkvOOcPnwYUWSPQcniD-O719yjVP58=.8b8b3daf-c71d-4759-9e15-842f21dd7c6d@github.com>
On Tue, 8 Oct 2024 07:40:24 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:
>> After re-reading this again I agree with what you're writing. If you make the change to use:
>>
>> if (MinObjAlignment >= CollectedHeap::min_fill_size()) {
>> return;
>> }
>>
>>
>> do you even have to check for UCOH in this function?
>>
>> I also wonder if you could tweak the comment now that this is not true when UCOH is on:
>>
>> // The size of the filler (min-obj-size) is 2 heap words with the default
>> // MinObjAlignment, since both markword and klass take 1 heap word.
>
> I took UCOH into account when this code was written -- the current version of PR would fail the following assert.
>
>
> // Note: If min-fill-size decreases to 1, this whole method becomes redundant.
> assert(CollectedHeap::min_fill_size() >= 2, "inv");
>
>
> The least intrusive way, IMO, is to put `if (UCOH) { return; }` right before `// Note: ...`, kind of like what Roman originally put it. I believe the advantage of this style is that when UCOH before always-true, it's obvious this whole method essentially becomes `return`and can be removed right away.
I was thinking that we should remove the entire:
// Note: If min-fill-size decreases to 1, this whole method becomes redundant.
assert(CollectedHeap::min_fill_size() >= 2, "inv");
block, since it is now incorrect, guarded by the proper check, and the comment is misleading since we now can have a min-fill-size that is 1.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1791409345
From rkennke at openjdk.org Tue Oct 8 10:03:40 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 8 Oct 2024 10:03:40 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v37]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <KrjrTqHnaXCIkD8T2a_EfnjTd0nVgxBD45NN6PeqXQY=.a4249a8f-ef4e-4008-9418-565ecf007c22@github.com>
> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>
> Main changes:
> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
> - Arrays will now store their length at offset 8.
> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...
Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
Improve PSParallelCompact::fill_dense_prefix_end() even more
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/20677/files
- new: https://git.openjdk.org/jdk/pull/20677/files/0be2fc40..d57dbfc5
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=36
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=35-36
Stats: 9 lines in 1 file changed: 2 ins; 7 del; 0 mod
Patch: https://git.openjdk.org/jdk/pull/20677.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677
PR: https://git.openjdk.org/jdk/pull/20677
From rkennke at openjdk.org Tue Oct 8 10:19:19 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 8 Oct 2024 10:19:19 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v8]
In-Reply-To: <6usTXIvS83aO2VzX5xu2EnXlpIJ8YbfrWS6b3EI0MhE=.0e8cc603-0cd3-4bd9-b309-55e4dd0f0cb0@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<J0g0PSye768dhN3JoXFsZ6FivocNBLPmHNtRUCOmLTw=.5756c64a-4763-4727-9637-ba3fe7b9b17d@github.com>
<6usTXIvS83aO2VzX5xu2EnXlpIJ8YbfrWS6b3EI0MhE=.0e8cc603-0cd3-4bd9-b309-55e4dd0f0cb0@github.com>
Message-ID: <hguzL3zLq9Svv4sZA-HwiYsvkSDHf5dPNdOmte1HU8Q=.b0caace6-3855-48eb-b93a-e0c81d257e8a@github.com>
On Mon, 9 Sep 2024 11:53:13 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:
>> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
>>
>> - Try to avoid lea in loadNklass (aarch64)
>> - Fix release build error
>
> src/hotspot/share/oops/klass.hpp line 169:
>
>> 167: // contention that may happen when a nearby object is modified.
>> 168: AccessFlags _access_flags; // Access flags. The class/interface distinction is stored here.
>> 169: // Some flags created by the JVM, not in the class file itself,
>
> Suggestion:
>
> markWord _prototype_header; // Used to initialize objects' header with compact headers.
>
>
> Maybe some comment why this is an instance member.
@tschatzl I just found your comment here, and I'm not sure what you mean, tbh. The prototype_header is a member of Klass because with compact headers, it encodes that Klass in the prototype header. Note that there is planned follow-up work to remove that field and encode the Klass* on the allocation path. https://bugs.openjdk.org/browse/JDK-8341703
Let me know if you still want me to change anything there, or if I can 'resolve' this request.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1791602989
From rkennke at openjdk.org Tue Oct 8 10:19:20 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 8 Oct 2024 10:19:20 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v8]
In-Reply-To: <NM8izXWScsGxiKeCqUapYVOoPaUfzdHwJq1GvAH58cs=.28e5b32c-59e0-4b24-8244-9580296d2e84@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<J0g0PSye768dhN3JoXFsZ6FivocNBLPmHNtRUCOmLTw=.5756c64a-4763-4727-9637-ba3fe7b9b17d@github.com>
<6usTXIvS83aO2VzX5xu2EnXlpIJ8YbfrWS6b3EI0MhE=.0e8cc603-0cd3-4bd9-b309-55e4dd0f0cb0@github.com>
<rhloCBhjvBZ4Cs8LLpD_UyHIBR08b8NIjXwIEQlirrs=.8a06186e-a315-4977-961c-b172e077bd9a@github.com>
<W-1ANH5uIdfAoNRB5Mp1wbdS_aswZz8JhdHNNzz6pMw=.b3e0db43-1df0-4b0f-a6fe-ca77aa23d8f1@github.com>
<k5oJ0MxPfzSI0V4d8SGr8ApvuM9Xpuy25WiJsJ51Tl8=.62dd2a4c-497d-42bc-a513-0151786b19c5@github.com>
<NM8izXWScsGxiKeCqUapYVOoPaUfzdHwJq1GvAH58cs=.28e5b32c-59e0-4b24-8244-9580296d2e84@github.com>
Message-ID: <BeD13wCpmDGgJ5pAAuIn6OyQuXGZ-yiscMW2wv821Gk=.86f10fb1-ba4e-4d36-8959-d06b4c7e4b89@github.com>
On Tue, 10 Sep 2024 09:28:41 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
>> With compact headers, this value should only be used in C2, and not really as an actual offset. An earlier version of the change had the value in src/hotspot/share/opto/type.hpp instead, and only an assert(!UCOH) in oopDesc::klass_offset_in_bytes(). I think this would be a better solution overall, because it prevents accidental (and wrong) usage of the klass_offset in the runtime. Back then it has been rejected by somebody (don't remember), because it made the C2 diff a little messier, so I kept it like it is now. I would prefer to reinstate it, though.
>
>> (Fwiw, the method is also used during Universe initialization).
>
> Yes, but only in the -UCOH branch.
We will deal with it in a follow-up. https://bugs.openjdk.org/browse/JDK-8340453
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1791605009
From ayang at openjdk.org Tue Oct 8 10:23:20 2024
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 8 Oct 2024 10:23:20 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v21]
In-Reply-To: <UNtxTRNZWBU2tOkvOOcPnwYUWSPQcniD-O719yjVP58=.8b8b3daf-c71d-4759-9e15-842f21dd7c6d@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<TCFshDmOrJjN0zTh1X9BGEa_rczyMqRbyDIiYsFr_5I=.ea051371-4c86-461e-8721-83b32caf808f@github.com>
<qPL-XuWVkfNYFmfYatyQZwbHismNzW_jXdvkDvIiVNc=.d4fd26a8-f509-494a-bd3d-0c6f37ba5269@github.com>
<-UEFgAIQjGBginN0JRoyuwwJLmDssUEQGE_tCP-tRkw=.01ef3f37-01fa-4931-b4f3-571d21252bbd@github.com>
<jj6GEQDn7YAPHbFlHtE6Hqx4BwCAUh2XEFLTJ1gBmeY=.faa0d50c-9e26-4dec-aeb9-15d3ca11b1b2@github.com>
<twhuRW8mlXjzlobkiklKNV0IUCWxzM0tu48uX-4rVeQ=.d98ae5da-502c-4f20-8bba-b9ff963dc53b@github.com>
<z1P1My8MgsUMZ6wFP1Ia0aMFzTkD8oxrGwDI4o4mHrY=.d4c22978-7190-432d-9206-dfbbb1a66a9b@github.com>
<PnedT3gP8uCpKbCKzXB5s6-KCwWVz1Yx7dHk7r42Tgk=.d4e87b94-058c-49f3-be69-9c4271d04117@github.com>
<UNtxTRNZWBU2tOkvOOcPnwYUWSPQcniD-O719yjVP58=.8b8b3daf-c71d-4759-9e15-842f21dd7c6d@github.com>
Message-ID: <PJi9AUPxZGcmcMyXZ01YX8-UkCQWV3CCPlXsR5zoB1w=.23331be1-6069-4241-b628-005309fcfd1b@github.com>
On Tue, 8 Oct 2024 08:12:31 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:
>> I took UCOH into account when this code was written -- the current version of PR would fail the following assert.
>>
>>
>> // Note: If min-fill-size decreases to 1, this whole method becomes redundant.
>> assert(CollectedHeap::min_fill_size() >= 2, "inv");
>>
>>
>> The least intrusive way, IMO, is to put `if (UCOH) { return; }` right before `// Note: ...`, kind of like what Roman originally put it. I believe the advantage of this style is that when UCOH before always-true, it's obvious this whole method essentially becomes `return`and can be removed right away.
>
> I was thinking that we should remove the entire:
>
> // Note: If min-fill-size decreases to 1, this whole method becomes redundant.
> assert(CollectedHeap::min_fill_size() >= 2, "inv");
>
> block, since it is now incorrect, guarded by the proper check, and the comment is misleading since we now can have a min-fill-size that is 1.
It's still correct when UCOH is disabled -- therefore, the UCOH check can be placed at the start without changing any existing logic. (The "rest" of this method assumes min-fill-size is 2, `assert(CollectedHeap::min_fill_size() == 2, "inv")`.)
In this PR, since this method doesn't access UCOH, it can be easily forgotten to update this method when the UCOH flag is removed eventually -- it's not obvious to me that `MinObjAlignment >= checked_cast<int>(CollectedHeap::min_fill_size())` is related to (or can be affected by) `UCOH` at first glance.
(I slightly prefer having a `if (UCOH)` inside this method, but considering this method will be nuked in the long run, any short-time decision is fine by me, assuming the failing assert is fixed.)
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1791611304
From mli at openjdk.org Tue Oct 8 10:28:01 2024
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 8 Oct 2024 10:28:01 GMT
Subject: RFR: 8341643: G1: Merged cards counter skewed by merge cards cache
[v2]
In-Reply-To: <77db893xQRpdQXGKwUa0IBOxdbID6rhjGJ6C1RZLQv4=.7eac6d60-5ce9-484f-85c0-39826052c037@github.com>
References: <YQ3btIxJtFpLGZaRn67gJ7fhelzV3D42XTOntYGfCZ8=.a9b12900-5125-4f3b-884f-a458f70ec584@github.com>
<77db893xQRpdQXGKwUa0IBOxdbID6rhjGJ6C1RZLQv4=.7eac6d60-5ce9-484f-85c0-39826052c037@github.com>
Message-ID: <Y2KhGaBfmtYTGb38B2Ks88KzZLOfxNvKuo_WfvYrf3k=.49103ebb-9f54-4068-b676-41558fcac733@github.com>
On Mon, 7 Oct 2024 14:53:11 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:
>> Hi all,
>>
>> please review this change that subtracts the dummy cards from the merge cards counter at the end of the phase to keep its value correct.
>>
>> E.g. previously log output with no actual cards being merged looks as follows:
>>
>> [0.991s][debug][gc,phases ] GC(11) Remembered Sets (ms): Min: 0.03, Avg: 0.03, Max: 0.03, Diff: 0.01, Sum: 0.11, Workers: 4
>> [0.991s][debug][gc,phases ] GC(11) Eager Reclaim (ms): skipped
>> [0.991s][debug][gc,phases ] GC(11) Merged Inline: Min: 0, Avg: 0.0, Max: 0, Diff: 0, Sum: 0, Workers: 4
>> [0.991s][debug][gc,phases ] GC(11) Merged ArrayOfCards: Min: 0, Avg: 0.0, Max: 0, Diff: 0, Sum: 0, Workers: 4
>> [0.991s][debug][gc,phases ] GC(11) Merged Howl: Min: 0, Avg: 0.0, Max: 0, Diff: 0, Sum: 0, Workers: 4
>> [0.991s][debug][gc,phases ] GC(11) Merged Full: Min: 0, Avg: 0.0, Max: 0, Diff: 0, Sum: 0, Workers: 4
>> [0.991s][debug][gc,phases ] GC(11) Merged Howl Inline: Min: 0, Avg: 0.0, Max: 0, Diff: 0, Sum: 0, Workers: 4
>> [0.991s][debug][gc,phases ] GC(11) Merged Howl ArrayOfCards: Min: 0, Avg: 0.0, Max: 0, Diff: 0, Sum: 0, Workers: 4
>> [0.991s][debug][gc,phases ] GC(11) Merged Howl BitMap: Min: 0, Avg: 0.0, Max: 0, Diff: 0, Sum: 0, Workers: 4
>> [0.991s][debug][gc,phases ] GC(11) Merged Howl Full: Min: 0, Avg: 0.0, Max: 0, Diff: 0, Sum: 0, Workers: 4
>> [0.991s][debug][gc,phases ] GC(11) Merged Cards: Min: 8, Avg: 8.0, Max: 8, Diff: 0, Sum: 32, Workers: 4
>>
>> (Note that none of the other categories have non-zero values)
>> to
>>
>> [0.991s][debug][gc,phases ] GC(11) Merged Cards: Min: 0, Avg: 0.0, Max: 0, Diff: 0, Sum: 0, Workers: 4
>>
>>
>> For the same test (gcbasher in this case).
>>
>> Testing: gha, log messages
>>
>> Thanks,
>> Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
>
> * fix documentation
Marked as reviewed by mli (Reviewer).
-------------
PR Review: https://git.openjdk.org/jdk/pull/21390#pullrequestreview-2354067778
From rkennke at openjdk.org Tue Oct 8 10:30:22 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 8 Oct 2024 10:30:22 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v21]
In-Reply-To: <PJi9AUPxZGcmcMyXZ01YX8-UkCQWV3CCPlXsR5zoB1w=.23331be1-6069-4241-b628-005309fcfd1b@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<TCFshDmOrJjN0zTh1X9BGEa_rczyMqRbyDIiYsFr_5I=.ea051371-4c86-461e-8721-83b32caf808f@github.com>
<qPL-XuWVkfNYFmfYatyQZwbHismNzW_jXdvkDvIiVNc=.d4fd26a8-f509-494a-bd3d-0c6f37ba5269@github.com>
<-UEFgAIQjGBginN0JRoyuwwJLmDssUEQGE_tCP-tRkw=.01ef3f37-01fa-4931-b4f3-571d21252bbd@github.com>
<jj6GEQDn7YAPHbFlHtE6Hqx4BwCAUh2XEFLTJ1gBmeY=.faa0d50c-9e26-4dec-aeb9-15d3ca11b1b2@github.com>
<twhuRW8mlXjzlobkiklKNV0IUCWxzM0tu48uX-4rVeQ=.d98ae5da-502c-4f20-8bba-b9ff963dc53b@github.com>
<z1P1My8MgsUMZ6wFP1Ia0aMFzTkD8oxrGwDI4o4mHrY=.d4c22978-7190-432d-9206-dfbbb1a66a9b@github.com>
<PnedT3gP8uCpKbCKzXB5s6-KCwWVz1Yx7dHk7r42Tgk=.d4e87b94-058c-49f3-be69-9c4271d04117@github.com>
<UNtxTRNZWBU2tOkvOOcPnwYUWSPQcniD-O719yjVP58=.8b8b3daf-c71d-4759-9e15-842f21dd7c6d@github.com>
<PJi9AUPxZGcmcMyXZ01YX8-UkCQWV3CCPlXsR5zoB1w=.23331be1-6069-4241-b628-005309fcfd1b@github.com>
Message-ID: <v9D7WHqlPwZ5D_94YhUU18rk_KY3M3rwAAZ-FK60src=.4404ecb2-6cd1-47a5-b5fb-c79b501aa766@github.com>
On Tue, 8 Oct 2024 10:20:45 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:
>> I was thinking that we should remove the entire:
>>
>> // Note: If min-fill-size decreases to 1, this whole method becomes redundant.
>> assert(CollectedHeap::min_fill_size() >= 2, "inv");
>>
>> block, since it is now incorrect, guarded by the proper check, and the comment is misleading since we now can have a min-fill-size that is 1.
>
> It's still correct when UCOH is disabled -- therefore, the UCOH check can be placed at the start without changing any existing logic. (The "rest" of this method assumes min-fill-size is 2, `assert(CollectedHeap::min_fill_size() == 2, "inv")`.)
>
> In this PR, since this method doesn't access UCOH, it can be easily forgotten to update this method when the UCOH flag is removed eventually -- it's not obvious to me that `MinObjAlignment >= checked_cast<int>(CollectedHeap::min_fill_size())` is related to (or can be affected by) `UCOH` at first glance.
>
> (I slightly prefer having a `if (UCOH)` inside this method, but considering this method will be nuked in the long run, any short-time decision is fine by me, assuming the failing assert is fixed.)
I added an assert(!UCOH) in the implementation so that we don't forget it once the UCOH flag becomes obsolete.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1791619505
From rkennke at openjdk.org Tue Oct 8 11:47:55 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 8 Oct 2024 11:47:55 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v38]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <XD3mmjy0GRP2dcKyaoxofOIWmOCNn4EqDzmdPBDKgmw=.0392fff7-367d-4553-8f56-62a0885cbfe2@github.com>
> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>
> Main changes:
> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
> - Arrays will now store their length at offset 8.
> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...
Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
Fix include guards
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/20677/files
- new: https://git.openjdk.org/jdk/pull/20677/files/d57dbfc5..4035bb61
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=37
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=36-37
Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
Patch: https://git.openjdk.org/jdk/pull/20677.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677
PR: https://git.openjdk.org/jdk/pull/20677
From stefank at openjdk.org Tue Oct 8 12:51:19 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 8 Oct 2024 12:51:19 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v38]
In-Reply-To: <XD3mmjy0GRP2dcKyaoxofOIWmOCNn4EqDzmdPBDKgmw=.0392fff7-367d-4553-8f56-62a0885cbfe2@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<XD3mmjy0GRP2dcKyaoxofOIWmOCNn4EqDzmdPBDKgmw=.0392fff7-367d-4553-8f56-62a0885cbfe2@github.com>
Message-ID: <RI9Sw9eEIlbW69JPFcs-TCh8tYLnESkCksxLrSbNZzQ=.b182f3c2-7073-4599-a129-b7198408085f@github.com>
On Tue, 8 Oct 2024 11:47:55 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>>
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>>
>> Main changes:
>> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>> - Arrays will now store their length at offset 8.
>> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>
> Fix include guards
I have looked through and reviewed most of the files many times and I've tried to give comments in parts of the code where I'm typically not a maintainer.
I'm giving an official Review/Approval of the gc/ code and most of the files in oops/. I'm specifically not approving the compressedKlass* files, because I think that others that are more vested in those bits, address ranges, and style need to fully Review those changes.
My review comes with a caveat that the there's no significant regressions in GC pauses, marking times, and GC cycle durations, when UCOH is turned off.
-------------
Marked as reviewed by stefank (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/20677#pullrequestreview-2354390888
From tschatzl at openjdk.org Tue Oct 8 14:16:02 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 8 Oct 2024 14:16:02 GMT
Subject: RFR: 8341643: G1: Merged cards counter skewed by merge cards cache
[v2]
In-Reply-To: <Y2KhGaBfmtYTGb38B2Ks88KzZLOfxNvKuo_WfvYrf3k=.49103ebb-9f54-4068-b676-41558fcac733@github.com>
References: <YQ3btIxJtFpLGZaRn67gJ7fhelzV3D42XTOntYGfCZ8=.a9b12900-5125-4f3b-884f-a458f70ec584@github.com>
<77db893xQRpdQXGKwUa0IBOxdbID6rhjGJ6C1RZLQv4=.7eac6d60-5ce9-484f-85c0-39826052c037@github.com>
<Y2KhGaBfmtYTGb38B2Ks88KzZLOfxNvKuo_WfvYrf3k=.49103ebb-9f54-4068-b676-41558fcac733@github.com>
Message-ID: <jsUNdRUPfD_cC2qyVg5sUsuDL0a3akv7xiMztPKDBVE=.52f35a5c-2b61-4a10-bae1-29ce70dcaba6@github.com>
On Tue, 8 Oct 2024 10:24:55 GMT, Hamlin Li <mli at openjdk.org> wrote:
>> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
>>
>> * fix documentation
>
> Marked as reviewed by mli (Reviewer).
Thanks @Hamlin-Li @walulyai for your reviews
-------------
PR Comment: https://git.openjdk.org/jdk/pull/21390#issuecomment-2399970973
From tschatzl at openjdk.org Tue Oct 8 14:16:03 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 8 Oct 2024 14:16:03 GMT
Subject: Integrated: 8341643: G1: Merged cards counter skewed by merge cards
cache
In-Reply-To: <YQ3btIxJtFpLGZaRn67gJ7fhelzV3D42XTOntYGfCZ8=.a9b12900-5125-4f3b-884f-a458f70ec584@github.com>
References: <YQ3btIxJtFpLGZaRn67gJ7fhelzV3D42XTOntYGfCZ8=.a9b12900-5125-4f3b-884f-a458f70ec584@github.com>
Message-ID: <wZX-6tAUzTqJR05vO73sePW9mEeLZlmX3bwTL1lN5bs=.2977c61c-7f53-4b84-8613-e52524bab53e@github.com>
On Mon, 7 Oct 2024 13:43:06 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:
> Hi all,
>
> please review this change that subtracts the dummy cards from the merge cards counter at the end of the phase to keep its value correct.
>
> E.g. previously log output with no actual cards being merged looks as follows:
>
> [0.991s][debug][gc,phases ] GC(11) Remembered Sets (ms): Min: 0.03, Avg: 0.03, Max: 0.03, Diff: 0.01, Sum: 0.11, Workers: 4
> [0.991s][debug][gc,phases ] GC(11) Eager Reclaim (ms): skipped
> [0.991s][debug][gc,phases ] GC(11) Merged Inline: Min: 0, Avg: 0.0, Max: 0, Diff: 0, Sum: 0, Workers: 4
> [0.991s][debug][gc,phases ] GC(11) Merged ArrayOfCards: Min: 0, Avg: 0.0, Max: 0, Diff: 0, Sum: 0, Workers: 4
> [0.991s][debug][gc,phases ] GC(11) Merged Howl: Min: 0, Avg: 0.0, Max: 0, Diff: 0, Sum: 0, Workers: 4
> [0.991s][debug][gc,phases ] GC(11) Merged Full: Min: 0, Avg: 0.0, Max: 0, Diff: 0, Sum: 0, Workers: 4
> [0.991s][debug][gc,phases ] GC(11) Merged Howl Inline: Min: 0, Avg: 0.0, Max: 0, Diff: 0, Sum: 0, Workers: 4
> [0.991s][debug][gc,phases ] GC(11) Merged Howl ArrayOfCards: Min: 0, Avg: 0.0, Max: 0, Diff: 0, Sum: 0, Workers: 4
> [0.991s][debug][gc,phases ] GC(11) Merged Howl BitMap: Min: 0, Avg: 0.0, Max: 0, Diff: 0, Sum: 0, Workers: 4
> [0.991s][debug][gc,phases ] GC(11) Merged Howl Full: Min: 0, Avg: 0.0, Max: 0, Diff: 0, Sum: 0, Workers: 4
> [0.991s][debug][gc,phases ] GC(11) Merged Cards: Min: 8, Avg: 8.0, Max: 8, Diff: 0, Sum: 32, Workers: 4
>
> (Note that none of the other categories have non-zero values)
> to
>
> [0.991s][debug][gc,phases ] GC(11) Merged Cards: Min: 0, Avg: 0.0, Max: 0, Diff: 0, Sum: 0, Workers: 4
>
>
> For the same test (gcbasher in this case).
>
> Testing: gha, log messages
>
> Thanks,
> Thomas
This pull request has now been integrated.
Changeset: 4a12f5b2
Author: Thomas Schatzl <tschatzl at openjdk.org>
URL: https://git.openjdk.org/jdk/commit/4a12f5b26e2b7fb638ee0946d3938451f5effd3d
Stats: 9 lines in 1 file changed: 9 ins; 0 del; 0 mod
8341643: G1: Merged cards counter skewed by merge cards cache
Reviewed-by: iwalulya, mli
-------------
PR: https://git.openjdk.org/jdk/pull/21390
From thomas.schatzl at oracle.com Tue Oct 8 15:34:55 2024
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Tue, 8 Oct 2024 17:34:55 +0200
Subject: Further discussion on Adaptable Heap Sizing with G1
In-Reply-To: <CACz-JM5_UjhLj2Yng83y9G5VUkfPT2kiLDSdUe+2u9J=dG5UvQ@mail.gmail.com>
References: <CACz-JM5_UjhLj2Yng83y9G5VUkfPT2kiLDSdUe+2u9J=dG5UvQ@mail.gmail.com>
Message-ID: <93ecaaaa-600e-4b91-a98b-f417f5505037@oracle.com>
Hi Jonathan,
On 05.10.24 00:39, Jonathan Joo wrote:
> Hi All,
>
> As Kirk mentioned in his email "Aligning the Serial collector with ZGC
> <https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-September/049616.html>", we are also working on adding Adaptable Heap Sizing (AHS) to G1.
>
> I created a draft Pull Request
> <https://github.com/openjdk/jdk/pull/20783>?and received some comments
> on it already, including the following points:
>
> 1. I should Convert CurrentMaxExpansionSize to CurrentMaxHeapSize.
>
> 2. SoftMaxHeapSize, as implemented in the PR, is different from the
> original intent.
>
> 3. We need some sort of global memory pressure to enforce heap shrinkage.
>
>
> The first point I already addressed on the pull request, and I agree
> that CurrentMaxHeapSize works well :)
>
> Regarding the second point, we had some discussions already outside of
> this mailing list, but if I were to summarize the main ideas, they are:
>
> 1. The intent of SoftMaxHeapSize initially was for the GC to use this
> value as a guide for when to start concurrent GC.
>
> 2. Our implementation of SoftMaxHeapSize (in the PR) currently behaves
> more like a ProposedHeapSize, where whenever we shrink and expand
> the heap, we try to set the heap size to ProposedHeapSize,
> regardless of the value of MinHeapSize.
>
> 3. We need to ensure that the heap regularly approaches the value of
> ProposedHeapSize by introducing some sort of periodic GC, which we
> have a Google-internal patch for, and is not yet present in the PR.
> If we are in alignment that this makes sense, I can try adding this
> as a separate PR.
I think what this suggestion overlooks is that a SoftMaxHeapSize that
guides used heap size will automatically guide committed size: i.e. if
G1 shrinks the used heap, G1 will automatically shrink (and keep) the
committed size.
So ProposedHeapSize seems to be very similar to SoftMaxHeapSize.
> As a separate point - Kirk mentioned in his email that he aims to
> introduce an adaptive size policy where "Heap should be large enough to
> minimize GC overhead but not large enough to trigger OOM". I think from
> our experience in G1, we don't actively try to minimize GC overhead, as
> we find that maintaining a higher GC overhead often results in overall
> RAM savings >> CPU usage.
>
I.e. if I understand this correctly: allowing a higher GC overhead,
automatically shrinks the heap.
> I think as a general summary - the way I see it, there's value in
> creating a simplified system where we control the majority of JVM
> behavior simply with two flags - the maximum heap size (to prevent
> OOMs), and a target heap size, which is our calculation of an "optimal"
> size based on our understanding of the environment. The exact
> calculations for this optimal size may change depending on
> workload/preference, but what we are trying to do at this point in time
> is allow for a way to pass in some calculation for "optimal heap size"
> and have G1 react to it in a meaningful way. I acknowledge that the
> current JVM behavior (as implemented in my PR) may be suboptimal in
> terms of getting the heap to get to and stay at this "optimal heap
> size". However, even with the basic implementation of passing this value
> to shrinks/expands and only triggering resizes on Remarks/Full GCs,
> we've seen dramatic improvements in heap behavior at Google, compared to
> the current G1.
I noticed the same with the patch attached to the SoftMaxHeapSize CR
(https://bugs.openjdk.org/browse/JDK-8236073) discounting effects of
Min/MaxHeapFreeRatio (i.e. if you remove it,
https://bugs.openjdk.org/browse/JDK-8238686 explains the issue).
In practice, these two flags prohibit G1 from adjusting the heap unless
the SoftMaxHeapSize change is very large.
So I would prefer to only think of an alternative to SoftMaxHeapSize if
it has been shown that it does not work.
There is the nit that unlike in this implementation of ProposedHeapSize,
SoftMaxHeapSize will not cauase uncommit below MinHeapSize. This is
another discussion on what to do about this issue - in a comment in
https://bugs.openjdk.org/browse/JDK-8236073 it is proposed to make
MinHeapSize manageable.
> I know there was some disagreement about the addition of this new
> "optimal heap size" flag, and I agree that SoftMaxHeapSize is probably
> not the right flag to represent this value. But I'd like to get some
> thoughts on whether the above summary seems like a reasonable way of
> reasoning about G1 AHS. If we agree, then we can always iteratively
> improve the JVM logic to better adhere to the optimal heap size. But
> it's not yet clear to me whether people are onboard the idea of having
> this "optimal heap size" calculation at all, since perhaps this
> functionality could be covered in other, existing ways.
I (still) believe that AHS and SoftMaxHeapSize/ProposedHeapSize are
somewhat orthogonal.
AHS (https://openjdk.org/jeps/8329758) is about finding a reasonable
heap size, and adjust on external "pressure". SoftMax/ProposedHeapSize
are manual external tunings.
Wdyt?
Thomas
From rcastanedalo at openjdk.org Tue Oct 8 15:47:16 2024
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Tue, 8 Oct 2024 15:47:16 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v26]
In-Reply-To: <6yrLSIp1cwJXxYVoMfSLxhbFA9Qdc9P3ML25QW0sfL4=.aa8bedac-1faa-4148-bcfc-a1434ddc9bac@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<fEpfi4CzTFr1Pl-IyOAVyHNXWlVz33lHKQyzVY0kBc8=.cc39355b-ee7a-4118-952a-28e4184eec84@github.com>
<DKuidQyyiiJOsrerLCeziselVyG9Ztpzsyc64ZNjlI4=.722fc4f7-d7cc-49df-9d82-5c1094508f74@github.com>
<hdttC4LhHE6y6Nbq0jjJwxxF4W0hTfJLK_siODDCBkM=.1667f495-fcd9-4b7f-8d58-24e27665eeb3@github.com>
<fWSdSqQfhOrGpFoExiaO4L-UDtR90_t0gRxp9YBO3_c=.0173618e-f392-4921-8fae-39d44b24de08@github.com>
<6PTWMepIDuZDdPfN3xNKV1vqUyO_R4yCSeiSTpYIyyQ=.61a5b462-7114-4385-a6d7-40e5c7b0005d@github.com>
<C5LwWrsa-VO87kdm_sYuisTGMsHoxv4Eoe0QikdkusE=.63b0993c-86c8-4ef6-a3cf-bc8a67e10815@github.com>
<WOlTJMNHCr_Kk69sEIUwCVI3ZbiRlckY4TSBRfL7zoA=.1a4c59f1-a000-4d9f-abbc-36b24ed5105e@github.com>
<UjwpWz9Y3W8WRzYHZmDk9EvoiLSCZG1aai5oASGtDKA=.68cab6dd-e67d-4651-a9c9-75dccf42d85f@github.com>
<l_7f8gGpIdG9H3Ini5vHWruIa0oDi7fkn2Lz5thDI5c=.969b804f-bae2-48e1-9c44-e631d90037e7@github.com>
<BtvwMUG5tcy_zU4tRG3Q5VVw08qE_3gSE35
wCxlDnj4=.954353e5-cab2-48f4-b0f2-5852e586ba20@github.com>
<zi8MM6qUWhvxPSyb3ewa3baXWhmDIDlut2uYUQmWvcw=.7b32fa42-7a3f-43bb-8f15-fe6b8e66c49b@github.com>
<TSxYcKKfAdx7SsVcq6iwiySCLlkoVbXQO7a25vsiG4k=.29e59a6c-b8e0-42e9-8bdd-cc8ca23df146@github.com>
<YpG7vj6W3LnbhvvRhaeLmLeBzc_vlzlzmD74xVu1FQY=.14a57f09-74c1-4b2f-962c-c923961c067c@github.com>
<YrOurf-ql2uciTYRjGDnvVIb3r9K1pYphx2yRism6SQ=.f5b2510c-d384-4e78-906b-08267a218185@github.com>
<YqRmzdVypPfgEUFG9TqiQvD846aTd9SE9pU746Ed3HU=.a0349ab7-aabc-471c-9375-ef432a187caa@github.com>
<6yrLSIp1cwJXxYVoMfSLxhbFA9Qdc9P3ML25QW0sfL4=.aa8bedac-1faa-4148-bcfc-a1434ddc9bac@github.com>
Message-ID: <lD7f-h93ZqWOHoJtIECJfizoH74j3_iwG2VG_jAYR1o=.db4be907-c20a-4f96-9b9e-e34eefa2e7f3@github.com>
On Tue, 8 Oct 2024 07:16:13 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
>> @rkennke Thanks for the explanation. I attach here a fix which is an extension of existing way of copying while taking care of the smaller object header. Also there are two instances of this in the intrinsic so I have factored the new code into a method and call it from both the places.
>> [indexof_fix.patch](https://github.com/user-attachments/files/17285239/indexof_fix.patch)
>
> Thank you, @sviswa7! Yes this fix looks correct. I've intergrated it into this PR and re-enabled the indexOf intrinsic for compact headers.
@rkennke @sviswa7 These changes trigger the following assertion failure:
#
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (codeBuffer.cpp:1004), pid=96032, tid=29699
# guarantee(sect->end() <= tend) failed: sanity
when running the following tests with compact object headers disabled (i.e. default JVM settings):
- `java/lang/StringBuffer/ECoreIndexOf.java`
- `java/lang/String/IndexOf.java`
on our test macosx-x64 machines. These machines are equipped with Intel Core i7-8700B processors with the following characteristics:
CPU: total 12 (initial active 12) (6 cores per cpu, 2 threads per core) family 6 model 158 stepping 10 microcode 0xf4, cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, lzcnt, tsc, tscinvbit, avx, avx2, aes, erms, clmul, bmi1, bmi2, rtm, adx, fma, vzeroupper, clflush, clflushopt, rdtscp, f16c
If you need more details to reproduce the issue, please let me know and I will try to help.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1792121119
From rcastanedalo at openjdk.org Tue Oct 8 16:01:23 2024
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Tue, 8 Oct 2024 16:01:23 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v26]
In-Reply-To: <lD7f-h93ZqWOHoJtIECJfizoH74j3_iwG2VG_jAYR1o=.db4be907-c20a-4f96-9b9e-e34eefa2e7f3@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<fEpfi4CzTFr1Pl-IyOAVyHNXWlVz33lHKQyzVY0kBc8=.cc39355b-ee7a-4118-952a-28e4184eec84@github.com>
<DKuidQyyiiJOsrerLCeziselVyG9Ztpzsyc64ZNjlI4=.722fc4f7-d7cc-49df-9d82-5c1094508f74@github.com>
<hdttC4LhHE6y6Nbq0jjJwxxF4W0hTfJLK_siODDCBkM=.1667f495-fcd9-4b7f-8d58-24e27665eeb3@github.com>
<fWSdSqQfhOrGpFoExiaO4L-UDtR90_t0gRxp9YBO3_c=.0173618e-f392-4921-8fae-39d44b24de08@github.com>
<6PTWMepIDuZDdPfN3xNKV1vqUyO_R4yCSeiSTpYIyyQ=.61a5b462-7114-4385-a6d7-40e5c7b0005d@github.com>
<C5LwWrsa-VO87kdm_sYuisTGMsHoxv4Eoe0QikdkusE=.63b0993c-86c8-4ef6-a3cf-bc8a67e10815@github.com>
<WOlTJMNHCr_Kk69sEIUwCVI3ZbiRlckY4TSBRfL7zoA=.1a4c59f1-a000-4d9f-abbc-36b24ed5105e@github.com>
<UjwpWz9Y3W8WRzYHZmDk9EvoiLSCZG1aai5oASGtDKA=.68cab6dd-e67d-4651-a9c9-75dccf42d85f@github.com>
<l_7f8gGpIdG9H3Ini5vHWruIa0oDi7fkn2Lz5thDI5c=.969b804f-bae2-48e1-9c44-e631d90037e7@github.com>
<BtvwMUG5tcy_zU4tRG3Q5VVw08qE_3gSE35
wCxlDnj4=.954353e5-cab2-48f4-b0f2-5852e586ba20@github.com>
<zi8MM6qUWhvxPSyb3ewa3baXWhmDIDlut2uYUQmWvcw=.7b32fa42-7a3f-43bb-8f15-fe6b8e66c49b@github.com>
<TSxYcKKfAdx7SsVcq6iwiySCLlkoVbXQO7a25vsiG4k=.29e59a6c-b8e0-42e9-8bdd-cc8ca23df146@github.com>
<YpG7vj6W3LnbhvvRhaeLmLeBzc_vlzlzmD74xVu1FQY=.14a57f09-74c1-4b2f-962c-c923961c067c@github.com>
<YrOurf-ql2uciTYRjGDnvVIb3r9K1pYphx2yRism6SQ=.f5b2510c-d384-4e78-906b-08267a218185@github.com>
<YqRmzdVypPfgEUFG9TqiQvD846aTd9SE9pU746Ed3HU=.a0349ab7-aabc-471c-9375-ef432a187caa@github.com>
<6yrLSIp1cwJXxYVoMfSLxhbFA9Qdc9P3ML25QW0sfL4=.aa8bedac-1faa-4148-bcfc-a1434ddc9bac@github.com>
<lD7f-h93ZqWOHoJtIECJfizoH74j3_iwG2VG_jAYR1o=.db4be907-c20a-4f96-9b9e-e34eefa2e7f3@github.com>
Message-ID: <Z0hfAlQlvNDCIcDK3LTPO4yKYN_dJnVa7CVinbFPgLI=.d1f5d4e7-8ff1-417c-8e8f-c2666a64f569@github.com>
On Tue, 8 Oct 2024 15:44:45 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:
>> Thank you, @sviswa7! Yes this fix looks correct. I've intergrated it into this PR and re-enabled the indexOf intrinsic for compact headers.
>
> @rkennke @sviswa7 These changes trigger the following assertion failure:
>
>
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # Internal Error (codeBuffer.cpp:1004), pid=96032, tid=29699
> # guarantee(sect->end() <= tend) failed: sanity
>
>
> when running the following tests with compact object headers disabled (i.e. default JVM settings):
>
> - `java/lang/StringBuffer/ECoreIndexOf.java`
> - `java/lang/String/IndexOf.java`
>
> on our test macosx-x64 machines. These machines are equipped with Intel Core i7-8700B processors with the following characteristics:
>
> CPU: total 12 (initial active 12) (6 cores per cpu, 2 threads per core) family 6 model 158 stepping 10 microcode 0xf4, cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, lzcnt, tsc, tscinvbit, avx, avx2, aes, erms, clmul, bmi1, bmi2, rtm, adx, fma, vzeroupper, clflush, clflushopt, rdtscp, f16c
>
>
> If you need more details to reproduce the issue, please let me know and I will try to help.
Turns out I can also reproduce the issue on my linux-x64 machine (Intel Core i7-9850H), simply running:
`make run-test TEST="java/lang/String/IndexOf.java" CONF=linux-x64-debug`
In this case I get:
#
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (codeBuffer.hpp:200), pid=51958, tid=51975
# assert(allocates2(pc)) failed: not in CodeBuffer memory: 0x00007c2778843560 <= 0x00007c27788543b3 <= 0x00007c27788543b0
A few more details of my processor:
family 6 model 158 stepping 13
flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb ssbd ibrs ibpb stibp ibrs_enhanced tpr_shadow flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp vnmi md_clear flush_l1d arch_capabilities
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1792141874
From rkennke at openjdk.org Tue Oct 8 16:30:47 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 8 Oct 2024 16:30:47 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v39]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <q4sTPbMm-cK1O35GhIbRytiakYgyKJYrBhotG_Kwn2o=.02620a61-e96d-4c93-af80-d27a61dd9ee7@github.com>
> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>
> Main changes:
> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
> - Arrays will now store their length at offset 8.
> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...
Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
Increase compiler code stubs size for indexOf intrinsic
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/20677/files
- new: https://git.openjdk.org/jdk/pull/20677/files/4035bb61..b289ef88
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=38
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=37-38
Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
Patch: https://git.openjdk.org/jdk/pull/20677.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677
PR: https://git.openjdk.org/jdk/pull/20677
From rkennke at openjdk.org Tue Oct 8 16:34:19 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 8 Oct 2024 16:34:19 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v26]
In-Reply-To: <Z0hfAlQlvNDCIcDK3LTPO4yKYN_dJnVa7CVinbFPgLI=.d1f5d4e7-8ff1-417c-8e8f-c2666a64f569@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<fEpfi4CzTFr1Pl-IyOAVyHNXWlVz33lHKQyzVY0kBc8=.cc39355b-ee7a-4118-952a-28e4184eec84@github.com>
<DKuidQyyiiJOsrerLCeziselVyG9Ztpzsyc64ZNjlI4=.722fc4f7-d7cc-49df-9d82-5c1094508f74@github.com>
<hdttC4LhHE6y6Nbq0jjJwxxF4W0hTfJLK_siODDCBkM=.1667f495-fcd9-4b7f-8d58-24e27665eeb3@github.com>
<fWSdSqQfhOrGpFoExiaO4L-UDtR90_t0gRxp9YBO3_c=.0173618e-f392-4921-8fae-39d44b24de08@github.com>
<6PTWMepIDuZDdPfN3xNKV1vqUyO_R4yCSeiSTpYIyyQ=.61a5b462-7114-4385-a6d7-40e5c7b0005d@github.com>
<C5LwWrsa-VO87kdm_sYuisTGMsHoxv4Eoe0QikdkusE=.63b0993c-86c8-4ef6-a3cf-bc8a67e10815@github.com>
<WOlTJMNHCr_Kk69sEIUwCVI3ZbiRlckY4TSBRfL7zoA=.1a4c59f1-a000-4d9f-abbc-36b24ed5105e@github.com>
<UjwpWz9Y3W8WRzYHZmDk9EvoiLSCZG1aai5oASGtDKA=.68cab6dd-e67d-4651-a9c9-75dccf42d85f@github.com>
<l_7f8gGpIdG9H3Ini5vHWruIa0oDi7fkn2Lz5thDI5c=.969b804f-bae2-48e1-9c44-e631d90037e7@github.com>
<BtvwMUG5tcy_zU4tRG3Q5VVw08qE_3gSE35
wCxlDnj4=.954353e5-cab2-48f4-b0f2-5852e586ba20@github.com>
<zi8MM6qUWhvxPSyb3ewa3baXWhmDIDlut2uYUQmWvcw=.7b32fa42-7a3f-43bb-8f15-fe6b8e66c49b@github.com>
<TSxYcKKfAdx7SsVcq6iwiySCLlkoVbXQO7a25vsiG4k=.29e59a6c-b8e0-42e9-8bdd-cc8ca23df146@github.com>
<YpG7vj6W3LnbhvvRhaeLmLeBzc_vlzlzmD74xVu1FQY=.14a57f09-74c1-4b2f-962c-c923961c067c@github.com>
<YrOurf-ql2uciTYRjGDnvVIb3r9K1pYphx2yRism6SQ=.f5b2510c-d384-4e78-906b-08267a218185@github.com>
<YqRmzdVypPfgEUFG9TqiQvD846aTd9SE9pU746Ed3HU=.a0349ab7-aabc-471c-9375-ef432a187caa@github.com>
<6yrLSIp1cwJXxYVoMfSLxhbFA9Qdc9P3ML25QW0sfL4=.aa8bedac-1faa-4148-bcfc-a1434ddc9bac@github.com>
<lD7f-h93ZqWOHoJtIECJfizoH74j3_iwG2VG_jAYR1o=.db4be907-c20a-4f96-9b9e-e34eefa2e7f3@github.com>
<Z0hfAlQlvNDCIcDK3LTPO4yKYN_dJnVa7CVinbFPgLI=.d1f5d4e7-8ff1-417c-8e8f-c2666a64f569@github.com>
Message-ID: <hIf7108CCy2cYFW9shrUuP_oR7GcrDN5czlDK7Erbt0=.49632b4b-d1f2-40a9-80da-47e89f46b479@github.com>
On Tue, 8 Oct 2024 15:58:33 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:
>> @rkennke @sviswa7 These changes trigger the following assertion failure:
>>
>>
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> # Internal Error (codeBuffer.cpp:1004), pid=96032, tid=29699
>> # guarantee(sect->end() <= tend) failed: sanity
>>
>>
>> when running the following tests with compact object headers disabled (i.e. default JVM settings):
>>
>> - `java/lang/StringBuffer/ECoreIndexOf.java`
>> - `java/lang/String/IndexOf.java`
>>
>> on our test macosx-x64 machines. These machines are equipped with Intel Core i7-8700B processors with the following characteristics:
>>
>> CPU: total 12 (initial active 12) (6 cores per cpu, 2 threads per core) family 6 model 158 stepping 10 microcode 0xf4, cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, lzcnt, tsc, tscinvbit, avx, avx2, aes, erms, clmul, bmi1, bmi2, rtm, adx, fma, vzeroupper, clflush, clflushopt, rdtscp, f16c
>>
>>
>> If you need more details to reproduce the issue, please let me know and I will try to help.
>
> Turns out I can also reproduce the issue on my linux-x64 machine (Intel Core i7-9850H), simply running:
>
> `make run-test TEST="java/lang/String/IndexOf.java" CONF=linux-x64-debug`
>
> In this case I get:
>
>
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # Internal Error (codeBuffer.hpp:200), pid=51958, tid=51975
> # assert(allocates2(pc)) failed: not in CodeBuffer memory: 0x00007c2778843560 <= 0x00007c27788543b3 <= 0x00007c27788543b0
>
>
> A few more details of my processor:
>
> family 6 model 158 stepping 13
> flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb ssbd ibrs ibpb stibp ibrs_enhanced tpr_shadow flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp vnmi md_clear flush_l1d arch_capabilities
Oh! We need to increase the compiler stub size for the indexOf changes. Strange that it blows up like this, I was sure there was a better check for this somewhere. I changed it like this, let me know if you agree that this is the correct fix:
https://github.com/openjdk/jdk/pull/20677/commits/b289ef885816958d9806c76f473b10e34a39e247
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1792186244
From sviswanathan at openjdk.org Tue Oct 8 16:38:23 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Tue, 8 Oct 2024 16:38:23 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v26]
In-Reply-To: <hIf7108CCy2cYFW9shrUuP_oR7GcrDN5czlDK7Erbt0=.49632b4b-d1f2-40a9-80da-47e89f46b479@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<fEpfi4CzTFr1Pl-IyOAVyHNXWlVz33lHKQyzVY0kBc8=.cc39355b-ee7a-4118-952a-28e4184eec84@github.com>
<DKuidQyyiiJOsrerLCeziselVyG9Ztpzsyc64ZNjlI4=.722fc4f7-d7cc-49df-9d82-5c1094508f74@github.com>
<hdttC4LhHE6y6Nbq0jjJwxxF4W0hTfJLK_siODDCBkM=.1667f495-fcd9-4b7f-8d58-24e27665eeb3@github.com>
<fWSdSqQfhOrGpFoExiaO4L-UDtR90_t0gRxp9YBO3_c=.0173618e-f392-4921-8fae-39d44b24de08@github.com>
<6PTWMepIDuZDdPfN3xNKV1vqUyO_R4yCSeiSTpYIyyQ=.61a5b462-7114-4385-a6d7-40e5c7b0005d@github.com>
<C5LwWrsa-VO87kdm_sYuisTGMsHoxv4Eoe0QikdkusE=.63b0993c-86c8-4ef6-a3cf-bc8a67e10815@github.com>
<WOlTJMNHCr_Kk69sEIUwCVI3ZbiRlckY4TSBRfL7zoA=.1a4c59f1-a000-4d9f-abbc-36b24ed5105e@github.com>
<UjwpWz9Y3W8WRzYHZmDk9EvoiLSCZG1aai5oASGtDKA=.68cab6dd-e67d-4651-a9c9-75dccf42d85f@github.com>
<l_7f8gGpIdG9H3Ini5vHWruIa0oDi7fkn2Lz5thDI5c=.969b804f-bae2-48e1-9c44-e631d90037e7@github.com>
<BtvwMUG5tcy_zU4tRG3Q5VVw08qE_3gSE35
wCxlDnj4=.954353e5-cab2-48f4-b0f2-5852e586ba20@github.com>
<zi8MM6qUWhvxPSyb3ewa3baXWhmDIDlut2uYUQmWvcw=.7b32fa42-7a3f-43bb-8f15-fe6b8e66c49b@github.com>
<TSxYcKKfAdx7SsVcq6iwiySCLlkoVbXQO7a25vsiG4k=.29e59a6c-b8e0-42e9-8bdd-cc8ca23df146@github.com>
<YpG7vj6W3LnbhvvRhaeLmLeBzc_vlzlzmD74xVu1FQY=.14a57f09-74c1-4b2f-962c-c923961c067c@github.com>
<YrOurf-ql2uciTYRjGDnvVIb3r9K1pYphx2yRism6SQ=.f5b2510c-d384-4e78-906b-08267a218185@github.com>
<YqRmzdVypPfgEUFG9TqiQvD846aTd9SE9pU746Ed3HU=.a0349ab7-aabc-471c-9375-ef432a187caa@github.com>
<6yrLSIp1cwJXxYVoMfSLxhbFA9Qdc9P3ML25QW0sfL4=.aa8bedac-1faa-4148-bcfc-a1434ddc9bac@github.com>
<lD7f-h93ZqWOHoJtIECJfizoH74j3_iwG2VG_jAYR1o=.db4be907-c20a-4f96-9b9e-e34eefa2e7f3@github.com>
<Z0hfAlQlvNDCIcDK3LTPO4yKYN_dJnVa7CVinbFPgLI=.d1f5d4e7-8ff1-417c-8e8f-c2666a64f569@github.com>
<hIf7108CCy2cYFW9shrUuP_oR7GcrDN5czlDK7Erbt0=.49632b4b-d1f2-40a9-80da-47e89f46b479@github.com>
Message-ID: <rDH4CrN_DbFWc6fYt6hudqSKv7CG_lcQCt7CB-wsljk=.313b0c44-e0af-47ca-a41e-76d1a18e2cdc@github.com>
On Tue, 8 Oct 2024 16:30:56 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
>> Turns out I can also reproduce the issue on my linux-x64 machine (Intel Core i7-9850H), simply running:
>>
>> `make run-test TEST="java/lang/String/IndexOf.java" CONF=linux-x64-debug`
>>
>> In this case I get:
>>
>>
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> # Internal Error (codeBuffer.hpp:200), pid=51958, tid=51975
>> # assert(allocates2(pc)) failed: not in CodeBuffer memory: 0x00007c2778843560 <= 0x00007c27788543b3 <= 0x00007c27788543b0
>>
>>
>> A few more details of my processor:
>>
>> family 6 model 158 stepping 13
>> flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb ssbd ibrs ibpb stibp ibrs_enhanced tpr_shadow flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp vnmi md_clear flush_l1d arch_capabilities
>
> Oh! We need to increase the compiler stub size for the indexOf changes. Strange that it blows up like this, I was sure there was a better check for this somewhere. I changed it like this, let me know if you agree that this is the correct fix:
> https://github.com/openjdk/jdk/pull/20677/commits/b289ef885816958d9806c76f473b10e34a39e247
Yes, the fix looks correct. Thanks.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1792191386
From rcastanedalo at openjdk.org Wed Oct 9 06:30:18 2024
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Wed, 9 Oct 2024 06:30:18 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v26]
In-Reply-To: <hIf7108CCy2cYFW9shrUuP_oR7GcrDN5czlDK7Erbt0=.49632b4b-d1f2-40a9-80da-47e89f46b479@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<fEpfi4CzTFr1Pl-IyOAVyHNXWlVz33lHKQyzVY0kBc8=.cc39355b-ee7a-4118-952a-28e4184eec84@github.com>
<DKuidQyyiiJOsrerLCeziselVyG9Ztpzsyc64ZNjlI4=.722fc4f7-d7cc-49df-9d82-5c1094508f74@github.com>
<hdttC4LhHE6y6Nbq0jjJwxxF4W0hTfJLK_siODDCBkM=.1667f495-fcd9-4b7f-8d58-24e27665eeb3@github.com>
<fWSdSqQfhOrGpFoExiaO4L-UDtR90_t0gRxp9YBO3_c=.0173618e-f392-4921-8fae-39d44b24de08@github.com>
<6PTWMepIDuZDdPfN3xNKV1vqUyO_R4yCSeiSTpYIyyQ=.61a5b462-7114-4385-a6d7-40e5c7b0005d@github.com>
<C5LwWrsa-VO87kdm_sYuisTGMsHoxv4Eoe0QikdkusE=.63b0993c-86c8-4ef6-a3cf-bc8a67e10815@github.com>
<WOlTJMNHCr_Kk69sEIUwCVI3ZbiRlckY4TSBRfL7zoA=.1a4c59f1-a000-4d9f-abbc-36b24ed5105e@github.com>
<UjwpWz9Y3W8WRzYHZmDk9EvoiLSCZG1aai5oASGtDKA=.68cab6dd-e67d-4651-a9c9-75dccf42d85f@github.com>
<l_7f8gGpIdG9H3Ini5vHWruIa0oDi7fkn2Lz5thDI5c=.969b804f-bae2-48e1-9c44-e631d90037e7@github.com>
<BtvwMUG5tcy_zU4tRG3Q5VVw08qE_3gSE35
wCxlDnj4=.954353e5-cab2-48f4-b0f2-5852e586ba20@github.com>
<zi8MM6qUWhvxPSyb3ewa3baXWhmDIDlut2uYUQmWvcw=.7b32fa42-7a3f-43bb-8f15-fe6b8e66c49b@github.com>
<TSxYcKKfAdx7SsVcq6iwiySCLlkoVbXQO7a25vsiG4k=.29e59a6c-b8e0-42e9-8bdd-cc8ca23df146@github.com>
<YpG7vj6W3LnbhvvRhaeLmLeBzc_vlzlzmD74xVu1FQY=.14a57f09-74c1-4b2f-962c-c923961c067c@github.com>
<YrOurf-ql2uciTYRjGDnvVIb3r9K1pYphx2yRism6SQ=.f5b2510c-d384-4e78-906b-08267a218185@github.com>
<YqRmzdVypPfgEUFG9TqiQvD846aTd9SE9pU746Ed3HU=.a0349ab7-aabc-471c-9375-ef432a187caa@github.com>
<6yrLSIp1cwJXxYVoMfSLxhbFA9Qdc9P3ML25QW0sfL4=.aa8bedac-1faa-4148-bcfc-a1434ddc9bac@github.com>
<lD7f-h93ZqWOHoJtIECJfizoH74j3_iwG2VG_jAYR1o=.db4be907-c20a-4f96-9b9e-e34eefa2e7f3@github.com>
<Z0hfAlQlvNDCIcDK3LTPO4yKYN_dJnVa7CVinbFPgLI=.d1f5d4e7-8ff1-417c-8e8f-c2666a64f569@github.com>
<hIf7108CCy2cYFW9shrUuP_oR7GcrDN5czlDK7Erbt0=.49632b4b-d1f2-40a9-80da-47e89f46b479@github.com>
Message-ID: <ouoemlEpzqpgckNviJxccPlr69RhOeCy2KCxMhRX8rg=.203da6e1-fa45-4377-bebe-2c41eb8e344d@github.com>
On Tue, 8 Oct 2024 16:30:56 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
>> Turns out I can also reproduce the issue on my linux-x64 machine (Intel Core i7-9850H), simply running:
>>
>> `make run-test TEST="java/lang/String/IndexOf.java" CONF=linux-x64-debug`
>>
>> In this case I get:
>>
>>
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> # Internal Error (codeBuffer.hpp:200), pid=51958, tid=51975
>> # assert(allocates2(pc)) failed: not in CodeBuffer memory: 0x00007c2778843560 <= 0x00007c27788543b3 <= 0x00007c27788543b0
>>
>>
>> A few more details of my processor:
>>
>> family 6 model 158 stepping 13
>> flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb ssbd ibrs ibpb stibp ibrs_enhanced tpr_shadow flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp vnmi md_clear flush_l1d arch_capabilities
>
> Oh! We need to increase the compiler stub size for the indexOf changes. Strange that it blows up like this, I was sure there was a better check for this somewhere. I changed it like this, let me know if you agree that this is the correct fix:
> https://github.com/openjdk/jdk/pull/20677/commits/b289ef885816958d9806c76f473b10e34a39e247
That seems to work, thanks @rkennke!
Since the [indexOf changes](https://github.com/openjdk/jdk/pull/20677/files#diff-ae1139bb5342494f9761e04389b090c543391bfdd7817af1625e854357c96e63) are complex and affect the default JVM configuration, they should be subject to the same level of scrutiny as if they were a standalone RFE, i.e. approved by at least a second reviewer. @sviswa7 could someone else at Intel have a second look and explicitly approve them?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1792911644
From aboldtch at openjdk.org Wed Oct 9 11:47:04 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 9 Oct 2024 11:47:04 GMT
Subject: RFR: 8336911: ZGC: Division by zero in heuristics after
JDK-8332717
In-Reply-To: <eUrp0LFMiszFVtg0ny3iu8udO7KKdkEU6PNTHiwz7Lo=.8d57efc4-3977-4f8a-94bc-e5d177f17579@github.com>
References: <rByxhEm3b3JZQVvugNz4KezLFPWc2NH_vOPaAl9Je2A=.703a5530-a302-43b2-a6bf-37f100c8bc79@github.com>
<TVdAZ6lUVILfil1wDSKBU-VcFyGEMuE0tWu1zIiL88Y=.80b704c2-8edf-4d15-af55-260a3a1e5a85@github.com>
<eUrp0LFMiszFVtg0ny3iu8udO7KKdkEU6PNTHiwz7Lo=.8d57efc4-3977-4f8a-94bc-e5d177f17579@github.com>
Message-ID: <Ps7ob3kpU3f8_q_NP3nGk9ktfNXRzgjx-IlMqyXLP_w=.b8609a53-5aeb-4224-a79a-ebb920770b87@github.com>
On Fri, 4 Oct 2024 07:33:06 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:
>> src/hotspot/share/gc/z/zDirector.cpp line 539:
>>
>>> 537: const double current_old_bytes_freed_per_gc_time = double(reclaimed_per_old_gc) / double(old_gc_time);
>>> 538: const double old_vs_young_efficiency_ratio = current_young_bytes_freed_per_gc_time == 0 ? std::numeric_limits<double>::infinity()
>>> 539: : current_old_bytes_freed_per_gc_time / current_young_bytes_freed_per_gc_time;
>>
>> I think returning infinity here will cause problems with NaN down the line. It is also unclear what this means if both are `0`. To me something like the following makes sense. But I will discus this with my team.
>> Suggestion:
>>
>>
>> if (current_young_bytes_freed_per_gc_time == 0.0) {
>> if (current_old_bytes_freed_per_gc_time == 0.0) {
>> // Neither young nor old collections have reclaimed any memory.
>> // Give them equal priority.
>> return 1.0;
>> }
>>
>> // Only old collections have reclaimed memory.
>> // Prioritize old.
>> return ZOldGCThreads;
>> }
>>
>> const double old_vs_young_efficiency_ratio = current_old_bytes_freed_per_gc_time / current_young_bytes_freed_per_gc_time;
>
> Hi Axel, thanks for the suggestion.
> Please discuss it in your team and tell me the outcome :-) !
I think you can go ahead and use my proposed change. And I will review it.
@fisk, who has the most familiarity with the heuristics code, is currently on vacation. So we should wait until he is back and let him review this as well.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/21304#discussion_r1793369646
From mbaesken at openjdk.org Wed Oct 9 13:29:12 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 9 Oct 2024 13:29:12 GMT
Subject: RFR: 8336911: ZGC: Division by zero in heuristics after
JDK-8332717 [v2]
In-Reply-To: <rByxhEm3b3JZQVvugNz4KezLFPWc2NH_vOPaAl9Je2A=.703a5530-a302-43b2-a6bf-37f100c8bc79@github.com>
References: <rByxhEm3b3JZQVvugNz4KezLFPWc2NH_vOPaAl9Je2A=.703a5530-a302-43b2-a6bf-37f100c8bc79@github.com>
Message-ID: <2OVE7gfBr7mpSgxO6FCoQIDfZqeFvufLta6KuVUFCoU=.460b937e-9852-4c0c-932e-06e6c6726016@github.com>
> When running with ubsan enabled binaries, the following issue is reported,
> e.g. in test
> compiler/uncommontrap/TestDeoptOOM_ZGenerational.jtr
> also in gc/z/TestSmallHeap.jtr
>
>
> jdk/src/hotspot/share/gc/z/zDirector.cpp:537:84: runtime error: division by zero
> #0 0x7f422495bd1f in calculate_young_to_old_worker_ratio src/hotspot/share/gc/z/zDirector.cpp:537
> #1 0x7f422495bd1f in select_worker_threads src/hotspot/share/gc/z/zDirector.cpp:694
> #2 0x7f42282a0d97 in select_worker_threads src/hotspot/share/gc/z/zDirector.cpp:689
> #3 0x7f42282a0d97 in initial_workers src/hotspot/share/gc/z/zDirector.cpp:784
> #4 0x7f42282a2485 in initial_workers src/hotspot/share/gc/z/zDirector.cpp:795
> #5 0x7f42282a2485 in start_minor_gc src/hotspot/share/gc/z/zDirector.cpp:797
> #6 0x7f42282a2485 in start_gc src/hotspot/share/gc/z/zDirector.cpp:826
> #7 0x7f42282a2485 in ZDirector::run_thread() src/hotspot/share/gc/z/zDirector.cpp:912
> #8 0x7f422840bdd8 in ZThread::run_service() src/hotspot/share/gc/z/zThread.cpp:29
> #9 0x7f4225ab6979 in ConcurrentGCThread::run() src/hotspot/share/gc/shared/concurrentGCThread.cpp:48
> #10 0x7f4227e1137a in Thread::call_run() src/hotspot/share/runtime/thread.cpp:225
> #11 0x7f42274619b1 in thread_native_entry src/hotspot/os/linux/os_linux.cpp:858
> #12 0x7f422c8d36e9 in start_thread (/lib64/libpthread.so.0+0xa6e9) (BuildId: 9a146bd267419cb6a8cf08d7c602953a0f2e12c5)
> #13 0x7f422c1dc58e in clone (/lib64/libc.so.6+0x11858e) (BuildId: f2d1cb1ef49f8c47d43a4053910ba6137673ccce)
>
>
> The division by 0 leads to 'infinity' on most of our platforms. So instead of relying on this behavior, we can add a small check and set 'infinity' for divisor == 0.
Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
adjustment from xmas - Update src/hotspot/share/gc/z/zDirector.cpp
Co-authored-by: Axel Boldt-Christmas <xmas1915 at gmail.com>
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/21304/files
- new: https://git.openjdk.org/jdk/pull/21304/files/5debdae2..3b5ffc53
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=21304&range=01
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=21304&range=00-01
Stats: 14 lines in 1 file changed: 12 ins; 0 del; 2 mod
Patch: https://git.openjdk.org/jdk/pull/21304.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/21304/head:pull/21304
PR: https://git.openjdk.org/jdk/pull/21304
From sviswanathan at openjdk.org Wed Oct 9 16:25:23 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Wed, 9 Oct 2024 16:25:23 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v26]
In-Reply-To: <ouoemlEpzqpgckNviJxccPlr69RhOeCy2KCxMhRX8rg=.203da6e1-fa45-4377-bebe-2c41eb8e344d@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<fEpfi4CzTFr1Pl-IyOAVyHNXWlVz33lHKQyzVY0kBc8=.cc39355b-ee7a-4118-952a-28e4184eec84@github.com>
<DKuidQyyiiJOsrerLCeziselVyG9Ztpzsyc64ZNjlI4=.722fc4f7-d7cc-49df-9d82-5c1094508f74@github.com>
<hdttC4LhHE6y6Nbq0jjJwxxF4W0hTfJLK_siODDCBkM=.1667f495-fcd9-4b7f-8d58-24e27665eeb3@github.com>
<fWSdSqQfhOrGpFoExiaO4L-UDtR90_t0gRxp9YBO3_c=.0173618e-f392-4921-8fae-39d44b24de08@github.com>
<6PTWMepIDuZDdPfN3xNKV1vqUyO_R4yCSeiSTpYIyyQ=.61a5b462-7114-4385-a6d7-40e5c7b0005d@github.com>
<C5LwWrsa-VO87kdm_sYuisTGMsHoxv4Eoe0QikdkusE=.63b0993c-86c8-4ef6-a3cf-bc8a67e10815@github.com>
<WOlTJMNHCr_Kk69sEIUwCVI3ZbiRlckY4TSBRfL7zoA=.1a4c59f1-a000-4d9f-abbc-36b24ed5105e@github.com>
<UjwpWz9Y3W8WRzYHZmDk9EvoiLSCZG1aai5oASGtDKA=.68cab6dd-e67d-4651-a9c9-75dccf42d85f@github.com>
<l_7f8gGpIdG9H3Ini5vHWruIa0oDi7fkn2Lz5thDI5c=.969b804f-bae2-48e1-9c44-e631d90037e7@github.com>
<BtvwMUG5tcy_zU4tRG3Q5VVw08qE_3gSE35
wCxlDnj4=.954353e5-cab2-48f4-b0f2-5852e586ba20@github.com>
<zi8MM6qUWhvxPSyb3ewa3baXWhmDIDlut2uYUQmWvcw=.7b32fa42-7a3f-43bb-8f15-fe6b8e66c49b@github.com>
<TSxYcKKfAdx7SsVcq6iwiySCLlkoVbXQO7a25vsiG4k=.29e59a6c-b8e0-42e9-8bdd-cc8ca23df146@github.com>
<YpG7vj6W3LnbhvvRhaeLmLeBzc_vlzlzmD74xVu1FQY=.14a57f09-74c1-4b2f-962c-c923961c067c@github.com>
<YrOurf-ql2uciTYRjGDnvVIb3r9K1pYphx2yRism6SQ=.f5b2510c-d384-4e78-906b-08267a218185@github.com>
<YqRmzdVypPfgEUFG9TqiQvD846aTd9SE9pU746Ed3HU=.a0349ab7-aabc-471c-9375-ef432a187caa@github.com>
<6yrLSIp1cwJXxYVoMfSLxhbFA9Qdc9P3ML25QW0sfL4=.aa8bedac-1faa-4148-bcfc-a1434ddc9bac@github.com>
<lD7f-h93ZqWOHoJtIECJfizoH74j3_iwG2VG_jAYR1o=.db4be907-c20a-4f96-9b9e-e34eefa2e7f3@github.com>
<Z0hfAlQlvNDCIcDK3LTPO4yKYN_dJnVa7CVinbFPgLI=.d1f5d4e7-8ff1-417c-8e8f-c2666a64f569@github.com>
<hIf7108CCy2cYFW9shrUuP_oR7GcrDN5czlDK7Erbt0=.49632b4b-d1f2-40a9-80da-47e89f46b479@github.com>
<ouoemlEpzqpgckNviJxccPlr69RhOeCy2KCxMhRX8rg=.203da6e1-fa45-4377-bebe-2c41eb8e344d@
github.com>
Message-ID: <Xl2cSg6Ql6ttcW4mtRAi7uq-lKjPX37xNqMF1zG398w=.90ceecb4-e531-417c-ae96-b03dba0fe313@github.com>
On Wed, 9 Oct 2024 06:25:28 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:
>> Oh! We need to increase the compiler stub size for the indexOf changes. Strange that it blows up like this, I was sure there was a better check for this somewhere. I changed it like this, let me know if you agree that this is the correct fix:
>> https://github.com/openjdk/jdk/pull/20677/commits/b289ef885816958d9806c76f473b10e34a39e247
>
> That seems to work, thanks @rkennke!
>
> Since the [indexOf changes](https://github.com/openjdk/jdk/pull/20677/files#diff-ae1139bb5342494f9761e04389b090c543391bfdd7817af1625e854357c96e63) are complex and affect the default JVM configuration, they should be subject to the same level of scrutiny as if they were a standalone RFE, i.e. approved by at least a second reviewer. @sviswa7 could someone else at Intel have a second look and explicitly approve them?
Yes, @vpaprotsk could review the changes that we made in src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1793814453
From rcastanedalo at openjdk.org Wed Oct 9 17:44:24 2024
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Wed, 9 Oct 2024 17:44:24 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v26]
In-Reply-To: <Xl2cSg6Ql6ttcW4mtRAi7uq-lKjPX37xNqMF1zG398w=.90ceecb4-e531-417c-ae96-b03dba0fe313@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<fEpfi4CzTFr1Pl-IyOAVyHNXWlVz33lHKQyzVY0kBc8=.cc39355b-ee7a-4118-952a-28e4184eec84@github.com>
<DKuidQyyiiJOsrerLCeziselVyG9Ztpzsyc64ZNjlI4=.722fc4f7-d7cc-49df-9d82-5c1094508f74@github.com>
<hdttC4LhHE6y6Nbq0jjJwxxF4W0hTfJLK_siODDCBkM=.1667f495-fcd9-4b7f-8d58-24e27665eeb3@github.com>
<fWSdSqQfhOrGpFoExiaO4L-UDtR90_t0gRxp9YBO3_c=.0173618e-f392-4921-8fae-39d44b24de08@github.com>
<6PTWMepIDuZDdPfN3xNKV1vqUyO_R4yCSeiSTpYIyyQ=.61a5b462-7114-4385-a6d7-40e5c7b0005d@github.com>
<C5LwWrsa-VO87kdm_sYuisTGMsHoxv4Eoe0QikdkusE=.63b0993c-86c8-4ef6-a3cf-bc8a67e10815@github.com>
<WOlTJMNHCr_Kk69sEIUwCVI3ZbiRlckY4TSBRfL7zoA=.1a4c59f1-a000-4d9f-abbc-36b24ed5105e@github.com>
<UjwpWz9Y3W8WRzYHZmDk9EvoiLSCZG1aai5oASGtDKA=.68cab6dd-e67d-4651-a9c9-75dccf42d85f@github.com>
<l_7f8gGpIdG9H3Ini5vHWruIa0oDi7fkn2Lz5thDI5c=.969b804f-bae2-48e1-9c44-e631d90037e7@github.com>
<BtvwMUG5tcy_zU4tRG3Q5VVw08qE_3gSE35
wCxlDnj4=.954353e5-cab2-48f4-b0f2-5852e586ba20@github.com>
<zi8MM6qUWhvxPSyb3ewa3baXWhmDIDlut2uYUQmWvcw=.7b32fa42-7a3f-43bb-8f15-fe6b8e66c49b@github.com>
<TSxYcKKfAdx7SsVcq6iwiySCLlkoVbXQO7a25vsiG4k=.29e59a6c-b8e0-42e9-8bdd-cc8ca23df146@github.com>
<YpG7vj6W3LnbhvvRhaeLmLeBzc_vlzlzmD74xVu1FQY=.14a57f09-74c1-4b2f-962c-c923961c067c@github.com>
<YrOurf-ql2uciTYRjGDnvVIb3r9K1pYphx2yRism6SQ=.f5b2510c-d384-4e78-906b-08267a218185@github.com>
<YqRmzdVypPfgEUFG9TqiQvD846aTd9SE9pU746Ed3HU=.a0349ab7-aabc-471c-9375-ef432a187caa@github.com>
<6yrLSIp1cwJXxYVoMfSLxhbFA9Qdc9P3ML25QW0sfL4=.aa8bedac-1faa-4148-bcfc-a1434ddc9bac@github.com>
<lD7f-h93ZqWOHoJtIECJfizoH74j3_iwG2VG_jAYR1o=.db4be907-c20a-4f96-9b9e-e34eefa2e7f3@github.com>
<Z0hfAlQlvNDCIcDK3LTPO4yKYN_dJnVa7CVinbFPgLI=.d1f5d4e7-8ff1-417c-8e8f-c2666a64f569@github.com>
<hIf7108CCy2cYFW9shrUuP_oR7GcrDN5czlDK7Erbt0=.49632b4b-d1f2-40a9-80da-47e89f46b479@github.com>
<ouoemlEpzqpgckNviJxccPlr69RhOeCy2KCxMhRX8rg=.203da6e1-fa45-4377-bebe-2c41eb8e344d@
github.com>
<Xl2cSg6Ql6ttcW4mtRAi7uq-lKjPX37xNqMF1zG398w=.90ceecb4-e531-417c-ae96-b03dba0fe313@github.com>
Message-ID: <ffUwCDUB5JmTDFXVZsEKkLiNfkF2D3YTSRp9qX13orc=.f4e454c3-9bf6-46ad-9491-89a50a8e7810@github.com>
On Wed, 9 Oct 2024 16:21:53 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:
>> That seems to work, thanks @rkennke!
>>
>> Since the [indexOf changes](https://github.com/openjdk/jdk/pull/20677/files#diff-ae1139bb5342494f9761e04389b090c543391bfdd7817af1625e854357c96e63) are complex and affect the default JVM configuration, they should be subject to the same level of scrutiny as if they were a standalone RFE, i.e. approved by at least a second reviewer. @sviswa7 could someone else at Intel have a second look and explicitly approve them?
>
> Yes, @vpaprotsk could review the changes that we made in src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp.
Yes, that would be great. In the meantime, I ran a few thousand times the randomized test `java/lang/StringBuffer/ECoreIndexOf.java` with and without compact object headers, on product and debug builds, on different x64 implementations, and found no failures.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1793917912
From sviswanathan at openjdk.org Wed Oct 9 20:28:29 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Wed, 9 Oct 2024 20:28:29 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v26]
In-Reply-To: <ffUwCDUB5JmTDFXVZsEKkLiNfkF2D3YTSRp9qX13orc=.f4e454c3-9bf6-46ad-9491-89a50a8e7810@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<fEpfi4CzTFr1Pl-IyOAVyHNXWlVz33lHKQyzVY0kBc8=.cc39355b-ee7a-4118-952a-28e4184eec84@github.com>
<DKuidQyyiiJOsrerLCeziselVyG9Ztpzsyc64ZNjlI4=.722fc4f7-d7cc-49df-9d82-5c1094508f74@github.com>
<hdttC4LhHE6y6Nbq0jjJwxxF4W0hTfJLK_siODDCBkM=.1667f495-fcd9-4b7f-8d58-24e27665eeb3@github.com>
<fWSdSqQfhOrGpFoExiaO4L-UDtR90_t0gRxp9YBO3_c=.0173618e-f392-4921-8fae-39d44b24de08@github.com>
<6PTWMepIDuZDdPfN3xNKV1vqUyO_R4yCSeiSTpYIyyQ=.61a5b462-7114-4385-a6d7-40e5c7b0005d@github.com>
<C5LwWrsa-VO87kdm_sYuisTGMsHoxv4Eoe0QikdkusE=.63b0993c-86c8-4ef6-a3cf-bc8a67e10815@github.com>
<WOlTJMNHCr_Kk69sEIUwCVI3ZbiRlckY4TSBRfL7zoA=.1a4c59f1-a000-4d9f-abbc-36b24ed5105e@github.com>
<UjwpWz9Y3W8WRzYHZmDk9EvoiLSCZG1aai5oASGtDKA=.68cab6dd-e67d-4651-a9c9-75dccf42d85f@github.com>
<l_7f8gGpIdG9H3Ini5vHWruIa0oDi7fkn2Lz5thDI5c=.969b804f-bae2-48e1-9c44-e631d90037e7@github.com>
<BtvwMUG5tcy_zU4tRG3Q5VVw08qE_3gSE35
wCxlDnj4=.954353e5-cab2-48f4-b0f2-5852e586ba20@github.com>
<zi8MM6qUWhvxPSyb3ewa3baXWhmDIDlut2uYUQmWvcw=.7b32fa42-7a3f-43bb-8f15-fe6b8e66c49b@github.com>
<TSxYcKKfAdx7SsVcq6iwiySCLlkoVbXQO7a25vsiG4k=.29e59a6c-b8e0-42e9-8bdd-cc8ca23df146@github.com>
<YpG7vj6W3LnbhvvRhaeLmLeBzc_vlzlzmD74xVu1FQY=.14a57f09-74c1-4b2f-962c-c923961c067c@github.com>
<YrOurf-ql2uciTYRjGDnvVIb3r9K1pYphx2yRism6SQ=.f5b2510c-d384-4e78-906b-08267a218185@github.com>
<YqRmzdVypPfgEUFG9TqiQvD846aTd9SE9pU746Ed3HU=.a0349ab7-aabc-471c-9375-ef432a187caa@github.com>
<6yrLSIp1cwJXxYVoMfSLxhbFA9Qdc9P3ML25QW0sfL4=.aa8bedac-1faa-4148-bcfc-a1434ddc9bac@github.com>
<lD7f-h93ZqWOHoJtIECJfizoH74j3_iwG2VG_jAYR1o=.db4be907-c20a-4f96-9b9e-e34eefa2e7f3@github.com>
<Z0hfAlQlvNDCIcDK3LTPO4yKYN_dJnVa7CVinbFPgLI=.d1f5d4e7-8ff1-417c-8e8f-c2666a64f569@github.com>
<hIf7108CCy2cYFW9shrUuP_oR7GcrDN5czlDK7Erbt0=.49632b4b-d1f2-40a9-80da-47e89f46b479@github.com>
<ouoemlEpzqpgckNviJxccPlr69RhOeCy2KCxMhRX8rg=.203da6e1-fa45-4377-bebe-2c41eb8e344d@
github.com>
<Xl2cSg6Ql6ttcW4mtRAi7uq-lKjPX37xNqMF1zG398w=.90ceecb4-e531-417c-ae96-b03dba0fe313@github.com>
<ffUwCDUB5JmTDFXVZsEKkLiNfkF2D3YTSRp9qX13orc=.f4e454c3-9bf6-46ad-9491-89a50a8e7810@github.com>
Message-ID: <mcGN2Xuld1ZujJVmIkv3NBCPbspQ7YdjXtnb_0ypftk=.75e66e61-97d0-4ae8-bc98-b6af592a1853@github.com>
On Wed, 9 Oct 2024 17:41:37 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:
>> Yes, @vpaprotsk could review the changes that we made in src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp.
>
> Yes, that would be great. In the meantime, I ran a few thousand times the randomized test `java/lang/StringBuffer/ECoreIndexOf.java` with and without compact object headers, on product and debug builds, on different x64 implementations, and found no failures.
Thanks a lot @robcasloz for doing the testing.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1794181528
From wkemper at openjdk.org Wed Oct 9 21:04:22 2024
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 9 Oct 2024 21:04:22 GMT
Subject: RFR: 8339651: ShenandoahPacer::setup_for_mark,
ShenandoahPacer::setup_for_updaterefs and ShenandoahPacer::setup_for_evac
runtime error: division by zero
Message-ID: <V4_JujuCficbks9qbfsAf4yvkFEXi5clAPa6IR2H01E=.77e12334-3365-4eb7-9d8a-300985822196@github.com>
Avoid divide by zero error when there is no memory available.
-------------
Commit messages:
- Fix 32bit and windows builds
- Avoid divide-by-zero error
Changes: https://git.openjdk.org/jdk/pull/21432/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21432&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8339651
Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
Patch: https://git.openjdk.org/jdk/pull/21432.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/21432/head:pull/21432
PR: https://git.openjdk.org/jdk/pull/21432
From duke at openjdk.org Thu Oct 10 00:17:32 2024
From: duke at openjdk.org (Luca Kellermann)
Date: Thu, 10 Oct 2024 00:17:32 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v35]
In-Reply-To: <q1FPAZv5Ri_LysFtpAM3BlpJVZ3RoUTA_9GkLwc-ppE=.efc42fb9-c5d6-4a15-ad30-3dcbf8449828@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
<q1FPAZv5Ri_LysFtpAM3BlpJVZ3RoUTA_9GkLwc-ppE=.efc42fb9-c5d6-4a15-ad30-3dcbf8449828@github.com>
Message-ID: <0nG6Ma5PqefNeOTJCPO7L-DUAxAkbB_YhPsLDjuqJ4s=.5118ab72-1ed7-4e81-abdd-f06f852cff67@github.com>
On Fri, 31 May 2024 18:33:39 GMT, Brent Christian <bchristi at openjdk.org> wrote:
>> Classes in the `java.lang.ref` package would benefit from an update to bring the spec in line with how the VM already behaves. The changes would focus on _happens-before_ edges at some key points during reference processing.
>>
>> A couple key things we want to be able to say are:
>> - `Reference.reachabilityFence(x)` _happens-before_ reference processing occurs for 'x'.
>> - `Cleaner.register()` _happens-before_ the Cleaner thread runs the registered cleaning action.
>>
>> This will bring Cleaner in line (or close) with the memory visibility guarantees made for finalizers in [JLS 17.4.5](https://docs.oracle.com/javase/specs/jls/se18/html/jls-17.html#jls-17.4.5):
>> _"There is a happens-before edge from the end of a constructor of an object to the start of a finalizer (?12.6) for that object."_
>
> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
>
> another package doc link
src/java.base/share/classes/java/lang/ref/Reference.java line 561:
> 559: * triggering garbage collection. This method is applicable only
> 560: * when reclamation may have visible effects,
> 561: * such as for objects that use finalizers or {@link Cleaner}, or code that
This `@link` tag [does not produce a link in the Javadoc](https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/lang/ref/Reference.html#reachabilityFence(java.lang.Object)) because this file imports `jdk.internal.ref.Cleaner`.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1794411907
From shade at openjdk.org Thu Oct 10 05:49:09 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 10 Oct 2024 05:49:09 GMT
Subject: RFR: 8339651: ShenandoahPacer::setup_for_mark,
ShenandoahPacer::setup_for_updaterefs and ShenandoahPacer::setup_for_evac
runtime error: division by zero
In-Reply-To: <V4_JujuCficbks9qbfsAf4yvkFEXi5clAPa6IR2H01E=.77e12334-3365-4eb7-9d8a-300985822196@github.com>
References: <V4_JujuCficbks9qbfsAf4yvkFEXi5clAPa6IR2H01E=.77e12334-3365-4eb7-9d8a-300985822196@github.com>
Message-ID: <DwmQclFBfOzLDxhUH1C7HguqevVkf9lT1s4-euixHi4=.cbaffc8c-f03c-42f5-8b95-da10b7edafca@github.com>
On Wed, 9 Oct 2024 20:59:49 GMT, William Kemper <wkemper at openjdk.org> wrote:
> Avoid divide by zero error when there is no memory available.
Looks fine, thanks.
-------------
Marked as reviewed by shade (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/21432#pullrequestreview-2359047911
From mli at openjdk.org Thu Oct 10 08:03:10 2024
From: mli at openjdk.org (Hamlin Li)
Date: Thu, 10 Oct 2024 08:03:10 GMT
Subject: RFR: 8339651: ShenandoahPacer::setup_for_mark,
ShenandoahPacer::setup_for_updaterefs and ShenandoahPacer::setup_for_evac
runtime error: division by zero
In-Reply-To: <V4_JujuCficbks9qbfsAf4yvkFEXi5clAPa6IR2H01E=.77e12334-3365-4eb7-9d8a-300985822196@github.com>
References: <V4_JujuCficbks9qbfsAf4yvkFEXi5clAPa6IR2H01E=.77e12334-3365-4eb7-9d8a-300985822196@github.com>
Message-ID: <Yq0pBhB1bIChO89g9_GAUJVDcEG4dMctS1sgWFRWRx8=.4afea77d-0824-4fc5-83d8-21f9908dbb43@github.com>
On Wed, 9 Oct 2024 20:59:49 GMT, William Kemper <wkemper at openjdk.org> wrote:
> Avoid divide by zero error when there is no memory available.
Marked as reviewed by mli (Reviewer).
-------------
PR Review: https://git.openjdk.org/jdk/pull/21432#pullrequestreview-2359414240
From tschatzl at openjdk.org Thu Oct 10 10:02:22 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 10 Oct 2024 10:02:22 GMT
Subject: RFR: 8337269: G1ConfidencePercent interpreted inconsistently
Message-ID: <gzTcofH9ul6O6ZIol3nGtVbbZOY7uzu5doUU5jMBsAY=.3652c863-dae5-4728-846f-bffe563643bb@github.com>
Hi all,
please review this change that removes the inconsistency in interpretation of G1ConfidencePercent; higher confidence means that G1 should use less safety margin (i.e. part of the variance).
Other than that it does not change the uses for it.
Testing: gha
Thanks,
Thomas
-------------
Commit messages:
- 8337269
Changes: https://git.openjdk.org/jdk/pull/21448/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21448&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8337269
Stats: 3 lines in 2 files changed: 1 ins; 0 del; 2 mod
Patch: https://git.openjdk.org/jdk/pull/21448.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/21448/head:pull/21448
PR: https://git.openjdk.org/jdk/pull/21448
From rcastanedalo at openjdk.org Thu Oct 10 10:03:33 2024
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Thu, 10 Oct 2024 10:03:33 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v39]
In-Reply-To: <q4sTPbMm-cK1O35GhIbRytiakYgyKJYrBhotG_Kwn2o=.02620a61-e96d-4c93-af80-d27a61dd9ee7@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<q4sTPbMm-cK1O35GhIbRytiakYgyKJYrBhotG_Kwn2o=.02620a61-e96d-4c93-af80-d27a61dd9ee7@github.com>
Message-ID: <ARBYJMJ_9fg6m5fGG6XyheX64J-YKzfyyBIhcX8Zzqs=.f7a44bfa-ca40-4ee7-b49c-4ba3161b0c0c@github.com>
On Tue, 8 Oct 2024 16:30:47 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>>
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>>
>> Main changes:
>> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>> - Arrays will now store their length at offset 8.
>> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>
> Increase compiler code stubs size for indexOf intrinsic
Thanks @rkennke and @tstuefe for patiently addressing my comments. I have reviewed the HotSpot compiler parts of this changeset, except those in `src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp` which should be reviewed by someone more familiar with the `indexOf` intrinsic implementation (@sviswa7 has suggested @vpaprotsk for this task). More specifically, my approval covers the following files/directories:
src/hotspot/cpu/aarch64 (excluding interpreter-only changes)
src/hotspot/cpu/x86 (excluding interpreter-only and c2_stubGenerator_x86_64_string.cpp changes)
src/hotspot/share/opto
src/hotspot/share/ci
src/hotspot/share/gc/{shared,x,z}/c2/{x,z}barrierSetC2.cpp
test/hotspot/jtreg/compiler
As I mentioned earlier, after the integration of this changeset and before compact headers can be considered non-experimental, I think C2's dependency on `klass_offset_in_bytes()` (when using compact headers) should be removed, and a more robust C2 model for klass pointer loading should be developed ([JDK-8340453](https://bugs.openjdk.org/browse/JDK-8340453)).
-------------
Marked as reviewed by rcastanedalo (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/20677#pullrequestreview-2359713290
From iwalulya at openjdk.org Thu Oct 10 12:32:10 2024
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Thu, 10 Oct 2024 12:32:10 GMT
Subject: RFR: 8337269: G1ConfidencePercent interpreted inconsistently
In-Reply-To: <gzTcofH9ul6O6ZIol3nGtVbbZOY7uzu5doUU5jMBsAY=.3652c863-dae5-4728-846f-bffe563643bb@github.com>
References: <gzTcofH9ul6O6ZIol3nGtVbbZOY7uzu5doUU5jMBsAY=.3652c863-dae5-4728-846f-bffe563643bb@github.com>
Message-ID: <GlWz9rkGjoS2etN5I2ONq5iDL2kl2YSMsl660MVsNAI=.4a8cab91-ef8f-4e61-9a67-41f3e5b7e3be@github.com>
On Thu, 10 Oct 2024 09:56:58 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:
> Hi all,
>
> please review this change that removes the inconsistency in interpretation of G1ConfidencePercent; higher confidence means that G1 should use less safety margin (i.e. part of the variance).
>
> Other than that it does not change the uses for it.
>
> Testing: gha
>
> Thanks,
> Thomas
Marked as reviewed by iwalulya (Reviewer).
-------------
PR Review: https://git.openjdk.org/jdk/pull/21448#pullrequestreview-2360161667
From kbarrett at openjdk.org Thu Oct 10 14:51:10 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 10 Oct 2024 14:51:10 GMT
Subject: RFR: 8337269: G1ConfidencePercent interpreted inconsistently
In-Reply-To: <gzTcofH9ul6O6ZIol3nGtVbbZOY7uzu5doUU5jMBsAY=.3652c863-dae5-4728-846f-bffe563643bb@github.com>
References: <gzTcofH9ul6O6ZIol3nGtVbbZOY7uzu5doUU5jMBsAY=.3652c863-dae5-4728-846f-bffe563643bb@github.com>
Message-ID: <Z_6x2ctQmW5HcOeAb-XYVNTh4sEuCJql_E9cttUybNY=.ee54b79d-c35c-4af2-aa06-20d88f20b582@github.com>
On Thu, 10 Oct 2024 09:56:58 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:
> Hi all,
>
> please review this change that removes the inconsistency in interpretation of G1ConfidencePercent; higher confidence means that G1 should use less safety margin (i.e. part of the variance).
>
> Other than that it does not change the uses for it.
>
> Testing: gha
>
> Thanks,
> Thomas
Looks good.
-------------
Marked as reviewed by kbarrett (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/21448#pullrequestreview-2360625323
From tschatzl at openjdk.org Thu Oct 10 15:18:20 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 10 Oct 2024 15:18:20 GMT
Subject: RFR: 8341909: G1: Add region index to region printer output
Message-ID: <uGKch90jzIdAWjn9jO5d1DvCSn6T1R2xMeFxOmu8hfY=.6a9c8a5d-1371-497a-b2df-9e194632aac4@github.com>
Hi all,
please review this small improvement to the G1HeapRegionPrinter output to add the region index - this makes cross-referencing with other log messages much easier.
Testing: gha
Thanks,
Thomas
-------------
Commit messages:
- 8341909
Changes: https://git.openjdk.org/jdk/pull/21454/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21454&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8341909
Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
Patch: https://git.openjdk.org/jdk/pull/21454.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/21454/head:pull/21454
PR: https://git.openjdk.org/jdk/pull/21454
From wkemper at openjdk.org Thu Oct 10 18:48:15 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 10 Oct 2024 18:48:15 GMT
Subject: Integrated: 8339651: ShenandoahPacer::setup_for_mark,
ShenandoahPacer::setup_for_updaterefs and ShenandoahPacer::setup_for_evac
runtime error: division by zero
In-Reply-To: <V4_JujuCficbks9qbfsAf4yvkFEXi5clAPa6IR2H01E=.77e12334-3365-4eb7-9d8a-300985822196@github.com>
References: <V4_JujuCficbks9qbfsAf4yvkFEXi5clAPa6IR2H01E=.77e12334-3365-4eb7-9d8a-300985822196@github.com>
Message-ID: <72I2dMGwfRo-b9KcfYis69RhEZA5hXVVGqxwRw2LI-A=.2cbb9737-8342-4593-9241-3a45bd533134@github.com>
On Wed, 9 Oct 2024 20:59:49 GMT, William Kemper <wkemper at openjdk.org> wrote:
> Avoid divide by zero error when there is no memory available.
This pull request has now been integrated.
Changeset: 06f34d7e
Author: William Kemper <wkemper at openjdk.org>
URL: https://git.openjdk.org/jdk/commit/06f34d7ed2ac77e30b2a891b7a0549055ed40da3
Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
8339651: ShenandoahPacer::setup_for_mark, ShenandoahPacer::setup_for_updaterefs and ShenandoahPacer::setup_for_evac runtime error: division by zero
Reviewed-by: shade, mli
-------------
PR: https://git.openjdk.org/jdk/pull/21432
From kbarrett at openjdk.org Thu Oct 10 21:34:10 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 10 Oct 2024 21:34:10 GMT
Subject: RFR: 8341909: G1: Add region index to region printer output
In-Reply-To: <uGKch90jzIdAWjn9jO5d1DvCSn6T1R2xMeFxOmu8hfY=.6a9c8a5d-1371-497a-b2df-9e194632aac4@github.com>
References: <uGKch90jzIdAWjn9jO5d1DvCSn6T1R2xMeFxOmu8hfY=.6a9c8a5d-1371-497a-b2df-9e194632aac4@github.com>
Message-ID: <GuOVyquaoW6PiIV2YApenyExYNQ3Gbv0C99ZQ1fQxAg=.df237095-0cab-4a6d-adac-7b33ad9bf169@github.com>
On Thu, 10 Oct 2024 15:13:48 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:
> Hi all,
>
> please review this small improvement to the G1HeapRegionPrinter output to add the region index - this makes cross-referencing with other log messages much easier.
>
> Testing: gha
>
> Thanks,
> Thomas
Looks good.
-------------
Marked as reviewed by kbarrett (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/21454#pullrequestreview-2361457504
From kbarrett at openjdk.org Fri Oct 11 00:43:09 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 11 Oct 2024 00:43:09 GMT
Subject: RFR: 8337269: G1ConfidencePercent interpreted inconsistently
In-Reply-To: <gzTcofH9ul6O6ZIol3nGtVbbZOY7uzu5doUU5jMBsAY=.3652c863-dae5-4728-846f-bffe563643bb@github.com>
References: <gzTcofH9ul6O6ZIol3nGtVbbZOY7uzu5doUU5jMBsAY=.3652c863-dae5-4728-846f-bffe563643bb@github.com>
Message-ID: <5V40DXAv0Oof1aL9Nar13Tq_khYq-ZaDIa-vKc1A6lA=.9af34ab6-0f8c-4c4c-94fc-b61dfead5f10@github.com>
On Thu, 10 Oct 2024 09:56:58 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:
> Hi all,
>
> please review this change that removes the inconsistency in interpretation of G1ConfidencePercent; higher confidence means that G1 should use less safety margin (i.e. part of the variance).
>
> Other than that it does not change the uses for it.
>
> Testing: gha
>
> Thanks,
> Thomas
Retracting my prior approval.
I think the proposed change does address the described inconsistency. But I
think it doesn't go far enough.
The G1Predictions constructor takes a "sigma" argument. It range checks it,
and the failure message describes it as "confidence". The accessor for that
value is described as "Confidence factor". That seems inconsistent with the
usage (a small value suggests higher confidence in the average value), and
with the new calculation of the argument.
-------------
Changes requested by kbarrett (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/21448#pullrequestreview-2361702801
From jonathanjoo at google.com Fri Oct 11 07:16:43 2024
From: jonathanjoo at google.com (Jonathan Joo)
Date: Fri, 11 Oct 2024 00:16:43 -0700
Subject: Further discussion on Adaptable Heap Sizing with G1
In-Reply-To: <93ecaaaa-600e-4b91-a98b-f417f5505037@oracle.com>
References: <CACz-JM5_UjhLj2Yng83y9G5VUkfPT2kiLDSdUe+2u9J=dG5UvQ@mail.gmail.com>
<93ecaaaa-600e-4b91-a98b-f417f5505037@oracle.com>
Message-ID: <CACz-JM4bgOfVA=6CbrNSK6bJFBnT8F5QecHUp8VbJTvHy=72vA@mail.gmail.com>
Hi Thomas,
I think what this suggestion overlooks is that a SoftMaxHeapSize that
> guides used heap size will automatically guide committed size: i.e. if
> G1 shrinks the used heap, G1 will automatically shrink (and keep) the
> committed size.
>
> So ProposedHeapSize seems to be very similar to SoftMaxHeapSize.
>
If I'm understanding this correctly - both ProposedHeapSize and (the
proposed version of) SoftMaxHeapSize have similar semantics, but actually
modify the heap in different ways. SoftMaxHeapSize helps us determine when
to start a concurrent mark, whereas ProposedHeapSize doesn't actually
trigger any GC directly, but affects the size of the heap after a GC. Is
that correct? Would it make sense then to have both flags, where one helps
set a trigger point for a GC, and one helps us determine the heap size we
are targeting after the GC? I might also be missing some nuances here.
I.e. if I understand this correctly: allowing a higher GC overhead,
> automatically shrinks the heap.
Exactly - in practice, tuning this one parameter up (the target gc cpu
overhead) correlates with decreasing both the average as well as maximum
heap usage for a java program.
I noticed the same with the patch attached to the SoftMaxHeapSize CR
> (https://bugs.openjdk.org/browse/JDK-8236073) discounting effects of
> Min/MaxHeapFreeRatio (i.e. if you remove it,
> https://bugs.openjdk.org/browse/JDK-8238686 explains the issue).
> In practice, these two flags prohibit G1 from adjusting the heap unless
> the SoftMaxHeapSize change is very large.
> So I would prefer to only think of an alternative to SoftMaxHeapSize if
> it has been shown that it does not work.
Given that you have a much stronger mental model than I do of how all these
flags fit together in the context of G1 GC, perhaps it would be helpful to
schedule some time to chat in person! I think that would help clarify
things much more quickly than email. To be clear - I have no reason to
doubt that SoftMaxHeapSize does not work. On the other hand, could we
possibly make use of both flags? For example, could SoftMaxHeapSize
potentially be a good replacement for our periodic GC?
There is the nit that unlike in this implementation of ProposedHeapSize,
> SoftMaxHeapSize will not cause uncommit below MinHeapSize. This is
> another discussion on what to do about this issue - in a comment in
> https://bugs.openjdk.org/browse/JDK-8236073 it is proposed to make
> MinHeapSize manageable.
How useful is MinHeapSize in practice? Do we need it, or can we just set it
to zero to avoid having to deal with it at all?
I (still) believe that AHS and SoftMaxHeapSize/ProposedHeapSize are
> somewhat orthogonal.
AHS (https://openjdk.org/jeps/8329758) is about finding a reasonable
> heap size, and adjust on external "pressure". SoftMax/ProposedHeapSize
> are manual external tunings.
> Wdyt?
I agree with the general idea - for us, we used a manual external flag like
ProposedHeapSize because we did not implement any of the AHS logic in the
JVM. (We had a separate AHS thread reading in container information and
then doing the calculations, then setting ProposedHeapSize as a manageable
flag.) The way I see it is that SoftMax/ProposedHeapSize is the "output" of
AHS, and then SoftMax/ProposedHeapSize is the "input" for the JVM, after
which the JVM uses this input to adjust its behavior accordingly. Does that
align with how you see things?
If we do indeed implement AHS logic fully within the JVM, then we could
internally manage the sizing of the heap without exposing a manageable
flag. That being said, it seems to me that exposing this as a manageable
flag brings the additional benefit that one could plug in their own AHS
implementation that calculates target heap sizes with whatever data they
want (and then passes it into the JVM via the manageable flag).
Again, I wonder if meeting to discuss would be efficient, and then we can
update the mailing list with the results of our discussion. Let me know
your thoughts!
Best,
~ Jonathan
On Tue, Oct 8, 2024 at 8:35?AM Thomas Schatzl <thomas.schatzl at oracle.com>
wrote:
> Hi Jonathan,
>
> On 05.10.24 00:39, Jonathan Joo wrote:
> > Hi All,
> >
> > As Kirk mentioned in his email "Aligning the Serial collector with ZGC
> > <
> https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-September/049616.html>",
> we are also working on adding Adaptable Heap Sizing (AHS) to G1.
> >
> > I created a draft Pull Request
> > <https://github.com/openjdk/jdk/pull/20783> and received some comments
> > on it already, including the following points:
> >
> > 1. I should Convert CurrentMaxExpansionSize to CurrentMaxHeapSize.
> >
> > 2. SoftMaxHeapSize, as implemented in the PR, is different from the
> > original intent.
> >
> > 3. We need some sort of global memory pressure to enforce heap
> shrinkage.
> >
> >
> > The first point I already addressed on the pull request, and I agree
> > that CurrentMaxHeapSize works well :)
> >
> > Regarding the second point, we had some discussions already outside of
> > this mailing list, but if I were to summarize the main ideas, they are:
> >
> > 1. The intent of SoftMaxHeapSize initially was for the GC to use this
> > value as a guide for when to start concurrent GC.
> >
> > 2. Our implementation of SoftMaxHeapSize (in the PR) currently behaves
> > more like a ProposedHeapSize, where whenever we shrink and expand
> > the heap, we try to set the heap size to ProposedHeapSize,
> > regardless of the value of MinHeapSize.
> >
> > 3. We need to ensure that the heap regularly approaches the value of
> > ProposedHeapSize by introducing some sort of periodic GC, which we
> > have a Google-internal patch for, and is not yet present in the PR.
> > If we are in alignment that this makes sense, I can try adding this
> > as a separate PR.
>
> I think what this suggestion overlooks is that a SoftMaxHeapSize that
> guides used heap size will automatically guide committed size: i.e. if
> G1 shrinks the used heap, G1 will automatically shrink (and keep) the
> committed size.
>
> So ProposedHeapSize seems to be very similar to SoftMaxHeapSize.
>
>
> > As a separate point - Kirk mentioned in his email that he aims to
> > introduce an adaptive size policy where "Heap should be large enough to
> > minimize GC overhead but not large enough to trigger OOM". I think from
> > our experience in G1, we don't actively try to minimize GC overhead, as
> > we find that maintaining a higher GC overhead often results in overall
> > RAM savings >> CPU usage.
> >
>
> I.e. if I understand this correctly: allowing a higher GC overhead,
> automatically shrinks the heap.
>
> > I think as a general summary - the way I see it, there's value in
> > creating a simplified system where we control the majority of JVM
> > behavior simply with two flags - the maximum heap size (to prevent
> > OOMs), and a target heap size, which is our calculation of an "optimal"
> > size based on our understanding of the environment. The exact
> > calculations for this optimal size may change depending on
> > workload/preference, but what we are trying to do at this point in time
> > is allow for a way to pass in some calculation for "optimal heap size"
> > and have G1 react to it in a meaningful way. I acknowledge that the
> > current JVM behavior (as implemented in my PR) may be suboptimal in
> > terms of getting the heap to get to and stay at this "optimal heap
> > size". However, even with the basic implementation of passing this value
> > to shrinks/expands and only triggering resizes on Remarks/Full GCs,
> > we've seen dramatic improvements in heap behavior at Google, compared to
> > the current G1.
>
> I noticed the same with the patch attached to the SoftMaxHeapSize CR
> (https://bugs.openjdk.org/browse/JDK-8236073) discounting effects of
> Min/MaxHeapFreeRatio (i.e. if you remove it,
> https://bugs.openjdk.org/browse/JDK-8238686 explains the issue).
> In practice, these two flags prohibit G1 from adjusting the heap unless
> the SoftMaxHeapSize change is very large.
>
> So I would prefer to only think of an alternative to SoftMaxHeapSize if
> it has been shown that it does not work.
>
> There is the nit that unlike in this implementation of ProposedHeapSize,
> SoftMaxHeapSize will not cauase uncommit below MinHeapSize. This is
> another discussion on what to do about this issue - in a comment in
> https://bugs.openjdk.org/browse/JDK-8236073 it is proposed to make
> MinHeapSize manageable.
> > I know there was some disagreement about the addition of this new
> > "optimal heap size" flag, and I agree that SoftMaxHeapSize is probably
> > not the right flag to represent this value. But I'd like to get some
> > thoughts on whether the above summary seems like a reasonable way of
> > reasoning about G1 AHS. If we agree, then we can always iteratively
> > improve the JVM logic to better adhere to the optimal heap size. But
> > it's not yet clear to me whether people are onboard the idea of having
> > this "optimal heap size" calculation at all, since perhaps this
> > functionality could be covered in other, existing ways.
>
> I (still) believe that AHS and SoftMaxHeapSize/ProposedHeapSize are
> somewhat orthogonal.
>
> AHS (https://openjdk.org/jeps/8329758) is about finding a reasonable
> heap size, and adjust on external "pressure". SoftMax/ProposedHeapSize
> are manual external tunings.
>
> Wdyt?
>
> Thomas
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20241011/b12c7b59/attachment.htm>
From lkorinth at openjdk.org Fri Oct 11 08:32:09 2024
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 11 Oct 2024 08:32:09 GMT
Subject: RFR: 8341909: G1: Add region index to region printer output
In-Reply-To: <uGKch90jzIdAWjn9jO5d1DvCSn6T1R2xMeFxOmu8hfY=.6a9c8a5d-1371-497a-b2df-9e194632aac4@github.com>
References: <uGKch90jzIdAWjn9jO5d1DvCSn6T1R2xMeFxOmu8hfY=.6a9c8a5d-1371-497a-b2df-9e194632aac4@github.com>
Message-ID: <DKCdeZHZvN2NMV1E7gvjoItTcZaZ2QfMXWAU2lWARUQ=.a4ebc0b3-fef9-4fa8-b062-f690ef8a9e92@github.com>
On Thu, 10 Oct 2024 15:13:48 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:
> Hi all,
>
> please review this small improvement to the G1HeapRegionPrinter output to add the region index - this makes cross-referencing with other log messages much easier.
>
> Testing: gha
>
> Thanks,
> Thomas
Looks good to me, if you change %4u to %5u that is okay with me as well even if it is more uncommon with that many regions.
-------------
Marked as reviewed by lkorinth (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/21454#pullrequestreview-2362256097
From tschatzl at openjdk.org Fri Oct 11 09:15:15 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 11 Oct 2024 09:15:15 GMT
Subject: RFR: 8341909: G1: Add region index to region printer output
In-Reply-To: <GuOVyquaoW6PiIV2YApenyExYNQ3Gbv0C99ZQ1fQxAg=.df237095-0cab-4a6d-adac-7b33ad9bf169@github.com>
References: <uGKch90jzIdAWjn9jO5d1DvCSn6T1R2xMeFxOmu8hfY=.6a9c8a5d-1371-497a-b2df-9e194632aac4@github.com>
<GuOVyquaoW6PiIV2YApenyExYNQ3Gbv0C99ZQ1fQxAg=.df237095-0cab-4a6d-adac-7b33ad9bf169@github.com>
Message-ID: <FjGsu-TAvQoeEqa6JtKUG36rI1vFSuize34bdnNvfKs=.d17660a1-b277-4a42-83a0-d380714bd59d@github.com>
On Thu, 10 Oct 2024 21:31:39 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:
>> Hi all,
>>
>> please review this small improvement to the G1HeapRegionPrinter output to add the region index - this makes cross-referencing with other log messages much easier.
>>
>> Testing: gha
>>
>> Thanks,
>> Thomas
>
> Looks good.
Thanks @kimbarrett @lkorinth for your reviews.
I will keep the 4 digits, it would cover ~300GB heaps at 32M per region (even more with larger regions). This is probably much larger than anyone would use this debug message with.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/21454#issuecomment-2406982113
From tschatzl at openjdk.org Fri Oct 11 09:15:15 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 11 Oct 2024 09:15:15 GMT
Subject: Integrated: 8341909: G1: Add region index to region printer output
In-Reply-To: <uGKch90jzIdAWjn9jO5d1DvCSn6T1R2xMeFxOmu8hfY=.6a9c8a5d-1371-497a-b2df-9e194632aac4@github.com>
References: <uGKch90jzIdAWjn9jO5d1DvCSn6T1R2xMeFxOmu8hfY=.6a9c8a5d-1371-497a-b2df-9e194632aac4@github.com>
Message-ID: <hblQPpJZNNBaZ7q2BzrFD8kAtBXiOC6Rum5v8rsyz50=.70dff1c7-aff6-402a-b690-3afc5a7a5aa4@github.com>
On Thu, 10 Oct 2024 15:13:48 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:
> Hi all,
>
> please review this small improvement to the G1HeapRegionPrinter output to add the region index - this makes cross-referencing with other log messages much easier.
>
> Testing: gha
>
> Thanks,
> Thomas
This pull request has now been integrated.
Changeset: 519544c1
Author: Thomas Schatzl <tschatzl at openjdk.org>
URL: https://git.openjdk.org/jdk/commit/519544c1d72bccb4528953adb054ea3ee97e35b9
Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
8341909: G1: Add region index to region printer output
Reviewed-by: kbarrett, lkorinth
-------------
PR: https://git.openjdk.org/jdk/pull/21454
From tschatzl at openjdk.org Fri Oct 11 13:18:45 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 11 Oct 2024 13:18:45 GMT
Subject: RFR: 8337269: G1ConfidencePercent interpreted inconsistently [v2]
In-Reply-To: <5V40DXAv0Oof1aL9Nar13Tq_khYq-ZaDIa-vKc1A6lA=.9af34ab6-0f8c-4c4c-94fc-b61dfead5f10@github.com>
References: <gzTcofH9ul6O6ZIol3nGtVbbZOY7uzu5doUU5jMBsAY=.3652c863-dae5-4728-846f-bffe563643bb@github.com>
<5V40DXAv0Oof1aL9Nar13Tq_khYq-ZaDIa-vKc1A6lA=.9af34ab6-0f8c-4c4c-94fc-b61dfead5f10@github.com>
Message-ID: <LLY3uxRqjrbnmnshcS4WqWmxAx9A1HX-jECpOPrwlOw=.960cb27b-9c62-47b6-801e-22932f18e6d3@github.com>
On Fri, 11 Oct 2024 00:40:25 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:
> Retracting my prior approval.
>
> I think the proposed change does address the described inconsistency. But I think it doesn't go far enough.
>
> The G1Predictions constructor takes a "sigma" argument. It range checks it, and the failure message describes it as "confidence". The accessor for that value is described as "Confidence factor". That seems inconsistent with the usage (a small value suggests higher confidence in the average value), and with the new calculation of the argument.
I renamed the member as it had a wrong name anyway; sigma is the actual value of the stddev, not some factor. I hope this is good enough to address your concerns.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/21448#issuecomment-2407394676
From tschatzl at openjdk.org Fri Oct 11 13:18:45 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 11 Oct 2024 13:18:45 GMT
Subject: RFR: 8337269: G1ConfidencePercent interpreted inconsistently [v2]
In-Reply-To: <gzTcofH9ul6O6ZIol3nGtVbbZOY7uzu5doUU5jMBsAY=.3652c863-dae5-4728-846f-bffe563643bb@github.com>
References: <gzTcofH9ul6O6ZIol3nGtVbbZOY7uzu5doUU5jMBsAY=.3652c863-dae5-4728-846f-bffe563643bb@github.com>
Message-ID: <tflqAQwALVkveGLOzeSchl5nIOHJ5ZfNkbRH0CPDoZw=.85f0b964-8949-4765-9b14-5214ec669741@github.com>
> Hi all,
>
> please review this change that removes the inconsistency in interpretation of G1ConfidencePercent; higher confidence means that G1 should use less safety margin (i.e. part of the variance).
>
> Other than that it does not change the uses for it.
>
> Testing: gha
>
> Thanks,
> Thomas
Thomas Schatzl has updated the pull request incrementally with two additional commits since the last revision:
- * whitespace fix
- * kbarrett review
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/21448/files
- new: https://git.openjdk.org/jdk/pull/21448/files/9ffbbdc9..8ffd34c6
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=21448&range=01
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=21448&range=00-01
Stats: 12 lines in 1 file changed: 3 ins; 4 del; 5 mod
Patch: https://git.openjdk.org/jdk/pull/21448.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/21448/head:pull/21448
PR: https://git.openjdk.org/jdk/pull/21448
From thomas.schatzl at oracle.com Mon Oct 14 09:52:42 2024
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Mon, 14 Oct 2024 11:52:42 +0200
Subject: Further discussion on Adaptable Heap Sizing with G1
In-Reply-To: <CACz-JM4bgOfVA=6CbrNSK6bJFBnT8F5QecHUp8VbJTvHy=72vA@mail.gmail.com>
References: <CACz-JM5_UjhLj2Yng83y9G5VUkfPT2kiLDSdUe+2u9J=dG5UvQ@mail.gmail.com>
<93ecaaaa-600e-4b91-a98b-f417f5505037@oracle.com>
<CACz-JM4bgOfVA=6CbrNSK6bJFBnT8F5QecHUp8VbJTvHy=72vA@mail.gmail.com>
Message-ID: <7d07385e-bc04-4251-a5db-81ede0b90465@oracle.com>
Hi,
On 11.10.24 09:16, Jonathan Joo wrote:
> Hi Thomas,
>
> I think what this suggestion overlooks is that a SoftMaxHeapSize that
> guides used heap size will automatically guide committed size: i.e. if
> G1 shrinks the used heap, G1 will automatically shrink (and keep) the
> committed size.
>
> So ProposedHeapSize seems to be very similar to SoftMaxHeapSize.
>
>
> If I'm understanding this correctly - both ProposedHeapSize and (the
> proposed version of) SoftMaxHeapSize have similar semantics, but
> actually modify the heap in different ways. SoftMaxHeapSize helps us
> determine when to start a concurrent mark, whereas ProposedHeapSize
> doesn't actually trigger any GC directly, but affects the size of the
> heap after a GC. Is that correct? Would it make sense then to have both
> flags, where one helps set a trigger point for a GC, and one helps us
> determine the heap size we are targeting after the GC? I might also be
> missing some nuances here.
I think SoftMaxHeapSize (or actually either) will result in
approximately the same behavior. The difference is in intrusiveness.
ProposedHeapSize forcefully attempts to decrease the committed heap size
and then the rest of the "heap sizing machinery" follows, while
SoftMaxHeapSize gives a target for the "heap sizing machinery" and
committed heap size follows.
ProposedHeapSize has the following disadvantages (as implemented):
- since it forces committed heap size, I expect that in case you are
close or above that target, you can get frequent uncommits/attempts to
uncommit which waste cpu cycles.
Hopefully, by giving the heap sizing machinery a goal, it will itself
determine a sustainable committed memory level without too frequent
commits and uncommits.
- for some reason it does not allow less memory to be committed than
proposed (but still larger than MinHeapSize). This can be inefficient
wrt to memory usage.
I.e. it basically disables other heap sizing afaict.
- (that's more a nit) the use of "0" as special marker for
SoftMaxHeapSize is unexpected.
This mechanism kind of feels like a very blunt tool to get the desired
effect (a certain committed heap) without caring about other goals. It
may be necessary to pull out the immediately un/commit hammer in some
situations, and imho, let's not give that hammer to users as the first
option to screw themselves.
>
> ?I.e. if I understand this correctly: allowing a higher GC overhead,
> automatically shrinks the heap.
>
>
> Exactly - in practice, tuning this one parameter up (the target gc cpu
> overhead) correlates with decreasing both the average as well as maximum
> heap usage for a java program.
>
> ?I noticed the same with the patch attached to the SoftMaxHeapSize CR
> (https://bugs.openjdk.org/browse/JDK-8236073
> <https://bugs.openjdk.org/browse/JDK-8236073>) discounting effects of
> Min/MaxHeapFreeRatio (i.e. if you remove it,
> https://bugs.openjdk.org/browse/JDK-8238686
> <https://bugs.openjdk.org/browse/JDK-8238686>?explains the issue).
> In practice, these two flags prohibit G1 from adjusting the heap unless
> the SoftMaxHeapSize change is very large.
>
>
> So I would prefer to only think of an alternative to SoftMaxHeapSize if
> it has been shown that it does not work.
>
>
> Given that you have a much stronger mental model than I do of how all
> these flags fit together in the context of G1 GC, perhaps it would be
> helpful to schedule some time to chat in person! I think that would help
> clarify things much more quickly than email. To be clear - I have no
> reason to doubt that SoftMaxHeapSize does not work. On the other hand,
> could we possibly make use of both flags? For example, could
> SoftMaxHeapSize potentially be a good replacement for our periodic GC?
Not sure what periodic GC has to do with SoftMaxHeapSize.
>
> There is the nit that unlike in this implementation of ProposedHeapSize,
> SoftMaxHeapSize will not cause uncommit below MinHeapSize. This is
> another discussion on what to do about this issue - in a comment in
> https://bugs.openjdk.org/browse/JDK-8236073
> <https://bugs.openjdk.org/browse/JDK-8236073>?it is proposed to make
> MinHeapSize manageable.
>
>
> How useful is MinHeapSize in practice? Do we need it, or can we just set
> it to zero to avoid having to deal with it at all?
I think you are mixing AHS (give decent heap sizing in presence of
external memory pressure) and getting "optimal" heap sizing (or iow
"steering heap size" externally).
AHS is mostly about the user not doing/setting any heap sizes; in this
case just having min heap size very low is just fine just as suggested
in the JEP.
SoftMaxHeapSize (and ProposedHeapSize) is about the user setting a
particular goal according to his whims. It is still interesting to set
-Xms==-Xmx for e.g. fast startup or during heavy activity; however if an
external system decides that it is useful to intermittently save memory
up to a certain level, then follow that guidance.
The mechanism to internally follow that guidance can be used by AHS.
>
> I (still) believe that AHS and SoftMaxHeapSize/ProposedHeapSize are
> somewhat orthogonal.
>
> AHS (https://openjdk.org/jeps/8329758
> <https://openjdk.org/jeps/8329758>) is about finding a reasonable
> heap size, and adjust on external "pressure". SoftMax/ProposedHeapSize
> are manual external tunings.
>
>
> Wdyt?
>
>
> I agree with the general idea - for us, we used a manual external flag
> like ProposedHeapSize because we did not implement any of the AHS logic
> in the JVM. (We had a separate AHS thread reading in container
> information and then doing the calculations, then setting
> ProposedHeapSize as a manageable flag.) The way I see it is that
> SoftMax/ProposedHeapSize is the "output" of AHS, and then
> SoftMax/ProposedHeapSize is the "input" for the JVM,?after which the JVM
> uses this input to adjust its behavior accordingly. Does that align with
> how you see things?
As mentioned in the other thread, SoftMaxHeapSize can be used by AHS to
get heap to a certain level (based on memory pressure), but there is
also that external entity that can modify SoftMaxHeapSize to adjust VM
behavior.
So ultimately there will be multiple inputs for target heap size (and
probably I'm forgetting one or the other):
* External memory pressure (AHS) (*)
* CurrentMaxHeapSize
* SoftMaxHeapSize
* CPU usage (existing GCTimeRatio based policy)
* other *HeapSize flags
that need to be merged into some target heap level using some policy.
After knowing that level, the VM needs to decide on a proper reaction,
which might be anything from just setting internal IHOP goal, to
(un-)committing memory directly, to doing the appropriate garbage
collection in a "timely" fashion (which is where the regular periodic
gc/marking comes in) or anything inbetween.
(*) I am aware that the AHS JEP not only includes reaction on external
memory pressure but also the merging of goals for different sources;
some of them are ZGC specific. Some of them are already implemented in
G1. So for this discussion it is imo useful to limit "AHS" in G1 context
to things that G1 does not do. Ie. "return another goal based on
external memory pressure", "min/max heap size defaults(!)", and "adjust
adaptive sizing".
> If we do indeed implement AHS logic fully within the JVM, then we could
> internally manage the sizing of the heap without exposing a manageable
> flag. That being said, it seems to me that exposing this as a manageable
> flag brings the additional benefit that one could plug in their own AHS
> implementation that calculates target heap sizes with whatever data they
> want (and then passes it into the JVM via the manageable flag).
>
> Again, I wonder if meeting to discuss would be efficient, and then we
> can update the mailing list with the results of our discussion. Let me
> know your thoughts!
It's fine with me to meet to recap and discuss above; please suggest
some time.
Hth,
Thomas
From mbaesken at openjdk.org Mon Oct 14 11:45:44 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 14 Oct 2024 11:45:44 GMT
Subject: RFR: 8342044: Increase timeout of
gc/shenandoah/oom/TestClassLoaderLeak.java
Message-ID: <vacjtHaJHS4QuyVB26411a-8BYXpiRfmC_xjpZJfz7I=.567b306b-1376-4a18-903d-5581f1a2212f@github.com>
Test gc/shenandoah/oom/TestClassLoaderLeak.java often times out on WIndows, we should increase the timeout values to avoid test errors.
-------------
Commit messages:
- JDK-8342044
Changes: https://git.openjdk.org/jdk/pull/21491/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21491&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8342044
Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
Patch: https://git.openjdk.org/jdk/pull/21491.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/21491/head:pull/21491
PR: https://git.openjdk.org/jdk/pull/21491
From mdoerr at openjdk.org Mon Oct 14 17:40:38 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 14 Oct 2024 17:40:38 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v11]
In-Reply-To: <toUdNzwkdDAQDltc4_t6wI06bCE-EHzpIs_t-arIwNY=.7d9ef348-0033-4268-9ed1-7c183855521f@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<DUgk6HT_Zk5KnbmAd_HzrJi4B8D1J-uuoAGzReWyI8s=.6c04f90a-bf1d-49af-a31d-5224973952d4@github.com>
<YTte6oY9EeAPHxzzOndL8M202wY91SbeaYC4hPva0W0=.caf00270-89c7-44b0-ab88-a970fb8e840d@github.com>
<kzodWwxj5qdAqPYcP2s4k2QTXqjju2H6Iftu7dojezk=.1f72fc31-94ba-4017-b330-c8688a8d39a4@github.com>
<hkGaBWSugvpV0PgoR9rnutHCgQzkeXv1ctH7QwV3zK0=.204737d5-fadb-410a-8891-7db59d36830f@github.com>
<shoDPnL4nQyaYX4xy-WyzQ7CwsoCbAeCE3c755CkE1o=.caf940aa-5fbb-4cb5-a4a2-68a2452ffe1b@github.com>
<TBZCkcFNNnEvat7TBnRkqUPo4Y5TEe1L0iUZ9loD7DI=.39c0249c-f6b2-45c8-b7c8-9e2c9c1b7a99@github.com>
<toUdNzwkdDAQDltc4_t6wI06bCE-EHzpIs_t-arIwNY=.7d9ef348-0033-4268-9ed1-7c183855521f@github.com>
Message-ID: <9F4j9U7srQ_aLXdOairjcjGy9Rm-gO8MXPCrqz03iec=.00254e94-dbcc-49ce-a0de-3b72cd2e2b4e@github.com>
On Tue, 1 Oct 2024 15:46:01 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
>>> Indeed, I could re-enable all tests in:
>>>
>>> ```
>>> test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationMismatchedAccess.java
>>> test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationNotRun.java
>>> test/hotspot/jtreg/compiler/loopopts/superword/TestIndependentPacksWithCyclicDependency.java
>>> ```
>>>
>>> but unfortunately not those others:
>>>
>>> ```
>>> > > > test/hotspot/jtreg/compiler/loopopts/superword/TestAlignVector.java
>>> > > > test/hotspot/jtreg/compiler/loopopts/superword/TestMulAddS2I.java
>>> ```
>>>
>>> I think the issue with all of them is that vectorization in those scenarios only works when the operations inside the loop start at an array index that addresses an element at 8-byte-aligned offset.
>>>
>>> I have filed https://bugs.openjdk.org/browse/JDK-8340010 to track it.
>>
>> @rkennke A test run of the current changeset in our internal CI system revealed that the following tests fail (because of missing vectorization) when using `-XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders -XX:UseSSE=N` with `N <= 3` on an Intel Xeon Platinum 8358 machine:
>>
>> - test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationNotRun.java
>> - test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationMismatchedAccess.java
>> - test/hotspot/jtreg/compiler/vectorization/runner/LoopCombinedOpTest.java
>>
>> Here are the failure details:
>>
>>
>> test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationNotRun.java:
>>
>> 1) Method "public static void compiler.c2.irTests.TestVectorizationNotRun.test(byte[],long[])" - [Failed IR rules: 1]:
>> * @IR rule 1: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={}, counts={"_#V#LOAD_VECTOR_L#_", ">=1", "_#STORE_VECTOR#_", ">=1"}, applyIfPlatform={}, applyIfPlatformOr={}, failOn={}, applyIfOr={}, applyIfCPUFeatureAnd={}, applyIf={}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})"
>> > Phase "PrintIdeal":
>> - counts: Graph contains wrong number of nodes:
>> * Constraint 1: "(\\d+(\\s){2}(LoadVector.*)+(\\s){2}===.*vector[A-Za-z]\[2\]:\{long\})"
>> - Failed comparison: [found] 0 >= 1 [given]
>> - No nodes matched!
>> * Constraint 2: "(\\d+(\\s){2}(StoreVector.*)+(\\s){2}===.*)"
>> - Failed comparison: [found] 0 >= 1 [given]
>> - No nodes matched!
>>
>>
>> test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationMismatchedAccess.java:
>>
>> 1) Method "public static void compiler.c2.irTests.TestVectorizati...
>
>> test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationNotRun.java:
>
> I think I would disable the tests for now. Is there a good way to say 'run this when UCOH is off OR UseSSE>3?
@rkennke: I have a PPC64 implementation: https://github.com/TheRealMDoerr/jdk/commit/6722f8be9a0940fab6417d4de58ec1538c436702
Do you want to include it? Should we also ask s390 and riscv folks?
-------------
PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2411867295
From shade at openjdk.org Mon Oct 14 18:52:39 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 14 Oct 2024 18:52:39 GMT
Subject: RFR: 8342079: Shenandoah: Eliminate extra
ShenandoahInitMarkRootsClosure
Message-ID: <wQe8tUlBQRovFLXCS3VzYbfzEd-cwePnxg8GBTP9cbw=.9a25d35b-ce88-4503-84e1-04e18503b0c8@github.com>
`ShenandoahInitMarkRootsClosure` in `ShenandoahSTWMark` is semantically similar to the shared `ShenandoahMarkRefsClosure`. It misses subclassing the metadata-visiting superclass, though, and `ShenandoahMarkRefsClosure` does it right. It is cleaner and safer to use the super-class directly, as concurrent mark does it.
Additional testing:
- [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`
-------------
Commit messages:
- Fix
Changes: https://git.openjdk.org/jdk/pull/21504/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21504&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8342079
Stats: 30 lines in 1 file changed: 1 ins; 27 del; 2 mod
Patch: https://git.openjdk.org/jdk/pull/21504.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/21504/head:pull/21504
PR: https://git.openjdk.org/jdk/pull/21504
From rkennke at openjdk.org Mon Oct 14 19:11:30 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 14 Oct 2024 19:11:30 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v11]
In-Reply-To: <toUdNzwkdDAQDltc4_t6wI06bCE-EHzpIs_t-arIwNY=.7d9ef348-0033-4268-9ed1-7c183855521f@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<DUgk6HT_Zk5KnbmAd_HzrJi4B8D1J-uuoAGzReWyI8s=.6c04f90a-bf1d-49af-a31d-5224973952d4@github.com>
<YTte6oY9EeAPHxzzOndL8M202wY91SbeaYC4hPva0W0=.caf00270-89c7-44b0-ab88-a970fb8e840d@github.com>
<kzodWwxj5qdAqPYcP2s4k2QTXqjju2H6Iftu7dojezk=.1f72fc31-94ba-4017-b330-c8688a8d39a4@github.com>
<hkGaBWSugvpV0PgoR9rnutHCgQzkeXv1ctH7QwV3zK0=.204737d5-fadb-410a-8891-7db59d36830f@github.com>
<shoDPnL4nQyaYX4xy-WyzQ7CwsoCbAeCE3c755CkE1o=.caf940aa-5fbb-4cb5-a4a2-68a2452ffe1b@github.com>
<TBZCkcFNNnEvat7TBnRkqUPo4Y5TEe1L0iUZ9loD7DI=.39c0249c-f6b2-45c8-b7c8-9e2c9c1b7a99@github.com>
<toUdNzwkdDAQDltc4_t6wI06bCE-EHzpIs_t-arIwNY=.7d9ef348-0033-4268-9ed1-7c183855521f@github.com>
Message-ID: <JCG6RiKoWCBiqIqi-DsgwqdFE1X_9KrJH1Sqnpdl-2E=.72327548-6e1c-44df-ae77-0fcdb3b92c32@github.com>
On Tue, 1 Oct 2024 15:46:01 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
>>> Indeed, I could re-enable all tests in:
>>>
>>> ```
>>> test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationMismatchedAccess.java
>>> test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationNotRun.java
>>> test/hotspot/jtreg/compiler/loopopts/superword/TestIndependentPacksWithCyclicDependency.java
>>> ```
>>>
>>> but unfortunately not those others:
>>>
>>> ```
>>> > > > test/hotspot/jtreg/compiler/loopopts/superword/TestAlignVector.java
>>> > > > test/hotspot/jtreg/compiler/loopopts/superword/TestMulAddS2I.java
>>> ```
>>>
>>> I think the issue with all of them is that vectorization in those scenarios only works when the operations inside the loop start at an array index that addresses an element at 8-byte-aligned offset.
>>>
>>> I have filed https://bugs.openjdk.org/browse/JDK-8340010 to track it.
>>
>> @rkennke A test run of the current changeset in our internal CI system revealed that the following tests fail (because of missing vectorization) when using `-XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders -XX:UseSSE=N` with `N <= 3` on an Intel Xeon Platinum 8358 machine:
>>
>> - test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationNotRun.java
>> - test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationMismatchedAccess.java
>> - test/hotspot/jtreg/compiler/vectorization/runner/LoopCombinedOpTest.java
>>
>> Here are the failure details:
>>
>>
>> test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationNotRun.java:
>>
>> 1) Method "public static void compiler.c2.irTests.TestVectorizationNotRun.test(byte[],long[])" - [Failed IR rules: 1]:
>> * @IR rule 1: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={}, counts={"_#V#LOAD_VECTOR_L#_", ">=1", "_#STORE_VECTOR#_", ">=1"}, applyIfPlatform={}, applyIfPlatformOr={}, failOn={}, applyIfOr={}, applyIfCPUFeatureAnd={}, applyIf={}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})"
>> > Phase "PrintIdeal":
>> - counts: Graph contains wrong number of nodes:
>> * Constraint 1: "(\\d+(\\s){2}(LoadVector.*)+(\\s){2}===.*vector[A-Za-z]\[2\]:\{long\})"
>> - Failed comparison: [found] 0 >= 1 [given]
>> - No nodes matched!
>> * Constraint 2: "(\\d+(\\s){2}(StoreVector.*)+(\\s){2}===.*)"
>> - Failed comparison: [found] 0 >= 1 [given]
>> - No nodes matched!
>>
>>
>> test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationMismatchedAccess.java:
>>
>> 1) Method "public static void compiler.c2.irTests.TestVectorizati...
>
>> test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationNotRun.java:
>
> I think I would disable the tests for now. Is there a good way to say 'run this when UCOH is off OR UseSSE>3?
> @rkennke: I have a PPC64 implementation: [TheRealMDoerr at 6722f8b](https://github.com/TheRealMDoerr/jdk/commit/6722f8be9a0940fab6417d4de58ec1538c436702) Do you want to include it? Should we also ask s390 and riscv folks?
AFAIK, @Hamlin-Li is working on the RISCV port. Not sure who would do s390. If it's available before intergration, I'll include it, but I'll not wait for it.
Thanks for the PPC64 port, I'll include it in this PR!
-------------
PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2412025660
From shade at openjdk.org Mon Oct 14 19:24:43 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 14 Oct 2024 19:24:43 GMT
Subject: RFR: 8342081: Shenandoah: Remove extra
ShenandoahMarkUpdateRefsSuperClosure
Message-ID: <btbf6MorZ7rEPf0UQBMVMeiUnPsUSpBapEhNHI4SldY=.452c9730-7048-43aa-9253-36797ecc6e09@github.com>
`ShenandoahMarkUpdateRefsSuperClosure` has only one real subclass, which is used in STW mark. We can collapse the class hierarchy a bit here.
Additional testing:
- [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`
-------------
Commit messages:
- Fix
Changes: https://git.openjdk.org/jdk/pull/21505/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21505&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8342081
Stats: 22 lines in 2 files changed: 2 ins; 11 del; 9 mod
Patch: https://git.openjdk.org/jdk/pull/21505.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/21505/head:pull/21505
PR: https://git.openjdk.org/jdk/pull/21505
From kbarrett at openjdk.org Mon Oct 14 20:16:44 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 14 Oct 2024 20:16:44 GMT
Subject: RFR: 8337269: G1ConfidencePercent interpreted inconsistently [v2]
In-Reply-To: <tflqAQwALVkveGLOzeSchl5nIOHJ5ZfNkbRH0CPDoZw=.85f0b964-8949-4765-9b14-5214ec669741@github.com>
References: <gzTcofH9ul6O6ZIol3nGtVbbZOY7uzu5doUU5jMBsAY=.3652c863-dae5-4728-846f-bffe563643bb@github.com>
<tflqAQwALVkveGLOzeSchl5nIOHJ5ZfNkbRH0CPDoZw=.85f0b964-8949-4765-9b14-5214ec669741@github.com>
Message-ID: <wOkbYzS1rMdzoxTX9hgImPhU_HeEgtiw3UEg2KcmaLw=.11947fd5-69be-4366-b192-566f0cad2aee@github.com>
On Fri, 11 Oct 2024 13:18:45 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:
>> Hi all,
>>
>> please review this change that removes the inconsistency in interpretation of G1ConfidencePercent; higher confidence means that G1 should use less safety margin (i.e. part of the variance).
>>
>> Other than that it does not change the uses for it.
>>
>> Testing: gha
>>
>> Thanks,
>> Thomas
>
> Thomas Schatzl has updated the pull request incrementally with two additional commits since the last revision:
>
> - * whitespace fix
> - * kbarrett review
Changes requested by kbarrett (Reviewer).
src/hotspot/share/gc/g1/g1Predictions.hpp line 53:
> 51: public:
> 52: G1Predictions(double sigma_scale) : _stddev_scale(sigma_scale) {
> 53: assert(sigma_scale >= 0.0, "must be larger than or equal to zero");
The argument uses "sigma" prefix, but everywhere else it's "stddev".
src/hotspot/share/gc/g1/g1Predictions.hpp line 53:
> 51: public:
> 52: G1Predictions(double sigma_scale) : _stddev_scale(sigma_scale) {
> 53: assert(sigma_scale >= 0.0, "must be larger than or equal to zero");
The message text doesn't provide any information beyond what what's given by the stringized predicate
code. It even makes things a bit worse, since I had to verify the two were consistent. I think just "precondition"
or "must be" or one of those common messages would actually be preferable here.
-------------
PR Review: https://git.openjdk.org/jdk/pull/21448#pullrequestreview-2367510228
PR Review Comment: https://git.openjdk.org/jdk/pull/21448#discussion_r1800014732
PR Review Comment: https://git.openjdk.org/jdk/pull/21448#discussion_r1800016820
From mdoerr at openjdk.org Mon Oct 14 21:49:28 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 14 Oct 2024 21:49:28 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v39]
In-Reply-To: <q4sTPbMm-cK1O35GhIbRytiakYgyKJYrBhotG_Kwn2o=.02620a61-e96d-4c93-af80-d27a61dd9ee7@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<q4sTPbMm-cK1O35GhIbRytiakYgyKJYrBhotG_Kwn2o=.02620a61-e96d-4c93-af80-d27a61dd9ee7@github.com>
Message-ID: <LjXNg7ygXw6KlgE0O5mMhgJ2IpNSpcZV1VKvF-p3qdQ=.608e20a4-25a8-4b9d-acaa-39eead7c4617@github.com>
On Tue, 8 Oct 2024 16:30:47 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>>
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>>
>> Main changes:
>> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>> - Arrays will now store their length at offset 8.
>> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>
> Increase compiler code stubs size for indexOf intrinsic
Thanks!
@offamitkumar: It could still be done after this PR is integrated, but I guess you want to provide an s390 implementation.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2412394373
From ysr at openjdk.org Mon Oct 14 22:55:09 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Mon, 14 Oct 2024 22:55:09 GMT
Subject: RFR: 8342081: Shenandoah: Remove extra
ShenandoahMarkUpdateRefsSuperClosure
In-Reply-To: <btbf6MorZ7rEPf0UQBMVMeiUnPsUSpBapEhNHI4SldY=.452c9730-7048-43aa-9253-36797ecc6e09@github.com>
References: <btbf6MorZ7rEPf0UQBMVMeiUnPsUSpBapEhNHI4SldY=.452c9730-7048-43aa-9253-36797ecc6e09@github.com>
Message-ID: <W_FxGYzL5R4mvNEKwRP50G1zv9erkdkdt8jtqArJ-mY=.3fb768a0-fd50-4611-95bf-cf357dfa0b45@github.com>
On Mon, 14 Oct 2024 19:20:08 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:
> `ShenandoahMarkUpdateRefsSuperClosure` has only one real subclass, which is used in STW mark. We can collapse the class hierarchy a bit here.
>
> Additional testing:
> - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`
lgtm
-------------
Marked as reviewed by ysr (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/21505#pullrequestreview-2367773398
From tschatzl at openjdk.org Tue Oct 15 06:24:47 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 15 Oct 2024 06:24:47 GMT
Subject: RFR: 8337269: G1ConfidencePercent interpreted inconsistently [v3]
In-Reply-To: <gzTcofH9ul6O6ZIol3nGtVbbZOY7uzu5doUU5jMBsAY=.3652c863-dae5-4728-846f-bffe563643bb@github.com>
References: <gzTcofH9ul6O6ZIol3nGtVbbZOY7uzu5doUU5jMBsAY=.3652c863-dae5-4728-846f-bffe563643bb@github.com>
Message-ID: <4ZRKdmYwGbFzCw2zaDrdYZSRI098hgb09_mGaIafbqY=.d63cbda5-8e8a-4086-b644-37b050f50d3a@github.com>
> Hi all,
>
> please review this change that removes the inconsistency in interpretation of G1ConfidencePercent; higher confidence means that G1 should use less safety margin (i.e. part of the variance).
>
> Other than that it does not change the uses for it.
>
> Testing: gha
>
> Thanks,
> Thomas
Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
* kbarrett review
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/21448/files
- new: https://git.openjdk.org/jdk/pull/21448/files/8ffd34c6..79d67ee3
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=21448&range=02
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=21448&range=01-02
Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
Patch: https://git.openjdk.org/jdk/pull/21448.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/21448/head:pull/21448
PR: https://git.openjdk.org/jdk/pull/21448
From mli at openjdk.org Tue Oct 15 08:09:36 2024
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 15 Oct 2024 08:09:36 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v23]
In-Reply-To: <cL1TRIR8QmiIxhVU8LmxcEjUcneCNyLOh7ik4fgmIcM=.abc5dea2-6d92-4b6e-9e3f-01137441d02e@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<0BrAbBTKmpqTGDrc--2znzO8t07yoqabwa6g2K05GHI=.d3c17fd5-4770-4623-8d2f-604816afc033@github.com>
<cL1TRIR8QmiIxhVU8LmxcEjUcneCNyLOh7ik4fgmIcM=.abc5dea2-6d92-4b6e-9e3f-01137441d02e@github.com>
Message-ID: <G60MN3iR1XqQsIpQ-u-TUb5UK7DmCkOOIZ8_UnTgS64=.d0da6080-2991-4578-af68-453ffc63f2ef@github.com>
On Thu, 19 Sep 2024 15:01:26 GMT, Hamlin Li <mli at openjdk.org> wrote:
>> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
>>
>> - Merge remote-tracking branch 'lilliput/JEP-450-temporary-fix-branch-2' into JDK-8305895-v4
>> - review feedback
>
> In both aarch64.ad and x86_64.ad, `MachUEPNode::format` might need some change accordingly?
> AFAIK, @Hamlin-Li is working on the RISCV port. Not sure who would do s390. If it's available before intergration, I'll include it, but I'll not wait for it.
Thanks! We're having some internal (riscv specific) discussion & review, should be able to provide the patch soon.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2413178574
From amitkumar at openjdk.org Tue Oct 15 08:14:30 2024
From: amitkumar at openjdk.org (Amit Kumar)
Date: Tue, 15 Oct 2024 08:14:30 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v39]
In-Reply-To: <LjXNg7ygXw6KlgE0O5mMhgJ2IpNSpcZV1VKvF-p3qdQ=.608e20a4-25a8-4b9d-acaa-39eead7c4617@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<q4sTPbMm-cK1O35GhIbRytiakYgyKJYrBhotG_Kwn2o=.02620a61-e96d-4c93-af80-d27a61dd9ee7@github.com>
<LjXNg7ygXw6KlgE0O5mMhgJ2IpNSpcZV1VKvF-p3qdQ=.608e20a4-25a8-4b9d-acaa-39eead7c4617@github.com>
Message-ID: <ay-vYduVhGNK9HQodtCnP9Awa_NXaGRtGYOh55KqgxU=.a4ba42c8-eafa-4517-87a8-a92bcbc398be@github.com>
On Mon, 14 Oct 2024 21:47:00 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:
>@offamitkumar: It could still be done after this PR is integrated, but I guess you want to provide an s390 implementation.
I haven't looked into it yet. I am looking into other issues for now, but I will if I can get time to work on this.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2413190779
From tschatzl at openjdk.org Tue Oct 15 08:15:54 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 15 Oct 2024 08:15:54 GMT
Subject: RFR: 8334010: VM crashes with ObjectAlignmentInBytes >
GCCardSizeInBytes
Message-ID: <zLptHq5hWMLcfhdYeJf5xYwePc10eKirOiJMoo7IqUA=.2240942e-d385-445b-9b19-0b3df1ae42af@github.com>
Hi all,
please review this change that makes VM initialization reject invalid combinations of `ObjectAlignmentInBytes` and `GCCardSizeInBytes`.
ObjectAlignmentInBytes larger than GCCardSizeInBytes causes issues with setting correct BOT offsets.
Testing: new test case, gha
Hth,
Thomas
-------------
Commit messages:
- 8334010
Changes: https://git.openjdk.org/jdk/pull/21515/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21515&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8334010
Stats: 71 lines in 2 files changed: 71 ins; 0 del; 0 mod
Patch: https://git.openjdk.org/jdk/pull/21515.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/21515/head:pull/21515
PR: https://git.openjdk.org/jdk/pull/21515
From kbarrett at openjdk.org Tue Oct 15 08:22:10 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 15 Oct 2024 08:22:10 GMT
Subject: RFR: 8337269: G1ConfidencePercent interpreted inconsistently [v3]
In-Reply-To: <4ZRKdmYwGbFzCw2zaDrdYZSRI098hgb09_mGaIafbqY=.d63cbda5-8e8a-4086-b644-37b050f50d3a@github.com>
References: <gzTcofH9ul6O6ZIol3nGtVbbZOY7uzu5doUU5jMBsAY=.3652c863-dae5-4728-846f-bffe563643bb@github.com>
<4ZRKdmYwGbFzCw2zaDrdYZSRI098hgb09_mGaIafbqY=.d63cbda5-8e8a-4086-b644-37b050f50d3a@github.com>
Message-ID: <LNs_Vfdv3yI4TwDjn4Cb5Hb9Fj5n-SaSrQeoeurGKHw=.be4db649-81ca-4f13-a8b3-e3bbd28c4ff1@github.com>
On Tue, 15 Oct 2024 06:24:47 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:
>> Hi all,
>>
>> please review this change that removes the inconsistency in interpretation of G1ConfidencePercent; higher confidence means that G1 should use less safety margin (i.e. part of the variance).
>>
>> Other than that it does not change the uses for it.
>>
>> Testing: gha
>>
>> Thanks,
>> Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
>
> * kbarrett review
Looks good.
-------------
Marked as reviewed by kbarrett (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/21448#pullrequestreview-2368524998
From tschatzl at openjdk.org Tue Oct 15 08:26:48 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 15 Oct 2024 08:26:48 GMT
Subject: RFR: 8337339: gc/arguments/Test*SizeFlags.java timing out with Xcomp
Message-ID: <TyorL9xA-L-JBmWtq_5FgMAGusQCT3qC4ahRaCai-Gc=.74f3a790-5684-4476-8524-a9ef0c527771@github.com>
Hi all,
please review this simple change to not run the Test*SizeFlags tests with -Xcomp to avoid timeouts. I do not expect any new insights running these tests with -Xcomp, so I agree that it is easiest to just not run them with that flag.
Testing: gha
Hth,
Thomas
-------------
Commit messages:
- 8337339
Changes: https://git.openjdk.org/jdk/pull/21516/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21516&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8337339
Stats: 3 lines in 3 files changed: 3 ins; 0 del; 0 mod
Patch: https://git.openjdk.org/jdk/pull/21516.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/21516/head:pull/21516
PR: https://git.openjdk.org/jdk/pull/21516
From shade at openjdk.org Tue Oct 15 08:41:13 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 15 Oct 2024 08:41:13 GMT
Subject: RFR: 8334010: VM crashes with ObjectAlignmentInBytes >
GCCardSizeInBytes
In-Reply-To: <zLptHq5hWMLcfhdYeJf5xYwePc10eKirOiJMoo7IqUA=.2240942e-d385-445b-9b19-0b3df1ae42af@github.com>
References: <zLptHq5hWMLcfhdYeJf5xYwePc10eKirOiJMoo7IqUA=.2240942e-d385-445b-9b19-0b3df1ae42af@github.com>
Message-ID: <wMBfwAo_G8xqQRdzyksO-Cik6p6084bpuqGxHhaNrjY=.0e91a483-4ec7-4fd1-920e-000e6322e069@github.com>
On Tue, 15 Oct 2024 08:10:09 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:
> Hi all,
>
> please review this change that makes VM initialization reject invalid combinations of `ObjectAlignmentInBytes` and `GCCardSizeInBytes`.
>
> ObjectAlignmentInBytes larger than GCCardSizeInBytes causes issues with setting correct BOT offsets.
>
> Testing: new test case, gha
>
> Hth,
> Thomas
This looks fine, I only have comments about the test.
test/hotspot/jtreg/gc/TestObjectAlignmentCardSize.java line 43:
> 41: "-XX:GCCardSizeInBytes=" + cardSize,
> 42: "-Xmx32m",
> 43: "-Xms32m",
I wonder if we are playing close to heap limits here, especially with large `ObjectAlignmentInBytes`. Do you have a feeling how much of the heap is used with `ObjectAlignmentInBytes=512`? Should this be `128m` instead, maybe?
test/hotspot/jtreg/gc/TestObjectAlignmentCardSize.java line 51:
> 49: output.shouldHaveExitValue(0);
> 50: } else {
> 51: output.shouldContain("Error occurred during initialization of VM");
Check for `Invalid combination of GCCardSizeInBytes and ObjectAlignmentInBytes` message explicitly?
-------------
PR Review: https://git.openjdk.org/jdk/pull/21515#pullrequestreview-2368567001
PR Review Comment: https://git.openjdk.org/jdk/pull/21515#discussion_r1800707594
PR Review Comment: https://git.openjdk.org/jdk/pull/21515#discussion_r1800705971
From shade at openjdk.org Tue Oct 15 08:41:13 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 15 Oct 2024 08:41:13 GMT
Subject: RFR: 8337339: gc/arguments/Test*SizeFlags.java timing out with
Xcomp
In-Reply-To: <TyorL9xA-L-JBmWtq_5FgMAGusQCT3qC4ahRaCai-Gc=.74f3a790-5684-4476-8524-a9ef0c527771@github.com>
References: <TyorL9xA-L-JBmWtq_5FgMAGusQCT3qC4ahRaCai-Gc=.74f3a790-5684-4476-8524-a9ef0c527771@github.com>
Message-ID: <tJFjKo2UM0GZ6o2gtvbePdkQimYitvbqH-GQpDtGN_s=.c52033d4-f840-44de-8ae8-c067c865b5b2@github.com>
On Tue, 15 Oct 2024 08:21:28 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:
> Hi all,
>
> please review this simple change to not run the Test*SizeFlags tests with -Xcomp to avoid timeouts. I do not expect any new insights running these tests with -Xcomp, so I agree that it is easiest to just not run them with that flag.
>
> Testing: gha
>
> Hth,
> Thomas
Marked as reviewed by shade (Reviewer).
-------------
PR Review: https://git.openjdk.org/jdk/pull/21516#pullrequestreview-2368572095
From rkennke at openjdk.org Tue Oct 15 08:46:57 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 15 Oct 2024 08:46:57 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v40]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <LMXcf9mNlOcl32Ii2GjKD3MU85-5ShuLCQ_R_53tKB8=.1f6fd73c-99a2-4c70-a925-55aa52904d9e@github.com>
> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>
> Main changes:
> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
> - Arrays will now store their length at offset 8.
> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...
Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
PPC64 implementation of Compact Object Headers (JEP 450)
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/20677/files
- new: https://git.openjdk.org/jdk/pull/20677/files/b289ef88..6722f8be
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=39
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=38-39
Stats: 161 lines in 9 files changed: 95 ins; 39 del; 27 mod
Patch: https://git.openjdk.org/jdk/pull/20677.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677
PR: https://git.openjdk.org/jdk/pull/20677
From shade at openjdk.org Tue Oct 15 08:49:10 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 15 Oct 2024 08:49:10 GMT
Subject: RFR: 8342044: Increase timeout of
gc/shenandoah/oom/TestClassLoaderLeak.java
In-Reply-To: <vacjtHaJHS4QuyVB26411a-8BYXpiRfmC_xjpZJfz7I=.567b306b-1376-4a18-903d-5581f1a2212f@github.com>
References: <vacjtHaJHS4QuyVB26411a-8BYXpiRfmC_xjpZJfz7I=.567b306b-1376-4a18-903d-5581f1a2212f@github.com>
Message-ID: <938a5y4eZ2YjOq3EzYlOZ0Kh9a_GqWR40PEQ43o5UjY=.f46cbd4b-846d-4473-a253-79995fcd9b0c@github.com>
On Mon, 14 Oct 2024 11:40:17 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:
> Test gc/shenandoah/oom/TestClassLoaderLeak.java often times out on WIndows, we should increase the timeout values to avoid test errors.
Marked as reviewed by shade (Reviewer).
-------------
PR Review: https://git.openjdk.org/jdk/pull/21491#pullrequestreview-2368591927
From iwalulya at openjdk.org Tue Oct 15 08:49:11 2024
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Tue, 15 Oct 2024 08:49:11 GMT
Subject: RFR: 8337339: gc/arguments/Test*SizeFlags.java timing out with
Xcomp
In-Reply-To: <TyorL9xA-L-JBmWtq_5FgMAGusQCT3qC4ahRaCai-Gc=.74f3a790-5684-4476-8524-a9ef0c527771@github.com>
References: <TyorL9xA-L-JBmWtq_5FgMAGusQCT3qC4ahRaCai-Gc=.74f3a790-5684-4476-8524-a9ef0c527771@github.com>
Message-ID: <OJ6vyamMNVa_KLicqzBUz88p0MAXtRrPfSfe_-oSig8=.838d344e-f38e-42ca-8226-e931c9ca43fd@github.com>
On Tue, 15 Oct 2024 08:21:28 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:
> Hi all,
>
> please review this simple change to not run the Test*SizeFlags tests with -Xcomp to avoid timeouts. I do not expect any new insights running these tests with -Xcomp, so I agree that it is easiest to just not run them with that flag.
>
> Testing: gha
>
> Hth,
> Thomas
Marked as reviewed by iwalulya (Reviewer).
-------------
PR Review: https://git.openjdk.org/jdk/pull/21516#pullrequestreview-2368589709
From tschatzl at openjdk.org Tue Oct 15 08:49:17 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 15 Oct 2024 08:49:17 GMT
Subject: RFR: 8337269: G1ConfidencePercent interpreted inconsistently [v3]
In-Reply-To: <GlWz9rkGjoS2etN5I2ONq5iDL2kl2YSMsl660MVsNAI=.4a8cab91-ef8f-4e61-9a67-41f3e5b7e3be@github.com>
References: <gzTcofH9ul6O6ZIol3nGtVbbZOY7uzu5doUU5jMBsAY=.3652c863-dae5-4728-846f-bffe563643bb@github.com>
<GlWz9rkGjoS2etN5I2ONq5iDL2kl2YSMsl660MVsNAI=.4a8cab91-ef8f-4e61-9a67-41f3e5b7e3be@github.com>
Message-ID: <rXPBlwo_tzkXOhKkwIoffZZt77dlrNS8fzpappqTDCo=.1609e3b1-c910-4238-9c8c-9c58c5c313f7@github.com>
On Thu, 10 Oct 2024 12:29:54 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:
>> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
>>
>> * kbarrett review
>
> Marked as reviewed by iwalulya (Reviewer).
Thanks @walulyai @kimbarrett for your reviews
-------------
PR Comment: https://git.openjdk.org/jdk/pull/21448#issuecomment-2413267761
From tschatzl at openjdk.org Tue Oct 15 08:49:18 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 15 Oct 2024 08:49:18 GMT
Subject: Integrated: 8337269: G1ConfidencePercent interpreted inconsistently
In-Reply-To: <gzTcofH9ul6O6ZIol3nGtVbbZOY7uzu5doUU5jMBsAY=.3652c863-dae5-4728-846f-bffe563643bb@github.com>
References: <gzTcofH9ul6O6ZIol3nGtVbbZOY7uzu5doUU5jMBsAY=.3652c863-dae5-4728-846f-bffe563643bb@github.com>
Message-ID: <1hGnBOIlGTUlmcQqIkVTkzRzbNZw6AUewl_KMzuq7y8=.e9f7c749-d877-43a8-8971-e63777a09142@github.com>
On Thu, 10 Oct 2024 09:56:58 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:
> Hi all,
>
> please review this change that removes the inconsistency in interpretation of G1ConfidencePercent; higher confidence means that G1 should use less safety margin (i.e. part of the variance).
>
> Other than that it does not change the uses for it.
>
> Testing: gha
>
> Thanks,
> Thomas
This pull request has now been integrated.
Changeset: 3b8a2f8c
Author: Thomas Schatzl <tschatzl at openjdk.org>
URL: https://git.openjdk.org/jdk/commit/3b8a2f8c45ffd0bdb48db805cf70b4652525d891
Stats: 15 lines in 3 files changed: 4 ins; 4 del; 7 mod
8337269: G1ConfidencePercent interpreted inconsistently
Reviewed-by: kbarrett, iwalulya
-------------
PR: https://git.openjdk.org/jdk/pull/21448
From tschatzl at openjdk.org Tue Oct 15 08:57:28 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 15 Oct 2024 08:57:28 GMT
Subject: RFR: 8334010: VM crashes with ObjectAlignmentInBytes >
GCCardSizeInBytes [v2]
In-Reply-To: <zLptHq5hWMLcfhdYeJf5xYwePc10eKirOiJMoo7IqUA=.2240942e-d385-445b-9b19-0b3df1ae42af@github.com>
References: <zLptHq5hWMLcfhdYeJf5xYwePc10eKirOiJMoo7IqUA=.2240942e-d385-445b-9b19-0b3df1ae42af@github.com>
Message-ID: <WDnAHTfkILVjxS09P-DgoqNPuvDOrkel7txfhfzoRyc=.96ded868-a97b-4c86-9958-38e3558c2528@github.com>
> Hi all,
>
> please review this change that makes VM initialization reject invalid combinations of `ObjectAlignmentInBytes` and `GCCardSizeInBytes`.
>
> ObjectAlignmentInBytes larger than GCCardSizeInBytes causes issues with setting correct BOT offsets.
>
> Testing: new test case, gha
>
> Hth,
> Thomas
Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
* shade review
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/21515/files
- new: https://git.openjdk.org/jdk/pull/21515/files/8a08233c..2e86be6a
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=21515&range=01
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=21515&range=00-01
Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
Patch: https://git.openjdk.org/jdk/pull/21515.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/21515/head:pull/21515
PR: https://git.openjdk.org/jdk/pull/21515
From tschatzl at openjdk.org Tue Oct 15 08:57:28 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 15 Oct 2024 08:57:28 GMT
Subject: RFR: 8334010: VM crashes with ObjectAlignmentInBytes >
GCCardSizeInBytes [v2]
In-Reply-To: <wMBfwAo_G8xqQRdzyksO-Cik6p6084bpuqGxHhaNrjY=.0e91a483-4ec7-4fd1-920e-000e6322e069@github.com>
References: <zLptHq5hWMLcfhdYeJf5xYwePc10eKirOiJMoo7IqUA=.2240942e-d385-445b-9b19-0b3df1ae42af@github.com>
<wMBfwAo_G8xqQRdzyksO-Cik6p6084bpuqGxHhaNrjY=.0e91a483-4ec7-4fd1-920e-000e6322e069@github.com>
Message-ID: <Kfvon6HLi8SvP2WAiRR2IJIQ3J3JnmMhMcxAW2g0re0=.30bb7912-4a6a-4ce7-9ec1-f34a346415b4@github.com>
On Tue, 15 Oct 2024 08:38:01 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:
>> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
>>
>> * shade review
>
> test/hotspot/jtreg/gc/TestObjectAlignmentCardSize.java line 43:
>
>> 41: "-XX:GCCardSizeInBytes=" + cardSize,
>> 42: "-Xmx32m",
>> 43: "-Xms32m",
>
> I wonder if we are playing close to heap limits here, especially with large `ObjectAlignmentInBytes`. Do you have a feeling how much of the heap is used with `ObjectAlignmentInBytes=512`? Should this be `128m` instead, maybe?
The gc+heap+exit memory usage shows <5m memory usage for all GCs (G1, Shenandoah, Serial, Parallel). We could go even lower to 16m easily.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/21515#discussion_r1800731877
From shade at openjdk.org Tue Oct 15 09:01:12 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 15 Oct 2024 09:01:12 GMT
Subject: RFR: 8334010: VM crashes with ObjectAlignmentInBytes >
GCCardSizeInBytes [v2]
In-Reply-To: <WDnAHTfkILVjxS09P-DgoqNPuvDOrkel7txfhfzoRyc=.96ded868-a97b-4c86-9958-38e3558c2528@github.com>
References: <zLptHq5hWMLcfhdYeJf5xYwePc10eKirOiJMoo7IqUA=.2240942e-d385-445b-9b19-0b3df1ae42af@github.com>
<WDnAHTfkILVjxS09P-DgoqNPuvDOrkel7txfhfzoRyc=.96ded868-a97b-4c86-9958-38e3558c2528@github.com>
Message-ID: <BfkGjfvuR2lRvqsS4yxkuoICztHQtsc4rDYdEOHYij4=.26052f2e-5c25-4077-b8a3-29adab732863@github.com>
On Tue, 15 Oct 2024 08:57:28 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:
>> Hi all,
>>
>> please review this change that makes VM initialization reject invalid combinations of `ObjectAlignmentInBytes` and `GCCardSizeInBytes`.
>>
>> ObjectAlignmentInBytes larger than GCCardSizeInBytes causes issues with setting correct BOT offsets.
>>
>> Testing: new test case, gha
>>
>> Hth,
>> Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
>
> * shade review
Marked as reviewed by shade (Reviewer).
-------------
PR Review: https://git.openjdk.org/jdk/pull/21515#pullrequestreview-2368621122
From shade at openjdk.org Tue Oct 15 09:01:14 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 15 Oct 2024 09:01:14 GMT
Subject: RFR: 8334010: VM crashes with ObjectAlignmentInBytes >
GCCardSizeInBytes [v2]
In-Reply-To: <Kfvon6HLi8SvP2WAiRR2IJIQ3J3JnmMhMcxAW2g0re0=.30bb7912-4a6a-4ce7-9ec1-f34a346415b4@github.com>
References: <zLptHq5hWMLcfhdYeJf5xYwePc10eKirOiJMoo7IqUA=.2240942e-d385-445b-9b19-0b3df1ae42af@github.com>
<wMBfwAo_G8xqQRdzyksO-Cik6p6084bpuqGxHhaNrjY=.0e91a483-4ec7-4fd1-920e-000e6322e069@github.com>
<Kfvon6HLi8SvP2WAiRR2IJIQ3J3JnmMhMcxAW2g0re0=.30bb7912-4a6a-4ce7-9ec1-f34a346415b4@github.com>
Message-ID: <djRAF9-Ei4079uT3f6XnSHRWfxl8YNnZXaZ4hD2GsoE=.d94f7804-98ed-45fd-a8ba-4297c97779d6@github.com>
On Tue, 15 Oct 2024 08:53:39 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:
>> test/hotspot/jtreg/gc/TestObjectAlignmentCardSize.java line 43:
>>
>>> 41: "-XX:GCCardSizeInBytes=" + cardSize,
>>> 42: "-Xmx32m",
>>> 43: "-Xms32m",
>>
>> I wonder if we are playing close to heap limits here, especially with large `ObjectAlignmentInBytes`. Do you have a feeling how much of the heap is used with `ObjectAlignmentInBytes=512`? Should this be `128m` instead, maybe?
>
> The gc+heap+exit memory usage shows <5m memory usage for all GCs (G1, Shenandoah, Serial, Parallel). We could go even lower to 16m easily.
Cool, nevermind then.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/21515#discussion_r1800738320
From tschatzl at openjdk.org Tue Oct 15 09:01:15 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 15 Oct 2024 09:01:15 GMT
Subject: RFR: 8334010: VM crashes with ObjectAlignmentInBytes >
GCCardSizeInBytes [v2]
In-Reply-To: <djRAF9-Ei4079uT3f6XnSHRWfxl8YNnZXaZ4hD2GsoE=.d94f7804-98ed-45fd-a8ba-4297c97779d6@github.com>
References: <zLptHq5hWMLcfhdYeJf5xYwePc10eKirOiJMoo7IqUA=.2240942e-d385-445b-9b19-0b3df1ae42af@github.com>
<wMBfwAo_G8xqQRdzyksO-Cik6p6084bpuqGxHhaNrjY=.0e91a483-4ec7-4fd1-920e-000e6322e069@github.com>
<Kfvon6HLi8SvP2WAiRR2IJIQ3J3JnmMhMcxAW2g0re0=.30bb7912-4a6a-4ce7-9ec1-f34a346415b4@github.com>
<djRAF9-Ei4079uT3f6XnSHRWfxl8YNnZXaZ4hD2GsoE=.d94f7804-98ed-45fd-a8ba-4297c97779d6@github.com>
Message-ID: <KGhC_QR2OVU0WGadGesxuf-AEhJn325wxUOj9Nkw2WQ=.4abf96b7-5896-4838-880a-3e5ce8fedad5@github.com>
On Tue, 15 Oct 2024 08:57:33 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:
>> The gc+heap+exit memory usage shows <5m memory usage for all GCs (G1, Shenandoah, Serial, Parallel). We could go even lower to 16m easily.
>
> Cool, nevermind then.
Also the maximum allowed/used OAIB value is 256.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/21515#discussion_r1800739778
From rkennke at openjdk.org Tue Oct 15 09:02:16 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 15 Oct 2024 09:02:16 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v41]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <JBrhBOknUeYekenNA45sQtigIIHUEQaKpCvdBIZVdeA=.73bbcac9-af12-4672-92e0-cbe9b6921490@github.com>
> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>
> Main changes:
> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
> - Arrays will now store their length at offset 8.
> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...
Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 90 commits:
- Merge tag 'jdk-24+19' into JDK-8305895-v4
Added tag jdk-24+19 for changeset e7c5bf45
- PPC64 implementation of Compact Object Headers (JEP 450)
- Increase compiler code stubs size for indexOf intrinsic
- Fix include guards
- Improve PSParallelCompact::fill_dense_prefix_end() even more
- Re-enable indexOf intrinsic for compact headers
- Rename nklass in aarch64
- Fix comment
- Rename nklass in x86 code
- Fix header < 16 bytes in indexOf intrinsic, by @sviswa7
- ... and 80 more: https://git.openjdk.org/jdk/compare/e7c5bf45...86f94fee
-------------
Changes: https://git.openjdk.org/jdk/pull/20677/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=40
Stats: 4865 lines in 205 files changed: 3383 ins; 818 del; 664 mod
Patch: https://git.openjdk.org/jdk/pull/20677.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677
PR: https://git.openjdk.org/jdk/pull/20677
From iwalulya at openjdk.org Tue Oct 15 09:14:16 2024
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Tue, 15 Oct 2024 09:14:16 GMT
Subject: RFR: 8337339: gc/arguments/Test*SizeFlags.java timing out with
Xcomp
In-Reply-To: <TyorL9xA-L-JBmWtq_5FgMAGusQCT3qC4ahRaCai-Gc=.74f3a790-5684-4476-8524-a9ef0c527771@github.com>
References: <TyorL9xA-L-JBmWtq_5FgMAGusQCT3qC4ahRaCai-Gc=.74f3a790-5684-4476-8524-a9ef0c527771@github.com>
Message-ID: <CvfetalpXRIoVN9w-PWXX_thqHMaeOcmpjYFsWwsshM=.0b021720-1e47-4c38-9210-205ff3700123@github.com>
On Tue, 15 Oct 2024 08:21:28 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:
> Hi all,
>
> please review this simple change to not run the Test*SizeFlags tests with -Xcomp to avoid timeouts. I do not expect any new insights running these tests with -Xcomp, so I agree that it is easiest to just not run them with that flag.
>
> Testing: gha
>
> Hth,
> Thomas
Trivial!
-------------
PR Comment: https://git.openjdk.org/jdk/pull/21516#issuecomment-2413332889
From tschatzl at openjdk.org Tue Oct 15 09:18:15 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 15 Oct 2024 09:18:15 GMT
Subject: Integrated: 8337339: gc/arguments/Test*SizeFlags.java timing out with
Xcomp
In-Reply-To: <TyorL9xA-L-JBmWtq_5FgMAGusQCT3qC4ahRaCai-Gc=.74f3a790-5684-4476-8524-a9ef0c527771@github.com>
References: <TyorL9xA-L-JBmWtq_5FgMAGusQCT3qC4ahRaCai-Gc=.74f3a790-5684-4476-8524-a9ef0c527771@github.com>
Message-ID: <FeKqEihacckMPxhr5AsJsTEY_ykjTWU8XloBlaS9BSo=.8f62da80-c434-4111-b4c1-50ebe027c4d6@github.com>
On Tue, 15 Oct 2024 08:21:28 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:
> Hi all,
>
> please review this simple change to not run the Test*SizeFlags tests with -Xcomp to avoid timeouts. I do not expect any new insights running these tests with -Xcomp, so I agree that it is easiest to just not run them with that flag.
>
> Testing: gha
>
> Hth,
> Thomas
This pull request has now been integrated.
Changeset: c9a536c3
Author: Thomas Schatzl <tschatzl at openjdk.org>
URL: https://git.openjdk.org/jdk/commit/c9a536c330d37632139a1d71b0c054352eae5aa0
Stats: 3 lines in 3 files changed: 3 ins; 0 del; 0 mod
8337339: gc/arguments/Test*SizeFlags.java timing out with Xcomp
Reviewed-by: shade, iwalulya
-------------
PR: https://git.openjdk.org/jdk/pull/21516
From tschatzl at openjdk.org Tue Oct 15 09:18:14 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 15 Oct 2024 09:18:14 GMT
Subject: RFR: 8337339: gc/arguments/Test*SizeFlags.java timing out with
Xcomp
In-Reply-To: <CvfetalpXRIoVN9w-PWXX_thqHMaeOcmpjYFsWwsshM=.0b021720-1e47-4c38-9210-205ff3700123@github.com>
References: <TyorL9xA-L-JBmWtq_5FgMAGusQCT3qC4ahRaCai-Gc=.74f3a790-5684-4476-8524-a9ef0c527771@github.com>
<CvfetalpXRIoVN9w-PWXX_thqHMaeOcmpjYFsWwsshM=.0b021720-1e47-4c38-9210-205ff3700123@github.com>
Message-ID: <_WprTWfvrvDeA5U6o7KarewER1hP7bjMLAuTYXjF0U0=.15c16ef3-ed87-45a0-a69d-0da42abac300@github.com>
On Tue, 15 Oct 2024 09:12:00 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:
>> Hi all,
>>
>> please review this simple change to not run the Test*SizeFlags tests with -Xcomp to avoid timeouts. I do not expect any new insights running these tests with -Xcomp, so I agree that it is easiest to just not run them with that flag.
>>
>> Testing: gha
>>
>> Hth,
>> Thomas
>
> Trivial!
Thanks @walulyai @shipilev for your reviews
-------------
PR Comment: https://git.openjdk.org/jdk/pull/21516#issuecomment-2413339874
From iwalulya at openjdk.org Tue Oct 15 09:24:11 2024
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Tue, 15 Oct 2024 09:24:11 GMT
Subject: RFR: 8334010: VM crashes with ObjectAlignmentInBytes >
GCCardSizeInBytes [v2]
In-Reply-To: <WDnAHTfkILVjxS09P-DgoqNPuvDOrkel7txfhfzoRyc=.96ded868-a97b-4c86-9958-38e3558c2528@github.com>
References: <zLptHq5hWMLcfhdYeJf5xYwePc10eKirOiJMoo7IqUA=.2240942e-d385-445b-9b19-0b3df1ae42af@github.com>
<WDnAHTfkILVjxS09P-DgoqNPuvDOrkel7txfhfzoRyc=.96ded868-a97b-4c86-9958-38e3558c2528@github.com>
Message-ID: <1A_uTlWSEgekpTXDnCkYXjltqDZFhKgOE3d-qWEZQdI=.6cee3330-fd72-40c3-a278-a2a2987ac857@github.com>
On Tue, 15 Oct 2024 08:57:28 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:
>> Hi all,
>>
>> please review this change that makes VM initialization reject invalid combinations of `ObjectAlignmentInBytes` and `GCCardSizeInBytes`.
>>
>> ObjectAlignmentInBytes larger than GCCardSizeInBytes causes issues with setting correct BOT offsets.
>>
>> Testing: new test case, gha
>>
>> Hth,
>> Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
>
> * shade review
LGTM!
-------------
Marked as reviewed by iwalulya (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/21515#pullrequestreview-2368696071
From rkennke at openjdk.org Tue Oct 15 10:47:55 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 15 Oct 2024 10:47:55 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v42]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <5x48SX55xY_BRxqqcTTvGp_ocrKDH7t5VuJY-MDQuTA=.eed6083d-e2dc-4888-a2d5-b6934f098289@github.com>
> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>
> Main changes:
> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
> - Arrays will now store their length at offset 8.
> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...
Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
Fix aarch64.ad
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/20677/files
- new: https://git.openjdk.org/jdk/pull/20677/files/86f94fee..005498b1
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=41
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=40-41
Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
Patch: https://git.openjdk.org/jdk/pull/20677.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677
PR: https://git.openjdk.org/jdk/pull/20677
From tschatzl at openjdk.org Tue Oct 15 11:28:31 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 15 Oct 2024 11:28:31 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v8]
In-Reply-To: <6usTXIvS83aO2VzX5xu2EnXlpIJ8YbfrWS6b3EI0MhE=.0e8cc603-0cd3-4bd9-b309-55e4dd0f0cb0@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<J0g0PSye768dhN3JoXFsZ6FivocNBLPmHNtRUCOmLTw=.5756c64a-4763-4727-9637-ba3fe7b9b17d@github.com>
<6usTXIvS83aO2VzX5xu2EnXlpIJ8YbfrWS6b3EI0MhE=.0e8cc603-0cd3-4bd9-b309-55e4dd0f0cb0@github.com>
Message-ID: <N0f3YokOST3MTXR_iRwPjQGBEz15Pb9KB1zffJJwFuI=.d7ae3343-2fdd-43e0-855d-de8975603732@github.com>
On Mon, 9 Sep 2024 11:53:13 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:
>> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
>>
>> - Try to avoid lea in loadNklass (aarch64)
>> - Fix release build error
>
> src/hotspot/share/oops/klass.hpp line 169:
>
>> 167: // contention that may happen when a nearby object is modified.
>> 168: AccessFlags _access_flags; // Access flags. The class/interface distinction is stored here.
>> 169: // Some flags created by the JVM, not in the class file itself,
>
> Suggestion:
>
> markWord _prototype_header; // Used to initialize objects' header with compact headers.
>
>
> Maybe some comment why this is an instance member.
>@tschatzl I just found your comment here, and I'm not sure what you mean, tbh. The prototype_header is a member of Klass because with compact headers, it encodes that Klass in the prototype header. Note that there is planned follow-up work to remove that field and encode the Klass* on the allocation path. https://bugs.openjdk.org/browse/JDK-8341703
You explained what I had wanted to see here - why do we need a per-klass prototype header, because the markWord contains it ;)
Given that it is going away, I retract this comment and the request can be resolved.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1800983876
From jsikstro at openjdk.org Tue Oct 15 11:54:21 2024
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Tue, 15 Oct 2024 11:54:21 GMT
Subject: RFR: 8342102: ZGC: Optimize copy constructors in ZPhysicalMemory
Message-ID: <5hvFKET_jLREXmQcM1LygpEEnBuYzIV5fOXXajE-OEk=.7625a7a0-2cbf-4f0b-a7c9-b772f20599f7@github.com>
ZPhysicalMemory stores a sorted array of physical memory segments. Segments are added using either add_segments or add_segment, where the former calls add_segment on each individual segment. add_segment inserts segments in address order and also merges segments when possible.
When copying an instance of ZPhysicalMemory, segments are currently copied using either add_segments or add_segment, which works as described above. This requires more work than necessary and should be simplified to account for the fact that the array of segments is always sorted.
When copying, the copy constructors should instead use append or appendAll from the underlying GrowableArrayCHeap and also reserve enough memory so that the array's capacity is not increased more times than necessary during copying.
Tested with tiers 1-3.
-------------
Commit messages:
- 8342102: ZGC: Optimize copy constructors in ZPhysicalMemory
Changes: https://git.openjdk.org/jdk/pull/21523/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21523&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8342102
Stats: 8 lines in 1 file changed: 0 ins; 1 del; 7 mod
Patch: https://git.openjdk.org/jdk/pull/21523.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/21523/head:pull/21523
PR: https://git.openjdk.org/jdk/pull/21523
From mbaesken at openjdk.org Tue Oct 15 11:55:15 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 15 Oct 2024 11:55:15 GMT
Subject: RFR: 8342044: Increase timeout of
gc/shenandoah/oom/TestClassLoaderLeak.java
In-Reply-To: <vacjtHaJHS4QuyVB26411a-8BYXpiRfmC_xjpZJfz7I=.567b306b-1376-4a18-903d-5581f1a2212f@github.com>
References: <vacjtHaJHS4QuyVB26411a-8BYXpiRfmC_xjpZJfz7I=.567b306b-1376-4a18-903d-5581f1a2212f@github.com>
Message-ID: <ST9FMtBtLyorP8fJyHxdKdWi9gptRsEruvilJV-XFkQ=.662a2a43-4b0e-49eb-ab41-fcf4753e1d44@github.com>
On Mon, 14 Oct 2024 11:40:17 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:
> Test gc/shenandoah/oom/TestClassLoaderLeak.java often times out on WIndows, we should increase the timeout values to avoid test errors.
Thanks for the review !
-------------
PR Comment: https://git.openjdk.org/jdk/pull/21491#issuecomment-2413700365
From mbaesken at openjdk.org Tue Oct 15 11:55:16 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 15 Oct 2024 11:55:16 GMT
Subject: Integrated: 8342044: Increase timeout of
gc/shenandoah/oom/TestClassLoaderLeak.java
In-Reply-To: <vacjtHaJHS4QuyVB26411a-8BYXpiRfmC_xjpZJfz7I=.567b306b-1376-4a18-903d-5581f1a2212f@github.com>
References: <vacjtHaJHS4QuyVB26411a-8BYXpiRfmC_xjpZJfz7I=.567b306b-1376-4a18-903d-5581f1a2212f@github.com>
Message-ID: <gsqPgg4BHeLmUEFXafmUElIrn032Wlw1RrS82NYG3QI=.893163ec-6c22-41d5-b5c1-d5a8354745f0@github.com>
On Mon, 14 Oct 2024 11:40:17 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:
> Test gc/shenandoah/oom/TestClassLoaderLeak.java often times out on WIndows, we should increase the timeout values to avoid test errors.
This pull request has now been integrated.
Changeset: 2c0c6535
Author: Matthias Baesken <mbaesken at openjdk.org>
URL: https://git.openjdk.org/jdk/commit/2c0c65353b2f67bdcd954b4d2c2ae3e9b24d1c22
Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
8342044: Increase timeout of gc/shenandoah/oom/TestClassLoaderLeak.java
Reviewed-by: shade
-------------
PR: https://git.openjdk.org/jdk/pull/21491
From shade at openjdk.org Tue Oct 15 13:03:44 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 15 Oct 2024 13:03:44 GMT
Subject: RFR: 8342119: Shenandoah: Remove extra ShenandoahUpdateRefsClosure
Message-ID: <8v42ZVUQ6lc58IzwWUJeSd0IjkRNJIquDoEX1qRbOvM=.ea84c8d0-745c-42f7-b989-ecb2be9aaca1@github.com>
We have a duplicate `ShenandoahUpdateRefsClosure`, which we use in a few places. For bulk GC operations, we have `ShenandoahConcUpdateRefsClosure` and `ShenandoahSTWUpdateRefsClosure` that are semantically similar to that one. We can drop the `ShenandoahUpdateRefsClosure` in favor of these two existing ones.
Additional testing:
- [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`
- [ ] Performance tests (no regressions)
-------------
Commit messages:
- Fix
Changes: https://git.openjdk.org/jdk/pull/21517/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21517&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8342119
Stats: 37 lines in 5 files changed: 6 ins; 24 del; 7 mod
Patch: https://git.openjdk.org/jdk/pull/21517.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/21517/head:pull/21517
PR: https://git.openjdk.org/jdk/pull/21517
From iwalulya at openjdk.org Tue Oct 15 13:26:21 2024
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Tue, 15 Oct 2024 13:26:21 GMT
Subject: RFR: 8342182: G1: G1OldGenAllocationTracker does not account for
direct allocations in regions
Message-ID: <80Yg80fdSZM8KmryHjOQohAOJEETAQuOtSFejHw-lJw=.8cb4ec31-fcf0-49e0-89ac-77d5f4900747@github.com>
Hi,
Please review this change to add bytes allocated directly into the regions to G1OldGenAllocationTracker. Additional changes to the comments to claify that we keep track of allocations in between GCs and not only during mutator period.
Test: Tier 1
-------------
Commit messages:
- Merge remote-tracking branch 'upstream/master' into AllocationTracker
- space
- cleanup
Changes: https://git.openjdk.org/jdk/pull/21525/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21525&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8342182
Stats: 8 lines in 3 files changed: 1 ins; 0 del; 7 mod
Patch: https://git.openjdk.org/jdk/pull/21525.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/21525/head:pull/21525
PR: https://git.openjdk.org/jdk/pull/21525
From tschatzl at openjdk.org Tue Oct 15 13:26:22 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 15 Oct 2024 13:26:22 GMT
Subject: RFR: 8342182: G1: G1OldGenAllocationTracker does not account for
direct allocations in regions
In-Reply-To: <80Yg80fdSZM8KmryHjOQohAOJEETAQuOtSFejHw-lJw=.8cb4ec31-fcf0-49e0-89ac-77d5f4900747@github.com>
References: <80Yg80fdSZM8KmryHjOQohAOJEETAQuOtSFejHw-lJw=.8cb4ec31-fcf0-49e0-89ac-77d5f4900747@github.com>
Message-ID: <jgJfrezZUI1-UiwE9wObAL512QiKB1w3Yem8x2HVaxg=.ef9b1873-cf4b-4693-9528-153b149c8b6c@github.com>
On Tue, 15 Oct 2024 12:50:46 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:
> Hi,
>
> Please review this change to add bytes allocated directly into the regions to G1OldGenAllocationTracker. Additional changes to the comments to claify that we keep track of allocations in between GCs and not only during mutator period.
>
> Test: Tier 1
Marked as reviewed by tschatzl (Reviewer).
-------------
PR Review: https://git.openjdk.org/jdk/pull/21525#pullrequestreview-2369304037
From stefank at openjdk.org Tue Oct 15 19:16:14 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 15 Oct 2024 19:16:14 GMT
Subject: RFR: 8342102: ZGC: Optimize copy constructors in ZPhysicalMemory
In-Reply-To: <5hvFKET_jLREXmQcM1LygpEEnBuYzIV5fOXXajE-OEk=.7625a7a0-2cbf-4f0b-a7c9-b772f20599f7@github.com>
References: <5hvFKET_jLREXmQcM1LygpEEnBuYzIV5fOXXajE-OEk=.7625a7a0-2cbf-4f0b-a7c9-b772f20599f7@github.com>
Message-ID: <Sk02J3qq0ogn9tSO-MMf7Z4ObK943MLoGpqUkfLV3bw=.fbff07c0-6a19-40ef-ade9-8b943c1f4679@github.com>
On Tue, 15 Oct 2024 11:50:13 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:
> ZPhysicalMemory stores a sorted array of physical memory segments. Segments are added using either add_segments or add_segment, where the former calls add_segment on each individual segment. add_segment inserts segments in address order and also merges segments when possible.
>
> When copying an instance of ZPhysicalMemory, segments are currently copied using either add_segments or add_segment, which works as described above. This requires more work than necessary and should be simplified to account for the fact that the array of segments is always sorted.
>
> When copying, the copy constructors should instead use append or appendAll from the underlying GrowableArrayCHeap and also reserve enough memory so that the array's capacity is not increased more times than necessary during copying.
>
> Tested with tiers 1-3.
Looks good.
-------------
Marked as reviewed by stefank (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/21523#pullrequestreview-2370340762
From kbarrett at openjdk.org Tue Oct 15 22:28:11 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 15 Oct 2024 22:28:11 GMT
Subject: RFR: 8342102: ZGC: Optimize copy constructors in ZPhysicalMemory
In-Reply-To: <5hvFKET_jLREXmQcM1LygpEEnBuYzIV5fOXXajE-OEk=.7625a7a0-2cbf-4f0b-a7c9-b772f20599f7@github.com>
References: <5hvFKET_jLREXmQcM1LygpEEnBuYzIV5fOXXajE-OEk=.7625a7a0-2cbf-4f0b-a7c9-b772f20599f7@github.com>
Message-ID: <ta6zbRYmO_E7y0gp12TOcJ0jW0xUpFRlGq2I8PFYj6U=.73cff617-1706-47e9-b4fe-aa86f94f5f66@github.com>
On Tue, 15 Oct 2024 11:50:13 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:
> ZPhysicalMemory stores a sorted array of physical memory segments. Segments are added using either add_segments or add_segment, where the former calls add_segment on each individual segment. add_segment inserts segments in address order and also merges segments when possible.
>
> When copying an instance of ZPhysicalMemory, segments are currently copied using either add_segments or add_segment, which works as described above. This requires more work than necessary and should be simplified to account for the fact that the array of segments is always sorted.
>
> When copying, the copy constructors should instead use append or appendAll from the underlying GrowableArrayCHeap and also reserve enough memory so that the array's capacity is not increased more times than necessary during copying.
>
> Tested with tiers 1-3.
Changes requested by kbarrett (Reviewer).
src/hotspot/share/gc/z/zPhysicalMemory.cpp line 58:
> 56:
> 57: const ZPhysicalMemory& ZPhysicalMemory::operator=(const ZPhysicalMemory& pmem) {
> 58: // Free and copy segments
pre-existing: Seems like this ought to be checking for self-assign. I'd be okay with asserting against, even
though that's often frowned on in various writings on the subject.
-------------
PR Review: https://git.openjdk.org/jdk/pull/21523#pullrequestreview-2370803309
PR Review Comment: https://git.openjdk.org/jdk/pull/21523#discussion_r1802084247
From wkemper at openjdk.org Tue Oct 15 22:41:10 2024
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 15 Oct 2024 22:41:10 GMT
Subject: RFR: 8342119: Shenandoah: Remove extra ShenandoahUpdateRefsClosure
In-Reply-To: <8v42ZVUQ6lc58IzwWUJeSd0IjkRNJIquDoEX1qRbOvM=.ea84c8d0-745c-42f7-b989-ecb2be9aaca1@github.com>
References: <8v42ZVUQ6lc58IzwWUJeSd0IjkRNJIquDoEX1qRbOvM=.ea84c8d0-745c-42f7-b989-ecb2be9aaca1@github.com>
Message-ID: <HEQ6h3zNDOMoc-POIX6N7tCeea3qNVfa-zALiBt28os=.78e02c03-047f-4e2b-b995-5bc4964d9007@github.com>
On Tue, 15 Oct 2024 08:53:00 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:
> We have a duplicate `ShenandoahUpdateRefsClosure`, which we use in a few places. For bulk GC operations, we have `ShenandoahConcUpdateRefsClosure` and `ShenandoahSTWUpdateRefsClosure` that are semantically similar to that one. We can drop the `ShenandoahUpdateRefsClosure` in favor of these two existing ones.
>
> Additional testing:
> - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`
> - [ ] Performance tests (no regressions)
Marked as reviewed by wkemper (Committer).
-------------
PR Review: https://git.openjdk.org/jdk/pull/21517#pullrequestreview-2370816667
From duke at openjdk.org Tue Oct 15 22:44:35 2024
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Tue, 15 Oct 2024 22:44:35 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v42]
In-Reply-To: <5x48SX55xY_BRxqqcTTvGp_ocrKDH7t5VuJY-MDQuTA=.eed6083d-e2dc-4888-a2d5-b6934f098289@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<5x48SX55xY_BRxqqcTTvGp_ocrKDH7t5VuJY-MDQuTA=.eed6083d-e2dc-4888-a2d5-b6934f098289@github.com>
Message-ID: <zsXCn2nynPEIqUg3XFoI_UV_VUoIGyEmvPr2nRwkUiQ=.a3ff867d-cdb3-4a2a-bbcd-69065e3739bb@github.com>
On Tue, 15 Oct 2024 10:47:55 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>>
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>>
>> Main changes:
>> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>> - Arrays will now store their length at offset 8.
>> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>
> Fix aarch64.ad
Finished reviewing `src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp`, line by line and comparing old snippets that got merged into the new function: looks good to me, every (new) case handled
Only have some minor comments about comments.
src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 414:
> 412: // to the valid haystack bytes on the stack.
> 413: {
> 414: const Register haystack = rbx;
Keep `rax` as index for clarity? Although it is really used as a temp..
const Register index = rax;
const Register haystack = rbx;
copy_to_stack(haystack, haystack_len, false, index , XMM_TMP1, _masm);
src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 1568:
> 1566: assert((COPIED_HAYSTACK_STACK_SIZE == 64), "Must be 64!");
> 1567:
> 1568: // Copy incoming haystack onto stack
Old comment was slightly more precise. Move here. i.e.
`// Copy incoming haystack onto stack (haystack <= 32 bytes)`
src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 1634:
> 1632:
> 1633:
> 1634: // Copy the small (< 32 byte) haystack to the stack. Allows for vector reads without page fault
Just to be pedantic, its `(<=32)` - this function also handles 32bytes case.
- line 401:
__ cmpq(haystack_len, 0x20);
__ ja(L_bigSwitchTop);
- though line 293 (`highly_optimized_short_cases`) only seems to route16-byte cases here:
```__ cmpq(haystack_len_p, isU ? 8 : 16);```
src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 1659:
> 1657: Label L_moreThan8, L_moreThan16, L_moreThan24, L_adjustHaystack;
> 1658:
> 1659: assert(arrayOopDesc::base_offset_in_bytes(isU ? T_CHAR : T_BYTE) >= 8,
If we had to also optimize for header-size 16, it might be possible to remove one jump here. Looks correct for either size.
-------------
PR Review: https://git.openjdk.org/jdk/pull/20677#pullrequestreview-2370735887
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1802041876
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1802044880
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1802088545
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1802073195
From aboldtch at openjdk.org Wed Oct 16 05:26:10 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 16 Oct 2024 05:26:10 GMT
Subject: RFR: 8342102: ZGC: Optimize copy constructors in ZPhysicalMemory
In-Reply-To: <ta6zbRYmO_E7y0gp12TOcJ0jW0xUpFRlGq2I8PFYj6U=.73cff617-1706-47e9-b4fe-aa86f94f5f66@github.com>
References: <5hvFKET_jLREXmQcM1LygpEEnBuYzIV5fOXXajE-OEk=.7625a7a0-2cbf-4f0b-a7c9-b772f20599f7@github.com>
<ta6zbRYmO_E7y0gp12TOcJ0jW0xUpFRlGq2I8PFYj6U=.73cff617-1706-47e9-b4fe-aa86f94f5f66@github.com>
Message-ID: <aA4UlL9DOb01b0m3jgCgjMlnP1UgYsFW_owKGCXiObI=.6a686bb4-bf8b-41af-a32e-3c5648968f93@github.com>
On Tue, 15 Oct 2024 22:25:17 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:
>> ZPhysicalMemory stores a sorted array of physical memory segments. Segments are added using either add_segments or add_segment, where the former calls add_segment on each individual segment. add_segment inserts segments in address order and also merges segments when possible.
>>
>> When copying an instance of ZPhysicalMemory, segments are currently copied using either add_segments or add_segment, which works as described above. This requires more work than necessary and should be simplified to account for the fact that the array of segments is always sorted.
>>
>> When copying, the copy constructors should instead use append or appendAll from the underlying GrowableArrayCHeap and also reserve enough memory so that the array's capacity is not increased more times than necessary during copying.
>>
>> Tested with tiers 1-3.
>
> src/hotspot/share/gc/z/zPhysicalMemory.cpp line 58:
>
>> 56:
>> 57: const ZPhysicalMemory& ZPhysicalMemory::operator=(const ZPhysicalMemory& pmem) {
>> 58: // Free and copy segments
>
> pre-existing: Seems like this ought to be checking for self-assign. I'd be okay with asserting against, even
> though that's often frowned on in various writings on the subject.
Checking and returning `*this` seems fine to me. Seems like the least surprising solution.
The copy assignment operator is currently only ever used in a gtest.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/21523#discussion_r1802370478
From shade at openjdk.org Wed Oct 16 07:16:14 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 16 Oct 2024 07:16:14 GMT
Subject: RFR: 8342081: Shenandoah: Remove extra
ShenandoahMarkUpdateRefsSuperClosure
In-Reply-To: <btbf6MorZ7rEPf0UQBMVMeiUnPsUSpBapEhNHI4SldY=.452c9730-7048-43aa-9253-36797ecc6e09@github.com>
References: <btbf6MorZ7rEPf0UQBMVMeiUnPsUSpBapEhNHI4SldY=.452c9730-7048-43aa-9253-36797ecc6e09@github.com>
Message-ID: <_FC-WFqdRik4X5-TqwcpV4-T-F507RyufWE_zB8u_fs=.72fd6dc2-97d9-4860-942d-8641a90abffd@github.com>
On Mon, 14 Oct 2024 19:20:08 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:
> `ShenandoahMarkUpdateRefsSuperClosure` has only one real subclass, which is used in STW mark. We can collapse the class hierarchy a bit here.
>
> Additional testing:
> - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`
Thanks!
-------------
PR Comment: https://git.openjdk.org/jdk/pull/21505#issuecomment-2415922052
From shade at openjdk.org Wed Oct 16 07:16:14 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 16 Oct 2024 07:16:14 GMT
Subject: Integrated: 8342081: Shenandoah: Remove extra
ShenandoahMarkUpdateRefsSuperClosure
In-Reply-To: <btbf6MorZ7rEPf0UQBMVMeiUnPsUSpBapEhNHI4SldY=.452c9730-7048-43aa-9253-36797ecc6e09@github.com>
References: <btbf6MorZ7rEPf0UQBMVMeiUnPsUSpBapEhNHI4SldY=.452c9730-7048-43aa-9253-36797ecc6e09@github.com>
Message-ID: <OLjaU7drwUVXwnx_ThPJSN72QzPak4b3Ep0oDHOCepc=.ec4aea67-b22e-478f-9869-f53e0c933293@github.com>
On Mon, 14 Oct 2024 19:20:08 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:
> `ShenandoahMarkUpdateRefsSuperClosure` has only one real subclass, which is used in STW mark. We can collapse the class hierarchy a bit here.
>
> Additional testing:
> - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`
This pull request has now been integrated.
Changeset: 724de682
Author: Aleksey Shipilev <shade at openjdk.org>
URL: https://git.openjdk.org/jdk/commit/724de682091623cd9877ee4e5f13123ef1d92ddf
Stats: 22 lines in 2 files changed: 2 ins; 11 del; 9 mod
8342081: Shenandoah: Remove extra ShenandoahMarkUpdateRefsSuperClosure
Reviewed-by: ysr
-------------
PR: https://git.openjdk.org/jdk/pull/21505
From tschatzl at openjdk.org Wed Oct 16 07:30:22 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 16 Oct 2024 07:30:22 GMT
Subject: RFR: 8334010: VM crashes with ObjectAlignmentInBytes >
GCCardSizeInBytes [v2]
In-Reply-To: <BfkGjfvuR2lRvqsS4yxkuoICztHQtsc4rDYdEOHYij4=.26052f2e-5c25-4077-b8a3-29adab732863@github.com>
References: <zLptHq5hWMLcfhdYeJf5xYwePc10eKirOiJMoo7IqUA=.2240942e-d385-445b-9b19-0b3df1ae42af@github.com>
<WDnAHTfkILVjxS09P-DgoqNPuvDOrkel7txfhfzoRyc=.96ded868-a97b-4c86-9958-38e3558c2528@github.com>
<BfkGjfvuR2lRvqsS4yxkuoICztHQtsc4rDYdEOHYij4=.26052f2e-5c25-4077-b8a3-29adab732863@github.com>
Message-ID: <ILvE6Hj9jT2KhH8Zu66AsINykeEO5OsNYgZ7nhncBRU=.7fefc45f-06df-4e63-9356-2ae5a80e0bd0@github.com>
On Tue, 15 Oct 2024 08:57:59 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:
>> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
>>
>> * shade review
>
> Marked as reviewed by shade (Reviewer).
Thanks @shipilev @walulyai for your review
-------------
PR Comment: https://git.openjdk.org/jdk/pull/21515#issuecomment-2415945024
From tschatzl at openjdk.org Wed Oct 16 07:30:24 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 16 Oct 2024 07:30:24 GMT
Subject: Integrated: 8334010: VM crashes with ObjectAlignmentInBytes >
GCCardSizeInBytes
In-Reply-To: <zLptHq5hWMLcfhdYeJf5xYwePc10eKirOiJMoo7IqUA=.2240942e-d385-445b-9b19-0b3df1ae42af@github.com>
References: <zLptHq5hWMLcfhdYeJf5xYwePc10eKirOiJMoo7IqUA=.2240942e-d385-445b-9b19-0b3df1ae42af@github.com>
Message-ID: <0XB2WRVQ36ZyjG6QjHT8yjfVN5ili6aNALPbSxsQSdU=.3570b0d4-3540-41ed-adfb-92ba5704c4d8@github.com>
On Tue, 15 Oct 2024 08:10:09 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:
> Hi all,
>
> please review this change that makes VM initialization reject invalid combinations of `ObjectAlignmentInBytes` and `GCCardSizeInBytes`.
>
> ObjectAlignmentInBytes larger than GCCardSizeInBytes causes issues with setting correct BOT offsets.
>
> Testing: new test case, gha
>
> Hth,
> Thomas
This pull request has now been integrated.
Changeset: 577babf1
Author: Thomas Schatzl <tschatzl at openjdk.org>
URL: https://git.openjdk.org/jdk/commit/577babf1968700e4b648305cd5a5c2ddf712e2dc
Stats: 71 lines in 2 files changed: 71 ins; 0 del; 0 mod
8334010: VM crashes with ObjectAlignmentInBytes > GCCardSizeInBytes
Reviewed-by: shade, iwalulya
-------------
PR: https://git.openjdk.org/jdk/pull/21515
From kbarrett at openjdk.org Wed Oct 16 07:39:13 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 16 Oct 2024 07:39:13 GMT
Subject: RFR: 8342102: ZGC: Optimize copy constructors in ZPhysicalMemory
In-Reply-To: <aA4UlL9DOb01b0m3jgCgjMlnP1UgYsFW_owKGCXiObI=.6a686bb4-bf8b-41af-a32e-3c5648968f93@github.com>
References: <5hvFKET_jLREXmQcM1LygpEEnBuYzIV5fOXXajE-OEk=.7625a7a0-2cbf-4f0b-a7c9-b772f20599f7@github.com>
<ta6zbRYmO_E7y0gp12TOcJ0jW0xUpFRlGq2I8PFYj6U=.73cff617-1706-47e9-b4fe-aa86f94f5f66@github.com>
<aA4UlL9DOb01b0m3jgCgjMlnP1UgYsFW_owKGCXiObI=.6a686bb4-bf8b-41af-a32e-3c5648968f93@github.com>
Message-ID: <cQllMJwDY4dXVRjFV4rHBVrwRJ20AhsqPmT_rRcJiW4=.694dae1a-329f-428b-8417-620b4330b3b0@github.com>
On Wed, 16 Oct 2024 05:23:02 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:
>> src/hotspot/share/gc/z/zPhysicalMemory.cpp line 58:
>>
>>> 56:
>>> 57: const ZPhysicalMemory& ZPhysicalMemory::operator=(const ZPhysicalMemory& pmem) {
>>> 58: // Free and copy segments
>>
>> pre-existing: Seems like this ought to be checking for self-assign. I'd be okay with asserting against, even
>> though that's often frowned on in various writings on the subject.
>
> Checking and returning `*this` seems fine to me. Seems like the least surprising solution.
>
> The copy assignment operator is currently only ever used in a gtest.
Agreed that checking, and returning `*this` is the preferable way to handle it. I offered the assert option in
case there was some concern about doing that.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/21523#discussion_r1802522498
From jsikstro at openjdk.org Wed Oct 16 08:29:48 2024
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 16 Oct 2024 08:29:48 GMT
Subject: RFR: 8342102: ZGC: Optimize copy constructors in ZPhysicalMemory
[v2]
In-Reply-To: <5hvFKET_jLREXmQcM1LygpEEnBuYzIV5fOXXajE-OEk=.7625a7a0-2cbf-4f0b-a7c9-b772f20599f7@github.com>
References: <5hvFKET_jLREXmQcM1LygpEEnBuYzIV5fOXXajE-OEk=.7625a7a0-2cbf-4f0b-a7c9-b772f20599f7@github.com>
Message-ID: <bjfAiew622Vyz2arQQk6boW3NrS-KqRgOdIB8raTlGw=.35abe8ad-ecdb-4eba-8ba4-c86a22c90e86@github.com>
> ZPhysicalMemory stores a sorted array of physical memory segments. Segments are added using either add_segments or add_segment, where the former calls add_segment on each individual segment. add_segment inserts segments in address order and also merges segments when possible.
>
> When copying an instance of ZPhysicalMemory, segments are currently copied using either add_segments or add_segment, which works as described above. This requires more work than necessary and should be simplified to account for the fact that the array of segments is always sorted.
>
> When copying, the copy constructors should instead use append or appendAll from the underlying GrowableArrayCHeap and also reserve enough memory so that the array's capacity is not increased more times than necessary during copying.
>
> Tested with tiers 1-3.
Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
Add check for self-assignment
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/21523/files
- new: https://git.openjdk.org/jdk/pull/21523/files/4bb84663..dedc1e0c
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=21523&range=01
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=21523&range=00-01
Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod
Patch: https://git.openjdk.org/jdk/pull/21523.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/21523/head:pull/21523
PR: https://git.openjdk.org/jdk/pull/21523
From aboldtch at openjdk.org Wed Oct 16 08:29:48 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 16 Oct 2024 08:29:48 GMT
Subject: RFR: 8342102: ZGC: Optimize copy constructors in ZPhysicalMemory
[v2]
In-Reply-To: <bjfAiew622Vyz2arQQk6boW3NrS-KqRgOdIB8raTlGw=.35abe8ad-ecdb-4eba-8ba4-c86a22c90e86@github.com>
References: <5hvFKET_jLREXmQcM1LygpEEnBuYzIV5fOXXajE-OEk=.7625a7a0-2cbf-4f0b-a7c9-b772f20599f7@github.com>
<bjfAiew622Vyz2arQQk6boW3NrS-KqRgOdIB8raTlGw=.35abe8ad-ecdb-4eba-8ba4-c86a22c90e86@github.com>
Message-ID: <D0iFuuLyJFmuikU0n7S_h62rh9M_iD4esWwlA9cJSfM=.559ef5a4-711e-41ef-8143-7e9789cd228e@github.com>
On Wed, 16 Oct 2024 08:26:55 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:
>> ZPhysicalMemory stores a sorted array of physical memory segments. Segments are added using either add_segments or add_segment, where the former calls add_segment on each individual segment. add_segment inserts segments in address order and also merges segments when possible.
>>
>> When copying an instance of ZPhysicalMemory, segments are currently copied using either add_segments or add_segment, which works as described above. This requires more work than necessary and should be simplified to account for the fact that the array of segments is always sorted.
>>
>> When copying, the copy constructors should instead use append or appendAll from the underlying GrowableArrayCHeap and also reserve enough memory so that the array's capacity is not increased more times than necessary during copying.
>>
>> Tested with tiers 1-3.
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
>
> Add check for self-assignment
lgtm.
-------------
Marked as reviewed by aboldtch (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/21523#pullrequestreview-2371602750
From jsikstro at openjdk.org Wed Oct 16 08:29:48 2024
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 16 Oct 2024 08:29:48 GMT
Subject: RFR: 8342102: ZGC: Optimize copy constructors in ZPhysicalMemory
[v2]
In-Reply-To: <cQllMJwDY4dXVRjFV4rHBVrwRJ20AhsqPmT_rRcJiW4=.694dae1a-329f-428b-8417-620b4330b3b0@github.com>
References: <5hvFKET_jLREXmQcM1LygpEEnBuYzIV5fOXXajE-OEk=.7625a7a0-2cbf-4f0b-a7c9-b772f20599f7@github.com>
<ta6zbRYmO_E7y0gp12TOcJ0jW0xUpFRlGq2I8PFYj6U=.73cff617-1706-47e9-b4fe-aa86f94f5f66@github.com>
<aA4UlL9DOb01b0m3jgCgjMlnP1UgYsFW_owKGCXiObI=.6a686bb4-bf8b-41af-a32e-3c5648968f93@github.com>
<cQllMJwDY4dXVRjFV4rHBVrwRJ20AhsqPmT_rRcJiW4=.694dae1a-329f-428b-8417-620b4330b3b0@github.com>
Message-ID: <YB_iVkf52ujCkAZgbSV9SMu81_KSpS2xNzxr324XGmo=.57336493-f9f8-469b-806e-71a4f887f3d7@github.com>
On Wed, 16 Oct 2024 07:36:54 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:
>> Checking and returning `*this` seems fine to me. Seems like the least surprising solution.
>>
>> The copy assignment operator is currently only ever used in a gtest.
>
> Agreed that checking, and returning `*this` is the preferable way to handle it. I offered the assert option in
> case there was some concern about doing that.
I've added a self-assignment check in a new commit.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/21523#discussion_r1802600353
From iwalulya at openjdk.org Wed Oct 16 08:51:21 2024
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Wed, 16 Oct 2024 08:51:21 GMT
Subject: RFR: 8342329: G1: Rename
G1HeapRegionManager::_allocated_heapregions_length
Message-ID: <hfOPnyp8w89EMp02oTxVY7odheEkxtYNWMytSHclrdM=.750dcaa9-36a2-486d-bd87-33c62436b53c@github.com>
Hi,
Please review the refactor rename of G1HeapRegionManager::_allocated_heapregions_length to G1HeapRegionManager::_next_highest_used_hrm_index which better reflects the purpose of the field.
-------------
Commit messages:
- init
Changes: https://git.openjdk.org/jdk/pull/21530/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21530&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8342329
Stats: 21 lines in 2 files changed: 0 ins; 0 del; 21 mod
Patch: https://git.openjdk.org/jdk/pull/21530.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/21530/head:pull/21530
PR: https://git.openjdk.org/jdk/pull/21530
From rkennke at openjdk.org Wed Oct 16 09:01:34 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 16 Oct 2024 09:01:34 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v42]
In-Reply-To: <zsXCn2nynPEIqUg3XFoI_UV_VUoIGyEmvPr2nRwkUiQ=.a3ff867d-cdb3-4a2a-bbcd-69065e3739bb@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<5x48SX55xY_BRxqqcTTvGp_ocrKDH7t5VuJY-MDQuTA=.eed6083d-e2dc-4888-a2d5-b6934f098289@github.com>
<zsXCn2nynPEIqUg3XFoI_UV_VUoIGyEmvPr2nRwkUiQ=.a3ff867d-cdb3-4a2a-bbcd-69065e3739bb@github.com>
Message-ID: <9pMfQtqoAkkOP0pYjYrqozV1umS5A-BYo2a0GsNcihA=.7779b1c5-993c-4c60-9b65-31fb3c57e659@github.com>
On Tue, 15 Oct 2024 21:30:13 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:
>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>>
>> Fix aarch64.ad
>
> src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 414:
>
>> 412: // to the valid haystack bytes on the stack.
>> 413: {
>> 414: const Register haystack = rbx;
>
> Keep `rax` as index for clarity? Although it is really used as a temp..
>
>
> const Register index = rax;
> const Register haystack = rbx;
> copy_to_stack(haystack, haystack_len, false, index , XMM_TMP1, _masm);
I'll use rax as tmp, then.
const Register tmp = rax;
const Register haystack = rbx;
copy_to_stack(haystack, haystack_len, false, tmp , XMM_TMP1, _masm);
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1802659159
From rkennke at openjdk.org Wed Oct 16 09:05:32 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 16 Oct 2024 09:05:32 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v42]
In-Reply-To: <zsXCn2nynPEIqUg3XFoI_UV_VUoIGyEmvPr2nRwkUiQ=.a3ff867d-cdb3-4a2a-bbcd-69065e3739bb@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<5x48SX55xY_BRxqqcTTvGp_ocrKDH7t5VuJY-MDQuTA=.eed6083d-e2dc-4888-a2d5-b6934f098289@github.com>
<zsXCn2nynPEIqUg3XFoI_UV_VUoIGyEmvPr2nRwkUiQ=.a3ff867d-cdb3-4a2a-bbcd-69065e3739bb@github.com>
Message-ID: <vwaTIEUTS7HUI9kyrTATPU4rBNCkfdadecgfLxP6s3k=.f0f5ef80-dd3b-4511-9051-4918ba664f61@github.com>
On Tue, 15 Oct 2024 22:09:54 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:
>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>>
>> Fix aarch64.ad
>
> src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 1659:
>
>> 1657: Label L_moreThan8, L_moreThan16, L_moreThan24, L_adjustHaystack;
>> 1658:
>> 1659: assert(arrayOopDesc::base_offset_in_bytes(isU ? T_CHAR : T_BYTE) >= 8,
>
> If we had to also optimize for header-size 16, it might be possible to remove one jump here. Looks correct for either size.
Yeah. The old code optimized for header-size >= 16. But given that compact headers will soon become the default, I don't think it's worth optimizing for the old header layout.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1802665723
From rkennke at openjdk.org Wed Oct 16 09:16:36 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 16 Oct 2024 09:16:36 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v42]
In-Reply-To: <zsXCn2nynPEIqUg3XFoI_UV_VUoIGyEmvPr2nRwkUiQ=.a3ff867d-cdb3-4a2a-bbcd-69065e3739bb@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<5x48SX55xY_BRxqqcTTvGp_ocrKDH7t5VuJY-MDQuTA=.eed6083d-e2dc-4888-a2d5-b6934f098289@github.com>
<zsXCn2nynPEIqUg3XFoI_UV_VUoIGyEmvPr2nRwkUiQ=.a3ff867d-cdb3-4a2a-bbcd-69065e3739bb@github.com>
Message-ID: <0wbOnb32bfMQybp2M7vDrJpuTDCIrpKzvUy0KYGHtMU=.ec15027b-8a36-4402-ac33-330383d98e48@github.com>
On Tue, 15 Oct 2024 22:31:27 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:
>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>>
>> Fix aarch64.ad
>
> src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 1634:
>
>> 1632:
>> 1633:
>> 1634: // Copy the small (< 32 byte) haystack to the stack. Allows for vector reads without page fault
>
> Just to be pedantic, its `(<=32)` - this function also handles 32bytes case.
>
> - line 401:
>
> __ cmpq(haystack_len, 0x20);
> __ ja(L_bigSwitchTop);
>
> - though line 293 (`highly_optimized_short_cases`) only seems to route16-byte cases here:
> ```__ cmpq(haystack_len_p, isU ? 8 : 16);```
I am not sure what you are looking at, but line 293 reads:
__ cmpq(haystack_len_p, isU ? 16 : 32);
for me. IOW, it routes > 32 byte cases to `L_begin`. But the following cmp/ja also routes <= 32 byte cases there, when `needle_len > 6`.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1802694667
From rkennke at openjdk.org Wed Oct 16 09:31:12 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 16 Oct 2024 09:31:12 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v43]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <d8BYPKWeRrC0aK7WeqwXe2pphNUZRgqKf23s15leeNE=.8e8e13a2-5f2a-4ee5-86fb-beef1ea64555@github.com>
> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>
> Main changes:
> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
> - Arrays will now store their length at offset 8.
> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...
Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
Address comments by @vpaprotsk
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/20677/files
- new: https://git.openjdk.org/jdk/pull/20677/files/005498b1..1fd365df
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=42
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=41-42
Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod
Patch: https://git.openjdk.org/jdk/pull/20677.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677
PR: https://git.openjdk.org/jdk/pull/20677
From tschatzl at openjdk.org Wed Oct 16 09:48:10 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 16 Oct 2024 09:48:10 GMT
Subject: RFR: 8342329: G1: Rename
G1HeapRegionManager::_allocated_heapregions_length
In-Reply-To: <hfOPnyp8w89EMp02oTxVY7odheEkxtYNWMytSHclrdM=.750dcaa9-36a2-486d-bd87-33c62436b53c@github.com>
References: <hfOPnyp8w89EMp02oTxVY7odheEkxtYNWMytSHclrdM=.750dcaa9-36a2-486d-bd87-33c62436b53c@github.com>
Message-ID: <mU659W34HQ6RuzGJY36yoq8hqtt4ZE242KjangU80uA=.0df66800-cb2e-4c0a-9047-02d755ad1291@github.com>
On Wed, 16 Oct 2024 08:47:00 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:
> Hi,
>
> Please review the refactor rename of G1HeapRegionManager::_allocated_heapregions_length to G1HeapRegionManager::_next_highest_used_hrm_index which better reflects the purpose of the field.
Marked as reviewed by tschatzl (Reviewer).
-------------
PR Review: https://git.openjdk.org/jdk/pull/21530#pullrequestreview-2371857892
From shade at openjdk.org Wed Oct 16 10:01:10 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 16 Oct 2024 10:01:10 GMT
Subject: RFR: 8342329: G1: Rename
G1HeapRegionManager::_allocated_heapregions_length
In-Reply-To: <hfOPnyp8w89EMp02oTxVY7odheEkxtYNWMytSHclrdM=.750dcaa9-36a2-486d-bd87-33c62436b53c@github.com>
References: <hfOPnyp8w89EMp02oTxVY7odheEkxtYNWMytSHclrdM=.750dcaa9-36a2-486d-bd87-33c62436b53c@github.com>
Message-ID: <OhZTByjQRvltbItvhpbciSN65unTdk8WAeo2SOVRTmA=.6cf0720f-a39a-40e6-a6dc-2a0c6a3ff9f2@github.com>
On Wed, 16 Oct 2024 08:47:00 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:
> Hi,
>
> Please review the refactor rename of G1HeapRegionManager::_allocated_heapregions_length to G1HeapRegionManager::_next_highest_used_hrm_index which better reflects the purpose of the field.
Marked as reviewed by shade (Reviewer).
-------------
PR Review: https://git.openjdk.org/jdk/pull/21530#pullrequestreview-2371890112
From aboldtch at openjdk.org Wed Oct 16 12:01:14 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 16 Oct 2024 12:01:14 GMT
Subject: RFR: 8336911: ZGC: Division by zero in heuristics after
JDK-8332717 [v2]
In-Reply-To: <2OVE7gfBr7mpSgxO6FCoQIDfZqeFvufLta6KuVUFCoU=.460b937e-9852-4c0c-932e-06e6c6726016@github.com>
References: <rByxhEm3b3JZQVvugNz4KezLFPWc2NH_vOPaAl9Je2A=.703a5530-a302-43b2-a6bf-37f100c8bc79@github.com>
<2OVE7gfBr7mpSgxO6FCoQIDfZqeFvufLta6KuVUFCoU=.460b937e-9852-4c0c-932e-06e6c6726016@github.com>
Message-ID: <PhyV5OmbZq9vbaDhH86vcdifNve9dyUXbXU2qtUK02Q=.ed939078-5ec7-4dbb-9e48-263eb4e2fbcf@github.com>
On Wed, 9 Oct 2024 13:29:12 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:
>> When running with ubsan enabled binaries, the following issue is reported,
>> e.g. in test
>> compiler/uncommontrap/TestDeoptOOM_ZGenerational.jtr
>> also in gc/z/TestSmallHeap.jtr
>>
>>
>> jdk/src/hotspot/share/gc/z/zDirector.cpp:537:84: runtime error: division by zero
>> #0 0x7f422495bd1f in calculate_young_to_old_worker_ratio src/hotspot/share/gc/z/zDirector.cpp:537
>> #1 0x7f422495bd1f in select_worker_threads src/hotspot/share/gc/z/zDirector.cpp:694
>> #2 0x7f42282a0d97 in select_worker_threads src/hotspot/share/gc/z/zDirector.cpp:689
>> #3 0x7f42282a0d97 in initial_workers src/hotspot/share/gc/z/zDirector.cpp:784
>> #4 0x7f42282a2485 in initial_workers src/hotspot/share/gc/z/zDirector.cpp:795
>> #5 0x7f42282a2485 in start_minor_gc src/hotspot/share/gc/z/zDirector.cpp:797
>> #6 0x7f42282a2485 in start_gc src/hotspot/share/gc/z/zDirector.cpp:826
>> #7 0x7f42282a2485 in ZDirector::run_thread() src/hotspot/share/gc/z/zDirector.cpp:912
>> #8 0x7f422840bdd8 in ZThread::run_service() src/hotspot/share/gc/z/zThread.cpp:29
>> #9 0x7f4225ab6979 in ConcurrentGCThread::run() src/hotspot/share/gc/shared/concurrentGCThread.cpp:48
>> #10 0x7f4227e1137a in Thread::call_run() src/hotspot/share/runtime/thread.cpp:225
>> #11 0x7f42274619b1 in thread_native_entry src/hotspot/os/linux/os_linux.cpp:858
>> #12 0x7f422c8d36e9 in start_thread (/lib64/libpthread.so.0+0xa6e9) (BuildId: 9a146bd267419cb6a8cf08d7c602953a0f2e12c5)
>> #13 0x7f422c1dc58e in clone (/lib64/libc.so.6+0x11858e) (BuildId: f2d1cb1ef49f8c47d43a4053910ba6137673ccce)
>>
>>
>> The division by 0 leads to 'infinity' on most of our platforms. So instead of relying on this behavior, we can add a small check and set 'infinity' for divisor == 0.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>
> adjustment from xmas - Update src/hotspot/share/gc/z/zDirector.cpp
>
> Co-authored-by: Axel Boldt-Christmas <xmas1915 at gmail.com>
Marked as reviewed by aboldtch (Reviewer).
-------------
PR Review: https://git.openjdk.org/jdk/pull/21304#pullrequestreview-2372218118
From eosterlund at openjdk.org Wed Oct 16 12:01:14 2024
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Wed, 16 Oct 2024 12:01:14 GMT
Subject: RFR: 8336911: ZGC: Division by zero in heuristics after
JDK-8332717 [v2]
In-Reply-To: <2OVE7gfBr7mpSgxO6FCoQIDfZqeFvufLta6KuVUFCoU=.460b937e-9852-4c0c-932e-06e6c6726016@github.com>
References: <rByxhEm3b3JZQVvugNz4KezLFPWc2NH_vOPaAl9Je2A=.703a5530-a302-43b2-a6bf-37f100c8bc79@github.com>
<2OVE7gfBr7mpSgxO6FCoQIDfZqeFvufLta6KuVUFCoU=.460b937e-9852-4c0c-932e-06e6c6726016@github.com>
Message-ID: <5VjL_vftLwK0ue62WwFwh1S8_h4CdeIfX5k4YiEtCBQ=.6f1b45ab-fcf4-40e6-9217-752f1913f83d@github.com>
On Wed, 9 Oct 2024 13:29:12 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:
>> When running with ubsan enabled binaries, the following issue is reported,
>> e.g. in test
>> compiler/uncommontrap/TestDeoptOOM_ZGenerational.jtr
>> also in gc/z/TestSmallHeap.jtr
>>
>>
>> jdk/src/hotspot/share/gc/z/zDirector.cpp:537:84: runtime error: division by zero
>> #0 0x7f422495bd1f in calculate_young_to_old_worker_ratio src/hotspot/share/gc/z/zDirector.cpp:537
>> #1 0x7f422495bd1f in select_worker_threads src/hotspot/share/gc/z/zDirector.cpp:694
>> #2 0x7f42282a0d97 in select_worker_threads src/hotspot/share/gc/z/zDirector.cpp:689
>> #3 0x7f42282a0d97 in initial_workers src/hotspot/share/gc/z/zDirector.cpp:784
>> #4 0x7f42282a2485 in initial_workers src/hotspot/share/gc/z/zDirector.cpp:795
>> #5 0x7f42282a2485 in start_minor_gc src/hotspot/share/gc/z/zDirector.cpp:797
>> #6 0x7f42282a2485 in start_gc src/hotspot/share/gc/z/zDirector.cpp:826
>> #7 0x7f42282a2485 in ZDirector::run_thread() src/hotspot/share/gc/z/zDirector.cpp:912
>> #8 0x7f422840bdd8 in ZThread::run_service() src/hotspot/share/gc/z/zThread.cpp:29
>> #9 0x7f4225ab6979 in ConcurrentGCThread::run() src/hotspot/share/gc/shared/concurrentGCThread.cpp:48
>> #10 0x7f4227e1137a in Thread::call_run() src/hotspot/share/runtime/thread.cpp:225
>> #11 0x7f42274619b1 in thread_native_entry src/hotspot/os/linux/os_linux.cpp:858
>> #12 0x7f422c8d36e9 in start_thread (/lib64/libpthread.so.0+0xa6e9) (BuildId: 9a146bd267419cb6a8cf08d7c602953a0f2e12c5)
>> #13 0x7f422c1dc58e in clone (/lib64/libc.so.6+0x11858e) (BuildId: f2d1cb1ef49f8c47d43a4053910ba6137673ccce)
>>
>>
>> The division by 0 leads to 'infinity' on most of our platforms. So instead of relying on this behavior, we can add a small check and set 'infinity' for divisor == 0.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>
> adjustment from xmas - Update src/hotspot/share/gc/z/zDirector.cpp
>
> Co-authored-by: Axel Boldt-Christmas <xmas1915 at gmail.com>
I think in the end I'd like to sanitize the input data to all these calculations to have less zeros and hence divisions by zero. But we can do that as a separate cleanup. This change looks good to me.
-------------
Marked as reviewed by eosterlund (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/21304#pullrequestreview-2372219948
From coleenp at openjdk.org Wed Oct 16 12:16:34 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 16 Oct 2024 12:16:34 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v43]
In-Reply-To: <d8BYPKWeRrC0aK7WeqwXe2pphNUZRgqKf23s15leeNE=.8e8e13a2-5f2a-4ee5-86fb-beef1ea64555@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<d8BYPKWeRrC0aK7WeqwXe2pphNUZRgqKf23s15leeNE=.8e8e13a2-5f2a-4ee5-86fb-beef1ea64555@github.com>
Message-ID: <XDTAUAApVTM7iZAGsuosoHPDcEf5NH6rO4JPm1W-YjA=.7cf382e3-f9ca-4d2a-b22e-81f003da88b7@github.com>
On Wed, 16 Oct 2024 09:31:12 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>>
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>>
>> Main changes:
>> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>> - Arrays will now store their length at offset 8.
>> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>
> Address comments by @vpaprotsk
We're seeing failures in our nightly testing for tests runtime/cds/appcds/SharedBaseAddress.java and runtime/cds/SharedBaseAddress.java which I'm tracking in this bug [JDK-8340212](https://bugs.openjdk.org/browse/JDK-8340212)
This patch should problem list these two tests on aarch64 when UseCompactObjectHeaders is on (if possible to be that specific), or just plain problem list it until I have a fix for it.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2416647209
From duke at openjdk.org Wed Oct 16 13:21:14 2024
From: duke at openjdk.org (Abdelhak Zaaim)
Date: Wed, 16 Oct 2024 13:21:14 GMT
Subject: RFR: 8342102: ZGC: Optimize copy constructors in ZPhysicalMemory
[v2]
In-Reply-To: <bjfAiew622Vyz2arQQk6boW3NrS-KqRgOdIB8raTlGw=.35abe8ad-ecdb-4eba-8ba4-c86a22c90e86@github.com>
References: <5hvFKET_jLREXmQcM1LygpEEnBuYzIV5fOXXajE-OEk=.7625a7a0-2cbf-4f0b-a7c9-b772f20599f7@github.com>
<bjfAiew622Vyz2arQQk6boW3NrS-KqRgOdIB8raTlGw=.35abe8ad-ecdb-4eba-8ba4-c86a22c90e86@github.com>
Message-ID: <gZFEJR2JqOqMunukWeCUqlB8WaowN5D5Klj5wcB8G_Q=.a831efce-3f0f-480e-9034-9e3b382425f8@github.com>
On Wed, 16 Oct 2024 08:29:48 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:
>> ZPhysicalMemory stores a sorted array of physical memory segments. Segments are added using either add_segments or add_segment, where the former calls add_segment on each individual segment. add_segment inserts segments in address order and also merges segments when possible.
>>
>> When copying an instance of ZPhysicalMemory, segments are currently copied using either add_segments or add_segment, which works as described above. This requires more work than necessary and should be simplified to account for the fact that the array of segments is always sorted.
>>
>> When copying, the copy constructors should instead use append or appendAll from the underlying GrowableArrayCHeap and also reserve enough memory so that the array's capacity is not increased more times than necessary during copying.
>>
>> Tested with tiers 1-3.
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
>
> Add check for self-assignment
looks good to me
-------------
Marked as reviewed by abdelhak-zaaim at github.com (no known OpenJDK username).
PR Review: https://git.openjdk.org/jdk/pull/21523#pullrequestreview-2372448788
From mbaesken at openjdk.org Wed Oct 16 13:40:23 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 16 Oct 2024 13:40:23 GMT
Subject: RFR: 8336911: ZGC: Division by zero in heuristics after
JDK-8332717 [v2]
In-Reply-To: <2OVE7gfBr7mpSgxO6FCoQIDfZqeFvufLta6KuVUFCoU=.460b937e-9852-4c0c-932e-06e6c6726016@github.com>
References: <rByxhEm3b3JZQVvugNz4KezLFPWc2NH_vOPaAl9Je2A=.703a5530-a302-43b2-a6bf-37f100c8bc79@github.com>
<2OVE7gfBr7mpSgxO6FCoQIDfZqeFvufLta6KuVUFCoU=.460b937e-9852-4c0c-932e-06e6c6726016@github.com>
Message-ID: <eou-pp0LI5H_EMl6ruzxXHZ9OhXCYW9RPp8MYa7rXyM=.4b726847-d83c-4a31-b492-9c90326533cd@github.com>
On Wed, 9 Oct 2024 13:29:12 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:
>> When running with ubsan enabled binaries, the following issue is reported,
>> e.g. in test
>> compiler/uncommontrap/TestDeoptOOM_ZGenerational.jtr
>> also in gc/z/TestSmallHeap.jtr
>>
>>
>> jdk/src/hotspot/share/gc/z/zDirector.cpp:537:84: runtime error: division by zero
>> #0 0x7f422495bd1f in calculate_young_to_old_worker_ratio src/hotspot/share/gc/z/zDirector.cpp:537
>> #1 0x7f422495bd1f in select_worker_threads src/hotspot/share/gc/z/zDirector.cpp:694
>> #2 0x7f42282a0d97 in select_worker_threads src/hotspot/share/gc/z/zDirector.cpp:689
>> #3 0x7f42282a0d97 in initial_workers src/hotspot/share/gc/z/zDirector.cpp:784
>> #4 0x7f42282a2485 in initial_workers src/hotspot/share/gc/z/zDirector.cpp:795
>> #5 0x7f42282a2485 in start_minor_gc src/hotspot/share/gc/z/zDirector.cpp:797
>> #6 0x7f42282a2485 in start_gc src/hotspot/share/gc/z/zDirector.cpp:826
>> #7 0x7f42282a2485 in ZDirector::run_thread() src/hotspot/share/gc/z/zDirector.cpp:912
>> #8 0x7f422840bdd8 in ZThread::run_service() src/hotspot/share/gc/z/zThread.cpp:29
>> #9 0x7f4225ab6979 in ConcurrentGCThread::run() src/hotspot/share/gc/shared/concurrentGCThread.cpp:48
>> #10 0x7f4227e1137a in Thread::call_run() src/hotspot/share/runtime/thread.cpp:225
>> #11 0x7f42274619b1 in thread_native_entry src/hotspot/os/linux/os_linux.cpp:858
>> #12 0x7f422c8d36e9 in start_thread (/lib64/libpthread.so.0+0xa6e9) (BuildId: 9a146bd267419cb6a8cf08d7c602953a0f2e12c5)
>> #13 0x7f422c1dc58e in clone (/lib64/libc.so.6+0x11858e) (BuildId: f2d1cb1ef49f8c47d43a4053910ba6137673ccce)
>>
>>
>> The division by 0 leads to 'infinity' on most of our platforms. So instead of relying on this behavior, we can add a small check and set 'infinity' for divisor == 0.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>
> adjustment from xmas - Update src/hotspot/share/gc/z/zDirector.cpp
>
> Co-authored-by: Axel Boldt-Christmas <xmas1915 at gmail.com>
Thanks for the reviews !
-------------
PR Comment: https://git.openjdk.org/jdk/pull/21304#issuecomment-2416861985
From mbaesken at openjdk.org Wed Oct 16 13:40:23 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 16 Oct 2024 13:40:23 GMT
Subject: Integrated: 8336911: ZGC: Division by zero in heuristics after
JDK-8332717
In-Reply-To: <rByxhEm3b3JZQVvugNz4KezLFPWc2NH_vOPaAl9Je2A=.703a5530-a302-43b2-a6bf-37f100c8bc79@github.com>
References: <rByxhEm3b3JZQVvugNz4KezLFPWc2NH_vOPaAl9Je2A=.703a5530-a302-43b2-a6bf-37f100c8bc79@github.com>
Message-ID: <eNmUSc1Wn9RA3-eIxKS0P1tuu__QClvZTIGAERb6Kto=.4a9268ac-8862-47e7-bd68-d43c3b68b0bc@github.com>
On Wed, 2 Oct 2024 12:00:19 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:
> When running with ubsan enabled binaries, the following issue is reported,
> e.g. in test
> compiler/uncommontrap/TestDeoptOOM_ZGenerational.jtr
> also in gc/z/TestSmallHeap.jtr
>
>
> jdk/src/hotspot/share/gc/z/zDirector.cpp:537:84: runtime error: division by zero
> #0 0x7f422495bd1f in calculate_young_to_old_worker_ratio src/hotspot/share/gc/z/zDirector.cpp:537
> #1 0x7f422495bd1f in select_worker_threads src/hotspot/share/gc/z/zDirector.cpp:694
> #2 0x7f42282a0d97 in select_worker_threads src/hotspot/share/gc/z/zDirector.cpp:689
> #3 0x7f42282a0d97 in initial_workers src/hotspot/share/gc/z/zDirector.cpp:784
> #4 0x7f42282a2485 in initial_workers src/hotspot/share/gc/z/zDirector.cpp:795
> #5 0x7f42282a2485 in start_minor_gc src/hotspot/share/gc/z/zDirector.cpp:797
> #6 0x7f42282a2485 in start_gc src/hotspot/share/gc/z/zDirector.cpp:826
> #7 0x7f42282a2485 in ZDirector::run_thread() src/hotspot/share/gc/z/zDirector.cpp:912
> #8 0x7f422840bdd8 in ZThread::run_service() src/hotspot/share/gc/z/zThread.cpp:29
> #9 0x7f4225ab6979 in ConcurrentGCThread::run() src/hotspot/share/gc/shared/concurrentGCThread.cpp:48
> #10 0x7f4227e1137a in Thread::call_run() src/hotspot/share/runtime/thread.cpp:225
> #11 0x7f42274619b1 in thread_native_entry src/hotspot/os/linux/os_linux.cpp:858
> #12 0x7f422c8d36e9 in start_thread (/lib64/libpthread.so.0+0xa6e9) (BuildId: 9a146bd267419cb6a8cf08d7c602953a0f2e12c5)
> #13 0x7f422c1dc58e in clone (/lib64/libc.so.6+0x11858e) (BuildId: f2d1cb1ef49f8c47d43a4053910ba6137673ccce)
>
>
> The division by 0 leads to 'infinity' on most of our platforms. So instead of relying on this behavior, we can add a small check and set 'infinity' for divisor == 0.
This pull request has now been integrated.
Changeset: 1cc32237
Author: Matthias Baesken <mbaesken at openjdk.org>
URL: https://git.openjdk.org/jdk/commit/1cc32237aee03a38bfb0f6679f7328a682ad6ea9
Stats: 13 lines in 1 file changed: 13 ins; 0 del; 0 mod
8336911: ZGC: Division by zero in heuristics after JDK-8332717
Reviewed-by: aboldtch, eosterlund
-------------
PR: https://git.openjdk.org/jdk/pull/21304
From rkennke at openjdk.org Wed Oct 16 13:46:24 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 16 Oct 2024 13:46:24 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v44]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <logRSsOv-ZbKrosBAddqiXOOAcr-tMODEDmGksY6uJs=.ee83f2c3-2b57-41f5-b9f4-9b36811ced37@github.com>
> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>
> Main changes:
> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
> - Arrays will now store their length at offset 8.
> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...
Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
Problem-list SharedBaseAddress tests on aarch64
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/20677/files
- new: https://git.openjdk.org/jdk/pull/20677/files/1fd365df..ec42f4d6
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=43
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=42-43
Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod
Patch: https://git.openjdk.org/jdk/pull/20677.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677
PR: https://git.openjdk.org/jdk/pull/20677
From rkennke at openjdk.org Wed Oct 16 13:46:25 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 16 Oct 2024 13:46:25 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v43]
In-Reply-To: <XDTAUAApVTM7iZAGsuosoHPDcEf5NH6rO4JPm1W-YjA=.7cf382e3-f9ca-4d2a-b22e-81f003da88b7@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<d8BYPKWeRrC0aK7WeqwXe2pphNUZRgqKf23s15leeNE=.8e8e13a2-5f2a-4ee5-86fb-beef1ea64555@github.com>
<XDTAUAApVTM7iZAGsuosoHPDcEf5NH6rO4JPm1W-YjA=.7cf382e3-f9ca-4d2a-b22e-81f003da88b7@github.com>
Message-ID: <-8DXPgoraRNtE7uJw-Pdk5Z3eJAzIbhVRJOX5JH85UY=.358823f0-a30f-4994-b566-cdf064eac8f0@github.com>
On Wed, 16 Oct 2024 12:13:32 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:
> We're seeing failures in our nightly testing for tests runtime/cds/appcds/SharedBaseAddress.java and runtime/cds/SharedBaseAddress.java which I'm tracking in this bug [JDK-8340212](https://bugs.openjdk.org/browse/JDK-8340212)
>
> This patch should problem list these two tests on aarch64 when UseCompactObjectHeaders is on (if possible to be that specific), or just plain problem list it until I have a fix for it.
Thanks for pointing this out. I've problem-listed both tests on aarch64.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2416881886
From ivan.walulya at oracle.com Wed Oct 16 14:21:01 2024
From: ivan.walulya at oracle.com (Ivan Walulya)
Date: Wed, 16 Oct 2024 14:21:01 +0000
Subject: RFC: JEP: Reduce Latency of G1 Post-Write Barrier
Message-ID: <9EE743BA-EB83-49AD-80E7-F72A2929B8A1@oracle.com>
Hi,
We have written a draft JEP for reducing the latency of G1 write barriers.
JEP description is available here: https://bugs.openjdk.org/browse/JDK-8340827
Comments and feedback are welcome.
Kind Regards,
Ivan
From tschatzl at openjdk.org Wed Oct 16 14:40:38 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 16 Oct 2024 14:40:38 GMT
Subject: RFR: 8340389:
vmTestbase/gc/gctests/PhantomReference/phantom001/TestDescription.java Test
exit code: 97 with -Xcomp UseAVX=3
Message-ID: <XV6xPNGzGAzTREFF1ZOaeVpQXWRfb4tOStZbWnuAm2M=.3c35b874-385e-4996-a3fa-7f687ebbf491@github.com>
Hi all,
please review this fix to the phantom001 test to do much less garbage collections that inhibit passing the test.
Testing: gha, running the test with and without the change for 500 times with the problematic options - fails 379 times without the change, passes all runs with the change.
Thanks,
Thomas
-------------
Commit messages:
- 8340389
Changes: https://git.openjdk.org/jdk/pull/21538/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21538&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8340389
Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod
Patch: https://git.openjdk.org/jdk/pull/21538.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/21538/head:pull/21538
PR: https://git.openjdk.org/jdk/pull/21538
From shade at openjdk.org Wed Oct 16 14:49:14 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 16 Oct 2024 14:49:14 GMT
Subject: RFR: 8340389:
vmTestbase/gc/gctests/PhantomReference/phantom001/TestDescription.java Test
exit code: 97 with -Xcomp UseAVX=3
In-Reply-To: <XV6xPNGzGAzTREFF1ZOaeVpQXWRfb4tOStZbWnuAm2M=.3c35b874-385e-4996-a3fa-7f687ebbf491@github.com>
References: <XV6xPNGzGAzTREFF1ZOaeVpQXWRfb4tOStZbWnuAm2M=.3c35b874-385e-4996-a3fa-7f687ebbf491@github.com>
Message-ID: <1N_0sCDxxs1g0tEIpilYfnIrSlLbnRJH1afSs9R4vjU=.63e89eff-bc77-45d4-94da-65b1e4150b3a@github.com>
On Wed, 16 Oct 2024 14:18:24 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:
> Hi all,
>
> please review this fix to the phantom001 test to do much less garbage collections that inhibit passing the test.
>
> Testing: gha, running the test with and without the change for 500 times with the problematic options - fails 379 times without the change, passes all runs with the change.
>
> Thanks,
> Thomas
There is a comment a few lines above:
// There are scenarios where one WB.fillGC() isn't enough,
// but 10 iterations really ought to be sufficient.
Do you know what that is about?
-------------
PR Review: https://git.openjdk.org/jdk/pull/21538#pullrequestreview-2372738944
From shade at openjdk.org Wed Oct 16 15:01:48 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 16 Oct 2024 15:01:48 GMT
Subject: RFR: 8340389:
vmTestbase/gc/gctests/PhantomReference/phantom001/TestDescription.java Test
exit code: 97 with -Xcomp UseAVX=3 [v2]
In-Reply-To: <4n8ubErTv7IpzJfTFG-80BPm9WLTKBtMBo6kWrkw6pw=.c5f0d039-78f3-485f-aaa9-50b7a18f1e35@github.com>
References: <XV6xPNGzGAzTREFF1ZOaeVpQXWRfb4tOStZbWnuAm2M=.3c35b874-385e-4996-a3fa-7f687ebbf491@github.com>
<4n8ubErTv7IpzJfTFG-80BPm9WLTKBtMBo6kWrkw6pw=.c5f0d039-78f3-485f-aaa9-50b7a18f1e35@github.com>
Message-ID: <vyuzwuSL_7nGwbkRLYCJDBlZqQMvKxhjlBe0PFbMo1Y=.3798284c-76e3-4402-9a91-b44696c838d8@github.com>
On Wed, 16 Oct 2024 14:58:19 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:
>> Hi all,
>>
>> please review this fix to the phantom001 test to do much less garbage collections that inhibit passing the test.
>>
>> Testing: gha, running the test with and without the change for 500 times with the problematic options - fails 379 times without the change, passes all runs with the change.
>>
>> Thanks,
>> Thomas
>
> Thomas Schatzl has updated the pull request incrementally with two additional commits since the last revision:
>
> - * more comment update
> - * fix comment
OK then, thanks!
-------------
Marked as reviewed by shade (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/21538#pullrequestreview-2372772897
From tschatzl at openjdk.org Wed Oct 16 15:01:48 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 16 Oct 2024 15:01:48 GMT
Subject: RFR: 8340389:
vmTestbase/gc/gctests/PhantomReference/phantom001/TestDescription.java Test
exit code: 97 with -Xcomp UseAVX=3 [v2]
In-Reply-To: <XV6xPNGzGAzTREFF1ZOaeVpQXWRfb4tOStZbWnuAm2M=.3c35b874-385e-4996-a3fa-7f687ebbf491@github.com>
References: <XV6xPNGzGAzTREFF1ZOaeVpQXWRfb4tOStZbWnuAm2M=.3c35b874-385e-4996-a3fa-7f687ebbf491@github.com>
Message-ID: <4n8ubErTv7IpzJfTFG-80BPm9WLTKBtMBo6kWrkw6pw=.c5f0d039-78f3-485f-aaa9-50b7a18f1e35@github.com>
> Hi all,
>
> please review this fix to the phantom001 test to do much less garbage collections that inhibit passing the test.
>
> Testing: gha, running the test with and without the change for 500 times with the problematic options - fails 379 times without the change, passes all runs with the change.
>
> Thanks,
> Thomas
Thomas Schatzl has updated the pull request incrementally with two additional commits since the last revision:
- * more comment update
- * fix comment
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/21538/files
- new: https://git.openjdk.org/jdk/pull/21538/files/5327996b..2c707769
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=21538&range=01
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=21538&range=00-01
Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
Patch: https://git.openjdk.org/jdk/pull/21538.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/21538/head:pull/21538
PR: https://git.openjdk.org/jdk/pull/21538
From tschatzl at openjdk.org Wed Oct 16 15:01:48 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 16 Oct 2024 15:01:48 GMT
Subject: RFR: 8340389:
vmTestbase/gc/gctests/PhantomReference/phantom001/TestDescription.java Test
exit code: 97 with -Xcomp UseAVX=3 [v2]
In-Reply-To: <1N_0sCDxxs1g0tEIpilYfnIrSlLbnRJH1afSs9R4vjU=.63e89eff-bc77-45d4-94da-65b1e4150b3a@github.com>
References: <XV6xPNGzGAzTREFF1ZOaeVpQXWRfb4tOStZbWnuAm2M=.3c35b874-385e-4996-a3fa-7f687ebbf491@github.com>
<1N_0sCDxxs1g0tEIpilYfnIrSlLbnRJH1afSs9R4vjU=.63e89eff-bc77-45d4-94da-65b1e4150b3a@github.com>
Message-ID: <f9ZPkd2sa26j3p5dUiKE9JKgZ8AA_Y_OfkGyqLpGaOw=.45738ba7-4e6c-4226-aa07-3ddaf87f9fa3@github.com>
On Wed, 16 Oct 2024 14:46:40 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:
> There is a comment a few lines above:
>
> ```
> // There are scenarios where one WB.fillGC() isn't enough,
> // but 10 iterations really ought to be sufficient.
> ```
>
> Do you know what that is about?
This is a renmant of the original change that forced a full gc every iteration. This is not necessary, the object should be finalizable after the first full gc already. That is, the comment is wrong. However we might need to wait a bit until the finalizer actually executes. I updated the comment.
I did not try optimizing the maximum wait time.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/21538#issuecomment-2417079265
From shade at openjdk.org Wed Oct 16 15:05:10 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 16 Oct 2024 15:05:10 GMT
Subject: RFR: 8340389:
vmTestbase/gc/gctests/PhantomReference/phantom001/TestDescription.java Test
exit code: 97 with -Xcomp UseAVX=3 [v2]
In-Reply-To: <4n8ubErTv7IpzJfTFG-80BPm9WLTKBtMBo6kWrkw6pw=.c5f0d039-78f3-485f-aaa9-50b7a18f1e35@github.com>
References: <XV6xPNGzGAzTREFF1ZOaeVpQXWRfb4tOStZbWnuAm2M=.3c35b874-385e-4996-a3fa-7f687ebbf491@github.com>
<4n8ubErTv7IpzJfTFG-80BPm9WLTKBtMBo6kWrkw6pw=.c5f0d039-78f3-485f-aaa9-50b7a18f1e35@github.com>
Message-ID: <8CW4GA9Rdlw0QJu_PpRpnBYsCTTp3drG4IAWzsLX6dE=.890f5136-43f2-4d84-86cf-79bc3d116158@github.com>
On Wed, 16 Oct 2024 15:01:48 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:
>> Hi all,
>>
>> please review this fix to the phantom001 test to do much less garbage collections that inhibit passing the test.
>>
>> Testing: gha, running the test with and without the change for 500 times with the problematic options - fails 379 times without the change, passes all runs with the change.
>>
>> Thanks,
>> Thomas
>
> Thomas Schatzl has updated the pull request incrementally with two additional commits since the last revision:
>
> - * more comment update
> - * fix comment
Marked as reviewed by shade (Reviewer).
-------------
PR Review: https://git.openjdk.org/jdk/pull/21538#pullrequestreview-2372791262
From coleenp at openjdk.org Wed Oct 16 15:32:42 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 16 Oct 2024 15:32:42 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v44]
In-Reply-To: <logRSsOv-ZbKrosBAddqiXOOAcr-tMODEDmGksY6uJs=.ee83f2c3-2b57-41f5-b9f4-9b36811ced37@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<logRSsOv-ZbKrosBAddqiXOOAcr-tMODEDmGksY6uJs=.ee83f2c3-2b57-41f5-b9f4-9b36811ced37@github.com>
Message-ID: <jcJX7xDf0w0wDgFA-eoYVaK0rEgIUHTmbpgHiOUZEVw=.1b4528e8-805a-4914-928b-4fd906668204@github.com>
On Wed, 16 Oct 2024 13:46:24 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>>
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>>
>> Main changes:
>> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>> - Arrays will now store their length at offset 8.
>> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>
> Problem-list SharedBaseAddress tests on aarch64
Marked as reviewed by coleenp (Reviewer).
-------------
PR Review: https://git.openjdk.org/jdk/pull/20677#pullrequestreview-2372873633
From coleenp at openjdk.org Wed Oct 16 15:45:34 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 16 Oct 2024 15:45:34 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v44]
In-Reply-To: <logRSsOv-ZbKrosBAddqiXOOAcr-tMODEDmGksY6uJs=.ee83f2c3-2b57-41f5-b9f4-9b36811ced37@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<logRSsOv-ZbKrosBAddqiXOOAcr-tMODEDmGksY6uJs=.ee83f2c3-2b57-41f5-b9f4-9b36811ced37@github.com>
Message-ID: <cQ6B7ZfZdJrEd_dsmQouGG3i45UcX_e_5f1K7fdvTuI=.82c67fe3-671a-4b1e-bfb1-979e65d56b19@github.com>
On Wed, 16 Oct 2024 13:46:24 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>>
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>>
>> Main changes:
>> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>> - Arrays will now store their length at offset 8.
>> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>
> Problem-list SharedBaseAddress tests on aarch64
src/hotspot/share/oops/compressedKlass.cpp line 185:
> 183: #endif
> 184:
> 185: DEBUG_ONLY(sanity_check_after_initialization();)
This is here twice.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1803363047
From rkennke at openjdk.org Wed Oct 16 16:04:21 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 16 Oct 2024 16:04:21 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v45]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <nXvefC2q0Zv4iZH5NdDzBC_sxM3weHdrZpC6vPmUJGM=.c2ddaf31-6b8c-407c-b2a2-ab710486092c@github.com>
> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>
> Main changes:
> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
> - Arrays will now store their length at offset 8.
> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...
Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
Remove extra sanity check
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/20677/files
- new: https://git.openjdk.org/jdk/pull/20677/files/ec42f4d6..e4c08780
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=44
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=43-44
Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod
Patch: https://git.openjdk.org/jdk/pull/20677.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677
PR: https://git.openjdk.org/jdk/pull/20677
From kdnilsen at openjdk.org Wed Oct 16 16:41:15 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 16 Oct 2024 16:41:15 GMT
Subject: RFR: 8342119: Shenandoah: Remove extra ShenandoahUpdateRefsClosure
In-Reply-To: <8v42ZVUQ6lc58IzwWUJeSd0IjkRNJIquDoEX1qRbOvM=.ea84c8d0-745c-42f7-b989-ecb2be9aaca1@github.com>
References: <8v42ZVUQ6lc58IzwWUJeSd0IjkRNJIquDoEX1qRbOvM=.ea84c8d0-745c-42f7-b989-ecb2be9aaca1@github.com>
Message-ID: <i7iI7I2ff2jZFSaBo3y1sglW8PWJR3ushaCrCi5JC9o=.49cfb21d-3aae-4b4d-92fa-3eb8e3695c91@github.com>
On Tue, 15 Oct 2024 08:53:00 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:
> We have a duplicate `ShenandoahUpdateRefsClosure`, which we use in a few places. For bulk GC operations, we have `ShenandoahConcUpdateRefsClosure` and `ShenandoahSTWUpdateRefsClosure` that are semantically similar to that one. We can drop the `ShenandoahUpdateRefsClosure` in favor of these two existing ones.
>
> Additional testing:
> - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`
> - [ ] Performance tests (no regressions)
Marked as reviewed by kdnilsen (Author).
-------------
PR Review: https://git.openjdk.org/jdk/pull/21517#pullrequestreview-2373084021
From iwalulya at openjdk.org Wed Oct 16 17:46:11 2024
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Wed, 16 Oct 2024 17:46:11 GMT
Subject: RFR: 8340389:
vmTestbase/gc/gctests/PhantomReference/phantom001/TestDescription.java Test
exit code: 97 with -Xcomp UseAVX=3 [v2]
In-Reply-To: <4n8ubErTv7IpzJfTFG-80BPm9WLTKBtMBo6kWrkw6pw=.c5f0d039-78f3-485f-aaa9-50b7a18f1e35@github.com>
References: <XV6xPNGzGAzTREFF1ZOaeVpQXWRfb4tOStZbWnuAm2M=.3c35b874-385e-4996-a3fa-7f687ebbf491@github.com>
<4n8ubErTv7IpzJfTFG-80BPm9WLTKBtMBo6kWrkw6pw=.c5f0d039-78f3-485f-aaa9-50b7a18f1e35@github.com>
Message-ID: <8V0lne6vMm05xrXS9oF6dekNr2xz8s3qG0XAHKwWniQ=.4ba97264-bf3a-4c2b-a7c5-84e6b7e9d2bc@github.com>
On Wed, 16 Oct 2024 15:01:48 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:
>> Hi all,
>>
>> please review this fix to the phantom001 test to do much less garbage collections that inhibit passing the test.
>>
>> Testing: gha, running the test with and without the change for 500 times with the problematic options - fails 379 times without the change, passes all runs with the change.
>>
>> Thanks,
>> Thomas
>
> Thomas Schatzl has updated the pull request incrementally with two additional commits since the last revision:
>
> - * more comment update
> - * fix comment
Marked as reviewed by iwalulya (Reviewer).
-------------
PR Review: https://git.openjdk.org/jdk/pull/21538#pullrequestreview-2373234557
From wkemper at openjdk.org Wed Oct 16 18:29:11 2024
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 16 Oct 2024 18:29:11 GMT
Subject: RFR: 8342079: Shenandoah: Remove extra
ShenandoahInitMarkRootsClosure
In-Reply-To: <wQe8tUlBQRovFLXCS3VzYbfzEd-cwePnxg8GBTP9cbw=.9a25d35b-ce88-4503-84e1-04e18503b0c8@github.com>
References: <wQe8tUlBQRovFLXCS3VzYbfzEd-cwePnxg8GBTP9cbw=.9a25d35b-ce88-4503-84e1-04e18503b0c8@github.com>
Message-ID: <aQWEEkE0DZXOdDGjMB3S9wx5-QKrKb3SJjiJrRfL1Ao=.c7a7afd6-a8c7-4f29-9d5b-061a814b7361@github.com>
On Mon, 14 Oct 2024 18:42:53 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:
> `ShenandoahInitMarkRootsClosure` in `ShenandoahSTWMark` is semantically similar to the shared `ShenandoahMarkRefsClosure`. It misses subclassing the metadata-visiting superclass, though, and `ShenandoahMarkRefsClosure` does it right. It is cleaner and safer to use the super-class directly, as concurrent mark does it.
>
> Additional testing:
> - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`
Marked as reviewed by wkemper (Committer).
-------------
PR Review: https://git.openjdk.org/jdk/pull/21504#pullrequestreview-2373331951
From duke at openjdk.org Wed Oct 16 20:42:31 2024
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Wed, 16 Oct 2024 20:42:31 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v45]
In-Reply-To: <nXvefC2q0Zv4iZH5NdDzBC_sxM3weHdrZpC6vPmUJGM=.c2ddaf31-6b8c-407c-b2a2-ab710486092c@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<nXvefC2q0Zv4iZH5NdDzBC_sxM3weHdrZpC6vPmUJGM=.c2ddaf31-6b8c-407c-b2a2-ab710486092c@github.com>
Message-ID: <Q7F4DYDHbZ5PFV9p0aI7CJRgiWRUIB58IEBiPkVlQ3Y=.60539a7f-7eea-42d9-b453-508e6d9cdf7b@github.com>
On Wed, 16 Oct 2024 16:04:21 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>>
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>>
>> Main changes:
>> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>> - Arrays will now store their length at offset 8.
>> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>
> Remove extra sanity check
Looks good to me (reviewed just `src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp`)
Thanks!
-------------
Marked as reviewed by vpaprotsk at github.com (no known OpenJDK username).
PR Review: https://git.openjdk.org/jdk/pull/20677#pullrequestreview-2373635524
From kbarrett at openjdk.org Wed Oct 16 21:19:32 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 16 Oct 2024 21:19:32 GMT
Subject: RFR: 8342102: ZGC: Optimize copy constructors in ZPhysicalMemory
[v2]
In-Reply-To: <bjfAiew622Vyz2arQQk6boW3NrS-KqRgOdIB8raTlGw=.35abe8ad-ecdb-4eba-8ba4-c86a22c90e86@github.com>
References: <5hvFKET_jLREXmQcM1LygpEEnBuYzIV5fOXXajE-OEk=.7625a7a0-2cbf-4f0b-a7c9-b772f20599f7@github.com>
<bjfAiew622Vyz2arQQk6boW3NrS-KqRgOdIB8raTlGw=.35abe8ad-ecdb-4eba-8ba4-c86a22c90e86@github.com>
Message-ID: <hZ4X_hRre9hINdbdB_J6W9YNn_qqLQ4z1C_TbzxTXmI=.a8fb82b4-ff92-4187-9d47-b137674e5f8a@github.com>
On Wed, 16 Oct 2024 08:29:48 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:
>> ZPhysicalMemory stores a sorted array of physical memory segments. Segments are added using either add_segments or add_segment, where the former calls add_segment on each individual segment. add_segment inserts segments in address order and also merges segments when possible.
>>
>> When copying an instance of ZPhysicalMemory, segments are currently copied using either add_segments or add_segment, which works as described above. This requires more work than necessary and should be simplified to account for the fact that the array of segments is always sorted.
>>
>> When copying, the copy constructors should instead use append or appendAll from the underlying GrowableArrayCHeap and also reserve enough memory so that the array's capacity is not increased more times than necessary during copying.
>>
>> Tested with tiers 1-3.
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
>
> Add check for self-assignment
Looks good.
-------------
Marked as reviewed by kbarrett (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/21523#pullrequestreview-2373699132
From stefank at openjdk.org Thu Oct 17 07:12:12 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 17 Oct 2024 07:12:12 GMT
Subject: RFR: 8342102: ZGC: Optimize copy constructors in ZPhysicalMemory
[v2]
In-Reply-To: <bjfAiew622Vyz2arQQk6boW3NrS-KqRgOdIB8raTlGw=.35abe8ad-ecdb-4eba-8ba4-c86a22c90e86@github.com>
References: <5hvFKET_jLREXmQcM1LygpEEnBuYzIV5fOXXajE-OEk=.7625a7a0-2cbf-4f0b-a7c9-b772f20599f7@github.com>
<bjfAiew622Vyz2arQQk6boW3NrS-KqRgOdIB8raTlGw=.35abe8ad-ecdb-4eba-8ba4-c86a22c90e86@github.com>
Message-ID: <Xkj5SrZ_DZuG-QUl0_-ffTJ7ypru4PMszYY8NlQAR_w=.6b714036-6c73-41d1-8b57-261aaa30c692@github.com>
On Wed, 16 Oct 2024 08:29:48 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:
>> ZPhysicalMemory stores a sorted array of physical memory segments. Segments are added using either add_segments or add_segment, where the former calls add_segment on each individual segment. add_segment inserts segments in address order and also merges segments when possible.
>>
>> When copying an instance of ZPhysicalMemory, segments are currently copied using either add_segments or add_segment, which works as described above. This requires more work than necessary and should be simplified to account for the fact that the array of segments is always sorted.
>>
>> When copying, the copy constructors should instead use append or appendAll from the underlying GrowableArrayCHeap and also reserve enough memory so that the array's capacity is not increased more times than necessary during copying.
>>
>> Tested with tiers 1-3.
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
>
> Add check for self-assignment
Marked as reviewed by stefank (Reviewer).
-------------
PR Review: https://git.openjdk.org/jdk/pull/21523#pullrequestreview-2374345908
From mli at openjdk.org Thu Oct 17 10:07:35 2024
From: mli at openjdk.org (Hamlin Li)
Date: Thu, 17 Oct 2024 10:07:35 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v43]
In-Reply-To: <-8DXPgoraRNtE7uJw-Pdk5Z3eJAzIbhVRJOX5JH85UY=.358823f0-a30f-4994-b566-cdf064eac8f0@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<d8BYPKWeRrC0aK7WeqwXe2pphNUZRgqKf23s15leeNE=.8e8e13a2-5f2a-4ee5-86fb-beef1ea64555@github.com>
<XDTAUAApVTM7iZAGsuosoHPDcEf5NH6rO4JPm1W-YjA=.7cf382e3-f9ca-4d2a-b22e-81f003da88b7@github.com>
<-8DXPgoraRNtE7uJw-Pdk5Z3eJAzIbhVRJOX5JH85UY=.358823f0-a30f-4994-b566-cdf064eac8f0@github.com>
Message-ID: <I5wW9So_ctsg-umi8UqIV8vWKbFUTHej5n_Jep3G_9Y=.17d468f8-1d13-4ed5-9584-bd097216fe4a@github.com>
On Wed, 16 Oct 2024 13:42:42 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
>> We're seeing failures in our nightly testing for tests runtime/cds/appcds/SharedBaseAddress.java and runtime/cds/SharedBaseAddress.java which I'm tracking in this bug [JDK-8340212](https://bugs.openjdk.org/browse/JDK-8340212)
>>
>> This patch should problem list these two tests on aarch64 when UseCompactObjectHeaders is on (if possible to be that specific), or just plain problem list it until I have a fix for it.
>
>> We're seeing failures in our nightly testing for tests runtime/cds/appcds/SharedBaseAddress.java and runtime/cds/SharedBaseAddress.java which I'm tracking in this bug [JDK-8340212](https://bugs.openjdk.org/browse/JDK-8340212)
>>
>> This patch should problem list these two tests on aarch64 when UseCompactObjectHeaders is on (if possible to be that specific), or just plain problem list it until I have a fix for it.
>
> Thanks for pointing this out. I've problem-listed both tests on aarch64.
@rkennke Here is the [riscv implementation](https://github.com/rkennke/jdk/compare/JDK-8305895-v4...rivosinc:jdk-compact-2:compact-header-riscv?expand=1#diff-5808bc502bdf55f1ae7ba30504c8ee6eb92527f0c11670a35d6279d671b52c6bR271), could you help to include it in this pr? Thanks!
-------------
PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2419103904
From rkennke at openjdk.org Thu Oct 17 10:57:24 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 17 Oct 2024 10:57:24 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v46]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <TSoqyHiesRchgObQUULLugQ15WdZJlOp21VQTyxrEbQ=.fff7ec53-1145-40e1-90ed-af55b3defb5f@github.com>
> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>
> Main changes:
> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
> - Arrays will now store their length at offset 8.
> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...
Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
Compact header riscv (#3)
Implement compact headers on RISCV
---------
Co-authored-by: hamlin <hamlin at rivosinc.com>
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/20677/files
- new: https://git.openjdk.org/jdk/pull/20677/files/e4c08780..1b907cc8
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=45
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=44-45
Stats: 136 lines in 10 files changed: 76 ins; 31 del; 29 mod
Patch: https://git.openjdk.org/jdk/pull/20677.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677
PR: https://git.openjdk.org/jdk/pull/20677
From iwalulya at openjdk.org Thu Oct 17 12:29:13 2024
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Thu, 17 Oct 2024 12:29:13 GMT
Subject: RFR: 8342329: G1: Rename
G1HeapRegionManager::_allocated_heapregions_length
In-Reply-To: <OhZTByjQRvltbItvhpbciSN65unTdk8WAeo2SOVRTmA=.6cf0720f-a39a-40e6-a6dc-2a0c6a3ff9f2@github.com>
References: <hfOPnyp8w89EMp02oTxVY7odheEkxtYNWMytSHclrdM=.750dcaa9-36a2-486d-bd87-33c62436b53c@github.com>
<OhZTByjQRvltbItvhpbciSN65unTdk8WAeo2SOVRTmA=.6cf0720f-a39a-40e6-a6dc-2a0c6a3ff9f2@github.com>
Message-ID: <555O0VtBYIczaS2vp6qr0jN_Ngq9FzVG3lqvBzktaLg=.0f513c2c-4431-4882-9a80-fce0e9042b5d@github.com>
On Wed, 16 Oct 2024 09:58:53 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:
>> Hi,
>>
>> Please review the refactor rename of G1HeapRegionManager::_allocated_heapregions_length to G1HeapRegionManager::_next_highest_used_hrm_index which better reflects the purpose of the field.
>
> Marked as reviewed by shade (Reviewer).
Thanks @shipilev and @tschatzl for the reviews!
-------------
PR Comment: https://git.openjdk.org/jdk/pull/21530#issuecomment-2419402609
From iwalulya at openjdk.org Thu Oct 17 12:29:14 2024
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Thu, 17 Oct 2024 12:29:14 GMT
Subject: Integrated: 8342329: G1: Rename
G1HeapRegionManager::_allocated_heapregions_length
In-Reply-To: <hfOPnyp8w89EMp02oTxVY7odheEkxtYNWMytSHclrdM=.750dcaa9-36a2-486d-bd87-33c62436b53c@github.com>
References: <hfOPnyp8w89EMp02oTxVY7odheEkxtYNWMytSHclrdM=.750dcaa9-36a2-486d-bd87-33c62436b53c@github.com>
Message-ID: <1syA4AT_QYm3wls7nKTCVxZLhAxzFE1XS1JBsk88Hyk=.d1edf347-34ef-4597-b9a2-12452ecc7494@github.com>
On Wed, 16 Oct 2024 08:47:00 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:
> Hi,
>
> Please review the refactor rename of G1HeapRegionManager::_allocated_heapregions_length to G1HeapRegionManager::_next_highest_used_hrm_index which better reflects the purpose of the field.
This pull request has now been integrated.
Changeset: 8e16e674
Author: Ivan Walulya <iwalulya at openjdk.org>
URL: https://git.openjdk.org/jdk/commit/8e16e67492a46c5ee1e6fdb8f86d061cb8d3169b
Stats: 21 lines in 2 files changed: 0 ins; 0 del; 21 mod
8342329: G1: Rename G1HeapRegionManager::_allocated_heapregions_length
Reviewed-by: tschatzl, shade
-------------
PR: https://git.openjdk.org/jdk/pull/21530
From tschatzl at openjdk.org Thu Oct 17 12:35:30 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 17 Oct 2024 12:35:30 GMT
Subject: RFR: 8340389:
vmTestbase/gc/gctests/PhantomReference/phantom001/TestDescription.java Test
exit code: 97 with -Xcomp UseAVX=3 [v2]
In-Reply-To: <8CW4GA9Rdlw0QJu_PpRpnBYsCTTp3drG4IAWzsLX6dE=.890f5136-43f2-4d84-86cf-79bc3d116158@github.com>
References: <XV6xPNGzGAzTREFF1ZOaeVpQXWRfb4tOStZbWnuAm2M=.3c35b874-385e-4996-a3fa-7f687ebbf491@github.com>
<4n8ubErTv7IpzJfTFG-80BPm9WLTKBtMBo6kWrkw6pw=.c5f0d039-78f3-485f-aaa9-50b7a18f1e35@github.com>
<8CW4GA9Rdlw0QJu_PpRpnBYsCTTp3drG4IAWzsLX6dE=.890f5136-43f2-4d84-86cf-79bc3d116158@github.com>
Message-ID: <9qXbN7yZYQp9rybD5X_vPxvPWFYJZFdOlYedpM7yUAI=.62891ab6-6226-4b5e-b0df-aa4c32a8e064@github.com>
On Wed, 16 Oct 2024 15:02:18 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:
>> Thomas Schatzl has updated the pull request incrementally with two additional commits since the last revision:
>>
>> - * more comment update
>> - * fix comment
>
> Marked as reviewed by shade (Reviewer).
Thanks @shipilev @walulyai for your reviews.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/21538#issuecomment-2419413486
From tschatzl at openjdk.org Thu Oct 17 12:35:31 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 17 Oct 2024 12:35:31 GMT
Subject: Integrated: 8340389:
vmTestbase/gc/gctests/PhantomReference/phantom001/TestDescription.java Test
exit code: 97 with -Xcomp UseAVX=3
In-Reply-To: <XV6xPNGzGAzTREFF1ZOaeVpQXWRfb4tOStZbWnuAm2M=.3c35b874-385e-4996-a3fa-7f687ebbf491@github.com>
References: <XV6xPNGzGAzTREFF1ZOaeVpQXWRfb4tOStZbWnuAm2M=.3c35b874-385e-4996-a3fa-7f687ebbf491@github.com>
Message-ID: <Dm8dfd8-aN83N6SIWdJ9DcfQHm3_IQpqvmIv__C1sq0=.6dcccea3-5556-4752-bffd-629f39209c5b@github.com>
On Wed, 16 Oct 2024 14:18:24 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:
> Hi all,
>
> please review this fix to the phantom001 test to do much less garbage collections that inhibit passing the test.
>
> Testing: gha, running the test with and without the change for 500 times with the problematic options - fails 379 times without the change, passes all runs with the change.
>
> Thanks,
> Thomas
This pull request has now been integrated.
Changeset: d6f8b465
Author: Thomas Schatzl <tschatzl at openjdk.org>
URL: https://git.openjdk.org/jdk/commit/d6f8b465e47d40220bdba6bf7502de90ee9fa7f7
Stats: 5 lines in 1 file changed: 2 ins; 1 del; 2 mod
8340389: vmTestbase/gc/gctests/PhantomReference/phantom001/TestDescription.java Test exit code: 97 with -Xcomp UseAVX=3
Reviewed-by: shade, iwalulya
-------------
PR: https://git.openjdk.org/jdk/pull/21538
From tschatzl at openjdk.org Thu Oct 17 12:35:37 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 17 Oct 2024 12:35:37 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v46]
In-Reply-To: <TSoqyHiesRchgObQUULLugQ15WdZJlOp21VQTyxrEbQ=.fff7ec53-1145-40e1-90ed-af55b3defb5f@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<TSoqyHiesRchgObQUULLugQ15WdZJlOp21VQTyxrEbQ=.fff7ec53-1145-40e1-90ed-af55b3defb5f@github.com>
Message-ID: <f8MC9w61VqSlgiSOJSYoKQy1kStQVVnNHBgY7h4BLO8=.1804d5c9-3cdb-4664-812e-e10239917c23@github.com>
On Thu, 17 Oct 2024 10:57:24 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>>
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>>
>> Main changes:
>> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>> - Arrays will now store their length at offset 8.
>> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>
> Compact header riscv (#3)
>
> Implement compact headers on RISCV
> ---------
>
> Co-authored-by: hamlin <hamlin at rivosinc.com>
Mostly only looked at gc files.
-------------
Marked as reviewed by tschatzl (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/20677#pullrequestreview-2375093923
From yzheng at openjdk.org Thu Oct 17 13:07:32 2024
From: yzheng at openjdk.org (Yudi Zheng)
Date: Thu, 17 Oct 2024 13:07:32 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v46]
In-Reply-To: <TSoqyHiesRchgObQUULLugQ15WdZJlOp21VQTyxrEbQ=.fff7ec53-1145-40e1-90ed-af55b3defb5f@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<TSoqyHiesRchgObQUULLugQ15WdZJlOp21VQTyxrEbQ=.fff7ec53-1145-40e1-90ed-af55b3defb5f@github.com>
Message-ID: <1Bg-C0suC9IfxXU-2Yw5pvXwySVaEFCg6EpiVgsSw70=.f6f0d596-b465-4137-99de-fba8236e8908@github.com>
On Thu, 17 Oct 2024 10:57:24 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>>
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>>
>> Main changes:
>> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>> - Arrays will now store their length at offset 8.
>> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>
> Compact header riscv (#3)
>
> Implement compact headers on RISCV
> ---------
>
> Co-authored-by: hamlin <hamlin at rivosinc.com>
JVMCI changes look good!
-------------
Marked as reviewed by yzheng (Committer).
PR Review: https://git.openjdk.org/jdk/pull/20677#pullrequestreview-2375182126
From rkennke at openjdk.org Thu Oct 17 13:48:11 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 17 Oct 2024 13:48:11 GMT
Subject: RFR: 8342119: Shenandoah: Remove extra ShenandoahUpdateRefsClosure
In-Reply-To: <8v42ZVUQ6lc58IzwWUJeSd0IjkRNJIquDoEX1qRbOvM=.ea84c8d0-745c-42f7-b989-ecb2be9aaca1@github.com>
References: <8v42ZVUQ6lc58IzwWUJeSd0IjkRNJIquDoEX1qRbOvM=.ea84c8d0-745c-42f7-b989-ecb2be9aaca1@github.com>
Message-ID: <4VHK8WGYCR_Hlw9BJgx93bnCkgvO1bcJcbTiHwuQyHQ=.38d16e95-ec74-4462-9696-e40112a147ef@github.com>
On Tue, 15 Oct 2024 08:53:00 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:
> We have a duplicate `ShenandoahUpdateRefsClosure`, which we use in a few places. For bulk GC operations, we have `ShenandoahConcUpdateRefsClosure` and `ShenandoahSTWUpdateRefsClosure` that are semantically similar to that one. We can drop the `ShenandoahUpdateRefsClosure` in favor of these two existing ones.
>
> Additional testing:
> - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`
> - [ ] Performance tests (no regressions)
Changes look fine. I don't think we would ever do concurrent updates in Thread roots, but yeah let's err on the side of caution. Perf difference should be tiny because there'd be no contention anyway.
-------------
Marked as reviewed by rkennke (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/21517#pullrequestreview-2375298089
From shade at openjdk.org Thu Oct 17 14:16:47 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 17 Oct 2024 14:16:47 GMT
Subject: RFR: 8342119: Shenandoah: Remove extra ShenandoahUpdateRefsClosure
[v2]
In-Reply-To: <8v42ZVUQ6lc58IzwWUJeSd0IjkRNJIquDoEX1qRbOvM=.ea84c8d0-745c-42f7-b989-ecb2be9aaca1@github.com>
References: <8v42ZVUQ6lc58IzwWUJeSd0IjkRNJIquDoEX1qRbOvM=.ea84c8d0-745c-42f7-b989-ecb2be9aaca1@github.com>
Message-ID: <p2Jygn_f__MR9Xkxy1FS6wxz9wg8_ri0k2JcWXBNuuQ=.150a5924-a35d-4a00-b26f-cebf62b0a119@github.com>
> We have a duplicate `ShenandoahUpdateRefsClosure`, which we use in a few places. For bulk GC operations, we have `ShenandoahConcUpdateRefsClosure` and `ShenandoahSTWUpdateRefsClosure` that are semantically similar to that one. We can drop the `ShenandoahUpdateRefsClosure` in favor of these two existing ones.
>
> Additional testing:
> - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`
> - [x] Performance tests (no regressions)
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:
- Merge branch 'master' into JDK-8342119-shenandoah-remove-extra-ur-cl
- Switch back to non-concurrent closure, rename update methods
- Fix
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/21517/files
- new: https://git.openjdk.org/jdk/pull/21517/files/f930e5a4..8e0727da
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=21517&range=01
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=21517&range=00-01
Stats: 18413 lines in 583 files changed: 14207 ins; 1972 del; 2234 mod
Patch: https://git.openjdk.org/jdk/pull/21517.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/21517/head:pull/21517
PR: https://git.openjdk.org/jdk/pull/21517
From shade at openjdk.org Thu Oct 17 14:16:47 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 17 Oct 2024 14:16:47 GMT
Subject: RFR: 8342119: Shenandoah: Remove extra ShenandoahUpdateRefsClosure
In-Reply-To: <8v42ZVUQ6lc58IzwWUJeSd0IjkRNJIquDoEX1qRbOvM=.ea84c8d0-745c-42f7-b989-ecb2be9aaca1@github.com>
References: <8v42ZVUQ6lc58IzwWUJeSd0IjkRNJIquDoEX1qRbOvM=.ea84c8d0-745c-42f7-b989-ecb2be9aaca1@github.com>
Message-ID: <GrRLrfQoukPWzBRrDwQfXxKg-VAz9zutrvYM8qbW3BA=.4966c365-03d5-453f-b0ae-36ff1f8325f3@github.com>
On Tue, 15 Oct 2024 08:53:00 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:
> We have a duplicate `ShenandoahUpdateRefsClosure`, which we use in a few places. For bulk GC operations, we have `ShenandoahConcUpdateRefsClosure` and `ShenandoahSTWUpdateRefsClosure` that are semantically similar to that one. We can drop the `ShenandoahUpdateRefsClosure` in favor of these two existing ones.
>
> Additional testing:
> - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`
> - [x] Performance tests (no regressions)
Extended performance tests showed ever-so-slight regression in thread root times with concurrent closure. So new revision rolls that back, and uses the similar non-concurrent closure we used before. I also renamed a few things to make it very explicit where we are using non-concurrent closures, even in concurrent mode.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/21517#issuecomment-2419666178
From rkennke at openjdk.org Thu Oct 17 14:56:13 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 17 Oct 2024 14:56:13 GMT
Subject: RFR: 8342079: Shenandoah: Remove extra
ShenandoahInitMarkRootsClosure
In-Reply-To: <wQe8tUlBQRovFLXCS3VzYbfzEd-cwePnxg8GBTP9cbw=.9a25d35b-ce88-4503-84e1-04e18503b0c8@github.com>
References: <wQe8tUlBQRovFLXCS3VzYbfzEd-cwePnxg8GBTP9cbw=.9a25d35b-ce88-4503-84e1-04e18503b0c8@github.com>
Message-ID: <2aDG2ewinuL51sG05CsichuyCQXL9h1B9Djnsi94A2g=.b6bd152a-82d6-4dfe-bd3e-b243f85593dc@github.com>
On Mon, 14 Oct 2024 18:42:53 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:
> `ShenandoahInitMarkRootsClosure` in `ShenandoahSTWMark` is semantically similar to the shared `ShenandoahMarkRefsClosure`. It misses subclassing the metadata-visiting superclass, though, and `ShenandoahMarkRefsClosure` does it right. It is cleaner and safer to use the super-class directly, as concurrent mark does it.
>
> Additional testing:
> - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`
Yes, that makes sense. The extra metadata stuff would not be used during init-mark, anyway.
-------------
Marked as reviewed by rkennke (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/21504#pullrequestreview-2375499969
From shade at openjdk.org Thu Oct 17 15:06:13 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 17 Oct 2024 15:06:13 GMT
Subject: RFR: 8342079: Shenandoah: Remove extra
ShenandoahInitMarkRootsClosure
In-Reply-To: <wQe8tUlBQRovFLXCS3VzYbfzEd-cwePnxg8GBTP9cbw=.9a25d35b-ce88-4503-84e1-04e18503b0c8@github.com>
References: <wQe8tUlBQRovFLXCS3VzYbfzEd-cwePnxg8GBTP9cbw=.9a25d35b-ce88-4503-84e1-04e18503b0c8@github.com>
Message-ID: <ZOFKDO8kHVEHm4NjE3f4MEGZz04Zlc2_S_CBitGeVwE=.0d109027-03f0-46ad-a089-80f7a8bf31eb@github.com>
On Mon, 14 Oct 2024 18:42:53 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:
> `ShenandoahInitMarkRootsClosure` in `ShenandoahSTWMark` is semantically similar to the shared `ShenandoahMarkRefsClosure`. It misses subclassing the metadata-visiting superclass, though, and `ShenandoahMarkRefsClosure` does it right. It is cleaner and safer to use the super-class directly, as concurrent mark does it.
>
> Additional testing:
> - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`
Thanks!
-------------
PR Comment: https://git.openjdk.org/jdk/pull/21504#issuecomment-2419798118
From shade at openjdk.org Thu Oct 17 15:06:13 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 17 Oct 2024 15:06:13 GMT
Subject: Integrated: 8342079: Shenandoah: Remove extra
ShenandoahInitMarkRootsClosure
In-Reply-To: <wQe8tUlBQRovFLXCS3VzYbfzEd-cwePnxg8GBTP9cbw=.9a25d35b-ce88-4503-84e1-04e18503b0c8@github.com>
References: <wQe8tUlBQRovFLXCS3VzYbfzEd-cwePnxg8GBTP9cbw=.9a25d35b-ce88-4503-84e1-04e18503b0c8@github.com>
Message-ID: <HeUGUYqL0QNCFOcQ_EzohYfSz-CRFOhxE1YNvnIN1Zo=.b5c2afe4-9c19-4f4d-9b0e-97dd1b32d51a@github.com>
On Mon, 14 Oct 2024 18:42:53 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:
> `ShenandoahInitMarkRootsClosure` in `ShenandoahSTWMark` is semantically similar to the shared `ShenandoahMarkRefsClosure`. It misses subclassing the metadata-visiting superclass, though, and `ShenandoahMarkRefsClosure` does it right. It is cleaner and safer to use the super-class directly, as concurrent mark does it.
>
> Additional testing:
> - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`
This pull request has now been integrated.
Changeset: 979895d1
Author: Aleksey Shipilev <shade at openjdk.org>
URL: https://git.openjdk.org/jdk/commit/979895d175797a71c52da12f245d1040a27172cf
Stats: 30 lines in 1 file changed: 1 ins; 27 del; 2 mod
8342079: Shenandoah: Remove extra ShenandoahInitMarkRootsClosure
Reviewed-by: wkemper, rkennke
-------------
PR: https://git.openjdk.org/jdk/pull/21504
From rkennke at openjdk.org Thu Oct 17 15:27:11 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 17 Oct 2024 15:27:11 GMT
Subject: RFR: 8342119: Shenandoah: Remove extra ShenandoahUpdateRefsClosure
[v2]
In-Reply-To: <p2Jygn_f__MR9Xkxy1FS6wxz9wg8_ri0k2JcWXBNuuQ=.150a5924-a35d-4a00-b26f-cebf62b0a119@github.com>
References: <8v42ZVUQ6lc58IzwWUJeSd0IjkRNJIquDoEX1qRbOvM=.ea84c8d0-745c-42f7-b989-ecb2be9aaca1@github.com>
<p2Jygn_f__MR9Xkxy1FS6wxz9wg8_ri0k2JcWXBNuuQ=.150a5924-a35d-4a00-b26f-cebf62b0a119@github.com>
Message-ID: <ZdDDvVp3Sk94G-kljfQ6DRBjUpq21V7r-KKaN-CmMD4=.5829ca25-f833-4c66-9c43-d34faa824c7d@github.com>
On Thu, 17 Oct 2024 14:16:47 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:
>> We have a duplicate `ShenandoahUpdateRefsClosure`, which we use in a few places. For bulk GC operations, we have `ShenandoahConcUpdateRefsClosure` and `ShenandoahSTWUpdateRefsClosure` that are semantically similar to that one. We can drop the `ShenandoahUpdateRefsClosure` in favor of these two existing ones.
>>
>> Additional testing:
>> - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`
>> - [x] Performance tests (no regressions)
>
> 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:
>
> - Merge branch 'master' into JDK-8342119-shenandoah-remove-extra-ur-cl
> - Switch back to non-concurrent closure, rename update methods
> - Fix
Even better! Thanks!
-------------
Marked as reviewed by rkennke (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/21517#pullrequestreview-2375583406
From kdnilsen at openjdk.org Thu Oct 17 15:58:15 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 17 Oct 2024 15:58:15 GMT
Subject: RFR: 8342119: Shenandoah: Remove extra ShenandoahUpdateRefsClosure
[v2]
In-Reply-To: <p2Jygn_f__MR9Xkxy1FS6wxz9wg8_ri0k2JcWXBNuuQ=.150a5924-a35d-4a00-b26f-cebf62b0a119@github.com>
References: <8v42ZVUQ6lc58IzwWUJeSd0IjkRNJIquDoEX1qRbOvM=.ea84c8d0-745c-42f7-b989-ecb2be9aaca1@github.com>
<p2Jygn_f__MR9Xkxy1FS6wxz9wg8_ri0k2JcWXBNuuQ=.150a5924-a35d-4a00-b26f-cebf62b0a119@github.com>
Message-ID: <2bMiL9iWiNCU3-irO-Lg_mIhUOEgr8wNVQuSzcKBsHs=.3b35b5fe-45cb-4f6e-b700-dbbd343095d2@github.com>
On Thu, 17 Oct 2024 14:16:47 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:
>> We have a duplicate `ShenandoahUpdateRefsClosure`, which we use in a few places. For bulk GC operations, we have `ShenandoahConcUpdateRefsClosure` and `ShenandoahSTWUpdateRefsClosure` that are semantically similar to that one. We can drop the `ShenandoahUpdateRefsClosure` in favor of these two existing ones.
>>
>> Additional testing:
>> - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`
>> - [x] Performance tests (no regressions)
>
> 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:
>
> - Merge branch 'master' into JDK-8342119-shenandoah-remove-extra-ur-cl
> - Switch back to non-concurrent closure, rename update methods
> - Fix
Marked as reviewed by kdnilsen (Author).
-------------
PR Review: https://git.openjdk.org/jdk/pull/21517#pullrequestreview-2375663864
From wkemper at openjdk.org Thu Oct 17 16:51:38 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 17 Oct 2024 16:51:38 GMT
Subject: RFR: 8342119: Shenandoah: Remove extra ShenandoahUpdateRefsClosure
[v2]
In-Reply-To: <p2Jygn_f__MR9Xkxy1FS6wxz9wg8_ri0k2JcWXBNuuQ=.150a5924-a35d-4a00-b26f-cebf62b0a119@github.com>
References: <8v42ZVUQ6lc58IzwWUJeSd0IjkRNJIquDoEX1qRbOvM=.ea84c8d0-745c-42f7-b989-ecb2be9aaca1@github.com>
<p2Jygn_f__MR9Xkxy1FS6wxz9wg8_ri0k2JcWXBNuuQ=.150a5924-a35d-4a00-b26f-cebf62b0a119@github.com>
Message-ID: <WvHfdukKsH8bFtZBq3WlLqzDOAsZlDbZ94obIw3Au2k=.e33add3b-9a96-4bb7-881b-c2a33de1378b@github.com>
On Thu, 17 Oct 2024 14:16:47 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:
>> We have a duplicate `ShenandoahUpdateRefsClosure`, which we use in a few places. For bulk GC operations, we have `ShenandoahConcUpdateRefsClosure` and `ShenandoahSTWUpdateRefsClosure` that are semantically similar to that one. We can drop the `ShenandoahUpdateRefsClosure` in favor of these two existing ones.
>>
>> Additional testing:
>> - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`
>> - [x] Performance tests (no regressions)
>
> 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:
>
> - Merge branch 'master' into JDK-8342119-shenandoah-remove-extra-ur-cl
> - Switch back to non-concurrent closure, rename update methods
> - Fix
Marked as reviewed by wkemper (Committer).
-------------
PR Review: https://git.openjdk.org/jdk/pull/21517#pullrequestreview-2375768816
From shade at openjdk.org Thu Oct 17 16:51:38 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 17 Oct 2024 16:51:38 GMT
Subject: RFR: 8342119: Shenandoah: Remove extra ShenandoahUpdateRefsClosure
[v2]
In-Reply-To: <p2Jygn_f__MR9Xkxy1FS6wxz9wg8_ri0k2JcWXBNuuQ=.150a5924-a35d-4a00-b26f-cebf62b0a119@github.com>
References: <8v42ZVUQ6lc58IzwWUJeSd0IjkRNJIquDoEX1qRbOvM=.ea84c8d0-745c-42f7-b989-ecb2be9aaca1@github.com>
<p2Jygn_f__MR9Xkxy1FS6wxz9wg8_ri0k2JcWXBNuuQ=.150a5924-a35d-4a00-b26f-cebf62b0a119@github.com>
Message-ID: <KSfjzU51JCz99Td1DWKH-CEN02Iupxe8-T6gNVNy4ws=.f963504a-8dea-433a-b0f4-467c76e769b3@github.com>
On Thu, 17 Oct 2024 14:16:47 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:
>> We have a duplicate `ShenandoahUpdateRefsClosure`, which we use in a few places. For bulk GC operations, we have `ShenandoahConcUpdateRefsClosure` and `ShenandoahSTWUpdateRefsClosure` that are semantically similar to that one. We can drop the `ShenandoahUpdateRefsClosure` in favor of these two existing ones.
>>
>> Additional testing:
>> - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`
>> - [x] Performance tests (no regressions)
>
> 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:
>
> - Merge branch 'master' into JDK-8342119-shenandoah-remove-extra-ur-cl
> - Switch back to non-concurrent closure, rename update methods
> - Fix
Thank you!
-------------
PR Comment: https://git.openjdk.org/jdk/pull/21517#issuecomment-2420033090
From shade at openjdk.org Thu Oct 17 18:13:15 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 17 Oct 2024 18:13:15 GMT
Subject: Integrated: 8342119: Shenandoah: Remove extra
ShenandoahUpdateRefsClosure
In-Reply-To: <8v42ZVUQ6lc58IzwWUJeSd0IjkRNJIquDoEX1qRbOvM=.ea84c8d0-745c-42f7-b989-ecb2be9aaca1@github.com>
References: <8v42ZVUQ6lc58IzwWUJeSd0IjkRNJIquDoEX1qRbOvM=.ea84c8d0-745c-42f7-b989-ecb2be9aaca1@github.com>
Message-ID: <qHm4dFOo_2Awg2XxYeLo9HXYkc1LJosx_YbMecNvdCY=.cd885e97-9a19-46a6-ab7b-f73d56b0f9ba@github.com>
On Tue, 15 Oct 2024 08:53:00 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:
> We have a duplicate `ShenandoahUpdateRefsClosure`, which we use in a few places. For bulk GC operations, we have `ShenandoahConcUpdateRefsClosure` and `ShenandoahSTWUpdateRefsClosure` that are semantically similar to that one. We can drop the `ShenandoahUpdateRefsClosure` in favor of these two existing ones.
>
> Additional testing:
> - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`
> - [x] Performance tests (no regressions)
This pull request has now been integrated.
Changeset: b993227e
Author: Aleksey Shipilev <shade at openjdk.org>
URL: https://git.openjdk.org/jdk/commit/b993227e2f3233c7b34a77eebbeeb1c51d2b7cfe
Stats: 46 lines in 9 files changed: 4 ins; 27 del; 15 mod
8342119: Shenandoah: Remove extra ShenandoahUpdateRefsClosure
Reviewed-by: wkemper, kdnilsen, rkennke
-------------
PR: https://git.openjdk.org/jdk/pull/21517
From jonathanjoo at google.com Fri Oct 18 00:11:27 2024
From: jonathanjoo at google.com (Jonathan Joo)
Date: Thu, 17 Oct 2024 17:11:27 -0700
Subject: Further discussion on Adaptable Heap Sizing with G1
In-Reply-To: <7d07385e-bc04-4251-a5db-81ede0b90465@oracle.com>
References: <CACz-JM5_UjhLj2Yng83y9G5VUkfPT2kiLDSdUe+2u9J=dG5UvQ@mail.gmail.com>
<93ecaaaa-600e-4b91-a98b-f417f5505037@oracle.com>
<CACz-JM4bgOfVA=6CbrNSK6bJFBnT8F5QecHUp8VbJTvHy=72vA@mail.gmail.com>
<7d07385e-bc04-4251-a5db-81ede0b90465@oracle.com>
Message-ID: <CACz-JM462vnVRMP+wjofVO7ygSMC2rGrRn8C_ZUNAOQUu56VFw@mail.gmail.com>
Hi Thomas,
The points you mentioned make sense to me! There are some nuances that I'd
like to dig into further to make sure that we are aligned. I think to
summarize - I'm not sure exactly how SoftMaxHeapSize is intended to work,
whereas we have experimented with ProposedHeapSize at Google already, so I
want to bridge my gap in understanding there.
I appreciate you offering to meet and discuss! As far as meeting time - I'm
currently in US Pacific time, but flexible in terms of when we meet. (I am
generally awake from 9am-1am PT, so I am good to meet any time in that time
period -- please let me know what time works best for you.) Tuesday and
Thursday of the coming week I have the most availability, but if you have
any other dates/times in mind, I can let you know whether that works for me.
Best,
~ Jonathan
On Mon, Oct 14, 2024 at 2:52?AM Thomas Schatzl <thomas.schatzl at oracle.com>
wrote:
> Hi,
>
> On 11.10.24 09:16, Jonathan Joo wrote:
> > Hi Thomas,
> >
> > I think what this suggestion overlooks is that a SoftMaxHeapSize that
> > guides used heap size will automatically guide committed size: i.e.
> if
> > G1 shrinks the used heap, G1 will automatically shrink (and keep) the
> > committed size.
> >
> > So ProposedHeapSize seems to be very similar to SoftMaxHeapSize.
> >
> >
> > If I'm understanding this correctly - both ProposedHeapSize and (the
> > proposed version of) SoftMaxHeapSize have similar semantics, but
> > actually modify the heap in different ways. SoftMaxHeapSize helps us
> > determine when to start a concurrent mark, whereas ProposedHeapSize
> > doesn't actually trigger any GC directly, but affects the size of the
> > heap after a GC. Is that correct? Would it make sense then to have both
> > flags, where one helps set a trigger point for a GC, and one helps us
> > determine the heap size we are targeting after the GC? I might also be
> > missing some nuances here.
>
> I think SoftMaxHeapSize (or actually either) will result in
> approximately the same behavior. The difference is in intrusiveness.
>
> ProposedHeapSize forcefully attempts to decrease the committed heap size
> and then the rest of the "heap sizing machinery" follows, while
> SoftMaxHeapSize gives a target for the "heap sizing machinery" and
> committed heap size follows.
>
> ProposedHeapSize has the following disadvantages (as implemented):
>
> - since it forces committed heap size, I expect that in case you are
> close or above that target, you can get frequent uncommits/attempts to
> uncommit which waste cpu cycles.
>
> Hopefully, by giving the heap sizing machinery a goal, it will itself
> determine a sustainable committed memory level without too frequent
> commits and uncommits.
>
> - for some reason it does not allow less memory to be committed than
> proposed (but still larger than MinHeapSize). This can be inefficient
> wrt to memory usage.
> I.e. it basically disables other heap sizing afaict.
>
> - (that's more a nit) the use of "0" as special marker for
> SoftMaxHeapSize is unexpected.
>
> This mechanism kind of feels like a very blunt tool to get the desired
> effect (a certain committed heap) without caring about other goals. It
> may be necessary to pull out the immediately un/commit hammer in some
> situations, and imho, let's not give that hammer to users as the first
> option to screw themselves.
>
> >
> > I.e. if I understand this correctly: allowing a higher GC overhead,
> > automatically shrinks the heap.
> >
> >
> > Exactly - in practice, tuning this one parameter up (the target gc cpu
> > overhead) correlates with decreasing both the average as well as maximum
> > heap usage for a java program.
> >
> > I noticed the same with the patch attached to the SoftMaxHeapSize
> CR
> > (https://bugs.openjdk.org/browse/JDK-8236073
> > <https://bugs.openjdk.org/browse/JDK-8236073>) discounting effects
> of
> > Min/MaxHeapFreeRatio (i.e. if you remove it,
> > https://bugs.openjdk.org/browse/JDK-8238686
> > <https://bugs.openjdk.org/browse/JDK-8238686> explains the issue).
> > In practice, these two flags prohibit G1 from adjusting the heap
> unless
> > the SoftMaxHeapSize change is very large.
> >
> >
> > So I would prefer to only think of an alternative to SoftMaxHeapSize
> if
> > it has been shown that it does not work.
> >
> >
> > Given that you have a much stronger mental model than I do of how all
> > these flags fit together in the context of G1 GC, perhaps it would be
> > helpful to schedule some time to chat in person! I think that would help
> > clarify things much more quickly than email. To be clear - I have no
> > reason to doubt that SoftMaxHeapSize does not work. On the other hand,
> > could we possibly make use of both flags? For example, could
> > SoftMaxHeapSize potentially be a good replacement for our periodic GC?
>
> Not sure what periodic GC has to do with SoftMaxHeapSize.
>
> >
> > There is the nit that unlike in this implementation of
> ProposedHeapSize,
> > SoftMaxHeapSize will not cause uncommit below MinHeapSize. This is
> > another discussion on what to do about this issue - in a comment in
> > https://bugs.openjdk.org/browse/JDK-8236073
> > <https://bugs.openjdk.org/browse/JDK-8236073> it is proposed to make
> > MinHeapSize manageable.
> >
> >
> > How useful is MinHeapSize in practice? Do we need it, or can we just set
> > it to zero to avoid having to deal with it at all?
>
> I think you are mixing AHS (give decent heap sizing in presence of
> external memory pressure) and getting "optimal" heap sizing (or iow
> "steering heap size" externally).
>
> AHS is mostly about the user not doing/setting any heap sizes; in this
> case just having min heap size very low is just fine just as suggested
> in the JEP.
>
> SoftMaxHeapSize (and ProposedHeapSize) is about the user setting a
> particular goal according to his whims. It is still interesting to set
> -Xms==-Xmx for e.g. fast startup or during heavy activity; however if an
> external system decides that it is useful to intermittently save memory
> up to a certain level, then follow that guidance.
>
> The mechanism to internally follow that guidance can be used by AHS.
>
>
> >
> > I (still) believe that AHS and SoftMaxHeapSize/ProposedHeapSize are
> > somewhat orthogonal.
> >
> > AHS (https://openjdk.org/jeps/8329758
> > <https://openjdk.org/jeps/8329758>) is about finding a reasonable
> > heap size, and adjust on external "pressure".
> SoftMax/ProposedHeapSize
> > are manual external tunings.
> >
> >
> > Wdyt?
> >
> >
> > I agree with the general idea - for us, we used a manual external flag
> > like ProposedHeapSize because we did not implement any of the AHS logic
> > in the JVM. (We had a separate AHS thread reading in container
> > information and then doing the calculations, then setting
> > ProposedHeapSize as a manageable flag.) The way I see it is that
> > SoftMax/ProposedHeapSize is the "output" of AHS, and then
> > SoftMax/ProposedHeapSize is the "input" for the JVM, after which the JVM
> > uses this input to adjust its behavior accordingly. Does that align with
> > how you see things?
>
> As mentioned in the other thread, SoftMaxHeapSize can be used by AHS to
> get heap to a certain level (based on memory pressure), but there is
> also that external entity that can modify SoftMaxHeapSize to adjust VM
> behavior.
>
> So ultimately there will be multiple inputs for target heap size (and
> probably I'm forgetting one or the other):
>
> * External memory pressure (AHS) (*)
>
> * CurrentMaxHeapSize
>
> * SoftMaxHeapSize
>
> * CPU usage (existing GCTimeRatio based policy)
>
> * other *HeapSize flags
>
> that need to be merged into some target heap level using some policy.
>
> After knowing that level, the VM needs to decide on a proper reaction,
> which might be anything from just setting internal IHOP goal, to
> (un-)committing memory directly, to doing the appropriate garbage
> collection in a "timely" fashion (which is where the regular periodic
> gc/marking comes in) or anything inbetween.
>
> (*) I am aware that the AHS JEP not only includes reaction on external
> memory pressure but also the merging of goals for different sources;
> some of them are ZGC specific. Some of them are already implemented in
> G1. So for this discussion it is imo useful to limit "AHS" in G1 context
> to things that G1 does not do. Ie. "return another goal based on
> external memory pressure", "min/max heap size defaults(!)", and "adjust
> adaptive sizing".
>
> > If we do indeed implement AHS logic fully within the JVM, then we could
> > internally manage the sizing of the heap without exposing a manageable
> > flag. That being said, it seems to me that exposing this as a manageable
> > flag brings the additional benefit that one could plug in their own AHS
> > implementation that calculates target heap sizes with whatever data they
> > want (and then passes it into the JVM via the manageable flag).
> >
> > Again, I wonder if meeting to discuss would be efficient, and then we
> > can update the mailing list with the results of our discussion. Let me
> > know your thoughts!
>
> It's fine with me to meet to recap and discuss above; please suggest
> some time.
>
> Hth,
> Thomas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20241017/eff9540b/attachment.htm>
From tschatzl at openjdk.org Fri Oct 18 08:05:30 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 18 Oct 2024 08:05:30 GMT
Subject: RFR: 8295269: G1: Improve slow startup due to predictor initialization
Message-ID: <qFFwxaSWYOikI5bPZKCMa1VIWTEXI6pwQPLmVf2sTWA=.497a0fa1-2553-4293-b4a0-7a8b7e02b6c8@github.com>
Hi all,
please review this change that improves the time it takes to adapt the predictors to actual values during startup.
Currently predictors are initialized using compiled-in values. These values are extremely conservative as they have been based on some SPARC test runs on specjbb2000(?) or so, which means that it takes a while until the weights from these values are "gone" from the predictor sequences. (This can take 20-30 GCs).
The change modifies prediction so that only the first prediction will use these pre-baked values, after that use live values.
This makes G1 adapt much more quickly to the current application/environment.
The drawback is that there may be differences (including regressions) in out-of-box performance because the garbage collections heavily impact heap expansion, potentially expanding the heap much less, resulting in less throughput. I.e. we do more GCs during startup, causing higher cpu time ratio, expanding more.
The changes are still well within allowed range wrt to cpu time ratio etc.
This also does not impact reasonable test setups.
Testing: gha, internal performance benchmarks mostly show no change or improvements. There are some regressions that are "fixed" by setting min/max heap size indicating this is a heap sizing difference caused by differences due to faster startup.
Hth,
Thomas
-------------
Commit messages:
- * remove debug code
- * workaround for unproductive concurrent cycles
- * boost prediction initialization
Changes: https://git.openjdk.org/jdk/pull/21518/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21518&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8295269
Stats: 7 lines in 2 files changed: 6 ins; 0 del; 1 mod
Patch: https://git.openjdk.org/jdk/pull/21518.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/21518/head:pull/21518
PR: https://git.openjdk.org/jdk/pull/21518
From tschatzl at openjdk.org Fri Oct 18 08:05:30 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 18 Oct 2024 08:05:30 GMT
Subject: RFR: 8295269: G1: Improve slow startup due to predictor
initialization
In-Reply-To: <qFFwxaSWYOikI5bPZKCMa1VIWTEXI6pwQPLmVf2sTWA=.497a0fa1-2553-4293-b4a0-7a8b7e02b6c8@github.com>
References: <qFFwxaSWYOikI5bPZKCMa1VIWTEXI6pwQPLmVf2sTWA=.497a0fa1-2553-4293-b4a0-7a8b7e02b6c8@github.com>
Message-ID: <J3BX7grZroAHXyTqov21Enrn5BYRgZboW-cnvVHO3UE=.1f498164-1d7e-4620-bf53-f6ac1ee04c21@github.com>
On Tue, 15 Oct 2024 09:53:05 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:
> Hi all,
>
> please review this change that improves the time it takes to adapt the predictors to actual values during startup.
>
> Currently predictors are initialized using compiled-in values. These values are extremely conservative as they have been based on some SPARC test runs on specjbb2000(?) or so, which means that it takes a while until the weights from these values are "gone" from the predictor sequences. (This can take 20-30 GCs).
>
> The change modifies prediction so that only the first prediction will use these pre-baked values, after that use live values.
>
> This makes G1 adapt much more quickly to the current application/environment.
>
> The drawback is that there may be differences (including regressions) in out-of-box performance because the garbage collections heavily impact heap expansion, potentially expanding the heap much less, resulting in less throughput. I.e. we do more GCs during startup, causing higher cpu time ratio, expanding more.
>
> The changes are still well within allowed range wrt to cpu time ratio etc.
>
> This also does not impact reasonable test setups.
>
> Testing: gha, internal performance benchmarks mostly show no change or improvements. There are some regressions that are "fixed" by setting min/max heap size indicating this is a heap sizing difference caused by differences due to faster startup.
>
> Hth,
> Thomas
The GHA failures are due to some script not being found i.e. infrastructure issue afaict.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/21518#issuecomment-2421752102
From iwalulya at openjdk.org Fri Oct 18 09:12:59 2024
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Fri, 18 Oct 2024 09:12:59 GMT
Subject: RFR: 8295269: G1: Improve slow startup due to predictor
initialization
In-Reply-To: <qFFwxaSWYOikI5bPZKCMa1VIWTEXI6pwQPLmVf2sTWA=.497a0fa1-2553-4293-b4a0-7a8b7e02b6c8@github.com>
References: <qFFwxaSWYOikI5bPZKCMa1VIWTEXI6pwQPLmVf2sTWA=.497a0fa1-2553-4293-b4a0-7a8b7e02b6c8@github.com>
Message-ID: <OV5VFHKCX5rczCS_jesXIFLJ4UmMCxenFo1C8dmc410=.376e5a82-6150-4bf2-9a02-dc1c892c2c32@github.com>
On Tue, 15 Oct 2024 09:53:05 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:
> Hi all,
>
> please review this change that improves the time it takes to adapt the predictors to actual values during startup.
>
> Currently predictors are initialized using compiled-in values. These values are extremely conservative as they have been based on some SPARC test runs on specjbb2000(?) or so, which means that it takes a while until the weights from these values are "gone" from the predictor sequences. (This can take 20-30 GCs).
>
> The change modifies prediction so that only the first prediction will use these pre-baked values, after that use live values.
>
> This makes G1 adapt much more quickly to the current application/environment.
>
> The drawback is that there may be differences (including regressions) in out-of-box performance because the garbage collections heavily impact heap expansion, potentially expanding the heap much less, resulting in less throughput. I.e. we do more GCs during startup, causing higher cpu time ratio, expanding more.
>
> GC cpu usage is still well within allowed range wrt to cpu time ratio with the change.
>
> This also does not impact reasonable test setups.
>
> Testing: gha, internal performance benchmarks mostly show no change or improvements. There are some regressions that are "fixed" by setting min/max heap size indicating this is a heap sizing difference caused by differences due to faster startup.
>
> Hth,
> Thomas
LGTM!
-------------
Marked as reviewed by iwalulya (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/21518#pullrequestreview-2377500735
From shade at openjdk.org Fri Oct 18 09:19:31 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 18 Oct 2024 09:19:31 GMT
Subject: RFR: 8342588: Shenandoah: Pull shared closures together in one header
Message-ID: <jrhYA2e60xAZ6ytXp0Tojw0gL8Fs-ZJ5yitPn2Bmfp8=.3635c0be-86bb-41d8-a951-75b2bc43759d@github.com>
Currently we have shenandoahClosures.hpp and shenandoahOopClosures.hpp, each of which have some closure inside. There is no reason to have this separation, and we should really just merge everything in one header. I also did a bit of mechanical renames. There should be no semantic change with this patch.
Additional testing:
- [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`
-------------
Commit messages:
- Fix
Changes: https://git.openjdk.org/jdk/pull/21579/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21579&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8342588
Stats: 448 lines in 16 files changed: 188 ins; 234 del; 26 mod
Patch: https://git.openjdk.org/jdk/pull/21579.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/21579/head:pull/21579
PR: https://git.openjdk.org/jdk/pull/21579
From shade at openjdk.org Fri Oct 18 10:31:23 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 18 Oct 2024 10:31:23 GMT
Subject: RFR: 8342588: Shenandoah: Pull shared closures together in one
header [v2]
In-Reply-To: <jrhYA2e60xAZ6ytXp0Tojw0gL8Fs-ZJ5yitPn2Bmfp8=.3635c0be-86bb-41d8-a951-75b2bc43759d@github.com>
References: <jrhYA2e60xAZ6ytXp0Tojw0gL8Fs-ZJ5yitPn2Bmfp8=.3635c0be-86bb-41d8-a951-75b2bc43759d@github.com>
Message-ID: <14GqBlYL2XDV0k6WC1La5SmYLSAyYcf2FlVE4V75T2s=.bd5ddb3f-e520-44ef-85f9-22d498d5151e@github.com>
> Currently we have shenandoahClosures.hpp and shenandoahOopClosures.hpp, each of which have some closure inside. There is no reason to have this separation, and we should really just merge everything in one header. I also did a bit of mechanical renames. There should be no semantic change with this patch.
>
> Additional testing:
> - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`
Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
Fix Zero builds
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/21579/files
- new: https://git.openjdk.org/jdk/pull/21579/files/cbc94ff4..c9af382c
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=21579&range=01
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=21579&range=00-01
Stats: 12 lines in 2 files changed: 7 ins; 3 del; 2 mod
Patch: https://git.openjdk.org/jdk/pull/21579.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/21579/head:pull/21579
PR: https://git.openjdk.org/jdk/pull/21579
From stefank at openjdk.org Mon Oct 21 07:49:23 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 21 Oct 2024 07:49:23 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v46]
In-Reply-To: <TSoqyHiesRchgObQUULLugQ15WdZJlOp21VQTyxrEbQ=.fff7ec53-1145-40e1-90ed-af55b3defb5f@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<TSoqyHiesRchgObQUULLugQ15WdZJlOp21VQTyxrEbQ=.fff7ec53-1145-40e1-90ed-af55b3defb5f@github.com>
Message-ID: <GuER3Aj4WpJqyLXvCAolRt63PdXIQv-x6Q7V4wKc2iM=.1754df87-fcb5-4734-b181-288ce1f5b9b1@github.com>
On Thu, 17 Oct 2024 10:57:24 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>>
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>>
>> Main changes:
>> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>> - Arrays will now store their length at offset 8.
>> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>
> Compact header riscv (#3)
>
> Implement compact headers on RISCV
> ---------
>
> Co-authored-by: hamlin <hamlin at rivosinc.com>
The following test crashes `java/lang/StringBuffer/ECoreIndexOf.java#id1` when running with -XX:+UseCompactObjectHeaders.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2425878646
From stefank at openjdk.org Mon Oct 21 08:20:49 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 21 Oct 2024 08:20:49 GMT
Subject: RFR: 8342610: ZGC: Cleanup pre-touching code
Message-ID: <XH3QWfMEhsjjQGuBRhLNvcPe6MRAJgfphDS7GdwLlsE=.dd7696f4-644e-48df-bbcc-aede7f2f85c6@github.com>
There's a few things that we'd like to cleanup around the pre-touching code.
* Remove the dependency to ZPhysicalMemoryManager - cleans up the call site
* Remove unimplemented function pretouch_view (and its friends)
* Change type from zoffset for the iteration variable - multiple threads update it and it is not guaranteed to stay below the required ZAddressOffsetMax. I can trigger an assert here if I change the code to prime_cache in the higher address range instead of the lower and setting a max heap size that matches ZAddressOffsetMax.
-------------
Commit messages:
- 8342610: ZGC: Cleanup pre-touching code
Changes: https://git.openjdk.org/jdk/pull/21600/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21600&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8342610
Stats: 38 lines in 3 files changed: 12 ins; 14 del; 12 mod
Patch: https://git.openjdk.org/jdk/pull/21600.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/21600/head:pull/21600
PR: https://git.openjdk.org/jdk/pull/21600
From aboldtch at openjdk.org Mon Oct 21 09:12:50 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 21 Oct 2024 09:12:50 GMT
Subject: RFR: 8342610: ZGC: Cleanup pre-touching code
In-Reply-To: <XH3QWfMEhsjjQGuBRhLNvcPe6MRAJgfphDS7GdwLlsE=.dd7696f4-644e-48df-bbcc-aede7f2f85c6@github.com>
References: <XH3QWfMEhsjjQGuBRhLNvcPe6MRAJgfphDS7GdwLlsE=.dd7696f4-644e-48df-bbcc-aede7f2f85c6@github.com>
Message-ID: <Dkk109px2JPA70AgkS967-v3l91nzUHXXHnOgHz6-uM=.01bf75a0-0131-4f54-aaf0-122da33b4e78@github.com>
On Mon, 21 Oct 2024 08:15:16 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:
> There's a few things that we'd like to cleanup around the pre-touching code.
> * Remove the dependency to ZPhysicalMemoryManager - cleans up the call site
> * Remove unimplemented function pretouch_view (and its friends)
> * Change type from zoffset for the iteration variable - multiple threads update it and it is not guaranteed to stay below the required ZAddressOffsetMax. I can trigger an assert here if I change the code to prime_cache in the higher address range instead of the lower and setting a max heap size that matches ZAddressOffsetMax.
lgtm.
-------------
Marked as reviewed by aboldtch (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/21600#pullrequestreview-2381407369
From jsikstro at openjdk.org Mon Oct 21 09:17:00 2024
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Mon, 21 Oct 2024 09:17:00 GMT
Subject: RFR: 8342610: ZGC: Cleanup pre-touching code
In-Reply-To: <XH3QWfMEhsjjQGuBRhLNvcPe6MRAJgfphDS7GdwLlsE=.dd7696f4-644e-48df-bbcc-aede7f2f85c6@github.com>
References: <XH3QWfMEhsjjQGuBRhLNvcPe6MRAJgfphDS7GdwLlsE=.dd7696f4-644e-48df-bbcc-aede7f2f85c6@github.com>
Message-ID: <cWbv1OVNInBKeMgdh9-tasgiym63stXhma4dSa-O53Y=.56e6f7d3-18e9-4a8d-a689-67dba383d2a0@github.com>
On Mon, 21 Oct 2024 08:15:16 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:
> There's a few things that we'd like to cleanup around the pre-touching code.
> * Remove the dependency to ZPhysicalMemoryManager - cleans up the call site
> * Remove unimplemented function pretouch_view (and its friends)
> * Change type from zoffset for the iteration variable - multiple threads update it and it is not guaranteed to stay below the required ZAddressOffsetMax. I can trigger an assert here if I change the code to prime_cache in the higher address range instead of the lower and setting a max heap size that matches ZAddressOffsetMax.
Marked as reviewed by jsikstro (Author).
-------------
PR Review: https://git.openjdk.org/jdk/pull/21600#pullrequestreview-2381416949
From eosterlund at openjdk.org Mon Oct 21 09:24:45 2024
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Mon, 21 Oct 2024 09:24:45 GMT
Subject: RFR: 8342610: ZGC: Cleanup pre-touching code
In-Reply-To: <XH3QWfMEhsjjQGuBRhLNvcPe6MRAJgfphDS7GdwLlsE=.dd7696f4-644e-48df-bbcc-aede7f2f85c6@github.com>
References: <XH3QWfMEhsjjQGuBRhLNvcPe6MRAJgfphDS7GdwLlsE=.dd7696f4-644e-48df-bbcc-aede7f2f85c6@github.com>
Message-ID: <-V8-X4sTwCGeVvOc6DXxJzgiS8aKilUt0GNk1ebLRvA=.30c53931-d782-46df-9e8f-d87f3a6805fc@github.com>
On Mon, 21 Oct 2024 08:15:16 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:
> There's a few things that we'd like to cleanup around the pre-touching code.
> * Remove the dependency to ZPhysicalMemoryManager - cleans up the call site
> * Remove unimplemented function pretouch_view (and its friends)
> * Change type from zoffset for the iteration variable - multiple threads update it and it is not guaranteed to stay below the required ZAddressOffsetMax. I can trigger an assert here if I change the code to prime_cache in the higher address range instead of the lower and setting a max heap size that matches ZAddressOffsetMax.
Looks good.
-------------
Marked as reviewed by eosterlund (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/21600#pullrequestreview-2381437828
From jsikstro at openjdk.org Mon Oct 21 11:45:35 2024
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Mon, 21 Oct 2024 11:45:35 GMT
Subject: RFR: 8342102: ZGC: Optimize copy constructors in ZPhysicalMemory
[v2]
In-Reply-To: <D0iFuuLyJFmuikU0n7S_h62rh9M_iD4esWwlA9cJSfM=.559ef5a4-711e-41ef-8143-7e9789cd228e@github.com>
References: <5hvFKET_jLREXmQcM1LygpEEnBuYzIV5fOXXajE-OEk=.7625a7a0-2cbf-4f0b-a7c9-b772f20599f7@github.com>
<bjfAiew622Vyz2arQQk6boW3NrS-KqRgOdIB8raTlGw=.35abe8ad-ecdb-4eba-8ba4-c86a22c90e86@github.com>
<D0iFuuLyJFmuikU0n7S_h62rh9M_iD4esWwlA9cJSfM=.559ef5a4-711e-41ef-8143-7e9789cd228e@github.com>
Message-ID: <-Eti0hCroGKC90R3ol1OiTD7PJoOt1mAgCbtsYxrlmQ=.eb14f891-b56a-40e2-b111-8c2320b82ec4@github.com>
On Wed, 16 Oct 2024 08:25:39 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:
>> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
>>
>> Add check for self-assignment
>
> lgtm.
Thank you for the reviews! @xmas92 @abdelhak-zaaim @kimbarrett @stefank
-------------
PR Comment: https://git.openjdk.org/jdk/pull/21523#issuecomment-2426434911
From duke at openjdk.org Mon Oct 21 11:45:37 2024
From: duke at openjdk.org (duke)
Date: Mon, 21 Oct 2024 11:45:37 GMT
Subject: RFR: 8342102: ZGC: Optimize copy constructors in ZPhysicalMemory
[v2]
In-Reply-To: <bjfAiew622Vyz2arQQk6boW3NrS-KqRgOdIB8raTlGw=.35abe8ad-ecdb-4eba-8ba4-c86a22c90e86@github.com>
References: <5hvFKET_jLREXmQcM1LygpEEnBuYzIV5fOXXajE-OEk=.7625a7a0-2cbf-4f0b-a7c9-b772f20599f7@github.com>
<bjfAiew622Vyz2arQQk6boW3NrS-KqRgOdIB8raTlGw=.35abe8ad-ecdb-4eba-8ba4-c86a22c90e86@github.com>
Message-ID: <OededNKgGc77NnZJB7rnx276IipajkpByLr2pJpI4K8=.35045b5f-d179-45be-97c5-b62402ac7d65@github.com>
On Wed, 16 Oct 2024 08:29:48 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:
>> ZPhysicalMemory stores a sorted array of physical memory segments. Segments are added using either add_segments or add_segment, where the former calls add_segment on each individual segment. add_segment inserts segments in address order and also merges segments when possible.
>>
>> When copying an instance of ZPhysicalMemory, segments are currently copied using either add_segments or add_segment, which works as described above. This requires more work than necessary and should be simplified to account for the fact that the array of segments is always sorted.
>>
>> When copying, the copy constructors should instead use append or appendAll from the underlying GrowableArrayCHeap and also reserve enough memory so that the array's capacity is not increased more times than necessary during copying.
>>
>> Tested with tiers 1-3.
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
>
> Add check for self-assignment
@jsikstro
Your change (at version dedc1e0ccd988e3ec653e303c81aa8b09d0fff15) is now ready to be sponsored by a Committer.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/21523#issuecomment-2426435691
From stuefe at openjdk.org Mon Oct 21 12:21:17 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 21 Oct 2024 12:21:17 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v23]
In-Reply-To: <VjSp2vvwfzZWKtreZyiwjxsSblAX5JHCpF3c0mcYUHs=.b154b3dd-a8f2-4fdf-8176-52709f906891@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<0BrAbBTKmpqTGDrc--2znzO8t07yoqabwa6g2K05GHI=.d3c17fd5-4770-4623-8d2f-604816afc033@github.com>
<VjSp2vvwfzZWKtreZyiwjxsSblAX5JHCpF3c0mcYUHs=.b154b3dd-a8f2-4fdf-8176-52709f906891@github.com>
Message-ID: <7CtwplIs-ILCZhSpPwPtZr-GPCd_XxtOnYwku9zIQTY=.8d8a96e1-9627-4da6-ae57-b692e0580598@github.com>
On Fri, 20 Sep 2024 17:46:21 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:
>> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
>>
>> - Merge remote-tracking branch 'lilliput/JEP-450-temporary-fix-branch-2' into JDK-8305895-v4
>> - review feedback
>
> src/hotspot/share/memory/metaspace.cpp line 799:
>
>> 797:
>> 798: // Set up compressed class pointer encoding.
>> 799: // In CDS=off mode, we give the JVM some leeway to choose a favorable base/shift combination.
>
> I don't know why this comment is here. Seems out of place.
Its not, but maybe too vague.
There are two ways to initialize CompressedKlassPointers :
- `CompressedKlassPointers::initialize(address, size)` - called here - is used for no CDS case and allows the JVM to freely pick encoding base and shift.
- `CompressedKlassPointers::initialize_for_given_encoding` is called when encoding base and shift are predetermined (when using CDS). Then, the JVM has no freedom at all, it just does sanity checks.
The comment basically says "since here we are not using CDS, we are calling CompressedKlassPointers::initialize(address, size) to give the JVM some freedom when choosing encoding base and shift".
Is this clearer? Should I just remove the code?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1808683312
From stuefe at openjdk.org Mon Oct 21 12:53:13 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 21 Oct 2024 12:53:13 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v44]
In-Reply-To: <cQ6B7ZfZdJrEd_dsmQouGG3i45UcX_e_5f1K7fdvTuI=.82c67fe3-671a-4b1e-bfb1-979e65d56b19@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<logRSsOv-ZbKrosBAddqiXOOAcr-tMODEDmGksY6uJs=.ee83f2c3-2b57-41f5-b9f4-9b36811ced37@github.com>
<cQ6B7ZfZdJrEd_dsmQouGG3i45UcX_e_5f1K7fdvTuI=.82c67fe3-671a-4b1e-bfb1-979e65d56b19@github.com>
Message-ID: <rNbxLonojk0uB0Tg01JpxevDvOxQMG45LludjywTzNU=.3d69f1a5-38cb-441c-90ba-0b027e6bd46e@github.com>
On Wed, 16 Oct 2024 15:37:59 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:
>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>>
>> Problem-list SharedBaseAddress tests on aarch64
>
> src/hotspot/share/oops/compressedKlass.cpp line 185:
>
>> 183: #endif
>> 184:
>> 185: DEBUG_ONLY(sanity_check_after_initialization();)
>
> This is here twice.
sanity_check_after_initialization is called from both initialization routines, but we only call either one or the other.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1808735324
From ihse at openjdk.org Mon Oct 21 13:05:13 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 21 Oct 2024 13:05:13 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v46]
In-Reply-To: <TSoqyHiesRchgObQUULLugQ15WdZJlOp21VQTyxrEbQ=.fff7ec53-1145-40e1-90ed-af55b3defb5f@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<TSoqyHiesRchgObQUULLugQ15WdZJlOp21VQTyxrEbQ=.fff7ec53-1145-40e1-90ed-af55b3defb5f@github.com>
Message-ID: <irVXsRVBlVnhU-iZOsdNTZ7Kg-LU52sApukBUSe3qos=.f6f89542-8ec7-4026-97f6-ca4bde99bf73@github.com>
On Thu, 17 Oct 2024 10:57:24 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>>
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>>
>> Main changes:
>> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>> - Arrays will now store their length at offset 8.
>> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>
> Compact header riscv (#3)
>
> Implement compact headers on RISCV
> ---------
>
> Co-authored-by: hamlin <hamlin at rivosinc.com>
Marked as reviewed by ihse (Reviewer).
-------------
PR Review: https://git.openjdk.org/jdk/pull/20677#pullrequestreview-2382030332
From coleenp at openjdk.org Mon Oct 21 13:05:14 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 21 Oct 2024 13:05:14 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v46]
In-Reply-To: <TSoqyHiesRchgObQUULLugQ15WdZJlOp21VQTyxrEbQ=.fff7ec53-1145-40e1-90ed-af55b3defb5f@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<TSoqyHiesRchgObQUULLugQ15WdZJlOp21VQTyxrEbQ=.fff7ec53-1145-40e1-90ed-af55b3defb5f@github.com>
Message-ID: <5bn9rl6P9_im5yuUGUuMF6Pn8bcn8nHt1xX6q3b03L4=.0d8ed88a-9599-42b1-9eec-fbab93cf3e37@github.com>
On Thu, 17 Oct 2024 10:57:24 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>>
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>>
>> Main changes:
>> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>> - Arrays will now store their length at offset 8.
>> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>
> Compact header riscv (#3)
>
> Implement compact headers on RISCV
> ---------
>
> Co-authored-by: hamlin <hamlin at rivosinc.com>
I think a lot of copyright headers need to be updated.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2426605597
From stefank at openjdk.org Mon Oct 21 13:05:14 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 21 Oct 2024 13:05:14 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v46]
In-Reply-To: <TSoqyHiesRchgObQUULLugQ15WdZJlOp21VQTyxrEbQ=.fff7ec53-1145-40e1-90ed-af55b3defb5f@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<TSoqyHiesRchgObQUULLugQ15WdZJlOp21VQTyxrEbQ=.fff7ec53-1145-40e1-90ed-af55b3defb5f@github.com>
Message-ID: <ykhwOpVpX0wlLZaUM8N1c6NaMVH0hn9UfCikwoTrHkw=.d30174f6-2138-481c-9929-a475fd187a56@github.com>
On Thu, 17 Oct 2024 10:57:24 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>>
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>>
>> Main changes:
>> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>> - Arrays will now store their length at offset 8.
>> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>
> Compact header riscv (#3)
>
> Implement compact headers on RISCV
> ---------
>
> Co-authored-by: hamlin <hamlin at rivosinc.com>
I've managed to reproduce the ECoreIndexOf crash locally by running with -XX:+UseSerialGC -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders. The crash happens on line 773 when reading past the needle.
? 762 __ movq(index, needle_len);
?
? 763 __ andq(index, 0xf); // nLen % 16
? 764 __ movq(offset, 0x10);
? 765 __ subq(offset, index); // 16 - (nLen % 16)
? 766 __ movq(index, offset);
? 767 __ shlq(offset, 1); // * 2
? 768 __ negq(index); // -(16 - (nLen % 16))
?
? 769 __ xorq(wr_index, wr_index);
? 770
? 771 __ bind(L_top);
? 772 // load needle and expand
? 773 __ vpmovzxbw(xmm0, Address(needle, index, Address::times_1), Assembler::AVX_256bit);
We're reading this address:
(SEGV_MAPERR), si_addr: 0x00000007cffffffe
which is just before the start of the heap:
Heap address: 0x00000007d0000000, size: 768 MB, Compressed Oops mode: Zero based, Oop shift amount: 3
When this crashed I had:
needle: 0x00000007d000000c
needle_len = 0x12
index = 0xfffffffffffffffe
There has been previous fix to not read past the haystack:
Fix header < 16 bytes in indexOf intrinsic, by @sviswa7
https://github.com/openjdk/jdk/pull/20677/commits/f65ef5dc325212155a50a2fc3a7f4aad18b8d9d0
maybe we need something similar for the needle.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2426614072
From syan at openjdk.org Mon Oct 21 13:06:39 2024
From: syan at openjdk.org (SendaoYan)
Date: Mon, 21 Oct 2024 13:06:39 GMT
Subject: RFR: 8342681: TestLoadBypassesNullCheck.java fails improperly
specified VM option
Message-ID: <MiRErOAQLeXA530ui9cQvk0H7MFcauRmfW15WvoT5yI=.f95d2a38-1ca2-4acb-9ed7-94d094a8ccb6@github.com>
Hi all,
Newly added test `gc/shenandoah/compiler/TestLoadBypassesNullCheck.java` fails `The unlock option must precede 'StressGCM'.` with release jdk build. This PR fix the test bug.
The change has been verified locally with release/fastdebug/slowdebug on linux-x64. Test-fix only, no risk.
-------------
Commit messages:
- 8342681: TestLoadBypassesNullCheck.java fails improperly specified VM option
Changes: https://git.openjdk.org/jdk/pull/21609/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21609&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8342681
Stats: 6 lines in 1 file changed: 2 ins; 0 del; 4 mod
Patch: https://git.openjdk.org/jdk/pull/21609.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/21609/head:pull/21609
PR: https://git.openjdk.org/jdk/pull/21609
From jsikstro at openjdk.org Mon Oct 21 13:19:41 2024
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Mon, 21 Oct 2024 13:19:41 GMT
Subject: Integrated: 8342102: ZGC: Optimize copy constructors in
ZPhysicalMemory
In-Reply-To: <5hvFKET_jLREXmQcM1LygpEEnBuYzIV5fOXXajE-OEk=.7625a7a0-2cbf-4f0b-a7c9-b772f20599f7@github.com>
References: <5hvFKET_jLREXmQcM1LygpEEnBuYzIV5fOXXajE-OEk=.7625a7a0-2cbf-4f0b-a7c9-b772f20599f7@github.com>
Message-ID: <3os9WPSjo_NioGHzySNVFnR7GtEPclQinNLwVgHFqsk=.28ee1c78-5ec6-4697-a4df-0b5bc384a17e@github.com>
On Tue, 15 Oct 2024 11:50:13 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:
> ZPhysicalMemory stores a sorted array of physical memory segments. Segments are added using either add_segments or add_segment, where the former calls add_segment on each individual segment. add_segment inserts segments in address order and also merges segments when possible.
>
> When copying an instance of ZPhysicalMemory, segments are currently copied using either add_segments or add_segment, which works as described above. This requires more work than necessary and should be simplified to account for the fact that the array of segments is always sorted.
>
> When copying, the copy constructors should instead use append or appendAll from the underlying GrowableArrayCHeap and also reserve enough memory so that the array's capacity is not increased more times than necessary during copying.
>
> Tested with tiers 1-3.
This pull request has now been integrated.
Changeset: 1f357485
Author: Joel Sikstr?m <jsikstro at openjdk.org>
URL: https://git.openjdk.org/jdk/commit/1f3574855e79221739d8800235583b7c47ebae97
Stats: 12 lines in 1 file changed: 4 ins; 0 del; 8 mod
8342102: ZGC: Optimize copy constructors in ZPhysicalMemory
Reviewed-by: stefank, kbarrett, aboldtch
-------------
PR: https://git.openjdk.org/jdk/pull/21523
From rkennke at openjdk.org Mon Oct 21 13:56:35 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 21 Oct 2024 13:56:35 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v46]
In-Reply-To: <TSoqyHiesRchgObQUULLugQ15WdZJlOp21VQTyxrEbQ=.fff7ec53-1145-40e1-90ed-af55b3defb5f@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<TSoqyHiesRchgObQUULLugQ15WdZJlOp21VQTyxrEbQ=.fff7ec53-1145-40e1-90ed-af55b3defb5f@github.com>
Message-ID: <R_8ZEOsn1sMwBK_6ECrFRv98FrybuIgn1L3tlGFOvcg=.0b947263-39f3-483b-9526-e5fcea4ba603@github.com>
On Thu, 17 Oct 2024 10:57:24 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>>
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>>
>> Main changes:
>> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>> - Arrays will now store their length at offset 8.
>> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>
> Compact header riscv (#3)
>
> Implement compact headers on RISCV
> ---------
>
> Co-authored-by: hamlin <hamlin at rivosinc.com>
> I've managed to reproduce the ECoreIndexOf crash locally by running with -XX:+UseSerialGC -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders. The crash happens on line 773 when reading past the needle.
>
> ```
> ? 762 __ movq(index, needle_len);
> ?
> ? 763 __ andq(index, 0xf); // nLen % 16
> ? 764 __ movq(offset, 0x10);
> ? 765 __ subq(offset, index); // 16 - (nLen % 16)
> ? 766 __ movq(index, offset);
> ? 767 __ shlq(offset, 1); // * 2
> ? 768 __ negq(index); // -(16 - (nLen % 16))
> ?
> ? 769 __ xorq(wr_index, wr_index);
> ? 770
> ? 771 __ bind(L_top);
> ? 772 // load needle and expand
> ? 773 __ vpmovzxbw(xmm0, Address(needle, index, Address::times_1), Assembler::AVX_256bit);
> ```
>
> We're reading this address:
>
> ```
> (SEGV_MAPERR), si_addr: 0x00000007cffffffe
> ```
>
> which is just before the start of the heap:
>
> ```
> Heap address: 0x00000007d0000000, size: 768 MB, Compressed Oops mode: Zero based, Oop shift amount: 3
> ```
>
> When this crashed I had:
>
> ```
> needle: 0x00000007d000000c
> needle_len = 0x12
> index = 0xfffffffffffffffe
> ```
>
> There has been previous fix to not read past the haystack: Fix header < 16 bytes in indexOf intrinsic, by @sviswa7 [f65ef5d](https://github.com/openjdk/jdk/commit/f65ef5dc325212155a50a2fc3a7f4aad18b8d9d0)
>
> maybe we need something similar for the needle.
@sviswa7 @vpaprotsk could you have a look? If we can have a reasonable fix for this soon, we could ship it in this PR, otherwise I'd defer it to a follow-up issue and disable indexOf intrinsic when running with +UseCompactObjectHeaders.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2426754934
From duke at openjdk.org Mon Oct 21 14:23:53 2024
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Mon, 21 Oct 2024 14:23:53 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v46]
In-Reply-To: <R_8ZEOsn1sMwBK_6ECrFRv98FrybuIgn1L3tlGFOvcg=.0b947263-39f3-483b-9526-e5fcea4ba603@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<TSoqyHiesRchgObQUULLugQ15WdZJlOp21VQTyxrEbQ=.fff7ec53-1145-40e1-90ed-af55b3defb5f@github.com>
<R_8ZEOsn1sMwBK_6ECrFRv98FrybuIgn1L3tlGFOvcg=.0b947263-39f3-483b-9526-e5fcea4ba603@github.com>
Message-ID: <-mco1SNkDsaGs1iPfVA_rYxd2rjKseRvjMMMO1KkDog=.ca9caf95-e6c7-4456-ace6-183c4ef45554@github.com>
On Mon, 21 Oct 2024 13:53:58 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>>
>> Compact header riscv (#3)
>>
>> Implement compact headers on RISCV
>> ---------
>>
>> Co-authored-by: hamlin <hamlin at rivosinc.com>
>
>> I've managed to reproduce the ECoreIndexOf crash locally by running with -XX:+UseSerialGC -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders. The crash happens on line 773 when reading past the needle.
>>
>> ```
>> ? 762 __ movq(index, needle_len);
>> ?
>> ? 763 __ andq(index, 0xf); // nLen % 16
>> ? 764 __ movq(offset, 0x10);
>> ? 765 __ subq(offset, index); // 16 - (nLen % 16)
>> ? 766 __ movq(index, offset);
>> ? 767 __ shlq(offset, 1); // * 2
>> ? 768 __ negq(index); // -(16 - (nLen % 16))
>> ?
>> ? 769 __ xorq(wr_index, wr_index);
>> ? 770
>> ? 771 __ bind(L_top);
>> ? 772 // load needle and expand
>> ? 773 __ vpmovzxbw(xmm0, Address(needle, index, Address::times_1), Assembler::AVX_256bit);
>> ```
>>
>> We're reading this address:
>>
>> ```
>> (SEGV_MAPERR), si_addr: 0x00000007cffffffe
>> ```
>>
>> which is just before the start of the heap:
>>
>> ```
>> Heap address: 0x00000007d0000000, size: 768 MB, Compressed Oops mode: Zero based, Oop shift amount: 3
>> ```
>>
>> When this crashed I had:
>>
>> ```
>> needle: 0x00000007d000000c
>> needle_len = 0x12
>> index = 0xfffffffffffffffe
>> ```
>>
>> There has been previous fix to not read past the haystack: Fix header < 16 bytes in indexOf intrinsic, by @sviswa7 [f65ef5d](https://github.com/openjdk/jdk/commit/f65ef5dc325212155a50a2fc3a7f4aad18b8d9d0)
>>
>> maybe we need something similar for the needle.
>
> @sviswa7 @vpaprotsk could you have a look? If we can have a reasonable fix for this soon, we could ship it in this PR, otherwise I'd defer it to a follow-up issue and disable indexOf intrinsic when running with +UseCompactObjectHeaders.
@rkennke looking!
-------------
PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2426828440
From shade at openjdk.org Mon Oct 21 16:02:25 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 21 Oct 2024 16:02:25 GMT
Subject: RFR: 8342681: TestLoadBypassesNullCheck.java fails improperly
specified VM option
In-Reply-To: <MiRErOAQLeXA530ui9cQvk0H7MFcauRmfW15WvoT5yI=.f95d2a38-1ca2-4acb-9ed7-94d094a8ccb6@github.com>
References: <MiRErOAQLeXA530ui9cQvk0H7MFcauRmfW15WvoT5yI=.f95d2a38-1ca2-4acb-9ed7-94d094a8ccb6@github.com>
Message-ID: <7AWUBcjYaW3RPVrNFaw27Mj8JNn0OaOGK4BsoW7V32Q=.6233d51f-0df5-4cbd-b26c-44c3eb0227fb@github.com>
On Mon, 21 Oct 2024 13:00:23 GMT, SendaoYan <syan at openjdk.org> wrote:
> Hi all,
> Newly added test `gc/shenandoah/compiler/TestLoadBypassesNullCheck.java` fails `The unlock option must precede 'StressGCM'.` with release jdk build. This PR fix the test bug, only add `-XX:+UnlockDiagnosticVMOptions` to make test run passed by release jdk build.
> The change has been verified locally with release/fastdebug/slowdebug on linux-x64. Test-fix only, no risk.
Marked as reviewed by shade (Reviewer).
test/hotspot/jtreg/gc/shenandoah/compiler/TestLoadBypassesNullCheck.java line 33:
> 31: * @run main/othervm -XX:+UnlockDiagnosticVMOptions -XX:-TieredCompilation -XX:-UseOnStackReplacement -XX:-BackgroundCompilation
> 32: * -XX:+StressGCM -XX:+StressLCM -XX:+UseShenandoahGC -XX:LoopMaxUnroll=0 -XX:StressSeed=270847015
> 33: * TestLoadBypassesNullCheck
I am good with this fix, but if you have time to re-test it, consider reshuffling the arguments a bit, so that we only unlock what we need:
* @run main/othervm -XX:-TieredCompilation -XX:-UseOnStackReplacement -XX:-BackgroundCompilation
* -XX:+UseShenandoahGC -XX:LoopMaxUnroll=0
* -XX:+UnlockDiagnosticVMOptions -XX:+StressGCM -XX:+StressLCM -XX:StressSeed=270847015
* TestLoadBypassesNullCheck
-------------
PR Review: https://git.openjdk.org/jdk/pull/21609#pullrequestreview-2382559833
PR Review Comment: https://git.openjdk.org/jdk/pull/21609#discussion_r1809092713
From syan at openjdk.org Mon Oct 21 16:44:26 2024
From: syan at openjdk.org (SendaoYan)
Date: Mon, 21 Oct 2024 16:44:26 GMT
Subject: RFR: 8342681: TestLoadBypassesNullCheck.java fails improperly
specified VM option [v2]
In-Reply-To: <MiRErOAQLeXA530ui9cQvk0H7MFcauRmfW15WvoT5yI=.f95d2a38-1ca2-4acb-9ed7-94d094a8ccb6@github.com>
References: <MiRErOAQLeXA530ui9cQvk0H7MFcauRmfW15WvoT5yI=.f95d2a38-1ca2-4acb-9ed7-94d094a8ccb6@github.com>
Message-ID: <zae0V9b4ewNnnyGGFjsBDe0mIwpsFL3oTrSg6P1B5iQ=.66df7883-3c1e-4dcf-8125-6ced76fe4901@github.com>
> Hi all,
> Newly added test `gc/shenandoah/compiler/TestLoadBypassesNullCheck.java` fails `The unlock option must precede 'StressGCM'.` with release jdk build. This PR fix the test bug, only add `-XX:+UnlockDiagnosticVMOptions` to make test run passed by release jdk build.
> The change has been verified locally with release/fastdebug/slowdebug on linux-x64. Test-fix only, no risk.
SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
only unlock Stress* VM option
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/21609/files
- new: https://git.openjdk.org/jdk/pull/21609/files/43731b9e..b7237e8e
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=21609&range=01
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=21609&range=00-01
Stats: 6 lines in 1 file changed: 2 ins; 0 del; 4 mod
Patch: https://git.openjdk.org/jdk/pull/21609.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/21609/head:pull/21609
PR: https://git.openjdk.org/jdk/pull/21609
From syan at openjdk.org Mon Oct 21 16:48:17 2024
From: syan at openjdk.org (SendaoYan)
Date: Mon, 21 Oct 2024 16:48:17 GMT
Subject: RFR: 8342681: TestLoadBypassesNullCheck.java fails improperly
specified VM option [v2]
In-Reply-To: <7AWUBcjYaW3RPVrNFaw27Mj8JNn0OaOGK4BsoW7V32Q=.6233d51f-0df5-4cbd-b26c-44c3eb0227fb@github.com>
References: <MiRErOAQLeXA530ui9cQvk0H7MFcauRmfW15WvoT5yI=.f95d2a38-1ca2-4acb-9ed7-94d094a8ccb6@github.com>
<7AWUBcjYaW3RPVrNFaw27Mj8JNn0OaOGK4BsoW7V32Q=.6233d51f-0df5-4cbd-b26c-44c3eb0227fb@github.com>
Message-ID: <KEpK5OPhcm1-7oCo74bAWBhnOz-ilHLe499C8ge19Cg=.cec3ad6f-c742-4da5-9525-877cec3bcae8@github.com>
On Mon, 21 Oct 2024 15:59:43 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:
>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>>
>> only unlock Stress* VM option
>
> test/hotspot/jtreg/gc/shenandoah/compiler/TestLoadBypassesNullCheck.java line 33:
>
>> 31: * @run main/othervm -XX:+UnlockDiagnosticVMOptions -XX:-TieredCompilation -XX:-UseOnStackReplacement -XX:-BackgroundCompilation
>> 32: * -XX:+StressGCM -XX:+StressLCM -XX:+UseShenandoahGC -XX:LoopMaxUnroll=0 -XX:StressSeed=270847015
>> 33: * TestLoadBypassesNullCheck
>
> I am good with this fix, but if you have time to re-test it, consider reshuffling the arguments a bit, so that we only unlock what we need:
>
>
> * @run main/othervm -XX:-TieredCompilation -XX:-UseOnStackReplacement -XX:-BackgroundCompilation
> * -XX:+UseShenandoahGC -XX:LoopMaxUnroll=0
> * -XX:+UnlockDiagnosticVMOptions -XX:+StressGCM -XX:+StressLCM -XX:StressSeed=270847015
> * TestLoadBypassesNullCheck
Thanks for your correction, arguments has been argument reshuffled.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/21609#discussion_r1809156369
From duke at openjdk.org Mon Oct 21 16:56:35 2024
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Mon, 21 Oct 2024 16:56:35 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v46]
In-Reply-To: <R_8ZEOsn1sMwBK_6ECrFRv98FrybuIgn1L3tlGFOvcg=.0b947263-39f3-483b-9526-e5fcea4ba603@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<TSoqyHiesRchgObQUULLugQ15WdZJlOp21VQTyxrEbQ=.fff7ec53-1145-40e1-90ed-af55b3defb5f@github.com>
<R_8ZEOsn1sMwBK_6ECrFRv98FrybuIgn1L3tlGFOvcg=.0b947263-39f3-483b-9526-e5fcea4ba603@github.com>
Message-ID: <xuz6jeipBqArYVTgblHr2g9l8UCmFrXf8M_3oMJjQZo=.7abd3294-a20e-4605-abc8-d40cd7c6d5a4@github.com>
On Mon, 21 Oct 2024 13:53:58 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>>
>> Compact header riscv (#3)
>>
>> Implement compact headers on RISCV
>> ---------
>>
>> Co-authored-by: hamlin <hamlin at rivosinc.com>
>
>> I've managed to reproduce the ECoreIndexOf crash locally by running with -XX:+UseSerialGC -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders. The crash happens on line 773 when reading past the needle.
>>
>> ```
>> ? 762 __ movq(index, needle_len);
>> ?
>> ? 763 __ andq(index, 0xf); // nLen % 16
>> ? 764 __ movq(offset, 0x10);
>> ? 765 __ subq(offset, index); // 16 - (nLen % 16)
>> ? 766 __ movq(index, offset);
>> ? 767 __ shlq(offset, 1); // * 2
>> ? 768 __ negq(index); // -(16 - (nLen % 16))
>> ?
>> ? 769 __ xorq(wr_index, wr_index);
>> ? 770
>> ? 771 __ bind(L_top);
>> ? 772 // load needle and expand
>> ? 773 __ vpmovzxbw(xmm0, Address(needle, index, Address::times_1), Assembler::AVX_256bit);
>> ```
>>
>> We're reading this address:
>>
>> ```
>> (SEGV_MAPERR), si_addr: 0x00000007cffffffe
>> ```
>>
>> which is just before the start of the heap:
>>
>> ```
>> Heap address: 0x00000007d0000000, size: 768 MB, Compressed Oops mode: Zero based, Oop shift amount: 3
>> ```
>>
>> When this crashed I had:
>>
>> ```
>> needle: 0x00000007d000000c
>> needle_len = 0x12
>> index = 0xfffffffffffffffe
>> ```
>>
>> There has been previous fix to not read past the haystack: Fix header < 16 bytes in indexOf intrinsic, by @sviswa7 [f65ef5d](https://github.com/openjdk/jdk/commit/f65ef5dc325212155a50a2fc3a7f4aad18b8d9d0)
>>
>> maybe we need something similar for the needle.
>
> @sviswa7 @vpaprotsk could you have a look? If we can have a reasonable fix for this soon, we could ship it in this PR, otherwise I'd defer it to a follow-up issue and disable indexOf intrinsic when running with +UseCompactObjectHeaders.
@rkennke Could you post the full command you used please? And perhaps also the seed that gets printed.. having trouble getting it to fail..
So far I added a few options and perrmitations of: `./build/linux-x86_64-server-fastdebug/images/jdk/bin/java -Xcomp -XX:-TieredCompilation -XX:+UnlockDiagnosticVMOptions -XX:+EnableX86ECoreOpts -XX:+UseSerialGC -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders test/jdk/java/lang/StringBuffer/ECoreIndexOf.java` and lo luck.. IndexOf.java test checks "all interesting" lengths of haystack and needle and can't get it to fail either.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2427232140
From shade at openjdk.org Mon Oct 21 17:16:14 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 21 Oct 2024 17:16:14 GMT
Subject: RFR: 8342681: TestLoadBypassesNullCheck.java fails improperly
specified VM option [v2]
In-Reply-To: <zae0V9b4ewNnnyGGFjsBDe0mIwpsFL3oTrSg6P1B5iQ=.66df7883-3c1e-4dcf-8125-6ced76fe4901@github.com>
References: <MiRErOAQLeXA530ui9cQvk0H7MFcauRmfW15WvoT5yI=.f95d2a38-1ca2-4acb-9ed7-94d094a8ccb6@github.com>
<zae0V9b4ewNnnyGGFjsBDe0mIwpsFL3oTrSg6P1B5iQ=.66df7883-3c1e-4dcf-8125-6ced76fe4901@github.com>
Message-ID: <4WzxRQ2msIu_FM_u_wus9_8y3YrAaG-L3oR812lVcA8=.3508a1ce-7da4-4822-b71e-087a81cf7958@github.com>
On Mon, 21 Oct 2024 16:44:26 GMT, SendaoYan <syan at openjdk.org> wrote:
>> Hi all,
>> Newly added test `gc/shenandoah/compiler/TestLoadBypassesNullCheck.java` fails `The unlock option must precede 'StressGCM'.` with release jdk build. This PR fix the test bug, only add `-XX:+UnlockDiagnosticVMOptions` to make test run passed by release jdk build.
>> The change has been verified locally with release/fastdebug/slowdebug on linux-x64. Test-fix only, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>
> only unlock Stress* VM option
Thank you!
-------------
Marked as reviewed by shade (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/21609#pullrequestreview-2382778280
From rkennke at openjdk.org Mon Oct 21 18:04:53 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 21 Oct 2024 18:04:53 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v46]
In-Reply-To: <R_8ZEOsn1sMwBK_6ECrFRv98FrybuIgn1L3tlGFOvcg=.0b947263-39f3-483b-9526-e5fcea4ba603@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<TSoqyHiesRchgObQUULLugQ15WdZJlOp21VQTyxrEbQ=.fff7ec53-1145-40e1-90ed-af55b3defb5f@github.com>
<R_8ZEOsn1sMwBK_6ECrFRv98FrybuIgn1L3tlGFOvcg=.0b947263-39f3-483b-9526-e5fcea4ba603@github.com>
Message-ID: <BCZjoP4Ao9C1F8kQJmpfooJCnGx3Ef-YNKGHdqZMSCs=.234de599-a258-45ec-9e63-7839f3a48e54@github.com>
On Mon, 21 Oct 2024 13:53:58 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>>
>> Compact header riscv (#3)
>>
>> Implement compact headers on RISCV
>> ---------
>>
>> Co-authored-by: hamlin <hamlin at rivosinc.com>
>
>> I've managed to reproduce the ECoreIndexOf crash locally by running with -XX:+UseSerialGC -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders. The crash happens on line 773 when reading past the needle.
>>
>> ```
>> ? 762 __ movq(index, needle_len);
>> ?
>> ? 763 __ andq(index, 0xf); // nLen % 16
>> ? 764 __ movq(offset, 0x10);
>> ? 765 __ subq(offset, index); // 16 - (nLen % 16)
>> ? 766 __ movq(index, offset);
>> ? 767 __ shlq(offset, 1); // * 2
>> ? 768 __ negq(index); // -(16 - (nLen % 16))
>> ?
>> ? 769 __ xorq(wr_index, wr_index);
>> ? 770
>> ? 771 __ bind(L_top);
>> ? 772 // load needle and expand
>> ? 773 __ vpmovzxbw(xmm0, Address(needle, index, Address::times_1), Assembler::AVX_256bit);
>> ```
>>
>> We're reading this address:
>>
>> ```
>> (SEGV_MAPERR), si_addr: 0x00000007cffffffe
>> ```
>>
>> which is just before the start of the heap:
>>
>> ```
>> Heap address: 0x00000007d0000000, size: 768 MB, Compressed Oops mode: Zero based, Oop shift amount: 3
>> ```
>>
>> When this crashed I had:
>>
>> ```
>> needle: 0x00000007d000000c
>> needle_len = 0x12
>> index = 0xfffffffffffffffe
>> ```
>>
>> There has been previous fix to not read past the haystack: Fix header < 16 bytes in indexOf intrinsic, by @sviswa7 [f65ef5d](https://github.com/openjdk/jdk/commit/f65ef5dc325212155a50a2fc3a7f4aad18b8d9d0)
>>
>> maybe we need something similar for the needle.
>
> @sviswa7 @vpaprotsk could you have a look? If we can have a reasonable fix for this soon, we could ship it in this PR, otherwise I'd defer it to a follow-up issue and disable indexOf intrinsic when running with +UseCompactObjectHeaders.
> @rkennke Could you post the full command you used please? And perhaps also the seed that gets printed.. having trouble getting it to fail..
>
> So far I added a few options and perrmitations of: `./build/linux-x86_64-server-fastdebug/images/jdk/bin/java -Xcomp -XX:-TieredCompilation -XX:+UnlockDiagnosticVMOptions -XX:+EnableX86ECoreOpts -XX:+UseSerialGC -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders test/jdk/java/lang/StringBuffer/ECoreIndexOf.java` and lo luck.. IndexOf.java test checks "all interesting" lengths of haystack and needle and can't get it to fail either.
I could reproduce on 3rd try with a fastdebug build with:
make test TEST=java/lang/StringBuffer/ECoreIndexOf.java TEST_VM_OPTS="-XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders -XX:+UseSerialGC"
It prints:
Seed set to 636754923980405411
It probably depends on GC operation: It would only fail when the array happens to be the very first object in the heap. The relevant GC/heap configs would be:
InitialHeapSize = 805306368
MaxHeapSize = 805306368
MaxNewSize = 268435456
So you should probably also add `-Xmx805306368 -Xms805306368 -Xmn268435456`
-------------
PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2427375886
From bpb at openjdk.org Mon Oct 21 18:26:41 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 21 Oct 2024 18:26:41 GMT
Subject: RFR: 8340728: Test vmTestbase/gc/memory/Nio/Nio.java is failing to
allocate all direct buffer memory
Message-ID: <H8qu4AgyLXV3JAEqy3ZpyOyFC3pIvFFg4Aiy0cTgrwg=.c463eaa1-71c2-4a07-be0e-15169e2a7568@github.com>
First attempt to allocate `VM.maxDirectMemory()` bytes of direct buffer memory, decreasing by 1024 bytes for each `OutOfMemoryError` until allocation succeeds.
-------------
Commit messages:
- 8340728: Test vmTestbase/gc/memory/Nio/Nio.java is failing to allocate all direct buffer memory
Changes: https://git.openjdk.org/jdk/pull/21623/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21623&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8340728
Stats: 25 lines in 2 files changed: 10 ins; 1 del; 14 mod
Patch: https://git.openjdk.org/jdk/pull/21623.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/21623/head:pull/21623
PR: https://git.openjdk.org/jdk/pull/21623
From bpb at openjdk.org Mon Oct 21 18:26:41 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 21 Oct 2024 18:26:41 GMT
Subject: RFR: 8340728: Test vmTestbase/gc/memory/Nio/Nio.java is failing to
allocate all direct buffer memory
In-Reply-To: <H8qu4AgyLXV3JAEqy3ZpyOyFC3pIvFFg4Aiy0cTgrwg=.c463eaa1-71c2-4a07-be0e-15169e2a7568@github.com>
References: <H8qu4AgyLXV3JAEqy3ZpyOyFC3pIvFFg4Aiy0cTgrwg=.c463eaa1-71c2-4a07-be0e-15169e2a7568@github.com>
Message-ID: <lTTle-dNZEUOBwtSKFuYMAjNXY3KRnug4KGtSAH9yGk=.19e9b12e-9daa-47fc-a3dc-a721d9a8c03d@github.com>
On Mon, 21 Oct 2024 18:22:03 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:
> First attempt to allocate `VM.maxDirectMemory()` bytes of direct buffer memory, decreasing by 1024 bytes for each `OutOfMemoryError` until allocation succeeds.
This passed 20 repeats on all CI platforms against an internal build created within the last 24 hours.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/21623#issuecomment-2427417969
From duke at openjdk.org Mon Oct 21 18:55:52 2024
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Mon, 21 Oct 2024 18:55:52 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v46]
In-Reply-To: <BCZjoP4Ao9C1F8kQJmpfooJCnGx3Ef-YNKGHdqZMSCs=.234de599-a258-45ec-9e63-7839f3a48e54@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<TSoqyHiesRchgObQUULLugQ15WdZJlOp21VQTyxrEbQ=.fff7ec53-1145-40e1-90ed-af55b3defb5f@github.com>
<R_8ZEOsn1sMwBK_6ECrFRv98FrybuIgn1L3tlGFOvcg=.0b947263-39f3-483b-9526-e5fcea4ba603@github.com>
<BCZjoP4Ao9C1F8kQJmpfooJCnGx3Ef-YNKGHdqZMSCs=.234de599-a258-45ec-9e63-7839f3a48e54@github.com>
Message-ID: <NN3GcO1kEKz8t-s1nwOkHjwhaO0Gy_Jgyo0oyH-Z_cU=.4fd9a5da-6f34-4343-ba41-3efbcbf826fc@github.com>
On Mon, 21 Oct 2024 18:00:14 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
>>> I've managed to reproduce the ECoreIndexOf crash locally by running with -XX:+UseSerialGC -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders. The crash happens on line 773 when reading past the needle.
>>>
>>> ```
>>> ? 762 __ movq(index, needle_len);
>>> ?
>>> ? 763 __ andq(index, 0xf); // nLen % 16
>>> ? 764 __ movq(offset, 0x10);
>>> ? 765 __ subq(offset, index); // 16 - (nLen % 16)
>>> ? 766 __ movq(index, offset);
>>> ? 767 __ shlq(offset, 1); // * 2
>>> ? 768 __ negq(index); // -(16 - (nLen % 16))
>>> ?
>>> ? 769 __ xorq(wr_index, wr_index);
>>> ? 770
>>> ? 771 __ bind(L_top);
>>> ? 772 // load needle and expand
>>> ? 773 __ vpmovzxbw(xmm0, Address(needle, index, Address::times_1), Assembler::AVX_256bit);
>>> ```
>>>
>>> We're reading this address:
>>>
>>> ```
>>> (SEGV_MAPERR), si_addr: 0x00000007cffffffe
>>> ```
>>>
>>> which is just before the start of the heap:
>>>
>>> ```
>>> Heap address: 0x00000007d0000000, size: 768 MB, Compressed Oops mode: Zero based, Oop shift amount: 3
>>> ```
>>>
>>> When this crashed I had:
>>>
>>> ```
>>> needle: 0x00000007d000000c
>>> needle_len = 0x12
>>> index = 0xfffffffffffffffe
>>> ```
>>>
>>> There has been previous fix to not read past the haystack: Fix header < 16 bytes in indexOf intrinsic, by @sviswa7 [f65ef5d](https://github.com/openjdk/jdk/commit/f65ef5dc325212155a50a2fc3a7f4aad18b8d9d0)
>>>
>>> maybe we need something similar for the needle.
>>
>> @sviswa7 @vpaprotsk could you have a look? If we can have a reasonable fix for this soon, we could ship it in this PR, otherwise I'd defer it to a follow-up issue and disable indexOf intrinsic when running with +UseCompactObjectHeaders.
>
>> @rkennke Could you post the full command you used please? And perhaps also the seed that gets printed.. having trouble getting it to fail..
>>
>> So far I added a few options and perrmitations of: `./build/linux-x86_64-server-fastdebug/images/jdk/bin/java -Xcomp -XX:-TieredCompilation -XX:+UnlockDiagnosticVMOptions -XX:+EnableX86ECoreOpts -XX:+UseSerialGC -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders test/jdk/java/lang/StringBuffer/ECoreIndexOf.java` and lo luck.. IndexOf.java test checks "all interesting" lengths of haystack and needle and can't get it to fail either.
>
> I could reproduce on 3rd try with a fastdebug build with:
>
> make test TEST=java/lang/StringBuffer/ECoreIndexOf.java TEST_VM_OPTS="-XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders -XX:+UseSerialGC"
>
>
> It prints:
>
> Seed set to 636754923980405411
>
>
> It probably depends on GC operation: It would only fail when the array happens to be the very first object in the heap. The relevant GC/heap configs would be:
>
> InitialHeapSize = 805306368
> MaxHeapSize = 805306368
> MaxNewSize = 268435456
>
>
> So you should probably also add `-Xmx805306368 -Xms805306368 -Xmn268435456`
Thanks @rkennke able to reproduce now.. Sandhya will have a patch soon and I will re-verify
-------------
PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2427477113
From sviswanathan at openjdk.org Mon Oct 21 19:26:39 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Mon, 21 Oct 2024 19:26:39 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v46]
In-Reply-To: <NN3GcO1kEKz8t-s1nwOkHjwhaO0Gy_Jgyo0oyH-Z_cU=.4fd9a5da-6f34-4343-ba41-3efbcbf826fc@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<TSoqyHiesRchgObQUULLugQ15WdZJlOp21VQTyxrEbQ=.fff7ec53-1145-40e1-90ed-af55b3defb5f@github.com>
<R_8ZEOsn1sMwBK_6ECrFRv98FrybuIgn1L3tlGFOvcg=.0b947263-39f3-483b-9526-e5fcea4ba603@github.com>
<BCZjoP4Ao9C1F8kQJmpfooJCnGx3Ef-YNKGHdqZMSCs=.234de599-a258-45ec-9e63-7839f3a48e54@github.com>
<NN3GcO1kEKz8t-s1nwOkHjwhaO0Gy_Jgyo0oyH-Z_cU=.4fd9a5da-6f34-4343-ba41-3efbcbf826fc@github.com>
Message-ID: <QzE3fKHgOAo9Jpsq7O_cer2evaHfByqgdv5bSU09-08=.6c26375c-26a1-40a9-bb8c-432e2a93c860@github.com>
On Mon, 21 Oct 2024 18:52:46 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:
> Thanks @rkennke able to reproduce now.. Sandhya will have a patch soon and I will re-verify
@rkennke @vpaprotsk Please find attached the patch which should fix the problem.
[smallneedlefix.patch](https://github.com/user-attachments/files/17466073/smallneedlefix.patch)
-------------
PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2427536012
From rkennke at openjdk.org Mon Oct 21 20:34:41 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 21 Oct 2024 20:34:41 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v46]
In-Reply-To: <BCZjoP4Ao9C1F8kQJmpfooJCnGx3Ef-YNKGHdqZMSCs=.234de599-a258-45ec-9e63-7839f3a48e54@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<TSoqyHiesRchgObQUULLugQ15WdZJlOp21VQTyxrEbQ=.fff7ec53-1145-40e1-90ed-af55b3defb5f@github.com>
<R_8ZEOsn1sMwBK_6ECrFRv98FrybuIgn1L3tlGFOvcg=.0b947263-39f3-483b-9526-e5fcea4ba603@github.com>
<BCZjoP4Ao9C1F8kQJmpfooJCnGx3Ef-YNKGHdqZMSCs=.234de599-a258-45ec-9e63-7839f3a48e54@github.com>
Message-ID: <qXNHwb48lt9LL_DePcb6QLEE0d_rsPQGzI_Bz5Swyzc=.e2d2f513-816d-4bf2-9dbd-67fb74522cfd@github.com>
On Mon, 21 Oct 2024 18:00:14 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
>>> I've managed to reproduce the ECoreIndexOf crash locally by running with -XX:+UseSerialGC -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders. The crash happens on line 773 when reading past the needle.
>>>
>>> ```
>>> ? 762 __ movq(index, needle_len);
>>> ?
>>> ? 763 __ andq(index, 0xf); // nLen % 16
>>> ? 764 __ movq(offset, 0x10);
>>> ? 765 __ subq(offset, index); // 16 - (nLen % 16)
>>> ? 766 __ movq(index, offset);
>>> ? 767 __ shlq(offset, 1); // * 2
>>> ? 768 __ negq(index); // -(16 - (nLen % 16))
>>> ?
>>> ? 769 __ xorq(wr_index, wr_index);
>>> ? 770
>>> ? 771 __ bind(L_top);
>>> ? 772 // load needle and expand
>>> ? 773 __ vpmovzxbw(xmm0, Address(needle, index, Address::times_1), Assembler::AVX_256bit);
>>> ```
>>>
>>> We're reading this address:
>>>
>>> ```
>>> (SEGV_MAPERR), si_addr: 0x00000007cffffffe
>>> ```
>>>
>>> which is just before the start of the heap:
>>>
>>> ```
>>> Heap address: 0x00000007d0000000, size: 768 MB, Compressed Oops mode: Zero based, Oop shift amount: 3
>>> ```
>>>
>>> When this crashed I had:
>>>
>>> ```
>>> needle: 0x00000007d000000c
>>> needle_len = 0x12
>>> index = 0xfffffffffffffffe
>>> ```
>>>
>>> There has been previous fix to not read past the haystack: Fix header < 16 bytes in indexOf intrinsic, by @sviswa7 [f65ef5d](https://github.com/openjdk/jdk/commit/f65ef5dc325212155a50a2fc3a7f4aad18b8d9d0)
>>>
>>> maybe we need something similar for the needle.
>>
>> @sviswa7 @vpaprotsk could you have a look? If we can have a reasonable fix for this soon, we could ship it in this PR, otherwise I'd defer it to a follow-up issue and disable indexOf intrinsic when running with +UseCompactObjectHeaders.
>
>> @rkennke Could you post the full command you used please? And perhaps also the seed that gets printed.. having trouble getting it to fail..
>>
>> So far I added a few options and perrmitations of: `./build/linux-x86_64-server-fastdebug/images/jdk/bin/java -Xcomp -XX:-TieredCompilation -XX:+UnlockDiagnosticVMOptions -XX:+EnableX86ECoreOpts -XX:+UseSerialGC -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders test/jdk/java/lang/StringBuffer/ECoreIndexOf.java` and lo luck.. IndexOf.java test checks "all interesting" lengths of haystack and needle and can't get it to fail either.
>
> I could reproduce on 3rd try with a fastdebug build with:
>
> make test TEST=java/lang/StringBuffer/ECoreIndexOf.java TEST_VM_OPTS="-XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders -XX:+UseSerialGC"
>
>
> It prints:
>
> Seed set to 636754923980405411
>
>
> It probably depends on GC operation: It would only fail when the array happens to be the very first object in the heap. The relevant GC/heap configs would be:
>
> InitialHeapSize = 805306368
> MaxHeapSize = 805306368
> MaxNewSize = 268435456
>
>
> So you should probably also add `-Xmx805306368 -Xms805306368 -Xmn268435456`
> > Thanks @rkennke able to reproduce now.. Sandhya will have a patch soon and I will re-verify
>
> @rkennke @vpaprotsk Please find attached the patch which should fix the problem.
>
> [smallneedlefix.patch](https://github.com/user-attachments/files/17466073/smallneedlefix.patch)
Testing now. Runs the reproducer in a loop since half an hour without crashing. I'll let it run overnight, and if @vpaprotsk approves the changes, then I'll intergrate them tomorrow morning.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2427660618
From wkemper at openjdk.org Mon Oct 21 21:04:14 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 21 Oct 2024 21:04:14 GMT
Subject: RFR: 8342588: Shenandoah: Pull shared closures together in one
header [v2]
In-Reply-To: <14GqBlYL2XDV0k6WC1La5SmYLSAyYcf2FlVE4V75T2s=.bd5ddb3f-e520-44ef-85f9-22d498d5151e@github.com>
References: <jrhYA2e60xAZ6ytXp0Tojw0gL8Fs-ZJ5yitPn2Bmfp8=.3635c0be-86bb-41d8-a951-75b2bc43759d@github.com>
<14GqBlYL2XDV0k6WC1La5SmYLSAyYcf2FlVE4V75T2s=.bd5ddb3f-e520-44ef-85f9-22d498d5151e@github.com>
Message-ID: <Y-Wafdtm1hK0TCP5-pknaeZNekGcx8BipT609RYZRzo=.39b9b5cd-91ed-4498-b327-a90ebffb22d5@github.com>
On Fri, 18 Oct 2024 10:31:23 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:
>> Currently we have shenandoahClosures.hpp and shenandoahOopClosures.hpp, each of which have some closure inside. There is no reason to have this separation, and we should really just merge everything in one header. I also did a bit of mechanical renames. There should be no semantic change with this patch.
>>
>> Additional testing:
>> - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>
> Fix Zero builds
Marked as reviewed by wkemper (Committer).
-------------
PR Review: https://git.openjdk.org/jdk/pull/21579#pullrequestreview-2383303701
From duke at openjdk.org Mon Oct 21 21:09:38 2024
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Mon, 21 Oct 2024 21:09:38 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v46]
In-Reply-To: <qXNHwb48lt9LL_DePcb6QLEE0d_rsPQGzI_Bz5Swyzc=.e2d2f513-816d-4bf2-9dbd-67fb74522cfd@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<TSoqyHiesRchgObQUULLugQ15WdZJlOp21VQTyxrEbQ=.fff7ec53-1145-40e1-90ed-af55b3defb5f@github.com>
<R_8ZEOsn1sMwBK_6ECrFRv98FrybuIgn1L3tlGFOvcg=.0b947263-39f3-483b-9526-e5fcea4ba603@github.com>
<BCZjoP4Ao9C1F8kQJmpfooJCnGx3Ef-YNKGHdqZMSCs=.234de599-a258-45ec-9e63-7839f3a48e54@github.com>
<qXNHwb48lt9LL_DePcb6QLEE0d_rsPQGzI_Bz5Swyzc=.e2d2f513-816d-4bf2-9dbd-67fb74522cfd@github.com>
Message-ID: <fBZr5Zvvl4oTLcO62RFVv9emvEccDwESuB7nNoc8HfI=.a09a0b4b-53a9-4808-9dcd-f0b877e73759@github.com>
On Mon, 21 Oct 2024 20:31:28 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
>>> @rkennke Could you post the full command you used please? And perhaps also the seed that gets printed.. having trouble getting it to fail..
>>>
>>> So far I added a few options and perrmitations of: `./build/linux-x86_64-server-fastdebug/images/jdk/bin/java -Xcomp -XX:-TieredCompilation -XX:+UnlockDiagnosticVMOptions -XX:+EnableX86ECoreOpts -XX:+UseSerialGC -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders test/jdk/java/lang/StringBuffer/ECoreIndexOf.java` and lo luck.. IndexOf.java test checks "all interesting" lengths of haystack and needle and can't get it to fail either.
>>
>> I could reproduce on 3rd try with a fastdebug build with:
>>
>> make test TEST=java/lang/StringBuffer/ECoreIndexOf.java TEST_VM_OPTS="-XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders -XX:+UseSerialGC"
>>
>>
>> It prints:
>>
>> Seed set to 636754923980405411
>>
>>
>> It probably depends on GC operation: It would only fail when the array happens to be the very first object in the heap. The relevant GC/heap configs would be:
>>
>> InitialHeapSize = 805306368
>> MaxHeapSize = 805306368
>> MaxNewSize = 268435456
>>
>>
>> So you should probably also add `-Xmx805306368 -Xms805306368 -Xmn268435456`
>
>> > Thanks @rkennke able to reproduce now.. Sandhya will have a patch soon and I will re-verify
>>
>> @rkennke @vpaprotsk Please find attached the patch which should fix the problem.
>>
>> [smallneedlefix.patch](https://github.com/user-attachments/files/17466073/smallneedlefix.patch)
>
> Testing now. Runs the reproducer in a loop since half an hour without crashing. I'll let it run overnight, and if @vpaprotsk approves the changes, then I'll intergrate them tomorrow morning.
@rkennke I've been running the patch too, for about 2.5 hours now, looks good to me.
Also looked things over again, looks good. Just to explain/document what I reviewed..
- Looked at other uses of the needle (that code didn't change, so not exhaustive claim). Typically size of the needle being less then 16 'doesnt matter'.. i.e. broadcast first char, last char, if first/last character mask matches, switch-table for comparing middle
- i.e. no reading headers needed
- The case Sandhya fixes, handles UL special case (i.e. haystack unicode, needle regular). For cases of needle less then 32 bytes, copy the needle to the stack, and expand 8->16 so regular UU code can be used. Previous code looped 256bit loads at a time, now we loop 128 instead.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2427718674
From syan at openjdk.org Tue Oct 22 02:12:22 2024
From: syan at openjdk.org (SendaoYan)
Date: Tue, 22 Oct 2024 02:12:22 GMT
Subject: RFR: 8342681: TestLoadBypassesNullCheck.java fails improperly
specified VM option [v2]
In-Reply-To: <zae0V9b4ewNnnyGGFjsBDe0mIwpsFL3oTrSg6P1B5iQ=.66df7883-3c1e-4dcf-8125-6ced76fe4901@github.com>
References: <MiRErOAQLeXA530ui9cQvk0H7MFcauRmfW15WvoT5yI=.f95d2a38-1ca2-4acb-9ed7-94d094a8ccb6@github.com>
<zae0V9b4ewNnnyGGFjsBDe0mIwpsFL3oTrSg6P1B5iQ=.66df7883-3c1e-4dcf-8125-6ced76fe4901@github.com>
Message-ID: <Ca_J8IA7QErDlafzQ4nzz9pRyqlEJbSIBhgyvvd1-ko=.330a9545-caaa-4906-afbc-d633046e1884@github.com>
On Mon, 21 Oct 2024 16:44:26 GMT, SendaoYan <syan at openjdk.org> wrote:
>> Hi all,
>> Newly added test `gc/shenandoah/compiler/TestLoadBypassesNullCheck.java` fails `The unlock option must precede 'StressGCM'.` with release jdk build. This PR fix the test bug, only add `-XX:+UnlockDiagnosticVMOptions` to make test run passed by release jdk build.
>> The change has been verified locally with release/fastdebug/slowdebug on linux-x64. Test-fix only, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>
> only unlock Stress* VM option
Thanks for the review.
To make CI test less noisy, I will integrate right now, ignore the 24 hours rule. Test-fix only, no risk.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/21609#issuecomment-2428063808
PR Comment: https://git.openjdk.org/jdk/pull/21609#issuecomment-2428065005
From syan at openjdk.org Tue Oct 22 02:12:22 2024
From: syan at openjdk.org (SendaoYan)
Date: Tue, 22 Oct 2024 02:12:22 GMT
Subject: Integrated: 8342681: TestLoadBypassesNullCheck.java fails improperly
specified VM option
In-Reply-To: <MiRErOAQLeXA530ui9cQvk0H7MFcauRmfW15WvoT5yI=.f95d2a38-1ca2-4acb-9ed7-94d094a8ccb6@github.com>
References: <MiRErOAQLeXA530ui9cQvk0H7MFcauRmfW15WvoT5yI=.f95d2a38-1ca2-4acb-9ed7-94d094a8ccb6@github.com>
Message-ID: <MC3-ToQ8YXFszBGEI8jqFC1tNiT873NF6f00aIl7pLo=.cedaa22d-b51e-48a7-b34e-70869fd5bff9@github.com>
On Mon, 21 Oct 2024 13:00:23 GMT, SendaoYan <syan at openjdk.org> wrote:
> Hi all,
> Newly added test `gc/shenandoah/compiler/TestLoadBypassesNullCheck.java` fails `The unlock option must precede 'StressGCM'.` with release jdk build. This PR fix the test bug, only add `-XX:+UnlockDiagnosticVMOptions` to make test run passed by release jdk build.
> The change has been verified locally with release/fastdebug/slowdebug on linux-x64. Test-fix only, no risk.
This pull request has now been integrated.
Changeset: 8bcd4920
Author: SendaoYan <syan at openjdk.org>
URL: https://git.openjdk.org/jdk/commit/8bcd4920f1b03d0ef8e295e53557c629f05ceaa4
Stats: 8 lines in 1 file changed: 4 ins; 0 del; 4 mod
8342681: TestLoadBypassesNullCheck.java fails improperly specified VM option
Reviewed-by: shade
-------------
PR: https://git.openjdk.org/jdk/pull/21609
From rkennke at openjdk.org Tue Oct 22 07:32:24 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 22 Oct 2024 07:32:24 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v47]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <PT1OZyKSCB7sEfiFsFugK3GTbr1JATJ1X7xP8XlD9-g=.c35de9eb-e8ab-4739-9957-2f7623500d23@github.com>
> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>
> Main changes:
> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
> - Arrays will now store their length at offset 8.
> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...
Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
Fix needle copying in indexOf intrinsic for smaller headers
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/20677/files
- new: https://git.openjdk.org/jdk/pull/20677/files/1b907cc8..8c4eb6d6
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=46
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=45-46
Stats: 16 lines in 1 file changed: 0 ins; 0 del; 16 mod
Patch: https://git.openjdk.org/jdk/pull/20677.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677
PR: https://git.openjdk.org/jdk/pull/20677
From stefank at openjdk.org Tue Oct 22 07:55:00 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 22 Oct 2024 07:55:00 GMT
Subject: RFR: 8342610: ZGC: Cleanup pre-touching code [v2]
In-Reply-To: <XH3QWfMEhsjjQGuBRhLNvcPe6MRAJgfphDS7GdwLlsE=.dd7696f4-644e-48df-bbcc-aede7f2f85c6@github.com>
References: <XH3QWfMEhsjjQGuBRhLNvcPe6MRAJgfphDS7GdwLlsE=.dd7696f4-644e-48df-bbcc-aede7f2f85c6@github.com>
Message-ID: <BZKNset57dKgYtqoiPgrcm-HjfFof_cZdA21TFPBQYI=.99fecb8a-940a-49b4-9650-7ca87eabfb58@github.com>
> There's a few things that we'd like to cleanup around the pre-touching code.
> * Remove the dependency to ZPhysicalMemoryManager - cleans up the call site
> * Remove unimplemented function pretouch_view (and its friends)
> * Change type from zoffset for the iteration variable - multiple threads update it and it is not guaranteed to stay below the required ZAddressOffsetMax. I can trigger an assert here if I change the code to prime_cache in the higher address range instead of the lower and setting a max heap size that matches ZAddressOffsetMax.
Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
Add explicit include of os.hpp
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/21600/files
- new: https://git.openjdk.org/jdk/pull/21600/files/fdb58e36..2b77896c
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=21600&range=01
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=21600&range=00-01
Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
Patch: https://git.openjdk.org/jdk/pull/21600.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/21600/head:pull/21600
PR: https://git.openjdk.org/jdk/pull/21600
From aboldtch at openjdk.org Tue Oct 22 09:32:13 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 22 Oct 2024 09:32:13 GMT
Subject: RFR: 8342610: ZGC: Cleanup pre-touching code [v2]
In-Reply-To: <BZKNset57dKgYtqoiPgrcm-HjfFof_cZdA21TFPBQYI=.99fecb8a-940a-49b4-9650-7ca87eabfb58@github.com>
References: <XH3QWfMEhsjjQGuBRhLNvcPe6MRAJgfphDS7GdwLlsE=.dd7696f4-644e-48df-bbcc-aede7f2f85c6@github.com>
<BZKNset57dKgYtqoiPgrcm-HjfFof_cZdA21TFPBQYI=.99fecb8a-940a-49b4-9650-7ca87eabfb58@github.com>
Message-ID: <RkO6vkyb3j3S0dhONRnLNuo1-_eSPiLTrnkVrjMdZVY=.b7c5cda2-2c7c-4e35-b4a2-69565fda2988@github.com>
On Tue, 22 Oct 2024 07:55:00 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:
>> There's a few things that we'd like to cleanup around the pre-touching code.
>> * Remove the dependency to ZPhysicalMemoryManager - cleans up the call site
>> * Remove unimplemented function pretouch_view (and its friends)
>> * Change type from zoffset for the iteration variable - multiple threads update it and it is not guaranteed to stay below the required ZAddressOffsetMax. I can trigger an assert here if I change the code to prime_cache in the higher address range instead of the lower and setting a max heap size that matches ZAddressOffsetMax.
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
>
> Add explicit include of os.hpp
Marked as reviewed by aboldtch (Reviewer).
-------------
PR Review: https://git.openjdk.org/jdk/pull/21600#pullrequestreview-2384565740
From sjohanss at openjdk.org Tue Oct 22 09:43:11 2024
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Tue, 22 Oct 2024 09:43:11 GMT
Subject: RFR: 8342182: G1: G1OldGenAllocationTracker does not account for
direct allocations in regions
In-Reply-To: <80Yg80fdSZM8KmryHjOQohAOJEETAQuOtSFejHw-lJw=.8cb4ec31-fcf0-49e0-89ac-77d5f4900747@github.com>
References: <80Yg80fdSZM8KmryHjOQohAOJEETAQuOtSFejHw-lJw=.8cb4ec31-fcf0-49e0-89ac-77d5f4900747@github.com>
Message-ID: <POr5CbIzMWuuzl_Bw0ka-6E9ZBeLjcF7o7U5UyMouL0=.f1d5d798-c034-4335-a1db-3e1377fde3b5@github.com>
On Tue, 15 Oct 2024 12:50:46 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:
> Hi,
>
> Please review this change to add bytes allocated directly into the regions to G1OldGenAllocationTracker. Additional changes to the comments to claify that we keep track of allocations in between GCs and not only during mutator period.
>
> Test: Tier 1
Marked as reviewed by sjohanss (Reviewer).
-------------
PR Review: https://git.openjdk.org/jdk/pull/21525#pullrequestreview-2384601485
From sjohanss at openjdk.org Tue Oct 22 09:49:25 2024
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Tue, 22 Oct 2024 09:49:25 GMT
Subject: RFR: 8295269: G1: Improve slow startup due to predictor
initialization
In-Reply-To: <qFFwxaSWYOikI5bPZKCMa1VIWTEXI6pwQPLmVf2sTWA=.497a0fa1-2553-4293-b4a0-7a8b7e02b6c8@github.com>
References: <qFFwxaSWYOikI5bPZKCMa1VIWTEXI6pwQPLmVf2sTWA=.497a0fa1-2553-4293-b4a0-7a8b7e02b6c8@github.com>
Message-ID: <gRrXtX5RV4xjVrPvJUEcB-pevnOx5cqYVnvz-FN8mMU=.86127bf4-2013-4f99-adaf-f26566dc6349@github.com>
On Tue, 15 Oct 2024 09:53:05 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:
> Hi all,
>
> please review this change that decreases the time it takes to adapt the predictors to actual values during startup.
>
> Currently predictors are initialized using compiled-in values. These values are extremely conservative as they have been based on some SPARC test runs on specjbb2000(?) or so, which means that it takes a while until the weights from these values are "gone" from the predictor sequences. (This can take 20-30 GCs).
>
> The change modifies prediction so that only the first prediction will use these pre-baked values, after that use live values.
>
> This makes G1 adapt much more quickly to the current application/environment.
>
> The drawback is that there may be differences (including regressions) in out-of-box performance because the initial garbage collections heavily impact heap expansion, potentially expanding the heap much less, resulting in less throughput. I.e. in the old policy we may do many more GCs during startup, causing higher cpu time ratio at that time, expanding more (than necessary).
>
> GC cpu usage with the new policy is still well within allowed range wrt to cpu time ratio.
>
> This also does not impact reasonable test setups.
>
> Testing: gha, internal performance benchmarks mostly show no change or improvements. There are some regressions that are "fixed" by setting min/max heap size indicating this is a heap sizing difference caused by differences due to faster startup.
>
> Hth,
> Thomas
Looks good.
-------------
Marked as reviewed by sjohanss (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/21518#pullrequestreview-2384620734
From rkennke at openjdk.org Tue Oct 22 11:19:19 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 22 Oct 2024 11:19:19 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v48]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <H6cywVFrD2hUSGZd1VCGpMu7OmP0ON0RC2QQaLJFBb8=.3960b3bb-8273-472c-9d3e-655638447762@github.com>
> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>
> Main changes:
> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
> - Arrays will now store their length at offset 8.
> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...
Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
- Merge tag 'jdk-24+20' into JDK-8305895-v4
Added tag jdk-24+20 for changeset 7a64fbbb
- Fix needle copying in indexOf intrinsic for smaller headers
- Compact header riscv (#3)
Implement compact headers on RISCV
---------
Co-authored-by: hamlin <hamlin at rivosinc.com>
- Remove extra sanity check
- Problem-list SharedBaseAddress tests on aarch64
- Address comments by @vpaprotsk
- Fix aarch64.ad
- Merge tag 'jdk-24+19' into JDK-8305895-v4
Added tag jdk-24+19 for changeset e7c5bf45
- PPC64 implementation of Compact Object Headers (JEP 450)
- Increase compiler code stubs size for indexOf intrinsic
- ... and 87 more: https://git.openjdk.org/jdk/compare/7a64fbbb...e324d95b
-------------
Changes: https://git.openjdk.org/jdk/pull/20677/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=47
Stats: 5021 lines in 212 files changed: 3472 ins; 847 del; 702 mod
Patch: https://git.openjdk.org/jdk/pull/20677.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677
PR: https://git.openjdk.org/jdk/pull/20677
From mli at openjdk.org Tue Oct 22 12:52:11 2024
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 22 Oct 2024 12:52:11 GMT
Subject: RFR: 8342610: ZGC: Cleanup pre-touching code [v2]
In-Reply-To: <BZKNset57dKgYtqoiPgrcm-HjfFof_cZdA21TFPBQYI=.99fecb8a-940a-49b4-9650-7ca87eabfb58@github.com>
References: <XH3QWfMEhsjjQGuBRhLNvcPe6MRAJgfphDS7GdwLlsE=.dd7696f4-644e-48df-bbcc-aede7f2f85c6@github.com>
<BZKNset57dKgYtqoiPgrcm-HjfFof_cZdA21TFPBQYI=.99fecb8a-940a-49b4-9650-7ca87eabfb58@github.com>
Message-ID: <dXPIQv18f57cyxazy5GnEnLZ2SQzpry1LEYL8sxcPMU=.fa39600c-f16b-45d7-a328-d14a5e117904@github.com>
On Tue, 22 Oct 2024 07:55:00 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:
>> There's a few things that we'd like to cleanup around the pre-touching code.
>> * Remove the dependency to ZPhysicalMemoryManager - cleans up the call site
>> * Remove unimplemented function pretouch_view (and its friends)
>> * Change type from zoffset for the iteration variable - multiple threads update it and it is not guaranteed to stay below the required ZAddressOffsetMax. I can trigger an assert here if I change the code to prime_cache in the higher address range instead of the lower and setting a max heap size that matches ZAddressOffsetMax.
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
>
> Add explicit include of os.hpp
LGTM.
-------------
Marked as reviewed by mli (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/21600#pullrequestreview-2385098881
From iwalulya at openjdk.org Tue Oct 22 13:16:22 2024
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Tue, 22 Oct 2024 13:16:22 GMT
Subject: RFR: 8342182: G1: G1OldGenAllocationTracker does not account for
direct allocations in regions
In-Reply-To: <POr5CbIzMWuuzl_Bw0ka-6E9ZBeLjcF7o7U5UyMouL0=.f1d5d798-c034-4335-a1db-3e1377fde3b5@github.com>
References: <80Yg80fdSZM8KmryHjOQohAOJEETAQuOtSFejHw-lJw=.8cb4ec31-fcf0-49e0-89ac-77d5f4900747@github.com>
<POr5CbIzMWuuzl_Bw0ka-6E9ZBeLjcF7o7U5UyMouL0=.f1d5d798-c034-4335-a1db-3e1377fde3b5@github.com>
Message-ID: <1GaVn2XGTooN3sme4FOUkFX6E-ymKRbx61q8z0zzwiA=.c1dc710e-9328-454d-b474-1d22f48b2b5e@github.com>
On Tue, 22 Oct 2024 09:40:24 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:
>> Hi,
>>
>> Please review this change to add bytes allocated directly into the regions to G1OldGenAllocationTracker. Additional changes to the comments to claify that we keep track of allocations in between GCs and not only during mutator period.
>>
>> Test: Tier 1
>
> Marked as reviewed by sjohanss (Reviewer).
Thanks @kstefanj and @tschatzl for the reviews
-------------
PR Comment: https://git.openjdk.org/jdk/pull/21525#issuecomment-2429251289
From iwalulya at openjdk.org Tue Oct 22 13:16:23 2024
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Tue, 22 Oct 2024 13:16:23 GMT
Subject: Integrated: 8342182: G1: G1OldGenAllocationTracker does not account
for direct allocations in regions
In-Reply-To: <80Yg80fdSZM8KmryHjOQohAOJEETAQuOtSFejHw-lJw=.8cb4ec31-fcf0-49e0-89ac-77d5f4900747@github.com>
References: <80Yg80fdSZM8KmryHjOQohAOJEETAQuOtSFejHw-lJw=.8cb4ec31-fcf0-49e0-89ac-77d5f4900747@github.com>
Message-ID: <bi9As64gWXZqmcgCM_5p3WSQgD4EA3E_Rb409wsoNlw=.b1ad173a-bae1-404f-b5c7-0712d3ede0cf@github.com>
On Tue, 15 Oct 2024 12:50:46 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:
> Hi,
>
> Please review this change to add bytes allocated directly into the regions to G1OldGenAllocationTracker. Additional changes to the comments to claify that we keep track of allocations in between GCs and not only during mutator period.
>
> Test: Tier 1
This pull request has now been integrated.
Changeset: f70ecc27
Author: Ivan Walulya <iwalulya at openjdk.org>
URL: https://git.openjdk.org/jdk/commit/f70ecc27a787a96795452c11262fe427ad03f96a
Stats: 8 lines in 3 files changed: 1 ins; 0 del; 7 mod
8342182: G1: G1OldGenAllocationTracker does not account for direct allocations in regions
Reviewed-by: tschatzl, sjohanss
-------------
PR: https://git.openjdk.org/jdk/pull/21525
From stefank at openjdk.org Tue Oct 22 13:18:33 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 22 Oct 2024 13:18:33 GMT
Subject: RFR: 8342610: ZGC: Cleanup pre-touching code [v2]
In-Reply-To: <BZKNset57dKgYtqoiPgrcm-HjfFof_cZdA21TFPBQYI=.99fecb8a-940a-49b4-9650-7ca87eabfb58@github.com>
References: <XH3QWfMEhsjjQGuBRhLNvcPe6MRAJgfphDS7GdwLlsE=.dd7696f4-644e-48df-bbcc-aede7f2f85c6@github.com>
<BZKNset57dKgYtqoiPgrcm-HjfFof_cZdA21TFPBQYI=.99fecb8a-940a-49b4-9650-7ca87eabfb58@github.com>
Message-ID: <cEE5f_HAv2qQRuKHzonoImQJVIBpQd-xSSZl6927gjw=.e707be07-6767-4d76-a9cb-3db1032fbdee@github.com>
On Tue, 22 Oct 2024 07:55:00 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:
>> There's a few things that we'd like to cleanup around the pre-touching code.
>> * Remove the dependency to ZPhysicalMemoryManager - cleans up the call site
>> * Remove unimplemented function pretouch_view (and its friends)
>> * Change type from zoffset for the iteration variable - multiple threads update it and it is not guaranteed to stay below the required ZAddressOffsetMax. I can trigger an assert here if I change the code to prime_cache in the higher address range instead of the lower and setting a max heap size that matches ZAddressOffsetMax.
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
>
> Add explicit include of os.hpp
Thanks all for the reviews!
-------------
PR Comment: https://git.openjdk.org/jdk/pull/21600#issuecomment-2429255859
From stefank at openjdk.org Tue Oct 22 13:18:34 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 22 Oct 2024 13:18:34 GMT
Subject: Integrated: 8342610: ZGC: Cleanup pre-touching code
In-Reply-To: <XH3QWfMEhsjjQGuBRhLNvcPe6MRAJgfphDS7GdwLlsE=.dd7696f4-644e-48df-bbcc-aede7f2f85c6@github.com>
References: <XH3QWfMEhsjjQGuBRhLNvcPe6MRAJgfphDS7GdwLlsE=.dd7696f4-644e-48df-bbcc-aede7f2f85c6@github.com>
Message-ID: <Tlu39NgCWQph-dip2CdhSoTc64k81ned-RbeW2ZxqRs=.dd2f0d38-0d0c-4025-b6c9-3666fec24c3f@github.com>
On Mon, 21 Oct 2024 08:15:16 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:
> There's a few things that we'd like to cleanup around the pre-touching code.
> * Remove the dependency to ZPhysicalMemoryManager - cleans up the call site
> * Remove unimplemented function pretouch_view (and its friends)
> * Change type from zoffset for the iteration variable - multiple threads update it and it is not guaranteed to stay below the required ZAddressOffsetMax. I can trigger an assert here if I change the code to prime_cache in the higher address range instead of the lower and setting a max heap size that matches ZAddressOffsetMax.
This pull request has now been integrated.
Changeset: 264d7014
Author: Stefan Karlsson <stefank at openjdk.org>
URL: https://git.openjdk.org/jdk/commit/264d7014a11b113d309dde2301ea23d6eba71f57
Stats: 39 lines in 3 files changed: 13 ins; 14 del; 12 mod
8342610: ZGC: Cleanup pre-touching code
Reviewed-by: aboldtch, mli, jsikstro, eosterlund
-------------
PR: https://git.openjdk.org/jdk/pull/21600
From stefank at openjdk.org Tue Oct 22 13:29:42 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 22 Oct 2024 13:29:42 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v48]
In-Reply-To: <H6cywVFrD2hUSGZd1VCGpMu7OmP0ON0RC2QQaLJFBb8=.3960b3bb-8273-472c-9d3e-655638447762@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<H6cywVFrD2hUSGZd1VCGpMu7OmP0ON0RC2QQaLJFBb8=.3960b3bb-8273-472c-9d3e-655638447762@github.com>
Message-ID: <4UtypHyHundxF7XNmcIsoarpmt4EcfgEzSO4uoobf3Q=.0351e5bb-000e-4068-a5e4-3e3db19a61a0@github.com>
On Tue, 22 Oct 2024 11:19:19 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>>
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>>
>> Main changes:
>> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>> - Arrays will now store their length at offset 8.
>> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
>
> - Merge tag 'jdk-24+20' into JDK-8305895-v4
>
> Added tag jdk-24+20 for changeset 7a64fbbb
> - Fix needle copying in indexOf intrinsic for smaller headers
> - Compact header riscv (#3)
>
> Implement compact headers on RISCV
> ---------
>
> Co-authored-by: hamlin <hamlin at rivosinc.com>
> - Remove extra sanity check
> - Problem-list SharedBaseAddress tests on aarch64
> - Address comments by @vpaprotsk
> - Fix aarch64.ad
> - Merge tag 'jdk-24+19' into JDK-8305895-v4
>
> Added tag jdk-24+19 for changeset e7c5bf45
> - PPC64 implementation of Compact Object Headers (JEP 450)
> - Increase compiler code stubs size for indexOf intrinsic
> - ... and 87 more: https://git.openjdk.org/jdk/compare/7a64fbbb...e324d95b
We've identified another failure in our testing:
java -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders -XX:TieredStopAtLevel=2 -XX:TLABSize=1 -XX:MinTLABSize=1 ~/tests/HelloWorld.java
#
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (src/hotspot/share/jfr/support/jfrObjectAllocationSample.cpp:50), pid=775231, tid=775232
# assert(desired_tlab_size_bytes > alignment_reserve_bytes) failed: invariant
...
V [libjvm.so+0xf4ec11] JfrObjectAllocationSample::send_event(Klass const*, unsigned long, bool, Thread*)+0x2d1 (jfrObjectAllocationSample.cpp:50)
V [libjvm.so+0x5d7899] AllocTracer::send_allocation_outside_tlab(Klass*, HeapWordImpl**, unsigned long, JavaThread*)+0x39 (allocTracer.cpp:35)
V [libjvm.so+0x139d6c5] MemAllocator::Allocation::notify_allocation_jfr_sampler()+0x225 (memAllocator.cpp:214)
V [libjvm.so+0x139f928] MemAllocator::allocate() const+0x2a8 (memAllocator.cpp:235)
V [libjvm.so+0x18379bd] TypeArrayKlass::allocate_common(int, bool, JavaThread*)+0x13d (collectedHeap.inline.hpp:41)
V [libjvm.so+0x14bc5c8] oopFactory::new_typeArray(BasicType, int, JavaThread*)+0x38 (typeArrayKlass.hpp:68)
V [libjvm.so+0x8327f1] Runtime1::new_type_array(JavaThread*, Klass*, int)+0xa1 (c1_Runtime1.cpp:388)
-------------
PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2429286279
From stuefe at openjdk.org Tue Oct 22 13:56:42 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 22 Oct 2024 13:56:42 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v21]
In-Reply-To: <Na5LWOz_h0ZGmLcETAxDA9wYiEopgWfvNTbYAELExR8=.e30fe7a0-c766-4bb4-aebb-fc6643c832c1@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<TCFshDmOrJjN0zTh1X9BGEa_rczyMqRbyDIiYsFr_5I=.ea051371-4c86-461e-8721-83b32caf808f@github.com>
<qPL-XuWVkfNYFmfYatyQZwbHismNzW_jXdvkDvIiVNc=.d4fd26a8-f509-494a-bd3d-0c6f37ba5269@github.com>
<spymZDxJXwseFGxL78zfn4V8qe9NpX3gifTgd_eQkiM=.d1af7cf3-b503-4c35-93bb-db00f3c4cfc8@github.com>
<U1HQ2ijNoadMNlrW_Adxkju4fM8kfAB4hn-a_gkPrnA=.7e0fee38-8534-4dcc-8aac-77d6559687c8@github.com>
<CNrcAK8SrGCzsreT3SdoxaoGaqKqGb989t-waCJUz64=.0662bccb-661f-4dc9-b8b6-24d615035261@github.com>
<YyPrYu-6p5wcUwfMQQamwoM1eGp6eUze_yC1lrc7mb0=.f1e5853b-3b6e-4460-8f57-a6f7588e513e@github.com>
<Na5LWOz_h0ZGmLcETAxDA9wYiEopgWfvNTbYAELExR8=.e30fe7a0-c766-4bb4-aebb-fc6643c832c1@github.com>
Message-ID: <0fDctIMZlpNZ4a5_idrN_w8KnvGfPS49Bw_9WRdjJ9I=.8bedb8be-0b33-468b-b711-9c0b4fb6649e@github.com>
On Thu, 19 Sep 2024 13:34:47 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:
>> Do you seen any effects of this in anything other than special-crafted micro benchmarks? I wonder if it would be good enough to hard-code this to be 10 for the first integration of Lilliput.
>
> I will do some benchmarks
I did SpecJBB runs with shift of 6, 8 and 10, respectively, which amounts to Klass alignment of 64, 256 and 1K. Benchmark scores did not show a significant pattern. I did not measure CPU stats though.
But I still think a dynamically calculated shift makes sense, and I hesitate to change this code at this point. I therefore would like to move this question to followup RFEs if necessary.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1810775878
From rkennke at openjdk.org Tue Oct 22 14:25:12 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 22 Oct 2024 14:25:12 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v49]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <x0CFyry6L7aq-kozLc85_MEo96bqnhen9RwrExALE4Q=.47b94dc7-94a9-443e-b607-8c873f54daf8@github.com>
> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>
> Main changes:
> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
> - Arrays will now store their length at offset 8.
> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...
Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
Update copyright headers
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/20677/files
- new: https://git.openjdk.org/jdk/pull/20677/files/e324d95b..19d05e43
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=48
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=47-48
Stats: 49 lines in 49 files changed: 0 ins; 0 del; 49 mod
Patch: https://git.openjdk.org/jdk/pull/20677.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677
PR: https://git.openjdk.org/jdk/pull/20677
From rkennke at openjdk.org Tue Oct 22 16:19:24 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 22 Oct 2024 16:19:24 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v50]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <F8pi_T7-BZh5Junuk22zJ5d9PnBRUs94urSreD5oH1c=.63e9a189-5d9a-45ca-a70c-53cf677627d9@github.com>
> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>
> Main changes:
> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
> - Arrays will now store their length at offset 8.
> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...
Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
- Update copyright
- Avoid assert/endless-loop in JFR code
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/20677/files
- new: https://git.openjdk.org/jdk/pull/20677/files/19d05e43..1ef6394d
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=49
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=48-49
Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod
Patch: https://git.openjdk.org/jdk/pull/20677.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677
PR: https://git.openjdk.org/jdk/pull/20677
From rkennke at openjdk.org Tue Oct 22 16:26:39 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 22 Oct 2024 16:26:39 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v50]
In-Reply-To: <F8pi_T7-BZh5Junuk22zJ5d9PnBRUs94urSreD5oH1c=.63e9a189-5d9a-45ca-a70c-53cf677627d9@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<F8pi_T7-BZh5Junuk22zJ5d9PnBRUs94urSreD5oH1c=.63e9a189-5d9a-45ca-a70c-53cf677627d9@github.com>
Message-ID: <QirAyr5mX2p_jDtPINJsXF8Dv5p2Y_T5Dj2aTqEX-5I=.e1d5c692-81f8-4611-acde-eea1ad6313cd@github.com>
On Tue, 22 Oct 2024 16:19:24 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>>
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>>
>> Main changes:
>> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>> - Arrays will now store their length at offset 8.
>> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
>
> - Update copyright
> - Avoid assert/endless-loop in JFR code
@egahlin / @mgronlun could you please review the JFR parts of this PR? One change is for getting the right prototype header, the other is for avoiding an endless loop/assert in a corner case.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2429724926
From bpb at openjdk.org Tue Oct 22 19:15:51 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 22 Oct 2024 19:15:51 GMT
Subject: RFR: 8340728: Test vmTestbase/gc/memory/Nio/Nio.java is failing to
allocate all direct buffer memory [v2]
In-Reply-To: <H8qu4AgyLXV3JAEqy3ZpyOyFC3pIvFFg4Aiy0cTgrwg=.c463eaa1-71c2-4a07-be0e-15169e2a7568@github.com>
References: <H8qu4AgyLXV3JAEqy3ZpyOyFC3pIvFFg4Aiy0cTgrwg=.c463eaa1-71c2-4a07-be0e-15169e2a7568@github.com>
Message-ID: <TIoLLPQxwVFXhiIoLT_GP8qTbRVxe41mA06zlNblHHE=.e12a38db-48ec-46a0-b3bc-b5b75140799f@github.com>
> First attempt to allocate `VM.maxDirectMemory()` bytes of direct buffer memory, decreasing by 1024 bytes for each `OutOfMemoryError` until allocation succeeds.
Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
- Merge
- 8340728: Test vmTestbase/gc/memory/Nio/Nio.java is failing to allocate all direct buffer memory
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/21623/files
- new: https://git.openjdk.org/jdk/pull/21623/files/6c94f2a6..b1e0c4d8
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=21623&range=01
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=21623&range=00-01
Stats: 113505 lines in 767 files changed: 105030 ins; 5971 del; 2504 mod
Patch: https://git.openjdk.org/jdk/pull/21623.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/21623/head:pull/21623
PR: https://git.openjdk.org/jdk/pull/21623
From stefank at openjdk.org Tue Oct 22 20:11:27 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 22 Oct 2024 20:11:27 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v50]
In-Reply-To: <F8pi_T7-BZh5Junuk22zJ5d9PnBRUs94urSreD5oH1c=.63e9a189-5d9a-45ca-a70c-53cf677627d9@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<F8pi_T7-BZh5Junuk22zJ5d9PnBRUs94urSreD5oH1c=.63e9a189-5d9a-45ca-a70c-53cf677627d9@github.com>
Message-ID: <8O2eaSeTC3JyNsCK6Tb-RGi8NzbA17M5S0mnuF_szo0=.f7da9bb1-fd4b-47df-a56c-e6803182dd27@github.com>
On Tue, 22 Oct 2024 16:19:24 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>>
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>>
>> Main changes:
>> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>> - Arrays will now store their length at offset 8.
>> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
>
> - Update copyright
> - Avoid assert/endless-loop in JFR code
Our testing has found a failure in serviceability/sa/ClhsdbJstackWithConcurrentLock.java when we run C1-only.
I've narrowed it down to be a stale, but seemingly working, implementation of the TLAB data structure. When Lilliput changes the header size this implementation doesn't work anymore and needs to be fixed.
The reproducer for this problem is:
make -C ../build/fastdebug test TEST=serviceability/sa/ClhsdbJstackWithConcurrentLock.java JTREG="JAVA_OPTIONS=-XX:TieredStopAtLevel=2 -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders"
See how the thread reports that the frame holds an AOS, but the list of "Locked ownable synchronizers" is (incorrectly) empty:
"Thread-0" #31 prio=5 tid=0x00007a708c259ad0 nid=1480533 waiting on condition [0x00007a706fefe000]
java.lang.Thread.State: TIMED_WAITING (sleeping)
JavaThread state: _thread_blocked
- java.lang.Thread.sleepNanos0(long) @bci=0 (Interpreted frame)
- java.lang.Thread.sleepNanos(long) @bci=33, line=497 (Interpreted frame)
- java.lang.Thread.sleep(long) @bci=25, line=528 (Interpreted frame)
- LingeredAppWithConcurrentLock.lockMethod(java.util.concurrent.locks.Lock) @bci=13, line=38 (Interpreted frame)
- locked <0x00000000ffd32d88> (a java.util.concurrent.locks.ReentrantLock)
- LingeredAppWithConcurrentLock.lambda$main$0() @bci=3, line=46 (Interpreted frame)
- LingeredAppWithConcurrentLock$$Lambda+0x00007a7023001000.run() @bci=0 (Interpreted frame)
- java.lang.Thread.runWith(java.lang.Object, java.lang.Runnable) @bci=5, line=1589 (Interpreted frame)
- java.lang.Thread.run() @bci=19, line=1576 (Interpreted frame)
Locked ownable synchronizers:
- None
This happens because the TLAB ranges become overlapped and that confuses the rest of the SA code that looks for objects in the heap.
I've created a fix for this, which I intend to try to get pushed to openjdk/jdk:
https://github.com/openjdk/jdk/compare/pr/20677...stefank:jdk:8342857_SA_heap_iterator_fix
https://github.com/stefank/jdk/tree/8342857_SA_heap_iterator_fix
-------------
PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2430157348
From stefank at openjdk.org Wed Oct 23 11:43:27 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 23 Oct 2024 11:43:27 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v50]
In-Reply-To: <F8pi_T7-BZh5Junuk22zJ5d9PnBRUs94urSreD5oH1c=.63e9a189-5d9a-45ca-a70c-53cf677627d9@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<F8pi_T7-BZh5Junuk22zJ5d9PnBRUs94urSreD5oH1c=.63e9a189-5d9a-45ca-a70c-53cf677627d9@github.com>
Message-ID: <pYI-64nT97A6U0xwVDOjKoXN4YKAJ3iNzxXFRDRd9Ss=.7334a043-2f5d-40e9-ba20-5bfb2266a4f2@github.com>
On Tue, 22 Oct 2024 16:19:24 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>>
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>>
>> Main changes:
>> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>> - Arrays will now store their length at offset 8.
>> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
>
> - Update copyright
> - Avoid assert/endless-loop in JFR code
I've published an upstream PR for the SA bug:
https://github.com/openjdk/jdk/pull/21662
-------------
PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2431837874
From stefank at openjdk.org Wed Oct 23 11:44:38 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 23 Oct 2024 11:44:38 GMT
Subject: RFR: 8342857: SA: Heap iterator makes incorrect assumptions about TLAB
layout
Message-ID: <lIV_Ob5b_ATRTNLNSWTTZQL1VQ35aW8A1QIOSR6Lslo=.4259ebec-6dec-45a4-a818-acabe530e206@github.com>
When testing Lilliput we found a failure in `serviceability/sa/ClhsdbJstackWithConcurrentLock.java` test when running with C1-only.
The test uses the SA's thread printing feature to print the threads *and* the "concurrent locks" / AbstractOwnableSynchronizers. It then verifies that the expected lock is listed in the section for "Locked ownable synchronizers".
When we turned on Lilliput's -XX:+UseCompactObjectHeaders this stopped working, and we got nothing reported in that section:
"Thread-0" #31 prio=5 tid=0x00007a708c259ad0 nid=1480533 waiting on condition [0x00007a706fefe000]
java.lang.Thread.State: TIMED_WAITING (sleeping)
JavaThread state: _thread_blocked
- java.lang.Thread.sleepNanos0(long) @bci=0 (Interpreted frame)
- java.lang.Thread.sleepNanos(long) @bci=33, line=497 (Interpreted frame)
- java.lang.Thread.sleep(long) @bci=25, line=528 (Interpreted frame)
- LingeredAppWithConcurrentLock.lockMethod(java.util.concurrent.locks.Lock) @bci=13, line=38 (Interpreted frame)
- locked <0x00000000ffd32d88> (a java.util.concurrent.locks.ReentrantLock)
- LingeredAppWithConcurrentLock.lambda$main$0() @bci=3, line=46 (Interpreted frame)
- LingeredAppWithConcurrentLock$$Lambda+0x00007a7023001000.run() @bci=0 (Interpreted frame)
- java.lang.Thread.runWith(java.lang.Object, java.lang.Runnable) @bci=5, line=1589 (Interpreted frame)
- java.lang.Thread.run() @bci=19, line=1576 (Interpreted frame)
Locked ownable synchronizers:
- None
It should be saying:
Locked ownable synchronizers:
- <0x00000000ffd32d88>, (a java/util/concurrent/locks/ReentrantLock$NonfairSync)
The problem lies within the code that searches for objects in the heap. It collects a bunch of regions and searches them for objects. However, the code that describes the TLAB regions are stale and doesn't match the C++ implementation in the JVM. When Lilliput shrinks the headers the SA code is broken enough to cause the TLAB regions to be reported as overlapping. This has ripple effects that the object iterators stop working.
I can get this test to pass, with and without compact object headers, by fixing the code in `ThreadLocalAllocBuffer::hard_end()`.
This is a reproducer of the problem:
make -C ../build/fastdebug test TEST=serviceability/sa/ClhsdbJstackWithConcurrentLock.java JTREG="JAVA_OPTIONS=-XX:TieredStopAtLevel=2 -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders"
I've tested this by running all 'serviceability' tests in our tier1-9 testing.
-------------
Commit messages:
- 8342857: SA: Heap iterator makes incorrect assumptions about TLAB layout
Changes: https://git.openjdk.org/jdk/pull/21662/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21662&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8342857
Stats: 13 lines in 3 files changed: 11 ins; 0 del; 2 mod
Patch: https://git.openjdk.org/jdk/pull/21662.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/21662/head:pull/21662
PR: https://git.openjdk.org/jdk/pull/21662
From rkennke at openjdk.org Wed Oct 23 13:07:04 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 23 Oct 2024 13:07:04 GMT
Subject: RFR: 8342857: SA: Heap iterator makes incorrect assumptions about
TLAB layout
In-Reply-To: <lIV_Ob5b_ATRTNLNSWTTZQL1VQ35aW8A1QIOSR6Lslo=.4259ebec-6dec-45a4-a818-acabe530e206@github.com>
References: <lIV_Ob5b_ATRTNLNSWTTZQL1VQ35aW8A1QIOSR6Lslo=.4259ebec-6dec-45a4-a818-acabe530e206@github.com>
Message-ID: <NOrA3MPYZrM8l75vf7PtWdwvot1Jw9jRwETHEmbJ5e0=.437c78a2-4d34-4b9c-b416-3c8db2681ff8@github.com>
On Wed, 23 Oct 2024 11:39:26 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:
> When testing Lilliput we found a failure in `serviceability/sa/ClhsdbJstackWithConcurrentLock.java` test when running with C1-only.
>
> The test uses the SA's thread printing feature to print the threads *and* the "concurrent locks" / AbstractOwnableSynchronizers. It then verifies that the expected lock is listed in the section for "Locked ownable synchronizers".
>
> When we turned on Lilliput's -XX:+UseCompactObjectHeaders this stopped working, and we got nothing reported in that section:
>
>
> "Thread-0" #31 prio=5 tid=0x00007a708c259ad0 nid=1480533 waiting on condition [0x00007a706fefe000]
> java.lang.Thread.State: TIMED_WAITING (sleeping)
> JavaThread state: _thread_blocked
> - java.lang.Thread.sleepNanos0(long) @bci=0 (Interpreted frame)
> - java.lang.Thread.sleepNanos(long) @bci=33, line=497 (Interpreted frame)
> - java.lang.Thread.sleep(long) @bci=25, line=528 (Interpreted frame)
> - LingeredAppWithConcurrentLock.lockMethod(java.util.concurrent.locks.Lock) @bci=13, line=38 (Interpreted frame)
> - locked <0x00000000ffd32d88> (a java.util.concurrent.locks.ReentrantLock)
> - LingeredAppWithConcurrentLock.lambda$main$0() @bci=3, line=46 (Interpreted frame)
> - LingeredAppWithConcurrentLock$$Lambda+0x00007a7023001000.run() @bci=0 (Interpreted frame)
> - java.lang.Thread.runWith(java.lang.Object, java.lang.Runnable) @bci=5, line=1589 (Interpreted frame)
> - java.lang.Thread.run() @bci=19, line=1576 (Interpreted frame)
>
> Locked ownable synchronizers:
> - None
>
>
> It should be saying:
>
> Locked ownable synchronizers:
> - <0x00000000ffd32d88>, (a java/util/concurrent/locks/ReentrantLock$NonfairSync)
>
>
> The problem lies within the code that searches for objects in the heap. It collects a bunch of regions and searches them for objects. However, the code that describes the TLAB regions are stale and doesn't match the C++ implementation in the JVM. When Lilliput shrinks the headers the SA code is broken enough to cause the TLAB regions to be reported as overlapping. This has ripple effects that the object iterators stop working.
>
> I can get this test to pass, with and without compact object headers, by fixing the code in `ThreadLocalAllocBuffer::hard_end()`.
>
> This is a reproducer of the problem:
>
> make -C ../build/fastdebug test TEST=serviceability/sa/ClhsdbJstackWithConcurrentLock.java JTREG="JAVA_OPTIONS=-XX:TieredStopAtLevel=2 -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders"
>
>
> I've tested this by running all 'serviceability' tests in our tier1-9 testing.
The changes make sense to me and the code now matches the C++ implementation on HotSpot. Thanks!
-------------
Marked as reviewed by rkennke (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/21662#pullrequestreview-2388617960
From bpb at openjdk.org Wed Oct 23 14:40:11 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 23 Oct 2024 14:40:11 GMT
Subject: RFR: 8340728: Test vmTestbase/gc/memory/Nio/Nio.java is failing to
allocate all direct buffer memory [v2]
In-Reply-To: <TIoLLPQxwVFXhiIoLT_GP8qTbRVxe41mA06zlNblHHE=.e12a38db-48ec-46a0-b3bc-b5b75140799f@github.com>
References: <H8qu4AgyLXV3JAEqy3ZpyOyFC3pIvFFg4Aiy0cTgrwg=.c463eaa1-71c2-4a07-be0e-15169e2a7568@github.com>
<TIoLLPQxwVFXhiIoLT_GP8qTbRVxe41mA06zlNblHHE=.e12a38db-48ec-46a0-b3bc-b5b75140799f@github.com>
Message-ID: <V5XyjhmRTiUStMRyifJMbDcM9EH4vDFd8OSOdp81DNk=.690dc1ad-7fa6-4673-bda6-968ffd3e4a9f@github.com>
On Tue, 22 Oct 2024 19:15:51 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:
>> First attempt to allocate `VM.maxDirectMemory()` bytes of direct buffer memory, decreasing by 1024 bytes for each `OutOfMemoryError` until allocation succeeds.
>
> Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
>
> - Merge
> - 8340728: Test vmTestbase/gc/memory/Nio/Nio.java is failing to allocate all direct buffer memory
test/hotspot/jtreg/vmTestbase/gc/memory/Nio/Nio.java line 85:
> 83: System.out.println("... success");
> 84: } catch (OutOfMemoryError oom) {
> 85: max_size -= 1024;
I wonder whether a test of `max_size` should be performed here to signal an error should it fall below some threshold, e.g., `MAX_VM_SIZE - 8*1024` or MAX_VM_SIZE - 16*1024`?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/21623#discussion_r1812928010
From lmesnik at openjdk.org Wed Oct 23 15:48:06 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 23 Oct 2024 15:48:06 GMT
Subject: RFR: 8342857: SA: Heap iterator makes incorrect assumptions about
TLAB layout
In-Reply-To: <lIV_Ob5b_ATRTNLNSWTTZQL1VQ35aW8A1QIOSR6Lslo=.4259ebec-6dec-45a4-a818-acabe530e206@github.com>
References: <lIV_Ob5b_ATRTNLNSWTTZQL1VQ35aW8A1QIOSR6Lslo=.4259ebec-6dec-45a4-a818-acabe530e206@github.com>
Message-ID: <Vp9hhG1x6E2_opVbRhURo9VazsuuPGtKD5MwKdus0tA=.5c86413b-f0d2-4a88-a93f-8664a531c641@github.com>
On Wed, 23 Oct 2024 11:39:26 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:
> When testing Lilliput we found a failure in `serviceability/sa/ClhsdbJstackWithConcurrentLock.java` test when running with C1-only.
>
> The test uses the SA's thread printing feature to print the threads *and* the "concurrent locks" / AbstractOwnableSynchronizers. It then verifies that the expected lock is listed in the section for "Locked ownable synchronizers".
>
> When we turned on Lilliput's -XX:+UseCompactObjectHeaders this stopped working, and we got nothing reported in that section:
>
>
> "Thread-0" #31 prio=5 tid=0x00007a708c259ad0 nid=1480533 waiting on condition [0x00007a706fefe000]
> java.lang.Thread.State: TIMED_WAITING (sleeping)
> JavaThread state: _thread_blocked
> - java.lang.Thread.sleepNanos0(long) @bci=0 (Interpreted frame)
> - java.lang.Thread.sleepNanos(long) @bci=33, line=497 (Interpreted frame)
> - java.lang.Thread.sleep(long) @bci=25, line=528 (Interpreted frame)
> - LingeredAppWithConcurrentLock.lockMethod(java.util.concurrent.locks.Lock) @bci=13, line=38 (Interpreted frame)
> - locked <0x00000000ffd32d88> (a java.util.concurrent.locks.ReentrantLock)
> - LingeredAppWithConcurrentLock.lambda$main$0() @bci=3, line=46 (Interpreted frame)
> - LingeredAppWithConcurrentLock$$Lambda+0x00007a7023001000.run() @bci=0 (Interpreted frame)
> - java.lang.Thread.runWith(java.lang.Object, java.lang.Runnable) @bci=5, line=1589 (Interpreted frame)
> - java.lang.Thread.run() @bci=19, line=1576 (Interpreted frame)
>
> Locked ownable synchronizers:
> - None
>
>
> It should be saying:
>
> Locked ownable synchronizers:
> - <0x00000000ffd32d88>, (a java/util/concurrent/locks/ReentrantLock$NonfairSync)
>
>
> The problem lies within the code that searches for objects in the heap. It collects a bunch of regions and searches them for objects. However, the code that describes the TLAB regions are stale and doesn't match the C++ implementation in the JVM. When Lilliput shrinks the headers the SA code is broken enough to cause the TLAB regions to be reported as overlapping. This has ripple effects that the object iterators stop working.
>
> I can get this test to pass, with and without compact object headers, by fixing the code in `ThreadLocalAllocBuffer::hard_end()`.
>
> This is a reproducer of the problem:
>
> make -C ../build/fastdebug test TEST=serviceability/sa/ClhsdbJstackWithConcurrentLock.java JTREG="JAVA_OPTIONS=-XX:TieredStopAtLevel=2 -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders"
>
>
> I've tested this by running all 'serviceability' tests in our tier1-9 testing.
Marked as reviewed by lmesnik (Reviewer).
-------------
PR Review: https://git.openjdk.org/jdk/pull/21662#pullrequestreview-2389260656
From mdoerr at openjdk.org Wed Oct 23 18:18:23 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 23 Oct 2024 18:18:23 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v21]
In-Reply-To: <0fDctIMZlpNZ4a5_idrN_w8KnvGfPS49Bw_9WRdjJ9I=.8bedb8be-0b33-468b-b711-9c0b4fb6649e@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<TCFshDmOrJjN0zTh1X9BGEa_rczyMqRbyDIiYsFr_5I=.ea051371-4c86-461e-8721-83b32caf808f@github.com>
<qPL-XuWVkfNYFmfYatyQZwbHismNzW_jXdvkDvIiVNc=.d4fd26a8-f509-494a-bd3d-0c6f37ba5269@github.com>
<spymZDxJXwseFGxL78zfn4V8qe9NpX3gifTgd_eQkiM=.d1af7cf3-b503-4c35-93bb-db00f3c4cfc8@github.com>
<U1HQ2ijNoadMNlrW_Adxkju4fM8kfAB4hn-a_gkPrnA=.7e0fee38-8534-4dcc-8aac-77d6559687c8@github.com>
<CNrcAK8SrGCzsreT3SdoxaoGaqKqGb989t-waCJUz64=.0662bccb-661f-4dc9-b8b6-24d615035261@github.com>
<YyPrYu-6p5wcUwfMQQamwoM1eGp6eUze_yC1lrc7mb0=.f1e5853b-3b6e-4460-8f57-a6f7588e513e@github.com>
<Na5LWOz_h0ZGmLcETAxDA9wYiEopgWfvNTbYAELExR8=.e30fe7a0-c766-4bb4-aebb-fc6643c832c1@github.com>
<0fDctIMZlpNZ4a5_idrN_w8KnvGfPS49Bw_9WRdjJ9I=.8bedb8be-0b33-468b-b711-9c0b4fb6649e@github.com>
Message-ID: <G2EVWD7HifRRUclJtjvBIZS7CdwuYg4HlUH9QyXMLCw=.b9ff7725-2d53-4ae8-94ee-cb32c3bf1dfa@github.com>
On Tue, 22 Oct 2024 13:53:03 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:
>> I will do some benchmarks
>
> I did SpecJBB runs with shift of 6, 8 and 10, respectively, which amounts to Klass alignment of 64, 256 and 1K. Benchmark scores did not show a significant pattern. I did not measure CPU stats though.
>
> But I still think a dynamically calculated shift makes sense, and I hesitate to change this code at this point. I therefore would like to move this question to followup RFEs if necessary.
This code causes test errors in `CompressedClassPointersEncodingScheme.java` on s390 and PPC64. It forces the shift to `log_cacheline` which is 7 on PPC64 and 9 on s390. The test passes when we remove "s > log_cacheline && " from the condition below.
In addition, it doesn't fit to the comment which claims we should avoid shifts larger than the cacheline size. This enforces shifts to be larger (or equal to) than the cacheline size.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1813304646
From egahlin at openjdk.org Wed Oct 23 19:31:26 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 23 Oct 2024 19:31:26 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v50]
In-Reply-To: <QirAyr5mX2p_jDtPINJsXF8Dv5p2Y_T5Dj2aTqEX-5I=.e1d5c692-81f8-4611-acde-eea1ad6313cd@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<F8pi_T7-BZh5Junuk22zJ5d9PnBRUs94urSreD5oH1c=.63e9a189-5d9a-45ca-a70c-53cf677627d9@github.com>
<QirAyr5mX2p_jDtPINJsXF8Dv5p2Y_T5Dj2aTqEX-5I=.e1d5c692-81f8-4611-acde-eea1ad6313cd@github.com>
Message-ID: <Dfb8NRaKopl215q7WQ68VBR4axwO7_dNTle1TCdZPZ0=.70d2d9bd-f0b0-431c-a472-f1e7f2ecfca5@github.com>
On Tue, 22 Oct 2024 16:22:20 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
> @egahlin / @mgronlun could you please review the JFR parts of this PR? One change is for getting the right prototype header, the other is for avoiding an endless loop/assert in a corner case.
JFR changes look reasonable.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2433263488
From egahlin at openjdk.org Wed Oct 23 19:31:26 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 23 Oct 2024 19:31:26 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v50]
In-Reply-To: <F8pi_T7-BZh5Junuk22zJ5d9PnBRUs94urSreD5oH1c=.63e9a189-5d9a-45ca-a70c-53cf677627d9@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<F8pi_T7-BZh5Junuk22zJ5d9PnBRUs94urSreD5oH1c=.63e9a189-5d9a-45ca-a70c-53cf677627d9@github.com>
Message-ID: <kg1P7IgX_T7-UHKt5vu-cy5LgmEGCF6DXQskxCjsMPo=.fd01234b-ac4d-48ce-97df-01acd1c1fa7d@github.com>
On Tue, 22 Oct 2024 16:19:24 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>>
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>>
>> Main changes:
>> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>> - Arrays will now store their length at offset 8.
>> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
>
> - Update copyright
> - Avoid assert/endless-loop in JFR code
Marked as reviewed by egahlin (Reviewer).
-------------
PR Review: https://git.openjdk.org/jdk/pull/20677#pullrequestreview-2389952721
From cjplummer at openjdk.org Wed Oct 23 19:51:11 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 23 Oct 2024 19:51:11 GMT
Subject: RFR: 8342857: SA: Heap iterator makes incorrect assumptions about
TLAB layout
In-Reply-To: <lIV_Ob5b_ATRTNLNSWTTZQL1VQ35aW8A1QIOSR6Lslo=.4259ebec-6dec-45a4-a818-acabe530e206@github.com>
References: <lIV_Ob5b_ATRTNLNSWTTZQL1VQ35aW8A1QIOSR6Lslo=.4259ebec-6dec-45a4-a818-acabe530e206@github.com>
Message-ID: <0_0LoiSECTe_JEfGgOTCICMw1lblyUhN0F7WSCE8GdA=.fc9c6013-657f-4eaa-9378-c1c51357e881@github.com>
On Wed, 23 Oct 2024 11:39:26 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:
> When testing Lilliput we found a failure in `serviceability/sa/ClhsdbJstackWithConcurrentLock.java` test when running with C1-only.
>
> The test uses the SA's thread printing feature to print the threads *and* the "concurrent locks" / AbstractOwnableSynchronizers. It then verifies that the expected lock is listed in the section for "Locked ownable synchronizers".
>
> When we turned on Lilliput's -XX:+UseCompactObjectHeaders this stopped working, and we got nothing reported in that section:
>
>
> "Thread-0" #31 prio=5 tid=0x00007a708c259ad0 nid=1480533 waiting on condition [0x00007a706fefe000]
> java.lang.Thread.State: TIMED_WAITING (sleeping)
> JavaThread state: _thread_blocked
> - java.lang.Thread.sleepNanos0(long) @bci=0 (Interpreted frame)
> - java.lang.Thread.sleepNanos(long) @bci=33, line=497 (Interpreted frame)
> - java.lang.Thread.sleep(long) @bci=25, line=528 (Interpreted frame)
> - LingeredAppWithConcurrentLock.lockMethod(java.util.concurrent.locks.Lock) @bci=13, line=38 (Interpreted frame)
> - locked <0x00000000ffd32d88> (a java.util.concurrent.locks.ReentrantLock)
> - LingeredAppWithConcurrentLock.lambda$main$0() @bci=3, line=46 (Interpreted frame)
> - LingeredAppWithConcurrentLock$$Lambda+0x00007a7023001000.run() @bci=0 (Interpreted frame)
> - java.lang.Thread.runWith(java.lang.Object, java.lang.Runnable) @bci=5, line=1589 (Interpreted frame)
> - java.lang.Thread.run() @bci=19, line=1576 (Interpreted frame)
>
> Locked ownable synchronizers:
> - None
>
>
> It should be saying:
>
> Locked ownable synchronizers:
> - <0x00000000ffd32d88>, (a java/util/concurrent/locks/ReentrantLock$NonfairSync)
>
>
> The problem lies within the code that searches for objects in the heap. It collects a bunch of regions and searches them for objects. However, the code that describes the TLAB regions are stale and doesn't match the C++ implementation in the JVM. When Lilliput shrinks the headers the SA code is broken enough to cause the TLAB regions to be reported as overlapping. This has ripple effects that the object iterators stop working.
>
> I can get this test to pass, with and without compact object headers, by fixing the code in `ThreadLocalAllocBuffer::hard_end()`.
>
> This is a reproducer of the problem:
>
> make -C ../build/fastdebug test TEST=serviceability/sa/ClhsdbJstackWithConcurrentLock.java JTREG="JAVA_OPTIONS=-XX:TieredStopAtLevel=2 -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders"
>
>
> I've tested this by running all 'serviceability' tests in our tier1-9 testing.
Changes requested by cjplummer (Reviewer).
src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VM.java line 443:
> 441:
> 442: Type collectedHeap = db.lookupType("CollectedHeap");
> 443: CIntegerType sizeType = (CIntegerType) db.lookupType("size_t");
I think you can use getSizet() here.
-------------
PR Review: https://git.openjdk.org/jdk/pull/21662#pullrequestreview-2390075171
PR Review Comment: https://git.openjdk.org/jdk/pull/21662#discussion_r1813440444
From lmesnik at openjdk.org Thu Oct 24 05:15:29 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 24 Oct 2024 05:15:29 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v50]
In-Reply-To: <F8pi_T7-BZh5Junuk22zJ5d9PnBRUs94urSreD5oH1c=.63e9a189-5d9a-45ca-a70c-53cf677627d9@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<F8pi_T7-BZh5Junuk22zJ5d9PnBRUs94urSreD5oH1c=.63e9a189-5d9a-45ca-a70c-53cf677627d9@github.com>
Message-ID: <kIFHgHW4e-LKs1cklS5gCfulvfjqP8uEHm2fvQNDLJM=.6e53020e-50ff-484b-b0ba-626dccf75c10@github.com>
On Tue, 22 Oct 2024 16:19:24 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>>
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>>
>> Main changes:
>> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>> - Arrays will now store their length at offset 8.
>> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
>
> - Update copyright
> - Avoid assert/endless-loop in JFR code
Not actually review, just confirming that my request fulfilled. And no more issues arised during PIT
-------------
Marked as reviewed by lmesnik (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/20677#pullrequestreview-2391292083
From lmesnik at openjdk.org Thu Oct 24 05:15:30 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 24 Oct 2024 05:15:30 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v6]
In-Reply-To: <YlpC3YUY4jE9Qb4Et5SqUc3q16AkDrY3b9-mXSMKzSg=.dd4d0fd4-ffac-42b8-83f5-639f3a930f8c@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<BGmZ04yibLn_KtPyQrA3sQv5OtMonrcDy3aN0vAj8NA=.5de6cae3-3a05-4a74-a15c-aade4176bdeb@github.com>
<JEzJGLkDHhgNGFns5-xLFV1TGH2-EkzWd568IcAO1Rg=.b48dc38e-57a9-4e4f-b512-fc86efdb77c4@github.com>
<YlpC3YUY4jE9Qb4Et5SqUc3q16AkDrY3b9-mXSMKzSg=.dd4d0fd4-ffac-42b8-83f5-639f3a930f8c@github.com>
Message-ID: <Q1kbjcs2NnrkL51fHs7B8y-Kyx-zVRor8ZKmRoXmXvw=.3ef65ffe-2edb-4640-874e-6b389926e12e@github.com>
On Fri, 30 Aug 2024 07:37:35 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:
>> make/Images.gmk line 135:
>>
>>> 133: #
>>> 134: # Param1 - VM variant (e.g., server, client, zero, ...)
>>> 135: # Param2 - _nocoops, _coh, _nocoops_coh, or empty
>>
>> The -XX:+UseCompactObjectHeaders ssems to incompatible withe zero vm. The zero vm build start failing while generating shared archive with +UseCompactObjectHeaders. Generation should be disabled by default for zero to don't break the build.
>
> No, zero works with +COH, but a small change is needed. I'll post a suggestion inline.
no objection anymore
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1814259543
From stefank at openjdk.org Thu Oct 24 08:30:47 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 24 Oct 2024 08:30:47 GMT
Subject: RFR: 8342857: SA: Heap iterator makes incorrect assumptions about
TLAB layout [v2]
In-Reply-To: <lIV_Ob5b_ATRTNLNSWTTZQL1VQ35aW8A1QIOSR6Lslo=.4259ebec-6dec-45a4-a818-acabe530e206@github.com>
References: <lIV_Ob5b_ATRTNLNSWTTZQL1VQ35aW8A1QIOSR6Lslo=.4259ebec-6dec-45a4-a818-acabe530e206@github.com>
Message-ID: <fHvk7yaB74M7pJnqE2-4ShK4DTyaA9Pjgu97aNvgbec=.e13801bd-ad0f-4d78-b660-6a3c6087d34f@github.com>
> When testing Lilliput we found a failure in `serviceability/sa/ClhsdbJstackWithConcurrentLock.java` test when running with C1-only.
>
> The test uses the SA's thread printing feature to print the threads *and* the "concurrent locks" / AbstractOwnableSynchronizers. It then verifies that the expected lock is listed in the section for "Locked ownable synchronizers".
>
> When we turned on Lilliput's -XX:+UseCompactObjectHeaders this stopped working, and we got nothing reported in that section:
>
>
> "Thread-0" #31 prio=5 tid=0x00007a708c259ad0 nid=1480533 waiting on condition [0x00007a706fefe000]
> java.lang.Thread.State: TIMED_WAITING (sleeping)
> JavaThread state: _thread_blocked
> - java.lang.Thread.sleepNanos0(long) @bci=0 (Interpreted frame)
> - java.lang.Thread.sleepNanos(long) @bci=33, line=497 (Interpreted frame)
> - java.lang.Thread.sleep(long) @bci=25, line=528 (Interpreted frame)
> - LingeredAppWithConcurrentLock.lockMethod(java.util.concurrent.locks.Lock) @bci=13, line=38 (Interpreted frame)
> - locked <0x00000000ffd32d88> (a java.util.concurrent.locks.ReentrantLock)
> - LingeredAppWithConcurrentLock.lambda$main$0() @bci=3, line=46 (Interpreted frame)
> - LingeredAppWithConcurrentLock$$Lambda+0x00007a7023001000.run() @bci=0 (Interpreted frame)
> - java.lang.Thread.runWith(java.lang.Object, java.lang.Runnable) @bci=5, line=1589 (Interpreted frame)
> - java.lang.Thread.run() @bci=19, line=1576 (Interpreted frame)
>
> Locked ownable synchronizers:
> - None
>
>
> It should be saying:
>
> Locked ownable synchronizers:
> - <0x00000000ffd32d88>, (a java/util/concurrent/locks/ReentrantLock$NonfairSync)
>
>
> The problem lies within the code that searches for objects in the heap. It collects a bunch of regions and searches them for objects. However, the code that describes the TLAB regions are stale and doesn't match the C++ implementation in the JVM. When Lilliput shrinks the headers the SA code is broken enough to cause the TLAB regions to be reported as overlapping. This has ripple effects that the object iterators stop working.
>
> I can get this test to pass, with and without compact object headers, by fixing the code in `ThreadLocalAllocBuffer::hard_end()`.
>
> This is a reproducer of the problem:
>
> make -C ../build/fastdebug test TEST=serviceability/sa/ClhsdbJstackWithConcurrentLock.java JTREG="JAVA_OPTIONS=-XX:TieredStopAtLevel=2 -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders"
>
>
> I've tested this by running all 'serviceability' tests in our tier1-9 testing.
Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
Remove redundant db.lookupType
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/21662/files
- new: https://git.openjdk.org/jdk/pull/21662/files/be690e24..e8ec2957
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=21662&range=01
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=21662&range=00-01
Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
Patch: https://git.openjdk.org/jdk/pull/21662.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/21662/head:pull/21662
PR: https://git.openjdk.org/jdk/pull/21662
From stuefe at openjdk.org Thu Oct 24 09:15:30 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 24 Oct 2024 09:15:30 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v21]
In-Reply-To: <G2EVWD7HifRRUclJtjvBIZS7CdwuYg4HlUH9QyXMLCw=.b9ff7725-2d53-4ae8-94ee-cb32c3bf1dfa@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<TCFshDmOrJjN0zTh1X9BGEa_rczyMqRbyDIiYsFr_5I=.ea051371-4c86-461e-8721-83b32caf808f@github.com>
<qPL-XuWVkfNYFmfYatyQZwbHismNzW_jXdvkDvIiVNc=.d4fd26a8-f509-494a-bd3d-0c6f37ba5269@github.com>
<spymZDxJXwseFGxL78zfn4V8qe9NpX3gifTgd_eQkiM=.d1af7cf3-b503-4c35-93bb-db00f3c4cfc8@github.com>
<U1HQ2ijNoadMNlrW_Adxkju4fM8kfAB4hn-a_gkPrnA=.7e0fee38-8534-4dcc-8aac-77d6559687c8@github.com>
<CNrcAK8SrGCzsreT3SdoxaoGaqKqGb989t-waCJUz64=.0662bccb-661f-4dc9-b8b6-24d615035261@github.com>
<YyPrYu-6p5wcUwfMQQamwoM1eGp6eUze_yC1lrc7mb0=.f1e5853b-3b6e-4460-8f57-a6f7588e513e@github.com>
<Na5LWOz_h0ZGmLcETAxDA9wYiEopgWfvNTbYAELExR8=.e30fe7a0-c766-4bb4-aebb-fc6643c832c1@github.com>
<0fDctIMZlpNZ4a5_idrN_w8KnvGfPS49Bw_9WRdjJ9I=.8bedb8be-0b33-468b-b711-9c0b4fb6649e@github.com>
<G2EVWD7HifRRUclJtjvBIZS7CdwuYg4HlUH9QyXMLCw=.b9ff7725-2d53-4ae8-94ee-cb32c3bf1dfa@github.com>
Message-ID: <vMlI9KnBvvHNvxT__7149la64QKN1CrHlr3OoX17x-E=.e06e392f-0e55-465d-b33e-a69d7f6ba5b3@github.com>
On Wed, 23 Oct 2024 18:14:50 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:
> This code causes test errors in `CompressedClassPointersEncodingScheme.java` on s390 and PPC64. It forces the shift to `log_cacheline` which is 7 on PPC64 and 9 on s390. The test passes when we remove "s > log_cacheline && " from the condition below.
It's a bit late. We are close to pushing. While it should be harmless to drop below alignment to below cache line size, this would be a change affecting all platforms and would require all tests repeated.
PPC/s390 are not targeted by the JEP. There had never been a discussion I am aware of that these platforms have to be clean with +COH. While it's nice that the changes had been contributed, I don't think that test errors on these platforms should hold up pushing this RFE. Therefore, if needed, we should just omit +COH part of the test for PPC/S390.
But then, what exactly is the error? If it's just the test assuming that cache line size is log 6, then the test should be fixed for ppc, not hotspot.
> In addition, it doesn't fit to the comment which claims we should avoid shifts larger than the cacheline size. This enforces shifts to be larger (or equal to) than the cacheline size.
?? The comment is correct. We try to avoid hyper alignment, hence we drop the shift to - if possible - log 2 cache line size. If it's equal to log 2 cache line size, we succeeded.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1814598543
From stuefe at openjdk.org Thu Oct 24 09:25:35 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 24 Oct 2024 09:25:35 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v21]
In-Reply-To: <vMlI9KnBvvHNvxT__7149la64QKN1CrHlr3OoX17x-E=.e06e392f-0e55-465d-b33e-a69d7f6ba5b3@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<TCFshDmOrJjN0zTh1X9BGEa_rczyMqRbyDIiYsFr_5I=.ea051371-4c86-461e-8721-83b32caf808f@github.com>
<qPL-XuWVkfNYFmfYatyQZwbHismNzW_jXdvkDvIiVNc=.d4fd26a8-f509-494a-bd3d-0c6f37ba5269@github.com>
<spymZDxJXwseFGxL78zfn4V8qe9NpX3gifTgd_eQkiM=.d1af7cf3-b503-4c35-93bb-db00f3c4cfc8@github.com>
<U1HQ2ijNoadMNlrW_Adxkju4fM8kfAB4hn-a_gkPrnA=.7e0fee38-8534-4dcc-8aac-77d6559687c8@github.com>
<CNrcAK8SrGCzsreT3SdoxaoGaqKqGb989t-waCJUz64=.0662bccb-661f-4dc9-b8b6-24d615035261@github.com>
<YyPrYu-6p5wcUwfMQQamwoM1eGp6eUze_yC1lrc7mb0=.f1e5853b-3b6e-4460-8f57-a6f7588e513e@github.com>
<Na5LWOz_h0ZGmLcETAxDA9wYiEopgWfvNTbYAELExR8=.e30fe7a0-c766-4bb4-aebb-fc6643c832c1@github.com>
<0fDctIMZlpNZ4a5_idrN_w8KnvGfPS49Bw_9WRdjJ9I=.8bedb8be-0b33-468b-b711-9c0b4fb6649e@github.com>
<G2EVWD7HifRRUclJtjvBIZS7CdwuYg4HlUH9QyXMLCw=.b9ff7725-2d53-4ae8-94ee-cb32c3bf1dfa@github.com>
<vMlI9KnBvvHNvxT__7149la64QKN1CrHlr3
OoX17x-E=.e06e392f-0e55-465d-b33e-a69d7f6ba5b3@github.com>
Message-ID: <cQxx13f6ujrDdrDqN_ynyMHKAEOJsKWwPpNDs3da_Mo=.d2fcfe0c-77d1-4e9c-8022-d103fd91fa0c@github.com>
On Thu, 24 Oct 2024 09:12:34 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:
> But then, what exactly is the error? If it's just the test assuming that cache line size is log 6, then the test should be fixed for ppc, not hotspot.
that is the problem, test assumes log2 of 6 for chacheline size
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1814617136
From amitkumar at openjdk.org Thu Oct 24 09:31:31 2024
From: amitkumar at openjdk.org (Amit Kumar)
Date: Thu, 24 Oct 2024 09:31:31 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v21]
In-Reply-To: <cQxx13f6ujrDdrDqN_ynyMHKAEOJsKWwPpNDs3da_Mo=.d2fcfe0c-77d1-4e9c-8022-d103fd91fa0c@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<TCFshDmOrJjN0zTh1X9BGEa_rczyMqRbyDIiYsFr_5I=.ea051371-4c86-461e-8721-83b32caf808f@github.com>
<qPL-XuWVkfNYFmfYatyQZwbHismNzW_jXdvkDvIiVNc=.d4fd26a8-f509-494a-bd3d-0c6f37ba5269@github.com>
<spymZDxJXwseFGxL78zfn4V8qe9NpX3gifTgd_eQkiM=.d1af7cf3-b503-4c35-93bb-db00f3c4cfc8@github.com>
<U1HQ2ijNoadMNlrW_Adxkju4fM8kfAB4hn-a_gkPrnA=.7e0fee38-8534-4dcc-8aac-77d6559687c8@github.com>
<CNrcAK8SrGCzsreT3SdoxaoGaqKqGb989t-waCJUz64=.0662bccb-661f-4dc9-b8b6-24d615035261@github.com>
<YyPrYu-6p5wcUwfMQQamwoM1eGp6eUze_yC1lrc7mb0=.f1e5853b-3b6e-4460-8f57-a6f7588e513e@github.com>
<Na5LWOz_h0ZGmLcETAxDA9wYiEopgWfvNTbYAELExR8=.e30fe7a0-c766-4bb4-aebb-fc6643c832c1@github.com>
<0fDctIMZlpNZ4a5_idrN_w8KnvGfPS49Bw_9WRdjJ9I=.8bedb8be-0b33-468b-b711-9c0b4fb6649e@github.com>
<G2EVWD7HifRRUclJtjvBIZS7CdwuYg4HlUH9QyXMLCw=.b9ff7725-2d53-4ae8-94ee-cb32c3bf1dfa@github.com>
<vMlI9KnBvvHNvxT__7149la64QKN1CrHlr3
OoX17x-E=.e06e392f-0e55-465d-b33e-a69d7f6ba5b3@github.com>
<cQxx13f6ujrDdrDqN_ynyMHKAEOJsKWwPpNDs3da_Mo=.d2fcfe0c-77d1-4e9c-8022-d103fd91fa0c@github.com>
Message-ID: <XuC0_RaUpR0_JvlEzq8-j7oqovvyqNHFQyWPmDQamqA=.a5e8730c-555a-4872-919b-c39fa0873f97@github.com>
On Thu, 24 Oct 2024 09:22:34 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:
>>> This code causes test errors in `CompressedClassPointersEncodingScheme.java` on s390 and PPC64. It forces the shift to `log_cacheline` which is 7 on PPC64 and 9 on s390. The test passes when we remove "s > log_cacheline && " from the condition below.
>>
>> It's a bit late. We are close to pushing. While it should be harmless to drop below alignment to below cache line size, this would be a change affecting all platforms and would require all tests repeated.
>>
>> PPC/s390 are not targeted by the JEP. There had never been a discussion I am aware of that these platforms have to be clean with +COH. While it's nice that the changes had been contributed, I don't think that test errors on these platforms should hold up pushing this RFE. Therefore, if needed, we should just omit +COH part of the test for PPC/S390.
>>
>> But then, what exactly is the error? If it's just the test assuming that cache line size is log 6, then the test should be fixed for ppc, not hotspot.
>>
>>> In addition, it doesn't fit to the comment which claims we should avoid shifts larger than the cacheline size. This enforces shifts to be larger (or equal to) than the cacheline size.
>>
>> ?? The comment is correct. We try to avoid hyper alignment, hence we drop the shift to - if possible - log 2 cache line size. If it's equal to log 2 cache line size, we succeeded.
>
>> But then, what exactly is the error? If it's just the test assuming that cache line size is log 6, then the test should be fixed for ppc, not hotspot.
>
> that is the problem, test assumes log2 of 6 for chacheline size
PPC log2 will be `7` (`DEFAULT_CACHE_LINE_SIZE? = 128`) and for S390x it will be `8` (`DEFAULT_CACHE_LINE_SIZE? = 256`).
So I guess this change should be fine for now :
diff --git a/test/hotspot/jtreg/runtime/CompressedOops/CompressedClassPointersEncodingScheme.java b/test/hotspot/jtreg/runtime/CompressedOops/CompressedClassPointersEncodingScheme.java
index e04e716315a..c1be59e77ab 100644
--- a/test/hotspot/jtreg/runtime/CompressedOops/CompressedClassPointersEncodingScheme.java
+++ b/test/hotspot/jtreg/runtime/CompressedOops/CompressedClassPointersEncodingScheme.java
@@ -108,7 +108,9 @@ public static void main(String[] args) throws Exception {
long ccsSize = 128 * M;
int expectedShift = 6;
- test(forceAddress, true, ccsSize, forceAddress, expectedShift);
+ if (!Platform.isPPC() && !Platform.isS390x()) {
+ test(forceAddress, true, ccsSize, forceAddress, expectedShift);
+ }
ccsSize = 512 * M;
expectedShift = 8;
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1814627120
From amitkumar at openjdk.org Thu Oct 24 09:46:31 2024
From: amitkumar at openjdk.org (Amit Kumar)
Date: Thu, 24 Oct 2024 09:46:31 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v50]
In-Reply-To: <QirAyr5mX2p_jDtPINJsXF8Dv5p2Y_T5Dj2aTqEX-5I=.e1d5c692-81f8-4611-acde-eea1ad6313cd@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<F8pi_T7-BZh5Junuk22zJ5d9PnBRUs94urSreD5oH1c=.63e9a189-5d9a-45ca-a70c-53cf677627d9@github.com>
<QirAyr5mX2p_jDtPINJsXF8Dv5p2Y_T5Dj2aTqEX-5I=.e1d5c692-81f8-4611-acde-eea1ad6313cd@github.com>
Message-ID: <ISW5WbcZr7Rr8Zg462H--apDVxKgiDKzVWGlXfhlgek=.2ea3202f-29e6-47f1-987c-52e11add973d@github.com>
On Tue, 22 Oct 2024 16:22:20 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
>> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
>>
>> - Update copyright
>> - Avoid assert/endless-loop in JFR code
>
> @egahlin / @mgronlun could you please review the JFR parts of this PR? One change is for getting the right prototype header, the other is for avoiding an endless loop/assert in a corner case.
@rkennke Please include s390x implementation from here: https://github.com/offamitkumar/jdk/commit/e67e332ce6b3b09e723c08b11146ebe0cc16f0fd.
This also disables this test on s390x & PPC for now, but if that's not what we want then I can revert changes done to `CompressedClassPointersEncodingScheme.java` file.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2434795830
From mdoerr at openjdk.org Thu Oct 24 09:57:41 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 24 Oct 2024 09:57:41 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v21]
In-Reply-To: <XuC0_RaUpR0_JvlEzq8-j7oqovvyqNHFQyWPmDQamqA=.a5e8730c-555a-4872-919b-c39fa0873f97@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<TCFshDmOrJjN0zTh1X9BGEa_rczyMqRbyDIiYsFr_5I=.ea051371-4c86-461e-8721-83b32caf808f@github.com>
<qPL-XuWVkfNYFmfYatyQZwbHismNzW_jXdvkDvIiVNc=.d4fd26a8-f509-494a-bd3d-0c6f37ba5269@github.com>
<spymZDxJXwseFGxL78zfn4V8qe9NpX3gifTgd_eQkiM=.d1af7cf3-b503-4c35-93bb-db00f3c4cfc8@github.com>
<U1HQ2ijNoadMNlrW_Adxkju4fM8kfAB4hn-a_gkPrnA=.7e0fee38-8534-4dcc-8aac-77d6559687c8@github.com>
<CNrcAK8SrGCzsreT3SdoxaoGaqKqGb989t-waCJUz64=.0662bccb-661f-4dc9-b8b6-24d615035261@github.com>
<YyPrYu-6p5wcUwfMQQamwoM1eGp6eUze_yC1lrc7mb0=.f1e5853b-3b6e-4460-8f57-a6f7588e513e@github.com>
<Na5LWOz_h0ZGmLcETAxDA9wYiEopgWfvNTbYAELExR8=.e30fe7a0-c766-4bb4-aebb-fc6643c832c1@github.com>
<0fDctIMZlpNZ4a5_idrN_w8KnvGfPS49Bw_9WRdjJ9I=.8bedb8be-0b33-468b-b711-9c0b4fb6649e@github.com>
<G2EVWD7HifRRUclJtjvBIZS7CdwuYg4HlUH9QyXMLCw=.b9ff7725-2d53-4ae8-94ee-cb32c3bf1dfa@github.com>
<vMlI9KnBvvHNvxT__7149la64QKN1CrHlr3
OoX17x-E=.e06e392f-0e55-465d-b33e-a69d7f6ba5b3@github.com>
<cQxx13f6ujrDdrDqN_ynyMHKAEOJsKWwPpNDs3da_Mo=.d2fcfe0c-77d1-4e9c-8022-d103fd91fa0c@github.com>
<XuC0_RaUpR0_JvlEzq8-j7oqovvyqNHFQyWPmDQamqA=.a5e8730c-555a-4872-919b-c39fa0873f97@github.com>
Message-ID: <EhhpOu63Iz3L0zJ24gmprx32GB024wOfF8dYejNwtBY=.95d2a304-9033-4fe0-9f20-939608451b9e@github.com>
On Thu, 24 Oct 2024 09:28:13 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:
>>> But then, what exactly is the error? If it's just the test assuming that cache line size is log 6, then the test should be fixed for ppc, not hotspot.
>>
>> that is the problem, test assumes log2 of 6 for chacheline size
>
> PPC log2 will be `7` (`DEFAULT_CACHE_LINE_SIZE? = 128`) and for S390x it will be `8` (`DEFAULT_CACHE_LINE_SIZE? = 256`).
>
> So I guess this change should be fine for now :
>
> diff --git a/test/hotspot/jtreg/runtime/CompressedOops/CompressedClassPointersEncodingScheme.java b/test/hotspot/jtreg/runtime/CompressedOops/CompressedClassPointersEncodingScheme.java
> index e04e716315a..c1be59e77ab 100644
> --- a/test/hotspot/jtreg/runtime/CompressedOops/CompressedClassPointersEncodingScheme.java
> +++ b/test/hotspot/jtreg/runtime/CompressedOops/CompressedClassPointersEncodingScheme.java
> @@ -108,7 +108,9 @@ public static void main(String[] args) throws Exception {
>
> long ccsSize = 128 * M;
> int expectedShift = 6;
> - test(forceAddress, true, ccsSize, forceAddress, expectedShift);
> + if (!Platform.isPPC() && !Platform.isS390x()) {
> + test(forceAddress, true, ccsSize, forceAddress, expectedShift);
> + }
>
> ccsSize = 512 * M;
> expectedShift = 8;
As I understand the comment, it says alignment <= cache line size. But the implementation makes alignment >= cache line size. "hyper alignment" means alignment > cache line size?
If we want alignment = cache line size, I'll be ok with disabling the +COH part of the test on PPC64 and s390. Correct, the problem is that the test assumes that log cache line size = 6.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1814666149
From stuefe at openjdk.org Thu Oct 24 10:05:29 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 24 Oct 2024 10:05:29 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v21]
In-Reply-To: <EhhpOu63Iz3L0zJ24gmprx32GB024wOfF8dYejNwtBY=.95d2a304-9033-4fe0-9f20-939608451b9e@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<TCFshDmOrJjN0zTh1X9BGEa_rczyMqRbyDIiYsFr_5I=.ea051371-4c86-461e-8721-83b32caf808f@github.com>
<qPL-XuWVkfNYFmfYatyQZwbHismNzW_jXdvkDvIiVNc=.d4fd26a8-f509-494a-bd3d-0c6f37ba5269@github.com>
<spymZDxJXwseFGxL78zfn4V8qe9NpX3gifTgd_eQkiM=.d1af7cf3-b503-4c35-93bb-db00f3c4cfc8@github.com>
<U1HQ2ijNoadMNlrW_Adxkju4fM8kfAB4hn-a_gkPrnA=.7e0fee38-8534-4dcc-8aac-77d6559687c8@github.com>
<CNrcAK8SrGCzsreT3SdoxaoGaqKqGb989t-waCJUz64=.0662bccb-661f-4dc9-b8b6-24d615035261@github.com>
<YyPrYu-6p5wcUwfMQQamwoM1eGp6eUze_yC1lrc7mb0=.f1e5853b-3b6e-4460-8f57-a6f7588e513e@github.com>
<Na5LWOz_h0ZGmLcETAxDA9wYiEopgWfvNTbYAELExR8=.e30fe7a0-c766-4bb4-aebb-fc6643c832c1@github.com>
<0fDctIMZlpNZ4a5_idrN_w8KnvGfPS49Bw_9WRdjJ9I=.8bedb8be-0b33-468b-b711-9c0b4fb6649e@github.com>
<G2EVWD7HifRRUclJtjvBIZS7CdwuYg4HlUH9QyXMLCw=.b9ff7725-2d53-4ae8-94ee-cb32c3bf1dfa@github.com>
<vMlI9KnBvvHNvxT__7149la64QKN1CrHlr3
OoX17x-E=.e06e392f-0e55-465d-b33e-a69d7f6ba5b3@github.com>
<cQxx13f6ujrDdrDqN_ynyMHKAEOJsKWwPpNDs3da_Mo=.d2fcfe0c-77d1-4e9c-8022-d103fd91fa0c@github.com>
<XuC0_RaUpR0_JvlEzq8-j7oqovvyqNHFQyWPmDQamqA=.a5e8730c-555a-4872-919b-c39fa0873f97@github.com>
<EhhpOu63Iz3L0zJ24gmprx32GB024wOfF8dYejNwtBY=.95d2a304-9033-4fe0-9f20-939608451b9e@github.com>
Message-ID: <jukDFOOSL9NVHA-RzXo6E9nhIV66vCf0lVnBtqu73ug=.ea8a5277-c7d3-4eb0-84b0-55960e4f3d38@github.com>
On Thu, 24 Oct 2024 09:54:05 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:
> As I understand the comment, it says alignment <= cache line size. But the implementation makes alignment >= cache line size. "hyper alignment" means alignment > cache line size?
Correct. since encoding range must cover the full klass range, and we only have 22bit nklass, shift is larger. at most 10. but since that causes hyper aligning, we try to get away with smaller shifts if klass range is smaller.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1814680330
From stefank at openjdk.org Thu Oct 24 12:19:19 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 24 Oct 2024 12:19:19 GMT
Subject: RFR: 8342857: SA: Heap iterator makes incorrect assumptions about
TLAB layout [v3]
In-Reply-To: <0_0LoiSECTe_JEfGgOTCICMw1lblyUhN0F7WSCE8GdA=.fc9c6013-657f-4eaa-9378-c1c51357e881@github.com>
References: <lIV_Ob5b_ATRTNLNSWTTZQL1VQ35aW8A1QIOSR6Lslo=.4259ebec-6dec-45a4-a818-acabe530e206@github.com>
<0_0LoiSECTe_JEfGgOTCICMw1lblyUhN0F7WSCE8GdA=.fc9c6013-657f-4eaa-9378-c1c51357e881@github.com>
Message-ID: <hhk-fgIOWjo43mkZp_kiKVNAGWcRyB8U-dRNi9Hbz48=.8b2b451f-bfb3-46f7-b04a-3faaf17eb3b2@github.com>
On Wed, 23 Oct 2024 19:48:13 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:
>> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
>>
>> Revert "Remove redundant db.lookupType"
>>
>> This reverts commit e8ec2957d43730560c73e2ea9b3ec7a91fc25535.
>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VM.java line 443:
>
>> 441:
>> 442: Type collectedHeap = db.lookupType("CollectedHeap");
>> 443: CIntegerType sizeType = (CIntegerType) db.lookupType("size_t");
>
> I think you can use getSizet() here.
`getSizet()` seems to be a function in `Flags`, so I don't see a direct way to use it. I could probably use the `sizetType` instead of `db.lookupType("size_t")`, however when I tested the tests failed because sizetType had not been initialized yet.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/21662#discussion_r1814862338
From stefank at openjdk.org Thu Oct 24 12:19:19 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 24 Oct 2024 12:19:19 GMT
Subject: RFR: 8342857: SA: Heap iterator makes incorrect assumptions about
TLAB layout [v3]
In-Reply-To: <lIV_Ob5b_ATRTNLNSWTTZQL1VQ35aW8A1QIOSR6Lslo=.4259ebec-6dec-45a4-a818-acabe530e206@github.com>
References: <lIV_Ob5b_ATRTNLNSWTTZQL1VQ35aW8A1QIOSR6Lslo=.4259ebec-6dec-45a4-a818-acabe530e206@github.com>
Message-ID: <QXV17HiekS1EfuDq0OXD0LZa5x2-a0tU2BHatDnZ1qE=.2c0d5871-cec0-42dc-9834-ed0717cef8da@github.com>
> When testing Lilliput we found a failure in `serviceability/sa/ClhsdbJstackWithConcurrentLock.java` test when running with C1-only.
>
> The test uses the SA's thread printing feature to print the threads *and* the "concurrent locks" / AbstractOwnableSynchronizers. It then verifies that the expected lock is listed in the section for "Locked ownable synchronizers".
>
> When we turned on Lilliput's -XX:+UseCompactObjectHeaders this stopped working, and we got nothing reported in that section:
>
>
> "Thread-0" #31 prio=5 tid=0x00007a708c259ad0 nid=1480533 waiting on condition [0x00007a706fefe000]
> java.lang.Thread.State: TIMED_WAITING (sleeping)
> JavaThread state: _thread_blocked
> - java.lang.Thread.sleepNanos0(long) @bci=0 (Interpreted frame)
> - java.lang.Thread.sleepNanos(long) @bci=33, line=497 (Interpreted frame)
> - java.lang.Thread.sleep(long) @bci=25, line=528 (Interpreted frame)
> - LingeredAppWithConcurrentLock.lockMethod(java.util.concurrent.locks.Lock) @bci=13, line=38 (Interpreted frame)
> - locked <0x00000000ffd32d88> (a java.util.concurrent.locks.ReentrantLock)
> - LingeredAppWithConcurrentLock.lambda$main$0() @bci=3, line=46 (Interpreted frame)
> - LingeredAppWithConcurrentLock$$Lambda+0x00007a7023001000.run() @bci=0 (Interpreted frame)
> - java.lang.Thread.runWith(java.lang.Object, java.lang.Runnable) @bci=5, line=1589 (Interpreted frame)
> - java.lang.Thread.run() @bci=19, line=1576 (Interpreted frame)
>
> Locked ownable synchronizers:
> - None
>
>
> It should be saying:
>
> Locked ownable synchronizers:
> - <0x00000000ffd32d88>, (a java/util/concurrent/locks/ReentrantLock$NonfairSync)
>
>
> The problem lies within the code that searches for objects in the heap. It collects a bunch of regions and searches them for objects. However, the code that describes the TLAB regions are stale and doesn't match the C++ implementation in the JVM. When Lilliput shrinks the headers the SA code is broken enough to cause the TLAB regions to be reported as overlapping. This has ripple effects that the object iterators stop working.
>
> I can get this test to pass, with and without compact object headers, by fixing the code in `ThreadLocalAllocBuffer::hard_end()`.
>
> This is a reproducer of the problem:
>
> make -C ../build/fastdebug test TEST=serviceability/sa/ClhsdbJstackWithConcurrentLock.java JTREG="JAVA_OPTIONS=-XX:TieredStopAtLevel=2 -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders"
>
>
> I've tested this by running all 'serviceability' tests in our tier1-9 testing.
Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
Revert "Remove redundant db.lookupType"
This reverts commit e8ec2957d43730560c73e2ea9b3ec7a91fc25535.
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/21662/files
- new: https://git.openjdk.org/jdk/pull/21662/files/e8ec2957..3f50944e
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=21662&range=02
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=21662&range=01-02
Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
Patch: https://git.openjdk.org/jdk/pull/21662.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/21662/head:pull/21662
PR: https://git.openjdk.org/jdk/pull/21662
From rkennke at openjdk.org Thu Oct 24 14:05:40 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 24 Oct 2024 14:05:40 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v51]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <V0bl0ewTz3kmPqZhynFqVFjlKjtpzxLCax-Yua5wCTQ=.326f5fee-58bd-4085-a4e8-3848f23f9cbe@github.com>
> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>
> Main changes:
> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
> - Arrays will now store their length at offset 8.
> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...
Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
Conditionalize platform specific parts of CompressedClassPointersEncodingScheme test
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/20677/files
- new: https://git.openjdk.org/jdk/pull/20677/files/1ef6394d..aadd7b8e
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=50
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=49-50
Stats: 16 lines in 1 file changed: 2 ins; 0 del; 14 mod
Patch: https://git.openjdk.org/jdk/pull/20677.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677
PR: https://git.openjdk.org/jdk/pull/20677
From rkennke at openjdk.org Thu Oct 24 14:19:11 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 24 Oct 2024 14:19:11 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v52]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <cjjVE9UklTmD7ofyudyMkhY9MWtD2MGmtPpZczGgm6w=.62f0f8eb-6c63-4ac2-8bcd-30d23240e989@github.com>
> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>
> Main changes:
> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
> - Arrays will now store their length at offset 8.
> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...
Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
s390 port
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/20677/files
- new: https://git.openjdk.org/jdk/pull/20677/files/aadd7b8e..c2f6d202
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=51
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=50-51
Stats: 151 lines in 9 files changed: 113 ins; 17 del; 21 mod
Patch: https://git.openjdk.org/jdk/pull/20677.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677
PR: https://git.openjdk.org/jdk/pull/20677
From cjplummer at openjdk.org Thu Oct 24 18:17:06 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 24 Oct 2024 18:17:06 GMT
Subject: RFR: 8342857: SA: Heap iterator makes incorrect assumptions about
TLAB layout [v3]
In-Reply-To: <hhk-fgIOWjo43mkZp_kiKVNAGWcRyB8U-dRNi9Hbz48=.8b2b451f-bfb3-46f7-b04a-3faaf17eb3b2@github.com>
References: <lIV_Ob5b_ATRTNLNSWTTZQL1VQ35aW8A1QIOSR6Lslo=.4259ebec-6dec-45a4-a818-acabe530e206@github.com>
<0_0LoiSECTe_JEfGgOTCICMw1lblyUhN0F7WSCE8GdA=.fc9c6013-657f-4eaa-9378-c1c51357e881@github.com>
<hhk-fgIOWjo43mkZp_kiKVNAGWcRyB8U-dRNi9Hbz48=.8b2b451f-bfb3-46f7-b04a-3faaf17eb3b2@github.com>
Message-ID: <QAkjnHtY_DGrtA4bBNUkm6DKES2xsgdHFXOeO4UjpHA=.774ac3fe-ee68-485f-b5dc-77ff9946ea72@github.com>
On Thu, 24 Oct 2024 12:16:22 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:
>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VM.java line 443:
>>
>>> 441:
>>> 442: Type collectedHeap = db.lookupType("CollectedHeap");
>>> 443: CIntegerType sizeType = (CIntegerType) db.lookupType("size_t");
>>
>> I think you can use getSizet() here.
>
> `getSizet()` seems to be a function in `Flags`, so I don't see a direct way to use it. I could probably use the `sizetType` instead of `db.lookupType("size_t")`, however when I tested the tests failed because sizetType had not been initialized yet.
It looks like `sizetType` is initialized further down in the constructor. You could move that up (and the other 6 types also) or move your new code down. And speaking of the new code, it is misplaced in the try block. Both the comment for that block and the exception thrown have to do with getting the version. The `reserveForAllocationPrefetch` code just above is also misplaced for the same reason. That got added by [JDK-8004710](https://bugs.openjdk.org/browse/JDK-8004710). Perhaps some cleanup is in order here. I don't think a try/catch/throw is needed for the tlab code. There are other places in the constructor that can throw an exception, and if that happens, it should be obvious from the stack trace where it happened. That is all you need to debug the issue. I think maybe the VMVersion section was special cased since it is the most likely failure point if something is really wrong that will result in a failure of SA to startup.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/21662#discussion_r1815517050
From mli at openjdk.org Thu Oct 24 19:01:36 2024
From: mli at openjdk.org (Hamlin Li)
Date: Thu, 24 Oct 2024 19:01:36 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v51]
In-Reply-To: <V0bl0ewTz3kmPqZhynFqVFjlKjtpzxLCax-Yua5wCTQ=.326f5fee-58bd-4085-a4e8-3848f23f9cbe@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<V0bl0ewTz3kmPqZhynFqVFjlKjtpzxLCax-Yua5wCTQ=.326f5fee-58bd-4085-a4e8-3848f23f9cbe@github.com>
Message-ID: <6cP6tvH2d8TU7TEuAxZoAtXFHg2jhtLEpOogKSCIeDE=.d2c3cce9-bb23-48c8-8829-8edd14249842@github.com>
On Thu, 24 Oct 2024 14:05:40 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>>
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>>
>> Main changes:
>> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>> - Arrays will now store their length at offset 8.
>> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>
> Conditionalize platform specific parts of CompressedClassPointersEncodingScheme test
test/hotspot/jtreg/runtime/CompressedOops/CompressedClassPointersEncodingScheme.java line 107:
> 105: // the encoding range. We expect the encoding Base to start at the class space start - but to enforce that,
> 106: // we choose a high address.
> 107: if (Platform.isAArch64() || Platform.isX64()) {
@rkennke please also enable riscv for this test `CompressedClassPointersEncodingScheme.java`, it passed in my environment. Thanks!
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1815565554
From stefank at openjdk.org Thu Oct 24 19:09:42 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 24 Oct 2024 19:09:42 GMT
Subject: RFR: 8342857: SA: Heap iterator makes incorrect assumptions about
TLAB layout [v4]
In-Reply-To: <lIV_Ob5b_ATRTNLNSWTTZQL1VQ35aW8A1QIOSR6Lslo=.4259ebec-6dec-45a4-a818-acabe530e206@github.com>
References: <lIV_Ob5b_ATRTNLNSWTTZQL1VQ35aW8A1QIOSR6Lslo=.4259ebec-6dec-45a4-a818-acabe530e206@github.com>
Message-ID: <o-3eJ3A5yUNKkXc3AuUUX0zZ9_dsz512oxIv_IzlGNc=.818b9e08-7071-47ee-ab12-808458d65925@github.com>
> When testing Lilliput we found a failure in `serviceability/sa/ClhsdbJstackWithConcurrentLock.java` test when running with C1-only.
>
> The test uses the SA's thread printing feature to print the threads *and* the "concurrent locks" / AbstractOwnableSynchronizers. It then verifies that the expected lock is listed in the section for "Locked ownable synchronizers".
>
> When we turned on Lilliput's -XX:+UseCompactObjectHeaders this stopped working, and we got nothing reported in that section:
>
>
> "Thread-0" #31 prio=5 tid=0x00007a708c259ad0 nid=1480533 waiting on condition [0x00007a706fefe000]
> java.lang.Thread.State: TIMED_WAITING (sleeping)
> JavaThread state: _thread_blocked
> - java.lang.Thread.sleepNanos0(long) @bci=0 (Interpreted frame)
> - java.lang.Thread.sleepNanos(long) @bci=33, line=497 (Interpreted frame)
> - java.lang.Thread.sleep(long) @bci=25, line=528 (Interpreted frame)
> - LingeredAppWithConcurrentLock.lockMethod(java.util.concurrent.locks.Lock) @bci=13, line=38 (Interpreted frame)
> - locked <0x00000000ffd32d88> (a java.util.concurrent.locks.ReentrantLock)
> - LingeredAppWithConcurrentLock.lambda$main$0() @bci=3, line=46 (Interpreted frame)
> - LingeredAppWithConcurrentLock$$Lambda+0x00007a7023001000.run() @bci=0 (Interpreted frame)
> - java.lang.Thread.runWith(java.lang.Object, java.lang.Runnable) @bci=5, line=1589 (Interpreted frame)
> - java.lang.Thread.run() @bci=19, line=1576 (Interpreted frame)
>
> Locked ownable synchronizers:
> - None
>
>
> It should be saying:
>
> Locked ownable synchronizers:
> - <0x00000000ffd32d88>, (a java/util/concurrent/locks/ReentrantLock$NonfairSync)
>
>
> The problem lies within the code that searches for objects in the heap. It collects a bunch of regions and searches them for objects. However, the code that describes the TLAB regions are stale and doesn't match the C++ implementation in the JVM. When Lilliput shrinks the headers the SA code is broken enough to cause the TLAB regions to be reported as overlapping. This has ripple effects that the object iterators stop working.
>
> I can get this test to pass, with and without compact object headers, by fixing the code in `ThreadLocalAllocBuffer::hard_end()`.
>
> This is a reproducer of the problem:
>
> make -C ../build/fastdebug test TEST=serviceability/sa/ClhsdbJstackWithConcurrentLock.java JTREG="JAVA_OPTIONS=-XX:TieredStopAtLevel=2 -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders"
>
>
> I've tested this by running all 'serviceability' tests in our tier1-9 testing.
Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
Cleanups
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/21662/files
- new: https://git.openjdk.org/jdk/pull/21662/files/3f50944e..adc7d755
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=21662&range=03
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=21662&range=02-03
Stats: 41 lines in 1 file changed: 17 ins; 18 del; 6 mod
Patch: https://git.openjdk.org/jdk/pull/21662.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/21662/head:pull/21662
PR: https://git.openjdk.org/jdk/pull/21662
From stefank at openjdk.org Thu Oct 24 19:09:42 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 24 Oct 2024 19:09:42 GMT
Subject: RFR: 8342857: SA: Heap iterator makes incorrect assumptions about
TLAB layout [v4]
In-Reply-To: <QAkjnHtY_DGrtA4bBNUkm6DKES2xsgdHFXOeO4UjpHA=.774ac3fe-ee68-485f-b5dc-77ff9946ea72@github.com>
References: <lIV_Ob5b_ATRTNLNSWTTZQL1VQ35aW8A1QIOSR6Lslo=.4259ebec-6dec-45a4-a818-acabe530e206@github.com>
<0_0LoiSECTe_JEfGgOTCICMw1lblyUhN0F7WSCE8GdA=.fc9c6013-657f-4eaa-9378-c1c51357e881@github.com>
<hhk-fgIOWjo43mkZp_kiKVNAGWcRyB8U-dRNi9Hbz48=.8b2b451f-bfb3-46f7-b04a-3faaf17eb3b2@github.com>
<QAkjnHtY_DGrtA4bBNUkm6DKES2xsgdHFXOeO4UjpHA=.774ac3fe-ee68-485f-b5dc-77ff9946ea72@github.com>
Message-ID: <RQ-ITSxYyU7Dry29P8-55SDilhHLn8tq0kAz5dtRLn4=.14b347e4-84a7-45d4-9851-d655e4a35ef8@github.com>
On Thu, 24 Oct 2024 18:14:25 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:
>> `getSizet()` seems to be a function in `Flags`, so I don't see a direct way to use it. I could probably use the `sizetType` instead of `db.lookupType("size_t")`, however when I tested the tests failed because sizetType had not been initialized yet.
>
> It looks like `sizetType` is initialized further down in the constructor. You could move that up (and the other 6 types also) or move your new code down. And speaking of the new code, it is misplaced in the try block. Both the comment for that block and the exception thrown have to do with getting the version. The `reserveForAllocationPrefetch` code just above is also misplaced for the same reason. That got added by [JDK-8004710](https://bugs.openjdk.org/browse/JDK-8004710). Perhaps some cleanup is in order here. I don't think a try/catch/throw is needed for the tlab code. There are other places in the constructor that can throw an exception, and if that happens, it should be obvious from the stack trace where it happened. That is all you need to debug the issue. I think maybe the VMVersion section was special cased since it is the most likely failure point if something is really wrong that will result in a failure of SA to startup.
OK. I did some cleanups. Could you take a look and see if this is good enough to get this integrated?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/21662#discussion_r1815573383
From cjplummer at openjdk.org Thu Oct 24 20:11:05 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 24 Oct 2024 20:11:05 GMT
Subject: RFR: 8342857: SA: Heap iterator makes incorrect assumptions about
TLAB layout [v4]
In-Reply-To: <o-3eJ3A5yUNKkXc3AuUUX0zZ9_dsz512oxIv_IzlGNc=.818b9e08-7071-47ee-ab12-808458d65925@github.com>
References: <lIV_Ob5b_ATRTNLNSWTTZQL1VQ35aW8A1QIOSR6Lslo=.4259ebec-6dec-45a4-a818-acabe530e206@github.com>
<o-3eJ3A5yUNKkXc3AuUUX0zZ9_dsz512oxIv_IzlGNc=.818b9e08-7071-47ee-ab12-808458d65925@github.com>
Message-ID: <_0uHT4bd7SU4eAejzvRxbm-irb0pEHleXHvzrxjsXdU=.74cd0b40-e811-418e-b1c1-e32cc13a68e1@github.com>
On Thu, 24 Oct 2024 19:09:42 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:
>> When testing Lilliput we found a failure in `serviceability/sa/ClhsdbJstackWithConcurrentLock.java` test when running with C1-only.
>>
>> The test uses the SA's thread printing feature to print the threads *and* the "concurrent locks" / AbstractOwnableSynchronizers. It then verifies that the expected lock is listed in the section for "Locked ownable synchronizers".
>>
>> When we turned on Lilliput's -XX:+UseCompactObjectHeaders this stopped working, and we got nothing reported in that section:
>>
>>
>> "Thread-0" #31 prio=5 tid=0x00007a708c259ad0 nid=1480533 waiting on condition [0x00007a706fefe000]
>> java.lang.Thread.State: TIMED_WAITING (sleeping)
>> JavaThread state: _thread_blocked
>> - java.lang.Thread.sleepNanos0(long) @bci=0 (Interpreted frame)
>> - java.lang.Thread.sleepNanos(long) @bci=33, line=497 (Interpreted frame)
>> - java.lang.Thread.sleep(long) @bci=25, line=528 (Interpreted frame)
>> - LingeredAppWithConcurrentLock.lockMethod(java.util.concurrent.locks.Lock) @bci=13, line=38 (Interpreted frame)
>> - locked <0x00000000ffd32d88> (a java.util.concurrent.locks.ReentrantLock)
>> - LingeredAppWithConcurrentLock.lambda$main$0() @bci=3, line=46 (Interpreted frame)
>> - LingeredAppWithConcurrentLock$$Lambda+0x00007a7023001000.run() @bci=0 (Interpreted frame)
>> - java.lang.Thread.runWith(java.lang.Object, java.lang.Runnable) @bci=5, line=1589 (Interpreted frame)
>> - java.lang.Thread.run() @bci=19, line=1576 (Interpreted frame)
>>
>> Locked ownable synchronizers:
>> - None
>>
>>
>> It should be saying:
>>
>> Locked ownable synchronizers:
>> - <0x00000000ffd32d88>, (a java/util/concurrent/locks/ReentrantLock$NonfairSync)
>>
>>
>> The problem lies within the code that searches for objects in the heap. It collects a bunch of regions and searches them for objects. However, the code that describes the TLAB regions are stale and doesn't match the C++ implementation in the JVM. When Lilliput shrinks the headers the SA code is broken enough to cause the TLAB regions to be reported as overlapping. This has ripple effects that the object iterators stop working.
>>
>> I can get this test to pass, with and without compact object headers, by fixing the code in `ThreadLocalAllocBuffer::hard_end()`.
>>
>> This is a reproducer of the problem:
>>
>> make -C ../build/fastdebug test TEST=serviceability/sa/ClhsdbJstackWithConcurrentLock.java JTREG="JAVA_OPTIONS=-XX:TieredStopAtLevel=2 -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders"
>>
>>
>> I've test...
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
>
> Cleanups
Looks good. Please update the SA copyrights before integrating.
-------------
Marked as reviewed by cjplummer (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/21662#pullrequestreview-2393613327
From rkennke at openjdk.org Thu Oct 24 21:04:51 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 24 Oct 2024 21:04:51 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v51]
In-Reply-To: <6cP6tvH2d8TU7TEuAxZoAtXFHg2jhtLEpOogKSCIeDE=.d2c3cce9-bb23-48c8-8829-8edd14249842@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<V0bl0ewTz3kmPqZhynFqVFjlKjtpzxLCax-Yua5wCTQ=.326f5fee-58bd-4085-a4e8-3848f23f9cbe@github.com>
<6cP6tvH2d8TU7TEuAxZoAtXFHg2jhtLEpOogKSCIeDE=.d2c3cce9-bb23-48c8-8829-8edd14249842@github.com>
Message-ID: <YfqWH6yBeIGE9yXnmP1j70P48QMaVrUa-RJGwVTw1yU=.70c9bb75-d223-4795-9438-1e76c315ffe3@github.com>
On Thu, 24 Oct 2024 18:58:03 GMT, Hamlin Li <mli at openjdk.org> wrote:
>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>>
>> Conditionalize platform specific parts of CompressedClassPointersEncodingScheme test
>
> test/hotspot/jtreg/runtime/CompressedOops/CompressedClassPointersEncodingScheme.java line 107:
>
>> 105: // the encoding range. We expect the encoding Base to start at the class space start - but to enforce that,
>> 106: // we choose a high address.
>> 107: if (Platform.isAArch64() || Platform.isX64()) {
>
> @rkennke please also enable riscv for this test `CompressedClassPointersEncodingScheme.java`, it passed in my environment. Thanks!
Done.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1815690759
From rkennke at openjdk.org Thu Oct 24 21:04:51 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 24 Oct 2024 21:04:51 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v53]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <LDg0GvC9lXkYPS90d9w8QfkTWlztUa5tlsgblGywCc4=.78ab2a17-2e28-4c27-b026-cd694ec02e21@github.com>
> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>
> Main changes:
> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
> - Arrays will now store their length at offset 8.
> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...
Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
Enable riscv in CompressedClassPointersEncodingScheme test
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/20677/files
- new: https://git.openjdk.org/jdk/pull/20677/files/c2f6d202..434c6817
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=52
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=51-52
Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
Patch: https://git.openjdk.org/jdk/pull/20677.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677
PR: https://git.openjdk.org/jdk/pull/20677
From kbarrett at openjdk.org Fri Oct 25 03:29:36 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 25 Oct 2024 03:29:36 GMT
Subject: RFR: 8342918: Building ParallelGC without G1 and Shenandoah fails
because SpaceMangler not declared
Message-ID: <_CC2D44TDh-MGMbf8PeGMg9uH7cMvO9G9P-NyA-OIbs=.a1bb205c-f813-4a6f-b3aa-0fca4aa88824@github.com>
Please review this simple (trivial?) change to add a missing include of
gc/shared/spaceDecorator.hpp to several files in gc/parallel. These are all
of the files that directly reference SpaceMangler or SpaceDecorator, except
mutableNUMASpace.cpp (which already had the include).
Testing: mach5 tier1
locally (linux-x64) built with g1, shenandoah, and zgc excluded from build.
locally (linux-x64) built linux-x86 with warnings != errors, to avoid failures
from things like JDK-8339313.
GHA OpenJDK Sanity Checks
-------------
Commit messages:
- add includes
Changes: https://git.openjdk.org/jdk/pull/21700/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21700&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8342918
Stats: 7 lines in 5 files changed: 5 ins; 0 del; 2 mod
Patch: https://git.openjdk.org/jdk/pull/21700.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/21700/head:pull/21700
PR: https://git.openjdk.org/jdk/pull/21700
From jwaters at openjdk.org Fri Oct 25 04:51:13 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 25 Oct 2024 04:51:13 GMT
Subject: RFR: 8342918: Building ParallelGC without G1 and Shenandoah fails
because SpaceMangler not declared
In-Reply-To: <_CC2D44TDh-MGMbf8PeGMg9uH7cMvO9G9P-NyA-OIbs=.a1bb205c-f813-4a6f-b3aa-0fca4aa88824@github.com>
References: <_CC2D44TDh-MGMbf8PeGMg9uH7cMvO9G9P-NyA-OIbs=.a1bb205c-f813-4a6f-b3aa-0fca4aa88824@github.com>
Message-ID: <fSLhgSE8cIahtuEagsIKpI90WZRTbULh5HmycE52SQ8=.44de5867-01a3-4641-802d-555c674382cc@github.com>
On Fri, 25 Oct 2024 03:24:26 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:
> Please review this simple (trivial?) change to add a missing include of
> gc/shared/spaceDecorator.hpp to several files in gc/parallel. These are all
> of the files that directly reference SpaceMangler or SpaceDecorator, except
> mutableNUMASpace.cpp (which already had the include).
>
> Testing: mach5 tier1
> locally (linux-x64) built with g1, shenandoah, and zgc excluded from build.
> locally (linux-x64) built linux-x86 with warnings != errors, to avoid failures
> from things like JDK-8339313.
> GHA OpenJDK Sanity Checks
Looks good
-------------
Marked as reviewed by jwaters (Committer).
PR Review: https://git.openjdk.org/jdk/pull/21700#pullrequestreview-2394159489
From shade at openjdk.org Fri Oct 25 05:53:06 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 25 Oct 2024 05:53:06 GMT
Subject: RFR: 8342918: Building ParallelGC without G1 and Shenandoah fails
because SpaceMangler not declared
In-Reply-To: <_CC2D44TDh-MGMbf8PeGMg9uH7cMvO9G9P-NyA-OIbs=.a1bb205c-f813-4a6f-b3aa-0fca4aa88824@github.com>
References: <_CC2D44TDh-MGMbf8PeGMg9uH7cMvO9G9P-NyA-OIbs=.a1bb205c-f813-4a6f-b3aa-0fca4aa88824@github.com>
Message-ID: <vCz1D9HwKcz0sUgPtNV1OHolF97XMHaRUFYyK7JuDCA=.da785d52-620d-466d-9ed6-592ab072d759@github.com>
On Fri, 25 Oct 2024 03:24:26 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:
> Please review this simple (trivial?) change to add a missing include of
> gc/shared/spaceDecorator.hpp to several files in gc/parallel. These are all
> of the files that directly reference SpaceMangler or SpaceDecorator, except
> mutableNUMASpace.cpp (which already had the include).
>
> Testing: mach5 tier1
> locally (linux-x64) built with g1, shenandoah, and zgc excluded from build.
> locally (linux-x64) built linux-x86 with warnings != errors, to avoid failures
> from things like JDK-8339313.
> GHA OpenJDK Sanity Checks
Looks fine. I believe it is trivial.
-------------
Marked as reviewed by shade (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/21700#pullrequestreview-2394235915
From kbarrett at openjdk.org Fri Oct 25 06:17:08 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 25 Oct 2024 06:17:08 GMT
Subject: RFR: 8342918: Building ParallelGC without G1 and Shenandoah fails
because SpaceMangler not declared
In-Reply-To: <fSLhgSE8cIahtuEagsIKpI90WZRTbULh5HmycE52SQ8=.44de5867-01a3-4641-802d-555c674382cc@github.com>
References: <_CC2D44TDh-MGMbf8PeGMg9uH7cMvO9G9P-NyA-OIbs=.a1bb205c-f813-4a6f-b3aa-0fca4aa88824@github.com>
<fSLhgSE8cIahtuEagsIKpI90WZRTbULh5HmycE52SQ8=.44de5867-01a3-4641-802d-555c674382cc@github.com>
Message-ID: <rRmIf_RipG_7NlJEGf_Dm8ihjtALE0lrXrDQU8Klzus=.653f87a5-24a2-4bf1-b513-0a9e12fc2031@github.com>
On Fri, 25 Oct 2024 04:48:34 GMT, Julian Waters <jwaters at openjdk.org> wrote:
>> Please review this simple (trivial?) change to add a missing include of
>> gc/shared/spaceDecorator.hpp to several files in gc/parallel. These are all
>> of the files that directly reference SpaceMangler or SpaceDecorator, except
>> mutableNUMASpace.cpp (which already had the include).
>>
>> Testing: mach5 tier1
>> locally (linux-x64) built with g1, shenandoah, and zgc excluded from build.
>> locally (linux-x64) built linux-x86 with warnings != errors, to avoid failures
>> from things like JDK-8339313.
>> GHA OpenJDK Sanity Checks
>
> Looks good
Thanks for reviews, @TheShermanTanker and @shipilev .
-------------
PR Comment: https://git.openjdk.org/jdk/pull/21700#issuecomment-2436935203
From kbarrett at openjdk.org Fri Oct 25 06:17:10 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 25 Oct 2024 06:17:10 GMT
Subject: Integrated: 8342918: Building ParallelGC without G1 and Shenandoah
fails because SpaceMangler not declared
In-Reply-To: <_CC2D44TDh-MGMbf8PeGMg9uH7cMvO9G9P-NyA-OIbs=.a1bb205c-f813-4a6f-b3aa-0fca4aa88824@github.com>
References: <_CC2D44TDh-MGMbf8PeGMg9uH7cMvO9G9P-NyA-OIbs=.a1bb205c-f813-4a6f-b3aa-0fca4aa88824@github.com>
Message-ID: <F5VKDc1xztBVA3iXaYzHMEyW_bT9elHC6u4v2mgQQbw=.035cc809-9a88-4046-b418-3dd0a75cb81a@github.com>
On Fri, 25 Oct 2024 03:24:26 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:
> Please review this simple (trivial?) change to add a missing include of
> gc/shared/spaceDecorator.hpp to several files in gc/parallel. These are all
> of the files that directly reference SpaceMangler or SpaceDecorator, except
> mutableNUMASpace.cpp (which already had the include).
>
> Testing: mach5 tier1
> locally (linux-x64) built with g1, shenandoah, and zgc excluded from build.
> locally (linux-x64) built linux-x86 with warnings != errors, to avoid failures
> from things like JDK-8339313.
> GHA OpenJDK Sanity Checks
This pull request has now been integrated.
Changeset: c5489866
Author: Kim Barrett <kbarrett at openjdk.org>
URL: https://git.openjdk.org/jdk/commit/c5489866308bd09729c5431537e0836145452624
Stats: 7 lines in 5 files changed: 5 ins; 0 del; 2 mod
8342918: Building ParallelGC without G1 and Shenandoah fails because SpaceMangler not declared
Reviewed-by: jwaters, shade
-------------
PR: https://git.openjdk.org/jdk/pull/21700
From stefank at openjdk.org Fri Oct 25 06:49:48 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 25 Oct 2024 06:49:48 GMT
Subject: RFR: 8342857: SA: Heap iterator makes incorrect assumptions about
TLAB layout [v5]
In-Reply-To: <lIV_Ob5b_ATRTNLNSWTTZQL1VQ35aW8A1QIOSR6Lslo=.4259ebec-6dec-45a4-a818-acabe530e206@github.com>
References: <lIV_Ob5b_ATRTNLNSWTTZQL1VQ35aW8A1QIOSR6Lslo=.4259ebec-6dec-45a4-a818-acabe530e206@github.com>
Message-ID: <fyPryzdw8KVKr0iHnuicJGEle2CV5JunN3xfGrsYxC0=.ca24dbe2-8f47-4a2a-b108-214eaf8d379c@github.com>
> When testing Lilliput we found a failure in `serviceability/sa/ClhsdbJstackWithConcurrentLock.java` test when running with C1-only.
>
> The test uses the SA's thread printing feature to print the threads *and* the "concurrent locks" / AbstractOwnableSynchronizers. It then verifies that the expected lock is listed in the section for "Locked ownable synchronizers".
>
> When we turned on Lilliput's -XX:+UseCompactObjectHeaders this stopped working, and we got nothing reported in that section:
>
>
> "Thread-0" #31 prio=5 tid=0x00007a708c259ad0 nid=1480533 waiting on condition [0x00007a706fefe000]
> java.lang.Thread.State: TIMED_WAITING (sleeping)
> JavaThread state: _thread_blocked
> - java.lang.Thread.sleepNanos0(long) @bci=0 (Interpreted frame)
> - java.lang.Thread.sleepNanos(long) @bci=33, line=497 (Interpreted frame)
> - java.lang.Thread.sleep(long) @bci=25, line=528 (Interpreted frame)
> - LingeredAppWithConcurrentLock.lockMethod(java.util.concurrent.locks.Lock) @bci=13, line=38 (Interpreted frame)
> - locked <0x00000000ffd32d88> (a java.util.concurrent.locks.ReentrantLock)
> - LingeredAppWithConcurrentLock.lambda$main$0() @bci=3, line=46 (Interpreted frame)
> - LingeredAppWithConcurrentLock$$Lambda+0x00007a7023001000.run() @bci=0 (Interpreted frame)
> - java.lang.Thread.runWith(java.lang.Object, java.lang.Runnable) @bci=5, line=1589 (Interpreted frame)
> - java.lang.Thread.run() @bci=19, line=1576 (Interpreted frame)
>
> Locked ownable synchronizers:
> - None
>
>
> It should be saying:
>
> Locked ownable synchronizers:
> - <0x00000000ffd32d88>, (a java/util/concurrent/locks/ReentrantLock$NonfairSync)
>
>
> The problem lies within the code that searches for objects in the heap. It collects a bunch of regions and searches them for objects. However, the code that describes the TLAB regions are stale and doesn't match the C++ implementation in the JVM. When Lilliput shrinks the headers the SA code is broken enough to cause the TLAB regions to be reported as overlapping. This has ripple effects that the object iterators stop working.
>
> I can get this test to pass, with and without compact object headers, by fixing the code in `ThreadLocalAllocBuffer::hard_end()`.
>
> This is a reproducer of the problem:
>
> make -C ../build/fastdebug test TEST=serviceability/sa/ClhsdbJstackWithConcurrentLock.java JTREG="JAVA_OPTIONS=-XX:TieredStopAtLevel=2 -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders"
>
>
> I've tested this by running all 'serviceability' tests in our tier1-9 testing.
Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
Copyright
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/21662/files
- new: https://git.openjdk.org/jdk/pull/21662/files/adc7d755..458165b6
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=21662&range=04
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=21662&range=03-04
Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
Patch: https://git.openjdk.org/jdk/pull/21662.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/21662/head:pull/21662
PR: https://git.openjdk.org/jdk/pull/21662
From cjplummer at openjdk.org Fri Oct 25 06:53:05 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 25 Oct 2024 06:53:05 GMT
Subject: RFR: 8342857: SA: Heap iterator makes incorrect assumptions about
TLAB layout [v5]
In-Reply-To: <fyPryzdw8KVKr0iHnuicJGEle2CV5JunN3xfGrsYxC0=.ca24dbe2-8f47-4a2a-b108-214eaf8d379c@github.com>
References: <lIV_Ob5b_ATRTNLNSWTTZQL1VQ35aW8A1QIOSR6Lslo=.4259ebec-6dec-45a4-a818-acabe530e206@github.com>
<fyPryzdw8KVKr0iHnuicJGEle2CV5JunN3xfGrsYxC0=.ca24dbe2-8f47-4a2a-b108-214eaf8d379c@github.com>
Message-ID: <cwgIJhoDs0dN6ttiZWOTS_YrI09Ddh1w3CQbP4PgGUw=.f15c1458-bb9d-4f0d-b28f-bd803a7ee994@github.com>
On Fri, 25 Oct 2024 06:49:48 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:
>> When testing Lilliput we found a failure in `serviceability/sa/ClhsdbJstackWithConcurrentLock.java` test when running with C1-only.
>>
>> The test uses the SA's thread printing feature to print the threads *and* the "concurrent locks" / AbstractOwnableSynchronizers. It then verifies that the expected lock is listed in the section for "Locked ownable synchronizers".
>>
>> When we turned on Lilliput's -XX:+UseCompactObjectHeaders this stopped working, and we got nothing reported in that section:
>>
>>
>> "Thread-0" #31 prio=5 tid=0x00007a708c259ad0 nid=1480533 waiting on condition [0x00007a706fefe000]
>> java.lang.Thread.State: TIMED_WAITING (sleeping)
>> JavaThread state: _thread_blocked
>> - java.lang.Thread.sleepNanos0(long) @bci=0 (Interpreted frame)
>> - java.lang.Thread.sleepNanos(long) @bci=33, line=497 (Interpreted frame)
>> - java.lang.Thread.sleep(long) @bci=25, line=528 (Interpreted frame)
>> - LingeredAppWithConcurrentLock.lockMethod(java.util.concurrent.locks.Lock) @bci=13, line=38 (Interpreted frame)
>> - locked <0x00000000ffd32d88> (a java.util.concurrent.locks.ReentrantLock)
>> - LingeredAppWithConcurrentLock.lambda$main$0() @bci=3, line=46 (Interpreted frame)
>> - LingeredAppWithConcurrentLock$$Lambda+0x00007a7023001000.run() @bci=0 (Interpreted frame)
>> - java.lang.Thread.runWith(java.lang.Object, java.lang.Runnable) @bci=5, line=1589 (Interpreted frame)
>> - java.lang.Thread.run() @bci=19, line=1576 (Interpreted frame)
>>
>> Locked ownable synchronizers:
>> - None
>>
>>
>> It should be saying:
>>
>> Locked ownable synchronizers:
>> - <0x00000000ffd32d88>, (a java/util/concurrent/locks/ReentrantLock$NonfairSync)
>>
>>
>> The problem lies within the code that searches for objects in the heap. It collects a bunch of regions and searches them for objects. However, the code that describes the TLAB regions are stale and doesn't match the C++ implementation in the JVM. When Lilliput shrinks the headers the SA code is broken enough to cause the TLAB regions to be reported as overlapping. This has ripple effects that the object iterators stop working.
>>
>> I can get this test to pass, with and without compact object headers, by fixing the code in `ThreadLocalAllocBuffer::hard_end()`.
>>
>> This is a reproducer of the problem:
>>
>> make -C ../build/fastdebug test TEST=serviceability/sa/ClhsdbJstackWithConcurrentLock.java JTREG="JAVA_OPTIONS=-XX:TieredStopAtLevel=2 -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders"
>>
>>
>> I've test...
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
>
> Copyright
Marked as reviewed by cjplummer (Reviewer).
-------------
PR Review: https://git.openjdk.org/jdk/pull/21662#pullrequestreview-2394351437
From stefank at openjdk.org Fri Oct 25 07:29:10 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 25 Oct 2024 07:29:10 GMT
Subject: RFR: 8342857: SA: Heap iterator makes incorrect assumptions about
TLAB layout [v5]
In-Reply-To: <fyPryzdw8KVKr0iHnuicJGEle2CV5JunN3xfGrsYxC0=.ca24dbe2-8f47-4a2a-b108-214eaf8d379c@github.com>
References: <lIV_Ob5b_ATRTNLNSWTTZQL1VQ35aW8A1QIOSR6Lslo=.4259ebec-6dec-45a4-a818-acabe530e206@github.com>
<fyPryzdw8KVKr0iHnuicJGEle2CV5JunN3xfGrsYxC0=.ca24dbe2-8f47-4a2a-b108-214eaf8d379c@github.com>
Message-ID: <VCr-EeSsX3rL_TzL3_3muU7xyu-PLnIXJ0cd3dCEcO0=.d1e4cbcc-236a-4580-8851-52938aefac19@github.com>
On Fri, 25 Oct 2024 06:49:48 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:
>> When testing Lilliput we found a failure in `serviceability/sa/ClhsdbJstackWithConcurrentLock.java` test when running with C1-only.
>>
>> The test uses the SA's thread printing feature to print the threads *and* the "concurrent locks" / AbstractOwnableSynchronizers. It then verifies that the expected lock is listed in the section for "Locked ownable synchronizers".
>>
>> When we turned on Lilliput's -XX:+UseCompactObjectHeaders this stopped working, and we got nothing reported in that section:
>>
>>
>> "Thread-0" #31 prio=5 tid=0x00007a708c259ad0 nid=1480533 waiting on condition [0x00007a706fefe000]
>> java.lang.Thread.State: TIMED_WAITING (sleeping)
>> JavaThread state: _thread_blocked
>> - java.lang.Thread.sleepNanos0(long) @bci=0 (Interpreted frame)
>> - java.lang.Thread.sleepNanos(long) @bci=33, line=497 (Interpreted frame)
>> - java.lang.Thread.sleep(long) @bci=25, line=528 (Interpreted frame)
>> - LingeredAppWithConcurrentLock.lockMethod(java.util.concurrent.locks.Lock) @bci=13, line=38 (Interpreted frame)
>> - locked <0x00000000ffd32d88> (a java.util.concurrent.locks.ReentrantLock)
>> - LingeredAppWithConcurrentLock.lambda$main$0() @bci=3, line=46 (Interpreted frame)
>> - LingeredAppWithConcurrentLock$$Lambda+0x00007a7023001000.run() @bci=0 (Interpreted frame)
>> - java.lang.Thread.runWith(java.lang.Object, java.lang.Runnable) @bci=5, line=1589 (Interpreted frame)
>> - java.lang.Thread.run() @bci=19, line=1576 (Interpreted frame)
>>
>> Locked ownable synchronizers:
>> - None
>>
>>
>> It should be saying:
>>
>> Locked ownable synchronizers:
>> - <0x00000000ffd32d88>, (a java/util/concurrent/locks/ReentrantLock$NonfairSync)
>>
>>
>> The problem lies within the code that searches for objects in the heap. It collects a bunch of regions and searches them for objects. However, the code that describes the TLAB regions are stale and doesn't match the C++ implementation in the JVM. When Lilliput shrinks the headers the SA code is broken enough to cause the TLAB regions to be reported as overlapping. This has ripple effects that the object iterators stop working.
>>
>> I can get this test to pass, with and without compact object headers, by fixing the code in `ThreadLocalAllocBuffer::hard_end()`.
>>
>> This is a reproducer of the problem:
>>
>> make -C ../build/fastdebug test TEST=serviceability/sa/ClhsdbJstackWithConcurrentLock.java JTREG="JAVA_OPTIONS=-XX:TieredStopAtLevel=2 -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders"
>>
>>
>> I've test...
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
>
> Copyright
Thanks for the reviews!
-------------
PR Comment: https://git.openjdk.org/jdk/pull/21662#issuecomment-2437083507
From stefank at openjdk.org Fri Oct 25 07:29:10 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 25 Oct 2024 07:29:10 GMT
Subject: Integrated: 8342857: SA: Heap iterator makes incorrect assumptions
about TLAB layout
In-Reply-To: <lIV_Ob5b_ATRTNLNSWTTZQL1VQ35aW8A1QIOSR6Lslo=.4259ebec-6dec-45a4-a818-acabe530e206@github.com>
References: <lIV_Ob5b_ATRTNLNSWTTZQL1VQ35aW8A1QIOSR6Lslo=.4259ebec-6dec-45a4-a818-acabe530e206@github.com>
Message-ID: <_Yq5NToiRS624xMdkcjzZQAwK_CHjTCS0LCWlBBH8Ec=.195d3a65-273e-4e92-8b58-0fd5c6521f7d@github.com>
On Wed, 23 Oct 2024 11:39:26 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:
> When testing Lilliput we found a failure in `serviceability/sa/ClhsdbJstackWithConcurrentLock.java` test when running with C1-only.
>
> The test uses the SA's thread printing feature to print the threads *and* the "concurrent locks" / AbstractOwnableSynchronizers. It then verifies that the expected lock is listed in the section for "Locked ownable synchronizers".
>
> When we turned on Lilliput's -XX:+UseCompactObjectHeaders this stopped working, and we got nothing reported in that section:
>
>
> "Thread-0" #31 prio=5 tid=0x00007a708c259ad0 nid=1480533 waiting on condition [0x00007a706fefe000]
> java.lang.Thread.State: TIMED_WAITING (sleeping)
> JavaThread state: _thread_blocked
> - java.lang.Thread.sleepNanos0(long) @bci=0 (Interpreted frame)
> - java.lang.Thread.sleepNanos(long) @bci=33, line=497 (Interpreted frame)
> - java.lang.Thread.sleep(long) @bci=25, line=528 (Interpreted frame)
> - LingeredAppWithConcurrentLock.lockMethod(java.util.concurrent.locks.Lock) @bci=13, line=38 (Interpreted frame)
> - locked <0x00000000ffd32d88> (a java.util.concurrent.locks.ReentrantLock)
> - LingeredAppWithConcurrentLock.lambda$main$0() @bci=3, line=46 (Interpreted frame)
> - LingeredAppWithConcurrentLock$$Lambda+0x00007a7023001000.run() @bci=0 (Interpreted frame)
> - java.lang.Thread.runWith(java.lang.Object, java.lang.Runnable) @bci=5, line=1589 (Interpreted frame)
> - java.lang.Thread.run() @bci=19, line=1576 (Interpreted frame)
>
> Locked ownable synchronizers:
> - None
>
>
> It should be saying:
>
> Locked ownable synchronizers:
> - <0x00000000ffd32d88>, (a java/util/concurrent/locks/ReentrantLock$NonfairSync)
>
>
> The problem lies within the code that searches for objects in the heap. It collects a bunch of regions and searches them for objects. However, the code that describes the TLAB regions are stale and doesn't match the C++ implementation in the JVM. When Lilliput shrinks the headers the SA code is broken enough to cause the TLAB regions to be reported as overlapping. This has ripple effects that the object iterators stop working.
>
> I can get this test to pass, with and without compact object headers, by fixing the code in `ThreadLocalAllocBuffer::hard_end()`.
>
> This is a reproducer of the problem:
>
> make -C ../build/fastdebug test TEST=serviceability/sa/ClhsdbJstackWithConcurrentLock.java JTREG="JAVA_OPTIONS=-XX:TieredStopAtLevel=2 -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders"
>
>
> I've tested this by running all 'serviceability' tests in our tier1-9 testing.
This pull request has now been integrated.
Changeset: 3c5db12b
Author: Stefan Karlsson <stefank at openjdk.org>
URL: https://git.openjdk.org/jdk/commit/3c5db12bbe4d1155ab874c2862005621c6b8541d
Stats: 46 lines in 3 files changed: 23 ins; 13 del; 10 mod
8342857: SA: Heap iterator makes incorrect assumptions about TLAB layout
Reviewed-by: cjplummer, rkennke, lmesnik
-------------
PR: https://git.openjdk.org/jdk/pull/21662
From tschatzl at openjdk.org Fri Oct 25 15:28:12 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 25 Oct 2024 15:28:12 GMT
Subject: RFR: 8295269: G1: Improve slow startup due to predictor
initialization
In-Reply-To: <gRrXtX5RV4xjVrPvJUEcB-pevnOx5cqYVnvz-FN8mMU=.86127bf4-2013-4f99-adaf-f26566dc6349@github.com>
References: <qFFwxaSWYOikI5bPZKCMa1VIWTEXI6pwQPLmVf2sTWA=.497a0fa1-2553-4293-b4a0-7a8b7e02b6c8@github.com>
<gRrXtX5RV4xjVrPvJUEcB-pevnOx5cqYVnvz-FN8mMU=.86127bf4-2013-4f99-adaf-f26566dc6349@github.com>
Message-ID: <macnhOIPnvrz1xLgZxlSPHx5TddUVvHY0SARf5N4BeM=.bb86c1cd-c96f-4d2a-9f52-463abe73056f@github.com>
On Tue, 22 Oct 2024 09:46:55 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:
>> Hi all,
>>
>> please review this change that decreases the time it takes to adapt the predictors to actual values during startup.
>>
>> Currently predictors are initialized using compiled-in values. These values are extremely conservative as they have been based on some SPARC test runs on specjbb2000(?) or so, which means that it takes a while until the weights from these values are "gone" from the predictor sequences. (This can take 20-30 GCs).
>>
>> The change modifies prediction so that only the first prediction will use these pre-baked values, after that use live values.
>>
>> This makes G1 adapt much more quickly to the current application/environment.
>>
>> The drawback is that there may be differences (including regressions) in out-of-box performance because the initial garbage collections heavily impact heap expansion, potentially expanding the heap much less, resulting in less throughput. I.e. in the old policy we may do many more GCs during startup, causing higher cpu time ratio at that time, expanding more (than necessary).
>>
>> GC cpu usage with the new policy is still well within allowed range wrt to cpu time ratio.
>>
>> This also does not impact reasonable test setups.
>>
>> Testing: gha, internal performance benchmarks mostly show no change or improvements. There are some regressions that are "fixed" by setting min/max heap size indicating this is a heap sizing difference caused by differences due to faster startup.
>>
>> Hth,
>> Thomas
>
> Looks good.
Thanks @kstefanj @walulyai for your reviews.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/21518#issuecomment-2438114216
From tschatzl at openjdk.org Fri Oct 25 15:28:13 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 25 Oct 2024 15:28:13 GMT
Subject: Integrated: 8295269: G1: Improve slow startup due to predictor
initialization
In-Reply-To: <qFFwxaSWYOikI5bPZKCMa1VIWTEXI6pwQPLmVf2sTWA=.497a0fa1-2553-4293-b4a0-7a8b7e02b6c8@github.com>
References: <qFFwxaSWYOikI5bPZKCMa1VIWTEXI6pwQPLmVf2sTWA=.497a0fa1-2553-4293-b4a0-7a8b7e02b6c8@github.com>
Message-ID: <iGfq01cKLD6PZ0YVDTUS8XvyFWhePd4CKxOKAdksEiM=.cb06c59b-4be3-4647-889d-8805e1375806@github.com>
On Tue, 15 Oct 2024 09:53:05 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:
> Hi all,
>
> please review this change that decreases the time it takes to adapt the predictors to actual values during startup.
>
> Currently predictors are initialized using compiled-in values. These values are extremely conservative as they have been based on some SPARC test runs on specjbb2000(?) or so, which means that it takes a while until the weights from these values are "gone" from the predictor sequences. (This can take 20-30 GCs).
>
> The change modifies prediction so that only the first prediction will use these pre-baked values, after that use live values.
>
> This makes G1 adapt much more quickly to the current application/environment.
>
> The drawback is that there may be differences (including regressions) in out-of-box performance because the initial garbage collections heavily impact heap expansion, potentially expanding the heap much less, resulting in less throughput. I.e. in the old policy we may do many more GCs during startup, causing higher cpu time ratio at that time, expanding more (than necessary).
>
> GC cpu usage with the new policy is still well within allowed range wrt to cpu time ratio.
>
> This also does not impact reasonable test setups.
>
> Testing: gha, internal performance benchmarks mostly show no change or improvements. There are some regressions that are "fixed" by setting min/max heap size indicating this is a heap sizing difference caused by differences due to faster startup.
>
> Hth,
> Thomas
This pull request has now been integrated.
Changeset: c202a2f7
Author: Thomas Schatzl <tschatzl at openjdk.org>
URL: https://git.openjdk.org/jdk/commit/c202a2f7b231152136bd8960c55e43bc96cf1eb9
Stats: 7 lines in 2 files changed: 6 ins; 0 del; 1 mod
8295269: G1: Improve slow startup due to predictor initialization
Reviewed-by: iwalulya, sjohanss
-------------
PR: https://git.openjdk.org/jdk/pull/21518
From tschatzl at openjdk.org Fri Oct 25 18:14:33 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 25 Oct 2024 18:14:33 GMT
Subject: RFR: 8343086: [BACKOUT] JDK-8295269 G1: Improve slow startup due to
predictor initialization
Message-ID: <17eb4ifMbNhTkmlvLQ-4PJ7zELN0WxSVJMXwXmp55es=.355d5236-e40c-4a33-a821-51fd481f0861@github.com>
Hi all,
please review this revert of JDK-8295269 because it makes the runtime/cds/DeterministicCDSDump.java test fail due to differences in startup behavior.
This is a clean revert.
Testing: gha
Thanks,
Thomas
-------------
Commit messages:
- 8343086
Changes: https://git.openjdk.org/jdk/pull/21718/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21718&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8343086
Stats: 7 lines in 2 files changed: 0 ins; 6 del; 1 mod
Patch: https://git.openjdk.org/jdk/pull/21718.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/21718/head:pull/21718
PR: https://git.openjdk.org/jdk/pull/21718
From tschatzl at openjdk.org Fri Oct 25 19:20:15 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 25 Oct 2024 19:20:15 GMT
Subject: RFR: 8343086: [BACKOUT] JDK-8295269 G1: Improve slow startup due
to predictor initialization
In-Reply-To: <17eb4ifMbNhTkmlvLQ-4PJ7zELN0WxSVJMXwXmp55es=.355d5236-e40c-4a33-a821-51fd481f0861@github.com>
References: <17eb4ifMbNhTkmlvLQ-4PJ7zELN0WxSVJMXwXmp55es=.355d5236-e40c-4a33-a821-51fd481f0861@github.com>
Message-ID: <3f3DTD4nNxMRMYlXmJ5p19q-huoK0NAkplJodd3cvWw=.9825f332-1cf0-4246-b6e2-5263f5739433@github.com>
On Fri, 25 Oct 2024 18:09:41 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:
> Hi all,
>
> please review this revert of JDK-8295269 because it makes the runtime/cds/DeterministicCDSDump.java test fail due to differences in startup behavior.
>
> This is a clean revert.
>
> Testing: gha
>
> Thanks,
> Thomas
Since this adds lots of noise to the CI, I will go ahead and integrate now.
Thanks @sangheon for your review.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/21718#issuecomment-2438627479
From tschatzl at openjdk.org Fri Oct 25 19:20:15 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 25 Oct 2024 19:20:15 GMT
Subject: Integrated: 8343086: [BACKOUT] JDK-8295269 G1: Improve slow startup
due to predictor initialization
In-Reply-To: <17eb4ifMbNhTkmlvLQ-4PJ7zELN0WxSVJMXwXmp55es=.355d5236-e40c-4a33-a821-51fd481f0861@github.com>
References: <17eb4ifMbNhTkmlvLQ-4PJ7zELN0WxSVJMXwXmp55es=.355d5236-e40c-4a33-a821-51fd481f0861@github.com>
Message-ID: <rrkhCto5zYIzM6HMesoxDDzsFkbozDoYKeZSsJlyQaY=.d2a97378-fc71-4ca3-86b0-c35fc9143c60@github.com>
On Fri, 25 Oct 2024 18:09:41 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:
> Hi all,
>
> please review this revert of JDK-8295269 because it makes the runtime/cds/DeterministicCDSDump.java test fail due to differences in startup behavior.
>
> This is a clean revert.
>
> Testing: gha
>
> Thanks,
> Thomas
This pull request has now been integrated.
Changeset: f1cc890d
Author: Thomas Schatzl <tschatzl at openjdk.org>
URL: https://git.openjdk.org/jdk/commit/f1cc890ddfe2e472cf786856dc7d01645f61b054
Stats: 7 lines in 2 files changed: 0 ins; 6 del; 1 mod
8343086: [BACKOUT] JDK-8295269 G1: Improve slow startup due to predictor initialization
Reviewed-by: sangheki
-------------
PR: https://git.openjdk.org/jdk/pull/21718
From kdnilsen at openjdk.org Mon Oct 28 16:04:13 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 28 Oct 2024 16:04:13 GMT
Subject: RFR: 8342588: Shenandoah: Pull shared closures together in one
header [v2]
In-Reply-To: <14GqBlYL2XDV0k6WC1La5SmYLSAyYcf2FlVE4V75T2s=.bd5ddb3f-e520-44ef-85f9-22d498d5151e@github.com>
References: <jrhYA2e60xAZ6ytXp0Tojw0gL8Fs-ZJ5yitPn2Bmfp8=.3635c0be-86bb-41d8-a951-75b2bc43759d@github.com>
<14GqBlYL2XDV0k6WC1La5SmYLSAyYcf2FlVE4V75T2s=.bd5ddb3f-e520-44ef-85f9-22d498d5151e@github.com>
Message-ID: <qnctyF5Uhrz0R2CBL7sYR2vIz96WuXtrgpjlnjQ7n8Y=.1ce51750-64eb-4bf2-9ba2-deda532335d0@github.com>
On Fri, 18 Oct 2024 10:31:23 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:
>> Currently we have shenandoahClosures.hpp and shenandoahOopClosures.hpp, each of which have some closure inside. There is no reason to have this separation, and we should really just merge everything in one header. I also did a bit of mechanical renames. There should be no semantic change with this patch.
>>
>> Additional testing:
>> - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>
> Fix Zero builds
Thanks.
-------------
Marked as reviewed by kdnilsen (Author).
PR Review: https://git.openjdk.org/jdk/pull/21579#pullrequestreview-2399529979
From bpb at openjdk.org Mon Oct 28 22:09:07 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 28 Oct 2024 22:09:07 GMT
Subject: RFR: 8340728: Test vmTestbase/gc/memory/Nio/Nio.java is failing to
allocate all direct buffer memory [v3]
In-Reply-To: <H8qu4AgyLXV3JAEqy3ZpyOyFC3pIvFFg4Aiy0cTgrwg=.c463eaa1-71c2-4a07-be0e-15169e2a7568@github.com>
References: <H8qu4AgyLXV3JAEqy3ZpyOyFC3pIvFFg4Aiy0cTgrwg=.c463eaa1-71c2-4a07-be0e-15169e2a7568@github.com>
Message-ID: <-LvX-iXqsW7StJQ22bEcZjI6-_rrA7doVsvyo_GMmhI=.22850b66-edea-4196-9544-47c84069bbae@github.com>
> First attempt to allocate `VM.maxDirectMemory()` bytes of direct buffer memory, decreasing by 1024 bytes for each `OutOfMemoryError` until allocation succeeds.
Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
8340728: Fail if too much direct memory was allocated before this test is run
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/21623/files
- new: https://git.openjdk.org/jdk/pull/21623/files/b1e0c4d8..ee76ec14
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=21623&range=02
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=21623&range=01-02
Stats: 12 lines in 1 file changed: 9 ins; 0 del; 3 mod
Patch: https://git.openjdk.org/jdk/pull/21623.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/21623/head:pull/21623
PR: https://git.openjdk.org/jdk/pull/21623
From bpb at openjdk.org Mon Oct 28 22:09:14 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 28 Oct 2024 22:09:14 GMT
Subject: RFR: 8340728: Test vmTestbase/gc/memory/Nio/Nio.java is failing to
allocate all direct buffer memory [v2]
In-Reply-To: <TIoLLPQxwVFXhiIoLT_GP8qTbRVxe41mA06zlNblHHE=.e12a38db-48ec-46a0-b3bc-b5b75140799f@github.com>
References: <H8qu4AgyLXV3JAEqy3ZpyOyFC3pIvFFg4Aiy0cTgrwg=.c463eaa1-71c2-4a07-be0e-15169e2a7568@github.com>
<TIoLLPQxwVFXhiIoLT_GP8qTbRVxe41mA06zlNblHHE=.e12a38db-48ec-46a0-b3bc-b5b75140799f@github.com>
Message-ID: <cUECK6uvvDcBnn0R3cAPNx7hfbcQyly9gUsqx-dK9-s=.73d18ed9-b593-4b40-83d9-040304bca22e@github.com>
On Tue, 22 Oct 2024 19:15:51 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:
>> First attempt to allocate `VM.maxDirectMemory()` bytes of direct buffer memory, decreasing by 1024 bytes for each `OutOfMemoryError` until allocation succeeds.
>
> Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
>
> - Merge
> - 8340728: Test vmTestbase/gc/memory/Nio/Nio.java is failing to allocate all direct buffer memory
ee76ec1 changes the test to fail if the amount of memory able to be allocated is less than a threshold, in this case,`MAX_VM_SIZE - 8*1024`. This change passed 30 repeats on all test platforms.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/21623#issuecomment-2442739459
From stefank at openjdk.org Tue Oct 29 12:16:33 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 29 Oct 2024 12:16:33 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v53]
In-Reply-To: <LDg0GvC9lXkYPS90d9w8QfkTWlztUa5tlsgblGywCc4=.78ab2a17-2e28-4c27-b026-cd694ec02e21@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<LDg0GvC9lXkYPS90d9w8QfkTWlztUa5tlsgblGywCc4=.78ab2a17-2e28-4c27-b026-cd694ec02e21@github.com>
Message-ID: <IoELh3tHR8eEK8ZJfXgd1VBulpypTeLXAS7Nqkw_uJ4=.c2e38997-4be2-412d-a01d-5017d970a49f@github.com>
On Thu, 24 Oct 2024 21:04:51 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>>
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>>
>> Main changes:
>> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>> - Arrays will now store their length at offset 8.
>> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>
> Enable riscv in CompressedClassPointersEncodingScheme test
src/hotspot/share/oops/markWord.inline.hpp line 29:
> 27:
> 28: #include "oops/compressedOops.inline.hpp"
> 29: #include "oops/markWord.hpp"
I found this nit while looking around the code.
Suggestion:
#include "oops/markWord.hpp"
#include "oops/compressedOops.inline.hpp"
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1820682388
From amitkumar at openjdk.org Tue Oct 29 13:12:34 2024
From: amitkumar at openjdk.org (Amit Kumar)
Date: Tue, 29 Oct 2024 13:12:34 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
(Experimental) [v50]
In-Reply-To: <QirAyr5mX2p_jDtPINJsXF8Dv5p2Y_T5Dj2aTqEX-5I=.e1d5c692-81f8-4611-acde-eea1ad6313cd@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
<F8pi_T7-BZh5Junuk22zJ5d9PnBRUs94urSreD5oH1c=.63e9a189-5d9a-45ca-a70c-53cf677627d9@github.com>
<QirAyr5mX2p_jDtPINJsXF8Dv5p2Y_T5Dj2aTqEX-5I=.e1d5c692-81f8-4611-acde-eea1ad6313cd@github.com>
Message-ID: <BMnEQkyopmAU46K23jp9I-EuIjqrWgd3eNnQTgqTMVE=.055b1538-96bc-47e4-836b-f2f294b7686c@github.com>
On Tue, 22 Oct 2024 16:22:20 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
>> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
>>
>> - Update copyright
>> - Avoid assert/endless-loop in JFR code
>
> @egahlin / @mgronlun could you please review the JFR parts of this PR? One change is for getting the right prototype header, the other is for avoiding an endless loop/assert in a corner case.
@rkennke can you include this small update for s390x as well:
```diff
diff --git a/src/hotspot/cpu/s390/c1_MacroAssembler_s390.cpp b/src/hotspot/cpu/s390/c1_MacroAssembler_s390.cpp
index 0f7e5c9f457..476e3d5daa4 100644
--- a/src/hotspot/cpu/s390/c1_MacroAssembler_s390.cpp
+++ b/src/hotspot/cpu/s390/c1_MacroAssembler_s390.cpp
@@ -174,8 +174,11 @@ void C1_MacroAssembler::try_allocate(
void C1_MacroAssembler::initialize_header(Register obj, Register klass, Register len, Register Rzero, Register t1) {
assert_different_registers(obj, klass, len, t1, Rzero);
if (UseCompactObjectHeaders) {
- z_lg(t1, Address(klass, in_bytes(Klass::prototype_header_offset())));
- z_stg(t1, Address(obj, oopDesc::mark_offset_in_bytes()));
+ z_mvc(
+ Address(obj, oopDesc::mark_offset_in_bytes()), /* move to */
+ Address(klass, in_bytes(Klass::prototype_header_offset())), /* move from */
+ sizeof(markWord) /* how much to move */
+ );
} else {
load_const_optimized(t1, (intx)markWord::prototype().value());
z_stg(t1, Address(obj, oopDesc::mark_offset_in_bytes()));
diff --git a/src/hotspot/cpu/s390/c2_MacroAssembler_s390.cpp b/src/hotspot/cpu/s390/c2_MacroAssembler_s390.cpp
index 378d5e4cfe1..c5713161bf9 100644
--- a/src/hotspot/cpu/s390/c2_MacroAssembler_s390.cpp
+++ b/src/hotspot/cpu/s390/c2_MacroAssembler_s390.cpp
@@ -46,7 +46,7 @@ void C2_MacroAssembler::load_narrow_klass_compact_c2(Register dst, Address src)
// The incoming address is pointing into obj-start + klass_offset_in_bytes. We need to extract
// obj-start, so that we can load from the object's mark-word instead.
z_lg(dst, src.plus_disp(-oopDesc::klass_offset_in_bytes()));
- z_srlg(dst, dst, markWord::klass_shift); // TODO: could be z_sra
+ z_srlg(dst, dst, markWord::klass_shift);
}
//------------------------------------------------------
diff --git a/src/hotspot/cpu/s390/templateTable_s390.cpp b/src/hotspot/cpu/s390/templateTable_s390.cpp
index 3cb1aba810d..5b8f7a20478 100644
--- a/src/hotspot/cpu/s390/templateTable_s390.cpp
+++ b/src/hotspot/cpu/s390/templateTable_s390.cpp
@@ -3980,8 +3980,11 @@ void TemplateTable::_new() {
// Initialize object header only.
__ bind(initialize_header);
if (UseCompactObjectHeaders) {
- __ z_lg(tmp, Address(iklass, in_bytes(Klass::prototype_header_offset())));
- __ z_stg(tmp, Address(RallocatedObject, oopDesc::mark_offset_in_bytes()));
+ __ z_mvc(
+ Address(RallocatedObject, oopDesc::mark_offset_in_bytes()), // move to
+ Address(iklass, in_bytes(Klass::prototype_header_offset())), // move from
+ sizeof(markWord) // how much to move
+ );
} else {
__ store_const(Address(RallocatedObject, oopDesc::mark_offset_in_bytes()),
(long) markWord::prototype().value());
-------------
PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2444180131
From simonis at openjdk.org Tue Oct 29 17:02:08 2024
From: simonis at openjdk.org (Volker Simonis)
Date: Tue, 29 Oct 2024 17:02:08 GMT
Subject: RFR: 8342588: Shenandoah: Pull shared closures together in one
header [v2]
In-Reply-To: <14GqBlYL2XDV0k6WC1La5SmYLSAyYcf2FlVE4V75T2s=.bd5ddb3f-e520-44ef-85f9-22d498d5151e@github.com>
References: <jrhYA2e60xAZ6ytXp0Tojw0gL8Fs-ZJ5yitPn2Bmfp8=.3635c0be-86bb-41d8-a951-75b2bc43759d@github.com>
<14GqBlYL2XDV0k6WC1La5SmYLSAyYcf2FlVE4V75T2s=.bd5ddb3f-e520-44ef-85f9-22d498d5151e@github.com>
Message-ID: <EToLNCZ0bc7XaNioNtWktCprhkMV31ncylSbrzZO1cs=.93606986-b5bc-4692-91cf-0fed03632954@github.com>
On Fri, 18 Oct 2024 10:31:23 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:
>> Currently we have shenandoahClosures.hpp and shenandoahOopClosures.hpp, each of which have some closure inside. There is no reason to have this separation, and we should really just merge everything in one header. I also did a bit of mechanical renames. There should be no semantic change with this patch.
>>
>> Additional testing:
>> - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>
> Fix Zero builds
In general looks good. The only thing I'd recommend (if you haven't done that already anyway) would be to configure with `--disable-precompiled-headers` and see if the build still works (i.e. if all the inline functions are still all available in all the compilation units).
-------------
Marked as reviewed by simonis (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/21579#pullrequestreview-2402576093
From shade at openjdk.org Tue Oct 29 17:59:04 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 29 Oct 2024 17:59:04 GMT
Subject: RFR: 8342588: Shenandoah: Pull shared closures together in one
header [v2]
In-Reply-To: <EToLNCZ0bc7XaNioNtWktCprhkMV31ncylSbrzZO1cs=.93606986-b5bc-4692-91cf-0fed03632954@github.com>
References: <jrhYA2e60xAZ6ytXp0Tojw0gL8Fs-ZJ5yitPn2Bmfp8=.3635c0be-86bb-41d8-a951-75b2bc43759d@github.com>
<14GqBlYL2XDV0k6WC1La5SmYLSAyYcf2FlVE4V75T2s=.bd5ddb3f-e520-44ef-85f9-22d498d5151e@github.com>
<EToLNCZ0bc7XaNioNtWktCprhkMV31ncylSbrzZO1cs=.93606986-b5bc-4692-91cf-0fed03632954@github.com>
Message-ID: <6v0izwPV9oylWKVifIesMz0EK9Qo7DHkLo3_ahumLow=.98d9b2f5-aecb-45bc-98bc-5faf0503a1ca@github.com>
On Tue, 29 Oct 2024 16:59:03 GMT, Volker Simonis <simonis at openjdk.org> wrote:
> In general looks good. The only thing I'd recommend (if you haven't done that already anyway) would be to configure with `--disable-precompiled-headers` and see if the build still works (i.e. if all the inline functions are still all available in all the compilation units).
Yup, thanks! GHA also does it for us.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/21579#issuecomment-2444976068
From shade at openjdk.org Tue Oct 29 18:18:01 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 29 Oct 2024 18:18:01 GMT
Subject: RFR: 8342588: Shenandoah: Pull shared closures together in one
header [v3]
In-Reply-To: <jrhYA2e60xAZ6ytXp0Tojw0gL8Fs-ZJ5yitPn2Bmfp8=.3635c0be-86bb-41d8-a951-75b2bc43759d@github.com>
References: <jrhYA2e60xAZ6ytXp0Tojw0gL8Fs-ZJ5yitPn2Bmfp8=.3635c0be-86bb-41d8-a951-75b2bc43759d@github.com>
Message-ID: <vRij8RPQ9PbB2cQq5dIzlNNnmZdL-kH1ai_Ha7JjDuI=.85b9b9a1-eebf-41b1-b06d-de02e31bdb38@github.com>
> Currently we have shenandoahClosures.hpp and shenandoahOopClosures.hpp, each of which have some closure inside. There is no reason to have this separation, and we should really just merge everything in one header. I also did a bit of mechanical renames. There should be no semantic change with this patch.
>
> Additional testing:
> - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`
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:
- Merge branch 'master' into JDK-8342588-shenandoah-shared-closures
- Fix Zero builds
- Fix
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/21579/files
- new: https://git.openjdk.org/jdk/pull/21579/files/c9af382c..831372cf
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=21579&range=02
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=21579&range=01-02
Stats: 44445 lines in 716 files changed: 21494 ins; 20581 del; 2370 mod
Patch: https://git.openjdk.org/jdk/pull/21579.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/21579/head:pull/21579
PR: https://git.openjdk.org/jdk/pull/21579
From shade at openjdk.org Wed Oct 30 07:20:43 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 30 Oct 2024 07:20:43 GMT
Subject: RFR: 8342588: Shenandoah: Pull shared closures together in one
header [v4]
In-Reply-To: <jrhYA2e60xAZ6ytXp0Tojw0gL8Fs-ZJ5yitPn2Bmfp8=.3635c0be-86bb-41d8-a951-75b2bc43759d@github.com>
References: <jrhYA2e60xAZ6ytXp0Tojw0gL8Fs-ZJ5yitPn2Bmfp8=.3635c0be-86bb-41d8-a951-75b2bc43759d@github.com>
Message-ID: <721dXjSoRCUw4xhyWZOfDBKv-nlMyfLKx6AnTwdsVR4=.c7e0f527-0692-4f7a-99ac-d6b446b6866e@github.com>
> Currently we have shenandoahClosures.hpp and shenandoahOopClosures.hpp, each of which have some closure inside. There is no reason to have this separation, and we should really just merge everything in one header. I also did a bit of mechanical renames. There should be no semantic change with this patch.
>
> Additional testing:
> - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`
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:
- Merge branch 'master' into JDK-8342588-shenandoah-shared-closures
- Merge branch 'master' into JDK-8342588-shenandoah-shared-closures
- Fix Zero builds
- Fix
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/21579/files
- new: https://git.openjdk.org/jdk/pull/21579/files/831372cf..ad14c6d0
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=21579&range=03
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=21579&range=02-03
Stats: 798 lines in 31 files changed: 553 ins; 132 del; 113 mod
Patch: https://git.openjdk.org/jdk/pull/21579.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/21579/head:pull/21579
PR: https://git.openjdk.org/jdk/pull/21579
From shade at openjdk.org Wed Oct 30 10:27:16 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 30 Oct 2024 10:27:16 GMT
Subject: RFR: 8342588: Shenandoah: Pull shared closures together in one
header [v4]
In-Reply-To: <721dXjSoRCUw4xhyWZOfDBKv-nlMyfLKx6AnTwdsVR4=.c7e0f527-0692-4f7a-99ac-d6b446b6866e@github.com>
References: <jrhYA2e60xAZ6ytXp0Tojw0gL8Fs-ZJ5yitPn2Bmfp8=.3635c0be-86bb-41d8-a951-75b2bc43759d@github.com>
<721dXjSoRCUw4xhyWZOfDBKv-nlMyfLKx6AnTwdsVR4=.c7e0f527-0692-4f7a-99ac-d6b446b6866e@github.com>
Message-ID: <vNfvVIpY3VFAHDnaQ1pVoB87Wh5oFuFXRONHGVK2rR4=.0d93a8fb-9ff9-4974-9f3d-6450e4b7d837@github.com>
On Wed, 30 Oct 2024 07:20:43 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:
>> Currently we have shenandoahClosures.hpp and shenandoahOopClosures.hpp, each of which have some closure inside. There is no reason to have this separation, and we should really just merge everything in one header. I also did a bit of mechanical renames. There should be no semantic change with this patch.
>>
>> Additional testing:
>> - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`
>
> 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:
>
> - Merge branch 'master' into JDK-8342588-shenandoah-shared-closures
> - Merge branch 'master' into JDK-8342588-shenandoah-shared-closures
> - Fix Zero builds
> - Fix
Thanks all!
-------------
PR Comment: https://git.openjdk.org/jdk/pull/21579#issuecomment-2446471913
From shade at openjdk.org Wed Oct 30 10:27:17 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 30 Oct 2024 10:27:17 GMT
Subject: Integrated: 8342588: Shenandoah: Pull shared closures together in one
header
In-Reply-To: <jrhYA2e60xAZ6ytXp0Tojw0gL8Fs-ZJ5yitPn2Bmfp8=.3635c0be-86bb-41d8-a951-75b2bc43759d@github.com>
References: <jrhYA2e60xAZ6ytXp0Tojw0gL8Fs-ZJ5yitPn2Bmfp8=.3635c0be-86bb-41d8-a951-75b2bc43759d@github.com>
Message-ID: <uQ5ZMhvodkzaA8P-YQzjV10SxZregmUyhQ6RpJFoNR4=.8e7ce81c-7c5a-4502-b942-bd2b5666cda5@github.com>
On Fri, 18 Oct 2024 09:14:47 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:
> Currently we have shenandoahClosures.hpp and shenandoahOopClosures.hpp, each of which have some closure inside. There is no reason to have this separation, and we should really just merge everything in one header. I also did a bit of mechanical renames. There should be no semantic change with this patch.
>
> Additional testing:
> - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`
This pull request has now been integrated.
Changeset: 9003524c
Author: Aleksey Shipilev <shade at openjdk.org>
URL: https://git.openjdk.org/jdk/commit/9003524c8bbe5041b8d51deb6000b688a29027f8
Stats: 452 lines in 16 files changed: 192 ins; 234 del; 26 mod
8342588: Shenandoah: Pull shared closures together in one header
Reviewed-by: wkemper, kdnilsen, simonis
-------------
PR: https://git.openjdk.org/jdk/pull/21579
From zgu at openjdk.org Thu Oct 31 02:13:54 2024
From: zgu at openjdk.org (Zhengyu Gu)
Date: Thu, 31 Oct 2024 02:13:54 GMT
Subject: RFR: 8343333: Parallel: Cleanup comment referring Solaris in
MutableNUMASpace
Message-ID: <YDqu-YkWv8ynhWIU1t7MP4T0MNJbkI_cTXd72pKKEWU=.5134eb0a-8934-4739-bd66-e30e0da43de6@github.com>
A trivial cleanup that removes comment referring Solaris.
-------------
Commit messages:
- 8343333: Parallel: Cleanup comment referring Solaris in MutableNUMASpace
Changes: https://git.openjdk.org/jdk/pull/21796/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21796&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8343333
Stats: 7 lines in 1 file changed: 0 ins; 2 del; 5 mod
Patch: https://git.openjdk.org/jdk/pull/21796.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/21796/head:pull/21796
PR: https://git.openjdk.org/jdk/pull/21796
From tschatzl at openjdk.org Thu Oct 31 08:10:27 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 31 Oct 2024 08:10:27 GMT
Subject: RFR: 8343333: Parallel: Cleanup comment referring Solaris in
MutableNUMASpace
In-Reply-To: <YDqu-YkWv8ynhWIU1t7MP4T0MNJbkI_cTXd72pKKEWU=.5134eb0a-8934-4739-bd66-e30e0da43de6@github.com>
References: <YDqu-YkWv8ynhWIU1t7MP4T0MNJbkI_cTXd72pKKEWU=.5134eb0a-8934-4739-bd66-e30e0da43de6@github.com>
Message-ID: <ewdFPf6YfiFaepG5SiCuAqbpE66YU5TaN-ysNLG_yQY=.5b32caa5-7c5c-4e45-9f57-66619af40263@github.com>
On Thu, 31 Oct 2024 02:07:29 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:
> A trivial cleanup that removes comment referring Solaris.
Lgtm and trivial.
(Note that the term "locality group" used in the whole comment is Solaris specific afaik too, but that can be fixed at some later point).
-------------
Marked as reviewed by tschatzl (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/21796#pullrequestreview-2407310005
From lmesnik at openjdk.org Thu Oct 31 16:13:53 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 31 Oct 2024 16:13:53 GMT
Subject: RFR: 8343173: Remove ZGC-specific non-JVMCI test groups [v2]
In-Reply-To: <Pi4NnowP97OycsrQNhqYKrx-ponv9Fcn6-l7PZGbAzk=.25064037-6535-400a-a063-c3d602be594f@github.com>
References: <Pi4NnowP97OycsrQNhqYKrx-ponv9Fcn6-l7PZGbAzk=.25064037-6535-400a-a063-c3d602be594f@github.com>
Message-ID: <IzozsqPYFk9XAot7mVxUN9s2qtm0gDCWovHBrTeSm-8=.7d1c082c-1d86-4cd5-8fe9-7a3ac8d0fa89@github.com>
> The JVMCI should be supported by all GCs and specific
> hotspot_compiler_all_gcs
> group is not needed anymore.
>
> There are few failures of JVMCI tests with ZGC happened, the bug
> https://bugs.openjdk.org/browse/JDK-8343233
> is filed and corresponding tests are problemlisted.
Leonid Mesnik has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
- typo fixed
- Merge branch 'master' of https://github.com/openjdk/jdk into 8343173
- 8343173: Remove ZGC-specific non-JVMCI test groups
-------------
Changes: https://git.openjdk.org/jdk/pull/21774/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21774&range=01
Stats: 12 lines in 2 files changed: 8 ins; 4 del; 0 mod
Patch: https://git.openjdk.org/jdk/pull/21774.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/21774/head:pull/21774
PR: https://git.openjdk.org/jdk/pull/21774