From rkennke at openjdk.org Tue Jan 3 17:11:55 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 3 Jan 2023 17:11:55 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8299478: [Lilliput/JDK17] Fix Windows
build
Message-ID: <-Es4fWxtQq40vS15d5ANOCaJz5Q-uNLRfxdPOegBvuA=.29b9f9fd-f19e-45e2-a70a-4de1b6ed5440@github.com>
These changes should fix the Windows (and MacOS) build of Lilliput/JDK17. I'm going blindly, here, only guided by GHA.
Ok?
Thanks,
Roman
-------------
Commit messages:
- Include objectMonitor.inline.hpp in thread.cpp
- More fixes
- Revert wrong attempt
- Second attempt
- Fix Windows build
Changes: https://git.openjdk.org/lilliput-jdk17u/pull/1/files
Webrev: https://webrevs.openjdk.org/?repo=lilliput-jdk17u&pr=1&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8299478
Stats: 4 lines in 4 files changed: 0 ins; 0 del; 4 mod
Patch: https://git.openjdk.org/lilliput-jdk17u/pull/1.diff
Fetch: git fetch https://git.openjdk.org/lilliput-jdk17u pull/1/head:pull/1
PR: https://git.openjdk.org/lilliput-jdk17u/pull/1
From shade at openjdk.org Tue Jan 3 17:20:26 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 3 Jan 2023 17:20:26 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8299478: [Lilliput/JDK17] Fix
Windows build
In-Reply-To: <-Es4fWxtQq40vS15d5ANOCaJz5Q-uNLRfxdPOegBvuA=.29b9f9fd-f19e-45e2-a70a-4de1b6ed5440@github.com>
References: <-Es4fWxtQq40vS15d5ANOCaJz5Q-uNLRfxdPOegBvuA=.29b9f9fd-f19e-45e2-a70a-4de1b6ed5440@github.com>
Message-ID: <JVUqu8maCgDtxFoAKBfJDh0d2Z5FtyvuwfLz4N4U7qI=.6819864d-fa7a-482a-948a-3a02073660c1@github.com>
On Mon, 2 Jan 2023 19:21:24 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
> These changes should fix the Windows (and MacOS) build of Lilliput/JDK17. I'm going blindly, here, only guided by GHA.
>
> Ok?
>
> Thanks,
> Roman
Can you explain a bit why this should be `int`, and not `size_t`, like the rest of upstream `object_size()` methods?
src/hotspot/share/oops/objArrayOop.hpp line 80:
> 78: size_t osz = align_object_size(size_words);
> 79: assert(osz < max_jint, "no overflow");
> 80: return static_cast<int>(osz);
`checked_cast`?
-------------
PR: https://git.openjdk.org/lilliput-jdk17u/pull/1
From shade at redhat.com Tue Jan 3 17:38:29 2023
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 3 Jan 2023 18:38:29 +0100
Subject: JDK17 backport repo of Lilliput
In-Reply-To: <59fc9186-e49f-1439-c1ee-c647387a2f2d@amazon.de>
References: <59fc9186-e49f-1439-c1ee-c647387a2f2d@amazon.de>
Message-ID: <91ffa897-11ef-908c-b787-5b17e7d5290c@redhat.com>
On 12/14/22 16:49, Kennke, Roman wrote:
> I've created and seeded a repository for tracking a backport of Lilliput
> to JDK17:
>
> https://github.com/openjdk/lilliput-jdk17u
>
> It is forked from openjdk/jdk17u and the intention is to follow this
> upstream repo at least for the JDK17u GA releases.
>
> The intention of it is to make testing easier for users who are on JDK17
> but cannot easily run JDK20+.
The nightly builds for that repo are here:
https://builds.shipilev.net/openjdk-jdk17-lilliput/
This should simplify testing even more.
--
Thanks,
-Aleksey
From rkennke at openjdk.org Tue Jan 3 17:53:49 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 3 Jan 2023 17:53:49 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8299478: [Lilliput/JDK17] Fix
Windows build [v2]
In-Reply-To: <-Es4fWxtQq40vS15d5ANOCaJz5Q-uNLRfxdPOegBvuA=.29b9f9fd-f19e-45e2-a70a-4de1b6ed5440@github.com>
References: <-Es4fWxtQq40vS15d5ANOCaJz5Q-uNLRfxdPOegBvuA=.29b9f9fd-f19e-45e2-a70a-4de1b6ed5440@github.com>
Message-ID: <pvZ-wSdUb3J0s-VYOe6ejXTQWkDMmXn9aQna6kuuZm0=.6e0ebf01-8518-4e05-a7fc-1a4eee10ccad@github.com>
> These changes should fix the Windows (and MacOS) build of Lilliput/JDK17. I'm going blindly, here, only guided by GHA.
>
> Ok?
>
> Thanks,
> Roman
Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
Use checked_cast instead of static_cast
-------------
Changes:
- all: https://git.openjdk.org/lilliput-jdk17u/pull/1/files
- new: https://git.openjdk.org/lilliput-jdk17u/pull/1/files/67c7cd75..3bd83408
Webrevs:
- full: https://webrevs.openjdk.org/?repo=lilliput-jdk17u&pr=1&range=01
- incr: https://webrevs.openjdk.org/?repo=lilliput-jdk17u&pr=1&range=00-01
Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
Patch: https://git.openjdk.org/lilliput-jdk17u/pull/1.diff
Fetch: git fetch https://git.openjdk.org/lilliput-jdk17u pull/1/head:pull/1
PR: https://git.openjdk.org/lilliput-jdk17u/pull/1
From shade at openjdk.org Tue Jan 3 17:53:50 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 3 Jan 2023 17:53:50 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8299478: [Lilliput/JDK17] Fix
Windows build [v2]
In-Reply-To: <pvZ-wSdUb3J0s-VYOe6ejXTQWkDMmXn9aQna6kuuZm0=.6e0ebf01-8518-4e05-a7fc-1a4eee10ccad@github.com>
References: <-Es4fWxtQq40vS15d5ANOCaJz5Q-uNLRfxdPOegBvuA=.29b9f9fd-f19e-45e2-a70a-4de1b6ed5440@github.com>
<pvZ-wSdUb3J0s-VYOe6ejXTQWkDMmXn9aQna6kuuZm0=.6e0ebf01-8518-4e05-a7fc-1a4eee10ccad@github.com>
Message-ID: <Ghcv5CsgvsveKUY58R4INYFpOsV4L02OrnZ0T--BvPg=.e94ef314-694f-4b1b-85e8-b255aee94a30@github.com>
On Tue, 3 Jan 2023 17:49:07 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
>> These changes should fix the Windows (and MacOS) build of Lilliput/JDK17. I'm going blindly, here, only guided by GHA.
>>
>> Ok?
>>
>> Thanks,
>> Roman
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>
> Use checked_cast instead of static_cast
All right, let's see what it breaks.
-------------
Marked as reviewed by shade (Reviewer).
PR: https://git.openjdk.org/lilliput-jdk17u/pull/1
From rkennke at openjdk.org Tue Jan 3 17:53:52 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 3 Jan 2023 17:53:52 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8299478: [Lilliput/JDK17] Fix
Windows build [v2]
In-Reply-To: <JVUqu8maCgDtxFoAKBfJDh0d2Z5FtyvuwfLz4N4U7qI=.6819864d-fa7a-482a-948a-3a02073660c1@github.com>
References: <-Es4fWxtQq40vS15d5ANOCaJz5Q-uNLRfxdPOegBvuA=.29b9f9fd-f19e-45e2-a70a-4de1b6ed5440@github.com>
<JVUqu8maCgDtxFoAKBfJDh0d2Z5FtyvuwfLz4N4U7qI=.6819864d-fa7a-482a-948a-3a02073660c1@github.com>
Message-ID: <qDivsnJbHCWRgzamsz95Ie77baj1z6eAYuycf3pCjaY=.5a486216-1521-4ce5-9623-108f8695dab8@github.com>
On Tue, 3 Jan 2023 17:17:24 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:
> Can you explain a bit why this should be `int`, and not `size_t`, like the rest of upstream `object_size()` methods?
It should be size_t, and it is size_t in tip, but it is int in jdk17, and I did not want to go down the rabbit hole of changing this and all the dependencies, and thereby risk to introduce funny bugs. The code is made specifically to not overflow int, and it even checks that. I believe we should be good.
-------------
PR: https://git.openjdk.org/lilliput-jdk17u/pull/1
From rkennke at openjdk.org Tue Jan 3 18:01:27 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 3 Jan 2023 18:01:27 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8299478: [Lilliput/JDK17] Fix
Windows build [v2]
In-Reply-To: <pvZ-wSdUb3J0s-VYOe6ejXTQWkDMmXn9aQna6kuuZm0=.6e0ebf01-8518-4e05-a7fc-1a4eee10ccad@github.com>
References: <-Es4fWxtQq40vS15d5ANOCaJz5Q-uNLRfxdPOegBvuA=.29b9f9fd-f19e-45e2-a70a-4de1b6ed5440@github.com>
<pvZ-wSdUb3J0s-VYOe6ejXTQWkDMmXn9aQna6kuuZm0=.6e0ebf01-8518-4e05-a7fc-1a4eee10ccad@github.com>
Message-ID: <bWUCSozF-zkaUlTGCbsDDFzmYiUWQOBJjcLe3S8qXAE=.bff564c3-dfbe-4047-8e37-01803727f555@github.com>
On Tue, 3 Jan 2023 17:53:49 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
>> These changes should fix the Windows (and MacOS) build of Lilliput/JDK17. I'm going blindly, here, only guided by GHA.
>>
>> Ok?
>>
>> Thanks,
>> Roman
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>
> Use checked_cast instead of static_cast
Thanks!
-------------
PR: https://git.openjdk.org/lilliput-jdk17u/pull/1
From rkennke at openjdk.org Tue Jan 3 18:01:28 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 3 Jan 2023 18:01:28 GMT
Subject: [lilliput-jdk17u:lilliput] Integrated: 8299478: [Lilliput/JDK17] Fix
Windows build
In-Reply-To: <-Es4fWxtQq40vS15d5ANOCaJz5Q-uNLRfxdPOegBvuA=.29b9f9fd-f19e-45e2-a70a-4de1b6ed5440@github.com>
References: <-Es4fWxtQq40vS15d5ANOCaJz5Q-uNLRfxdPOegBvuA=.29b9f9fd-f19e-45e2-a70a-4de1b6ed5440@github.com>
Message-ID: <cAwD_nnA6bt1ZXIRJ4LjA0M82-UhXJ_7eIyPf1LOBNg=.6232d056-e98a-41a8-824d-8f705009ed04@github.com>
On Mon, 2 Jan 2023 19:21:24 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
> These changes should fix the Windows (and MacOS) build of Lilliput/JDK17. I'm going blindly, here, only guided by GHA.
>
> Ok?
>
> Thanks,
> Roman
This pull request has now been integrated.
Changeset: a19d9a40
Author: Roman Kennke <rkennke at openjdk.org>
URL: https://git.openjdk.org/lilliput-jdk17u/commit/a19d9a4096e29b8479ea6421f0517965a7e19c9c
Stats: 4 lines in 4 files changed: 0 ins; 0 del; 4 mod
8299478: [Lilliput/JDK17] Fix Windows build
Reviewed-by: shade
-------------
PR: https://git.openjdk.org/lilliput-jdk17u/pull/1
From rkennke at openjdk.org Wed Jan 4 13:56:15 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 4 Jan 2023 13:56:15 GMT
Subject: [master] RFR: 8299594: [Lilliput] Revert
"Replace stack-locking with fast-locking"
Message-ID: <tirNGzF7ePOqR383tGkHlTiY1nlq9rx2pSxCvsMzhX4=.b5070def-839f-44b1-a049-3e973ad43e79@github.com>
I'd like to revert the original fast-locking change and later replace it with the reworked fast-locking (https://github.com/openjdk/jdk/pull/10590). This new version can be turned on/off by a runtime flag, and is also more efficient, because it doesn't need to check the lock stack size on every monitorenter.
The revert is clean.
Testing:
- [x] local build
-------------
Commit messages:
- 8299594: [Lilliput] Revert "Replace stack-locking with fast-locking"
Changes: https://git.openjdk.org/lilliput/pull/60/files
Webrev: https://webrevs.openjdk.org/?repo=lilliput&pr=60&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8299594
Stats: 4160 lines in 140 files changed: 2802 ins; 696 del; 662 mod
Patch: https://git.openjdk.org/lilliput/pull/60.diff
Fetch: git fetch https://git.openjdk.org/lilliput pull/60/head:pull/60
PR: https://git.openjdk.org/lilliput/pull/60
From shade at openjdk.org Wed Jan 4 16:06:21 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 4 Jan 2023 16:06:21 GMT
Subject: [master] RFR: 8299594: [Lilliput] Revert
"Replace stack-locking with fast-locking"
In-Reply-To: <tirNGzF7ePOqR383tGkHlTiY1nlq9rx2pSxCvsMzhX4=.b5070def-839f-44b1-a049-3e973ad43e79@github.com>
References: <tirNGzF7ePOqR383tGkHlTiY1nlq9rx2pSxCvsMzhX4=.b5070def-839f-44b1-a049-3e973ad43e79@github.com>
Message-ID: <Xw461UvsCKapYod7_1UYcMI7bJkUOyAi4xcLG0cjQIU=.436faf0e-3c84-4865-8135-f7c6f8efe3d8@github.com>
On Wed, 4 Jan 2023 13:49:21 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
> I'd like to revert the original fast-locking change and later replace it with the reworked fast-locking (https://github.com/openjdk/jdk/pull/10590). This new version can be turned on/off by a runtime flag, and is also more efficient, because it doesn't need to check the lock stack size on every monitorenter.
>
> The revert is clean.
> Testing:
> - [x] local build
Looks fine. I wonder if that is one of the issues I am seeing on x86_32.
-------------
Marked as reviewed by shade (Committer).
PR: https://git.openjdk.org/lilliput/pull/60
From rkennke at openjdk.org Wed Jan 4 18:00:30 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 4 Jan 2023 18:00:30 GMT
Subject: [master] RFR: 8299594: [Lilliput] Revert
"Replace stack-locking with fast-locking"
In-Reply-To: <Xw461UvsCKapYod7_1UYcMI7bJkUOyAi4xcLG0cjQIU=.436faf0e-3c84-4865-8135-f7c6f8efe3d8@github.com>
References: <tirNGzF7ePOqR383tGkHlTiY1nlq9rx2pSxCvsMzhX4=.b5070def-839f-44b1-a049-3e973ad43e79@github.com>
<Xw461UvsCKapYod7_1UYcMI7bJkUOyAi4xcLG0cjQIU=.436faf0e-3c84-4865-8135-f7c6f8efe3d8@github.com>
Message-ID: <o-6S_qmqzs5JjMZQePzXVZLdXnmE3vYwvLn7roiPN4Q=.ea559dee-f4ae-407b-8edb-2cf90fd59314@github.com>
On Wed, 4 Jan 2023 16:03:35 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:
> Looks fine. I wonder if that is one of the issues I am seeing on x86_32.
If you mean the thing in Lilliput/jdk17, then no. In 17, I already pushed the new stack-locking impl. I'm only now bringing Lilliput-tip to the same state.
Thanks!
-------------
PR: https://git.openjdk.org/lilliput/pull/60
From rkennke at openjdk.org Wed Jan 4 18:00:32 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 4 Jan 2023 18:00:32 GMT
Subject: [master] Integrated: 8299594: [Lilliput] Revert
"Replace stack-locking with fast-locking"
In-Reply-To: <tirNGzF7ePOqR383tGkHlTiY1nlq9rx2pSxCvsMzhX4=.b5070def-839f-44b1-a049-3e973ad43e79@github.com>
References: <tirNGzF7ePOqR383tGkHlTiY1nlq9rx2pSxCvsMzhX4=.b5070def-839f-44b1-a049-3e973ad43e79@github.com>
Message-ID: <QNdyCRY-xwj2YwVFb0pJifB45WeOz83Syv2qIVoh2aQ=.063233b6-2d76-479f-900f-96db31af94fa@github.com>
On Wed, 4 Jan 2023 13:49:21 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
> I'd like to revert the original fast-locking change and later replace it with the reworked fast-locking (https://github.com/openjdk/jdk/pull/10590). This new version can be turned on/off by a runtime flag, and is also more efficient, because it doesn't need to check the lock stack size on every monitorenter.
>
> The revert is clean.
> Testing:
> - [x] local build
This pull request has now been integrated.
Changeset: 16e2a110
Author: Roman Kennke <rkennke at openjdk.org>
URL: https://git.openjdk.org/lilliput/commit/16e2a110308ce62e009a95a9b9a0e38fc7f9492a
Stats: 4160 lines in 140 files changed: 2802 ins; 696 del; 662 mod
8299594: [Lilliput] Revert "Replace stack-locking with fast-locking"
Reviewed-by: shade
-------------
PR: https://git.openjdk.org/lilliput/pull/60
From shade at redhat.com Thu Jan 5 10:15:04 2023
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 5 Jan 2023 11:15:04 +0100
Subject: JDK17 backport repo of Lilliput
In-Reply-To: <91ffa897-11ef-908c-b787-5b17e7d5290c@redhat.com>
References: <59fc9186-e49f-1439-c1ee-c647387a2f2d@amazon.de>
<91ffa897-11ef-908c-b787-5b17e7d5290c@redhat.com>
Message-ID: <46cca648-5d25-9c25-ddc4-352ea7061d91@redhat.com>
On 1/3/23 18:38, Aleksey Shipilev wrote:
> On 12/14/22 16:49, Kennke, Roman wrote:
>> I've created and seeded a repository for tracking a backport of Lilliput
>> to JDK17:
>>
>> https://github.com/openjdk/lilliput-jdk17u
>>
>> It is forked from openjdk/jdk17u and the intention is to follow this
>> upstream repo at least for the JDK17u GA releases.
>>
>> The intention of it is to make testing easier for users who are on JDK17
>> but cannot easily run JDK20+.
>
> The nightly builds for that repo are here:
> https://builds.shipilev.net/openjdk-jdk17-lilliput/
The automatically generated webrev is here:
https://builds.shipilev.net/patch-openjdk-lilliput-jdk17/
--
Thanks,
-Aleksey
From rkennke at openjdk.org Tue Jan 10 12:44:25 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 10 Jan 2023 12:44:25 GMT
Subject: [master] RFR: Merge jdk:jdk-21+4
Message-ID: <4DhnlufcJrDK6ArHkHr9bIXS4kUhU6tXUosyXzXwAgE=.7445b0a1-0f5d-438d-bcc7-d8ac5308847a@github.com>
Let's merge latest jdk21 tag.
-------------
Commit messages:
- Merge tag 'jdk-21+4' into merge-jdk21+4
- 8299439: java/text/Format/NumberFormat/CurrencyFormat.java fails for hr_HR
- 8299563: Fix typos
- 8219810: javac throws NullPointerException
- 8200610: Compiling fails with java.nio.file.ReadOnlyFileSystemException
- Merge
- 8299476: PPC64 Zero build fails after JDK-8286302
- 8293824: gc/whitebox/TestConcMarkCycleWB.java failed "RuntimeException: assertTrue: expected true, was false"
- 8299483: ProblemList java/text/Format/NumberFormat/CurrencyFormat.java
- 8298324: Unable to run shell test with make
- ... and 1276 more: https://git.openjdk.org/lilliput/compare/16e2a110...515ffce7
The webrevs contain the adjustments done while merging with regards to each parent branch:
- master: https://webrevs.openjdk.org/?repo=lilliput&pr=61&range=00.0
- jdk:jdk-21+4: https://webrevs.openjdk.org/?repo=lilliput&pr=61&range=00.1
Changes: https://git.openjdk.org/lilliput/pull/61/files
Stats: 415414 lines in 5864 files changed: 211059 ins; 138427 del; 65928 mod
Patch: https://git.openjdk.org/lilliput/pull/61.diff
Fetch: git fetch https://git.openjdk.org/lilliput pull/61/head:pull/61
PR: https://git.openjdk.org/lilliput/pull/61
From shade at openjdk.org Tue Jan 10 13:11:37 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 10 Jan 2023 13:11:37 GMT
Subject: [master] RFR: Merge jdk:jdk-21+4
In-Reply-To: <4DhnlufcJrDK6ArHkHr9bIXS4kUhU6tXUosyXzXwAgE=.7445b0a1-0f5d-438d-bcc7-d8ac5308847a@github.com>
References: <4DhnlufcJrDK6ArHkHr9bIXS4kUhU6tXUosyXzXwAgE=.7445b0a1-0f5d-438d-bcc7-d8ac5308847a@github.com>
Message-ID: <VqNTUS98yiKI60haTOA8sACfG3hHUqVUIMyaPOFJgMQ=.419a2343-658a-477f-acab-743b50f3a9a3@github.com>
On Mon, 9 Jan 2023 19:44:13 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
> Let's merge latest jdk21 tag.
Marked as reviewed by shade (Committer).
-------------
PR: https://git.openjdk.org/lilliput/pull/61
From rkennke at openjdk.org Tue Jan 10 19:08:20 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 10 Jan 2023 19:08:20 GMT
Subject: [master] RFR: Merge jdk:jdk-21+4 [v2]
In-Reply-To: <4DhnlufcJrDK6ArHkHr9bIXS4kUhU6tXUosyXzXwAgE=.7445b0a1-0f5d-438d-bcc7-d8ac5308847a@github.com>
References: <4DhnlufcJrDK6ArHkHr9bIXS4kUhU6tXUosyXzXwAgE=.7445b0a1-0f5d-438d-bcc7-d8ac5308847a@github.com>
Message-ID: <jiRq6-2ginyjMRHcLwm55wJlK-fDWrhPl252xicNZe8=.3ba7838c-6234-4b16-a632-5e71634a117b@github.com>
> Let's merge latest jdk21 tag.
Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 69 commits:
- Merge tag 'jdk-21+4' into merge-jdk21+4
Added tag jdk-21+4 for changeset 3b374c01
- 8299594: [Lilliput] Revert "Replace stack-locking with fast-locking"
Reviewed-by: shade
- Replace stack-locking with fast-locking
Reviewed-by: shade, stuefe
- Merge jdk
Reviewed-by: stuefe
- Merge jdk
Reviewed-by: stuefe
- Implement Shenandoah support
Reviewed-by: zgu
- Merge tag 'jdk-19+20' into merge-jdk-19+20
Added tag jdk-19+20 for changeset 16a8ebbf
- Relax array elements alignment
Reviewed-by: stuefe
- Merge remote-tracking branch 'jdk-upstream/master'
- Merge remote-tracking branch 'jdk-upstream/master'
- ... and 59 more: https://git.openjdk.org/lilliput/compare/3b374c01...515ffce7
-------------
Changes: https://git.openjdk.org/lilliput/pull/61/files
Webrev: https://webrevs.openjdk.org/?repo=lilliput&pr=61&range=01
Stats: 6154 lines in 208 files changed: 4829 ins; 774 del; 551 mod
Patch: https://git.openjdk.org/lilliput/pull/61.diff
Fetch: git fetch https://git.openjdk.org/lilliput pull/61/head:pull/61
PR: https://git.openjdk.org/lilliput/pull/61
From rkennke at openjdk.org Tue Jan 10 19:08:23 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 10 Jan 2023 19:08:23 GMT
Subject: [master] Integrated: Merge jdk:jdk-21+4
In-Reply-To: <4DhnlufcJrDK6ArHkHr9bIXS4kUhU6tXUosyXzXwAgE=.7445b0a1-0f5d-438d-bcc7-d8ac5308847a@github.com>
References: <4DhnlufcJrDK6ArHkHr9bIXS4kUhU6tXUosyXzXwAgE=.7445b0a1-0f5d-438d-bcc7-d8ac5308847a@github.com>
Message-ID: <tlapMV35avxbjZJscHBzRtP8UgxHQHpkKvXsEEPXcn4=.faa663df-8d65-4b4d-839e-12a1fbebecdf@github.com>
On Mon, 9 Jan 2023 19:44:13 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
> Let's merge latest jdk21 tag.
This pull request has now been integrated.
Changeset: cbacaf02
Author: Roman Kennke <rkennke at openjdk.org>
URL: https://git.openjdk.org/lilliput/commit/cbacaf023d7d0940a38a6f5ba10b88b0e81cee72
Stats: 415414 lines in 5864 files changed: 211059 ins; 138427 del; 65928 mod
Merge jdk:jdk-21+4
Reviewed-by: shade
-------------
PR: https://git.openjdk.org/lilliput/pull/61
From evan.saulpaugh at gmail.com Wed Jan 11 23:26:01 2023
From: evan.saulpaugh at gmail.com (Evan Saulpaugh)
Date: Wed, 11 Jan 2023 17:26:01 -0600
Subject: bad Repository link on wiki
Message-ID: <CACsH+Ykn_U3GJNrhf7y1dXyF_7bOprO_Sp=bo454TQSWDOX1wA@mail.gmail.com>
I noticed that the link to the github page at the bottom of the wiki
page for Project Lilliput is misspelled and so does not work.
"Repository" links to https://github.com/openjdk/liliput instead of
https://github.com/openjdk/lilliput
See https://wiki.openjdk.org/display/lilliput
-Evan Saulpaugh
From rkennke at openjdk.org Fri Jan 13 08:03:44 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 13 Jan 2023 08:03:44 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8299552: [Lilliput/JDK17] Fix 32bit
builds
Message-ID: <hR9FDNhcxhsCKaAYT0HdmCcfwXlc6z5qkPXjvzgYVgM=.27e85d5f-4178-4acd-b538-4a5ba920b774@github.com>
32bit builds in Lilliput/JDK17 are broken:
* For target hotspot_variant-server_libjvm_objs_space.o:
-------------
Commit messages:
- Revert unnecessary change
- Use passed-in thread register in fast_lock/x86_32 instead of fetching the thread again
- Move owning_thread_from_monitor() back into Threads, and add check for thread being an active JavaThread
- Add fast_unlock impl in C2 path of x86_32
- Allow NULL monitor owners
- Fix race when fetching owning thread outside of STW pause
- SA fixes for 32 bits
- More fixes
- Exclude C2 parts when C2 is not built
- Exclude C2LoadNKlassStub from 32bit builds
- ... and 4 more: https://git.openjdk.org/lilliput-jdk17u/compare/a19d9a40...a0eab51d
Changes: https://git.openjdk.org/lilliput-jdk17u/pull/2/files
Webrev: https://webrevs.openjdk.org/?repo=lilliput-jdk17u&pr=2&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8299552
Stats: 84 lines in 13 files changed: 48 ins; 14 del; 22 mod
Patch: https://git.openjdk.org/lilliput-jdk17u/pull/2.diff
Fetch: git fetch https://git.openjdk.org/lilliput-jdk17u pull/2/head:pull/2
PR: https://git.openjdk.org/lilliput-jdk17u/pull/2
From shade at openjdk.org Fri Jan 13 08:03:45 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 13 Jan 2023 08:03:45 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8299552: [Lilliput/JDK17] Fix
32bit builds
In-Reply-To: <hR9FDNhcxhsCKaAYT0HdmCcfwXlc6z5qkPXjvzgYVgM=.27e85d5f-4178-4acd-b538-4a5ba920b774@github.com>
References: <hR9FDNhcxhsCKaAYT0HdmCcfwXlc6z5qkPXjvzgYVgM=.27e85d5f-4178-4acd-b538-4a5ba920b774@github.com>
Message-ID: <_jHRdwUiu3luAQYlYOt8NoGpOJ3XjLNCxrzlT1IEpNI=.5d1fec5a-0bfa-4704-be56-ac07bd62e476@github.com>
On Tue, 3 Jan 2023 18:27:22 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
> 32bit builds in Lilliput/JDK17 are broken:
>
> * For target hotspot_variant-server_libjvm_objs_space.o:
There must be a bug in fast-locking somewhere, because x86_32 `make bootcycle-images` asserts hard in `SharedRuntime::monitor_enter_helper`. I suggest we fix those separately. These are the additions I had to make x86_32 builds pass:
diff --git a/src/hotspot/share/gc/g1/heapRegion.inline.hpp b/src/hotspot/share/gc/g1/heapRegion.inline.hpp
index a4b38432ebb..8c40e0337db 100644
--- a/src/hotspot/share/gc/g1/heapRegion.inline.hpp
+++ b/src/hotspot/share/gc/g1/heapRegion.inline.hpp
@@ -184,9 +184,11 @@ inline size_t HeapRegion::block_size(const HeapWord *addr) const {
if (block_is_obj(addr)) {
oop obj = cast_to_oop(addr);
+#ifdef _LP64
if (obj->is_forwarded() && CompressedKlassPointers::is_null(obj->mark().narrow_klass())) {
obj = obj->forwardee();
}
+#endif
return obj->size();
}
diff --git a/src/hotspot/share/runtime/arguments.cpp b/src/hotspot/share/runtime/arguments.cpp
index af4d02b3825..4e249e65ae9 100644
--- a/src/hotspot/share/runtime/arguments.cpp
+++ b/src/hotspot/share/runtime/arguments.cpp
@@ -3154,7 +3154,10 @@ jint Arguments::finalize_vm_init_args(bool patch_mod_javabase) {
#endif // CAN_SHOW_REGISTERS_ON_ASSERT
// Lilliput requires fast-locking.
+ // FIXME: x86_32 has problems with fast locking, disable it temporarily.
+#ifdef _LP64
FLAG_SET_DEFAULT(UseFastLocking, true);
+#endif
FLAG_SET_DEFAULT(UseBiasedLocking, false);
#ifdef _LP64
FLAG_SET_DEFAULT(UseCompressedClassPointers, true);
-------------
PR: https://git.openjdk.org/lilliput-jdk17u/pull/2
From shade at openjdk.org Fri Jan 13 17:46:14 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 13 Jan 2023 17:46:14 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8299552: [Lilliput/JDK17] Fix
32bit builds
In-Reply-To: <hR9FDNhcxhsCKaAYT0HdmCcfwXlc6z5qkPXjvzgYVgM=.27e85d5f-4178-4acd-b538-4a5ba920b774@github.com>
References: <hR9FDNhcxhsCKaAYT0HdmCcfwXlc6z5qkPXjvzgYVgM=.27e85d5f-4178-4acd-b538-4a5ba920b774@github.com>
Message-ID: <fJwqQynWETrzY9s2D1BvBR7FbjoMVUX4osChC4QTrAo=.b087feb9-0d84-4ed5-b819-13a6caef0649@github.com>
On Tue, 3 Jan 2023 18:27:22 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
> 32bit builds in Lilliput/JDK17 are broken:
>
> * For target hotspot_variant-server_libjvm_objs_space.o:
Looks okay, but I have not reviewed the locking code additions carefully. I assume they match what `_LP64` paths are doing.
-------------
Marked as reviewed by shade (Reviewer).
PR: https://git.openjdk.org/lilliput-jdk17u/pull/2
From rkennke at openjdk.org Fri Jan 13 19:04:55 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 13 Jan 2023 19:04:55 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8299552: [Lilliput/JDK17] Fix
32bit builds
In-Reply-To: <fJwqQynWETrzY9s2D1BvBR7FbjoMVUX4osChC4QTrAo=.b087feb9-0d84-4ed5-b819-13a6caef0649@github.com>
References: <hR9FDNhcxhsCKaAYT0HdmCcfwXlc6z5qkPXjvzgYVgM=.27e85d5f-4178-4acd-b538-4a5ba920b774@github.com>
<fJwqQynWETrzY9s2D1BvBR7FbjoMVUX4osChC4QTrAo=.b087feb9-0d84-4ed5-b819-13a6caef0649@github.com>
Message-ID: <Nr-_mS3JKFThEj_Svdvwvg0h5jFd3eOx7kpqVvAdjn4=.9b9838a6-9741-45ef-bb4a-2600f9e59baf@github.com>
On Fri, 13 Jan 2023 17:43:23 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:
> Looks okay, but I have not reviewed the locking code additions carefully. I assume they match what `_LP64` paths are doing.
Yes. It brings x86_32 closer to what x86_64 is doing.
-------------
PR: https://git.openjdk.org/lilliput-jdk17u/pull/2
From rkennke at openjdk.org Fri Jan 13 19:04:57 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 13 Jan 2023 19:04:57 GMT
Subject: [lilliput-jdk17u:lilliput] Integrated: 8299552: [Lilliput/JDK17] Fix
32bit builds
In-Reply-To: <hR9FDNhcxhsCKaAYT0HdmCcfwXlc6z5qkPXjvzgYVgM=.27e85d5f-4178-4acd-b538-4a5ba920b774@github.com>
References: <hR9FDNhcxhsCKaAYT0HdmCcfwXlc6z5qkPXjvzgYVgM=.27e85d5f-4178-4acd-b538-4a5ba920b774@github.com>
Message-ID: <deCY7iizEYg5GbrCYWWz_FWHf7vmXPwgSEz0rLfXbwU=.dad70e03-ddd5-4fec-a604-8bb2f025e4f3@github.com>
On Tue, 3 Jan 2023 18:27:22 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
> 32bit builds in Lilliput/JDK17 are broken:
>
> * For target hotspot_variant-server_libjvm_objs_space.o:
This pull request has now been integrated.
Changeset: 8a18385a
Author: Roman Kennke <rkennke at openjdk.org>
URL: https://git.openjdk.org/lilliput-jdk17u/commit/8a18385a70b820fc3965ba8500f8ead308313aff
Stats: 84 lines in 13 files changed: 48 ins; 14 del; 22 mod
8299552: [Lilliput/JDK17] Fix 32bit builds
Reviewed-by: shade
-------------
PR: https://git.openjdk.org/lilliput-jdk17u/pull/2
From rkennke at openjdk.org Fri Jan 13 20:26:04 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 13 Jan 2023 20:26:04 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8300138: [Lilliput/JDK17] Optimize
anonymous owner fix-up path
Message-ID: <0YWDdcVhAJdhT1W9oSNnf1_IBlbDaNyMNP6DjA0LoX0=.1d47804e-6425-4833-a97e-8f2ef1d64a5b@github.com>
I'd like to push this optimization to Lilliput/JDK17. I already included it in the [upstream fast-locking change](https://github.com/openjdk/jdk/pull/10907), soon to be merged into Lilliput tip. It simplifies the fast-unlocking code and makes it more efficient. See JBS entry for more details.
Testing:
- [x] tier1
- [x] tier2
-------------
Commit messages:
- Use testb instead of testptr for anon-test
- Missing testptr with Address arg
- 8300138: [Lilliput/JDK17] Optimize anonymous owner fix-up path
Changes: https://git.openjdk.org/lilliput-jdk17u/pull/3/files
Webrev: https://webrevs.openjdk.org/?repo=lilliput-jdk17u&pr=3&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8300138
Stats: 21 lines in 3 files changed: 7 ins; 9 del; 5 mod
Patch: https://git.openjdk.org/lilliput-jdk17u/pull/3.diff
Fetch: git fetch https://git.openjdk.org/lilliput-jdk17u pull/3/head:pull/3
PR: https://git.openjdk.org/lilliput-jdk17u/pull/3
From shade at openjdk.org Mon Jan 16 11:53:47 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 16 Jan 2023 11:53:47 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8300138: [Lilliput/JDK17] Optimize
anonymous owner fix-up path
In-Reply-To: <0YWDdcVhAJdhT1W9oSNnf1_IBlbDaNyMNP6DjA0LoX0=.1d47804e-6425-4833-a97e-8f2ef1d64a5b@github.com>
References: <0YWDdcVhAJdhT1W9oSNnf1_IBlbDaNyMNP6DjA0LoX0=.1d47804e-6425-4833-a97e-8f2ef1d64a5b@github.com>
Message-ID: <sLTwZ79PUJxlPLYUGn79D70oHH6zigDzXV0-j8mZqLE=.1fd0158c-b4b9-4b34-8f16-5a4209aab6ad@github.com>
On Fri, 13 Jan 2023 19:28:23 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
> I'd like to push this optimization to Lilliput/JDK17. I already included it in the [upstream fast-locking change](https://github.com/openjdk/jdk/pull/10907), soon to be merged into Lilliput tip. It simplifies the fast-unlocking code and makes it more efficient. See JBS entry for more details.
>
> Testing:
> - [x] tier1
> - [x] tier2
Marked as reviewed by shade (Reviewer).
-------------
PR: https://git.openjdk.org/lilliput-jdk17u/pull/3
From rkennke at openjdk.org Mon Jan 16 12:01:52 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 16 Jan 2023 12:01:52 GMT
Subject: [lilliput-jdk17u:lilliput] Integrated: 8300138: [Lilliput/JDK17]
Optimize anonymous owner fix-up path
In-Reply-To: <0YWDdcVhAJdhT1W9oSNnf1_IBlbDaNyMNP6DjA0LoX0=.1d47804e-6425-4833-a97e-8f2ef1d64a5b@github.com>
References: <0YWDdcVhAJdhT1W9oSNnf1_IBlbDaNyMNP6DjA0LoX0=.1d47804e-6425-4833-a97e-8f2ef1d64a5b@github.com>
Message-ID: <5NVKl4eHwmPAe1_ArvctgfqPDKb83Cmb9Ayn3B9YOas=.f0e17be7-5720-4adc-b2cb-ef4ac935c99d@github.com>
On Fri, 13 Jan 2023 19:28:23 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
> I'd like to push this optimization to Lilliput/JDK17. I already included it in the [upstream fast-locking change](https://github.com/openjdk/jdk/pull/10907), soon to be merged into Lilliput tip. It simplifies the fast-unlocking code and makes it more efficient. See JBS entry for more details.
>
> Testing:
> - [x] tier1
> - [x] tier2
This pull request has now been integrated.
Changeset: 2d0f8d96
Author: Roman Kennke <rkennke at openjdk.org>
URL: https://git.openjdk.org/lilliput-jdk17u/commit/2d0f8d96792ad643f241e6c61529b28529671ce3
Stats: 21 lines in 3 files changed: 7 ins; 9 del; 5 mod
8300138: [Lilliput/JDK17] Optimize anonymous owner fix-up path
Reviewed-by: shade
-------------
PR: https://git.openjdk.org/lilliput-jdk17u/pull/3
From rkennke at openjdk.org Wed Jan 18 08:22:07 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 18 Jan 2023 08:22:07 GMT
Subject: [master] RFR: 8300440: [Lilliput] Implement alternative fast-locking
scheme
Message-ID: <dH-uqmMoECY1uCt2WcFxTlVUnqfdIRx7getxPct_OhI=.a8dc0610-51fd-49d6-8ba1-9ec934678d54@github.com>
This cherry-picks https://github.com/openjdk/jdk/pull/10907 before it lands in mainline JDK. It will:
- Greatly simply access to the header in the face of racy stack-locking
- Enable some optimizations in various places, most importantly accessing Klass* and i-hash
- Enable full SA support
- Enable full ZGC support
- Enable adding a runtime flag to turn on/off Lilliput
However, this PR implements none of the above. It is a straight port of the upstream change, and fast-locking is *not yet* enabled with Lilliput. This is going to happen in a follow-up PR.
Testing and performance impact, see upstream PR.
Ok to push to Lilliput?
-------------
Commit messages:
- 8300440: [Lilliput] Implement alternative fast-locking scheme
Changes: https://git.openjdk.org/lilliput/pull/62/files
Webrev: https://webrevs.openjdk.org/?repo=lilliput&pr=62&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8300440
Stats: 1925 lines in 74 files changed: 1213 ins; 97 del; 615 mod
Patch: https://git.openjdk.org/lilliput/pull/62.diff
Fetch: git fetch https://git.openjdk.org/lilliput pull/62/head:pull/62
PR: https://git.openjdk.org/lilliput/pull/62
From shade at openjdk.org Wed Jan 18 10:17:56 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 18 Jan 2023 10:17:56 GMT
Subject: [master] RFR: 8300440: [Lilliput] Implement alternative
fast-locking scheme
In-Reply-To: <dH-uqmMoECY1uCt2WcFxTlVUnqfdIRx7getxPct_OhI=.a8dc0610-51fd-49d6-8ba1-9ec934678d54@github.com>
References: <dH-uqmMoECY1uCt2WcFxTlVUnqfdIRx7getxPct_OhI=.a8dc0610-51fd-49d6-8ba1-9ec934678d54@github.com>
Message-ID: <h6afq93UUSVhkE_lEFp7SS9w5Y1vrOYglssm9N-gvLI=.667330a1-66b0-467a-9224-53f6d08c5a53@github.com>
On Wed, 18 Jan 2023 08:14:51 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
> This cherry-picks https://github.com/openjdk/jdk/pull/10907 before it lands in mainline JDK. It will:
> - Greatly simply access to the header in the face of racy stack-locking
> - Enable some optimizations in various places, most importantly accessing Klass* and i-hash
> - Enable full SA support
> - Enable full ZGC support
> - Enable adding a runtime flag to turn on/off Lilliput
>
> However, this PR implements none of the above. It is a straight port of the upstream change, and fast-locking is *not yet* enabled with Lilliput. This is going to happen in a follow-up PR.
>
> Testing and performance impact, see upstream PR.
>
> Ok to push to Lilliput?
OK for Lilliput.
-------------
Marked as reviewed by shade (Committer).
PR: https://git.openjdk.org/lilliput/pull/62
From rkennke at openjdk.org Wed Jan 18 13:05:27 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 18 Jan 2023 13:05:27 GMT
Subject: [master] RFR: 8300440: [Lilliput] Implement alternative
fast-locking scheme
In-Reply-To: <dH-uqmMoECY1uCt2WcFxTlVUnqfdIRx7getxPct_OhI=.a8dc0610-51fd-49d6-8ba1-9ec934678d54@github.com>
References: <dH-uqmMoECY1uCt2WcFxTlVUnqfdIRx7getxPct_OhI=.a8dc0610-51fd-49d6-8ba1-9ec934678d54@github.com>
Message-ID: <JaUdIQnEkJt9t92W3N27I2MA6KrmEmySgLrcigojhVc=.637435e0-f8f7-4cef-bdb8-871f27ae194b@github.com>
On Wed, 18 Jan 2023 08:14:51 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
> This cherry-picks https://github.com/openjdk/jdk/pull/10907 before it lands in mainline JDK. It will:
> - Greatly simply access to the header in the face of racy stack-locking
> - Enable some optimizations in various places, most importantly accessing Klass* and i-hash
> - Enable full SA support
> - Enable full ZGC support
> - Enable adding a runtime flag to turn on/off Lilliput
>
> However, this PR implements none of the above. It is a straight port of the upstream change, and fast-locking is *not yet* enabled with Lilliput. This is going to happen in a follow-up PR.
>
> Testing and performance impact, see upstream PR.
>
> Ok to push to Lilliput?
Thanks, Aleksey!
-------------
PR: https://git.openjdk.org/lilliput/pull/62
From rkennke at openjdk.org Wed Jan 18 13:12:45 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 18 Jan 2023 13:12:45 GMT
Subject: [master] Integrated: 8300440: [Lilliput] Implement alternative
fast-locking scheme
In-Reply-To: <dH-uqmMoECY1uCt2WcFxTlVUnqfdIRx7getxPct_OhI=.a8dc0610-51fd-49d6-8ba1-9ec934678d54@github.com>
References: <dH-uqmMoECY1uCt2WcFxTlVUnqfdIRx7getxPct_OhI=.a8dc0610-51fd-49d6-8ba1-9ec934678d54@github.com>
Message-ID: <3zLWga6fsQ4WQ43sJswjSOAi3swsOGbAg9xUZ5YkEOI=.b18556fe-98d2-47b0-aa4a-249cdf064271@github.com>
On Wed, 18 Jan 2023 08:14:51 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
> This cherry-picks https://github.com/openjdk/jdk/pull/10907 before it lands in mainline JDK. It will:
> - Greatly simply access to the header in the face of racy stack-locking
> - Enable some optimizations in various places, most importantly accessing Klass* and i-hash
> - Enable full SA support
> - Enable full ZGC support
> - Enable adding a runtime flag to turn on/off Lilliput
>
> However, this PR implements none of the above. It is a straight port of the upstream change, and fast-locking is *not yet* enabled with Lilliput. This is going to happen in a follow-up PR.
>
> Testing and performance impact, see upstream PR.
>
> Ok to push to Lilliput?
This pull request has now been integrated.
Changeset: 989cf15c
Author: Roman Kennke <rkennke at openjdk.org>
URL: https://git.openjdk.org/lilliput/commit/989cf15c170545ed376e007eafdb31a0c163045b
Stats: 1925 lines in 74 files changed: 1213 ins; 97 del; 615 mod
8300440: [Lilliput] Implement alternative fast-locking scheme
Reviewed-by: shade
-------------
PR: https://git.openjdk.org/lilliput/pull/62
From rkennke at openjdk.org Wed Jan 18 17:17:59 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 18 Jan 2023 17:17:59 GMT
Subject: [master] RFR: 8300573: [Lilliput] Properly set ZF on anon-check path;
avoid some conditional branches
Message-ID: <tKCv0ogPCMYVyC6ciJU8r1YC5CKpjb_rpq96Sx0TtN0=.bb38dc0a-5157-43f7-9902-095d87b77354@github.com>
In AArch64's fast_unlock(), we need to check if the monitor owner is ANONYMOUS (only with Lilliput/fast-locking), and if so, call the runtime to fix this before exiting the monitor. I tried to be smart and used tbnz there, but it turns out that tbnz does *not* set the zero flag, but we do need the ZF set correctly on exit of fast_unlock, so that C2 generated code would actually call the slow path. Therefore we need to use the longer tst/br instructions instead.
The change also removes some conditional branches.
All of the changes have already been integrated into the upstream proposed PR: https://github.com/openjdk/jdk/pull/10907/
Testing:
- [x] tier1
- [x] tier2
-------------
Commit messages:
- 8300573: [Lilliput] Properly set ZF on anon-check path; avoid some conditional branches
Changes: https://git.openjdk.org/lilliput/pull/63/files
Webrev: https://webrevs.openjdk.org/?repo=lilliput&pr=63&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8300573
Stats: 19 lines in 1 file changed: 12 ins; 2 del; 5 mod
Patch: https://git.openjdk.org/lilliput/pull/63.diff
Fetch: git fetch https://git.openjdk.org/lilliput pull/63/head:pull/63
PR: https://git.openjdk.org/lilliput/pull/63
From rkennke at openjdk.org Wed Jan 18 17:28:02 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 18 Jan 2023 17:28:02 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8300566: [Lilliput/JDK17] Properly set
ZF on anon-check path
Message-ID: <Hxy1fRse1ScHJk4zOwo_1u1NwUB1aK-zxVDwCYX_D88=.239987f6-9d0b-4234-90c0-f10c6071d21d@github.com>
In AArch64's fast_unlock(), we need to check if the monitor owner is ANONYMOUS (only with Lilliput/fast-locking), and if so, call the runtime to fix this before exiting the monitor. I tried to be smart and used tbnz there, but it turns out that tbnz does *not* set the zero flag, but we do need the ZF set correctly on exit of fast_unlock, so that C2 generated code would actually call the slow path. Therefore we need to use the longer tst/br instructions instead.
-------------
Commit messages:
- 8300566: [Lilliput/JDK17] Properly set ZF on anon-check path
Changes: https://git.openjdk.org/lilliput-jdk17u/pull/4/files
Webrev: https://webrevs.openjdk.org/?repo=lilliput-jdk17u&pr=4&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8300566
Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod
Patch: https://git.openjdk.org/lilliput-jdk17u/pull/4.diff
Fetch: git fetch https://git.openjdk.org/lilliput-jdk17u pull/4/head:pull/4
PR: https://git.openjdk.org/lilliput-jdk17u/pull/4
From shade at openjdk.org Thu Jan 19 11:00:52 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 19 Jan 2023 11:00:52 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8300566: [Lilliput/JDK17] Properly
set ZF on anon-check path
In-Reply-To: <Hxy1fRse1ScHJk4zOwo_1u1NwUB1aK-zxVDwCYX_D88=.239987f6-9d0b-4234-90c0-f10c6071d21d@github.com>
References: <Hxy1fRse1ScHJk4zOwo_1u1NwUB1aK-zxVDwCYX_D88=.239987f6-9d0b-4234-90c0-f10c6071d21d@github.com>
Message-ID: <fsqWnXkDmFCqHYgJ8EXfiKrBrNaQevRGo-AfyLUVy4g=.2129542b-5f8b-46ca-b282-d91a73a52173@github.com>
On Wed, 18 Jan 2023 16:07:01 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
> In AArch64's fast_unlock(), we need to check if the monitor owner is ANONYMOUS (only with Lilliput/fast-locking), and if so, call the runtime to fix this before exiting the monitor. I tried to be smart and used tbnz there, but it turns out that tbnz does *not* set the zero flag, but we do need the ZF set correctly on exit of fast_unlock, so that C2 generated code would actually call the slow path. Therefore we need to use the longer tst/br instructions instead.
Marked as reviewed by shade (Reviewer).
-------------
PR: https://git.openjdk.org/lilliput-jdk17u/pull/4
From rkennke at openjdk.org Fri Jan 20 09:27:09 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 20 Jan 2023 09:27:09 GMT
Subject: [master] RFR: 8300733: [Lilliput] Enable fast-locking for Lilliput
Message-ID: <sfg_8FSt-559lQcuMLjh7OheRgesUDsTwJv4pgMembU=.abd3f9c1-8fb6-4493-bccb-9ee3195fdc02@github.com>
Fast-locking provides many advantages for Lilliput. Most importantly, it greatly simplifies the access of the mark word: we no longer need to handle the case of stack-locking which has been racy and complicated.
This change enables fast-locking, but doesn't yet touch any of the improvements that it provides (simpler loading of Klass*, etc).
Testing:
- [x] tier1
- [x] tier2
-------------
Commit messages:
- [Lilliput] Enable fast-locking for Lilliput
Changes: https://git.openjdk.org/lilliput/pull/64/files
Webrev: https://webrevs.openjdk.org/?repo=lilliput&pr=64&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8300733
Stats: 7 lines in 4 files changed: 3 ins; 0 del; 4 mod
Patch: https://git.openjdk.org/lilliput/pull/64.diff
Fetch: git fetch https://git.openjdk.org/lilliput pull/64/head:pull/64
PR: https://git.openjdk.org/lilliput/pull/64
From rkennke at openjdk.org Fri Jan 20 10:33:08 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 20 Jan 2023 10:33:08 GMT
Subject: [master] RFR: 8300735: [Lilliput] Adjust GHA and jcheck config
Message-ID: <mfdyjuafMLmzehTuj80a3dgAw18hY9Z9vX75NWx8cEM=.4dae03d5-00a9-40c1-aec0-bcded98eb76a@github.com>
I'd like to exclude not-yet-supported platforms that are failing in GHA (ppc64le, risc64, s390x). Also, we should remove a stale submit.yml.
I would also like to adjust jcheck to require a JBS issue for each PR, as I have recently begun to do. This improves traceability and discoverability of Lilliput work in JBS.
-------------
Commit messages:
- Adjust jcheck config to require JBS issue
- 8300735: [Lilliput] Adjust GHA for Lilliput
Changes: https://git.openjdk.org/lilliput/pull/65/files
Webrev: https://webrevs.openjdk.org/?repo=lilliput&pr=65&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8300735
Stats: 1786 lines in 3 files changed: 3 ins; 1782 del; 1 mod
Patch: https://git.openjdk.org/lilliput/pull/65.diff
Fetch: git fetch https://git.openjdk.org/lilliput pull/65/head:pull/65
PR: https://git.openjdk.org/lilliput/pull/65
From shade at openjdk.org Fri Jan 20 10:33:08 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 20 Jan 2023 10:33:08 GMT
Subject: [master] RFR: 8300735: [Lilliput] Adjust GHA and jcheck config
In-Reply-To: <mfdyjuafMLmzehTuj80a3dgAw18hY9Z9vX75NWx8cEM=.4dae03d5-00a9-40c1-aec0-bcded98eb76a@github.com>
References: <mfdyjuafMLmzehTuj80a3dgAw18hY9Z9vX75NWx8cEM=.4dae03d5-00a9-40c1-aec0-bcded98eb76a@github.com>
Message-ID: <rmTvq8T_N0QFbE6iIWY0hn49n-ty8UInpKXJ6qSoznI=.049eef9c-8fad-4aab-8e43-b1fc2786f500@github.com>
On Fri, 20 Jan 2023 09:33:04 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
> I'd like to exclude not-yet-supported platforms that are failing in GHA (ppc64le, risc64, s390x). Also, we should remove a stale submit.yml.
> I would also like to adjust jcheck to require a JBS issue for each PR, as I have recently begun to do. This improves traceability and discoverability of Lilliput work in JBS.
I think it would be enough to just trim the defaults here:
default: "Linux additional (hotspot only), Linux x64, Linux x86, Windows aarch64, Windows x64, macOS x64"
-------------
PR: https://git.openjdk.org/lilliput/pull/65
From rkennke at openjdk.org Fri Jan 20 10:58:40 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 20 Jan 2023 10:58:40 GMT
Subject: [master] RFR: 8300735: [Lilliput] Adjust GHA and jcheck config
[v2]
In-Reply-To: <mfdyjuafMLmzehTuj80a3dgAw18hY9Z9vX75NWx8cEM=.4dae03d5-00a9-40c1-aec0-bcded98eb76a@github.com>
References: <mfdyjuafMLmzehTuj80a3dgAw18hY9Z9vX75NWx8cEM=.4dae03d5-00a9-40c1-aec0-bcded98eb76a@github.com>
Message-ID: <TKT5aH17p2vKwPRrfEHQX6YhrGM_mT4gJpil9gM1MKs=.a4cfbc7d-9354-4a89-b261-224b083b7200@github.com>
> I'd like to exclude not-yet-supported platforms that are failing in GHA (ppc64le, risc64, s390x). Also, we should remove a stale submit.yml.
> I would also like to adjust jcheck to require a JBS issue for each PR, as I have recently begun to do. This improves traceability and discoverability of Lilliput work in JBS.
Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
- Attempt to minimize GHA changes
- Revert "8300735: [Lilliput] Adjust GHA for Lilliput"
This reverts commit 1e11978b821f1581147856330f2b26715e7046c2.
-------------
Changes:
- all: https://git.openjdk.org/lilliput/pull/65/files
- new: https://git.openjdk.org/lilliput/pull/65/files/e2ee6f43..884c5fc5
Webrevs:
- full: https://webrevs.openjdk.org/?repo=lilliput&pr=65&range=01
- incr: https://webrevs.openjdk.org/?repo=lilliput&pr=65&range=00-01
Stats: 16 lines in 1 file changed: 16 ins; 0 del; 0 mod
Patch: https://git.openjdk.org/lilliput/pull/65.diff
Fetch: git fetch https://git.openjdk.org/lilliput pull/65/head:pull/65
PR: https://git.openjdk.org/lilliput/pull/65
From rkennke at openjdk.org Fri Jan 20 10:58:42 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 20 Jan 2023 10:58:42 GMT
Subject: [master] RFR: 8300735: [Lilliput] Adjust GHA and jcheck config
In-Reply-To: <rmTvq8T_N0QFbE6iIWY0hn49n-ty8UInpKXJ6qSoznI=.049eef9c-8fad-4aab-8e43-b1fc2786f500@github.com>
References: <mfdyjuafMLmzehTuj80a3dgAw18hY9Z9vX75NWx8cEM=.4dae03d5-00a9-40c1-aec0-bcded98eb76a@github.com>
<rmTvq8T_N0QFbE6iIWY0hn49n-ty8UInpKXJ6qSoznI=.049eef9c-8fad-4aab-8e43-b1fc2786f500@github.com>
Message-ID: <5xHWFkcgHxh6zD2I_ThBXMroXBT1hJyQVcM1dQp9Tfc=.e200cd2e-b5a0-4157-b614-1c4be15bfda6@github.com>
On Fri, 20 Jan 2023 10:12:08 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:
> I think it would be enough to just trim the defaults here:
>
> ```
> default: "Linux additional (hotspot only), Linux x64, Linux x86, Windows aarch64, Windows x64, macOS x64"
> ```
That line only exists in the removed submit.yml. I am trying to trim the 3 unsupported arches in build-cross-compile.yml without removing the actual configurations. Let's see if that works. Also, let me know if you think there is a better way. I would like to keep the linux-aarch64 x-compile target.
-------------
PR: https://git.openjdk.org/lilliput/pull/65
From rkennke at openjdk.org Fri Jan 20 12:28:16 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 20 Jan 2023 12:28:16 GMT
Subject: [master] RFR: 8300735: [Lilliput] Adjust GHA and jcheck config
[v3]
In-Reply-To: <mfdyjuafMLmzehTuj80a3dgAw18hY9Z9vX75NWx8cEM=.4dae03d5-00a9-40c1-aec0-bcded98eb76a@github.com>
References: <mfdyjuafMLmzehTuj80a3dgAw18hY9Z9vX75NWx8cEM=.4dae03d5-00a9-40c1-aec0-bcded98eb76a@github.com>
Message-ID: <4FOq4ZC3SDdt3eUIqTQ0v3qNyqzwn97aEuPJmU9yj-Y=.b6be22d5-e885-42c5-a09d-bbc3ef2a9abf@github.com>
> I'd like to exclude not-yet-supported platforms that are failing in GHA (ppc64le, risc64, s390x). Also, we should remove a stale submit.yml.
> I would also like to adjust jcheck to require a JBS issue for each PR, as I have recently begun to do. This improves traceability and discoverability of Lilliput work in JBS.
Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
Remove unsupported x-compile includes
-------------
Changes:
- all: https://git.openjdk.org/lilliput/pull/65/files
- new: https://git.openjdk.org/lilliput/pull/65/files/884c5fc5..21391524
Webrevs:
- full: https://webrevs.openjdk.org/?repo=lilliput&pr=65&range=02
- incr: https://webrevs.openjdk.org/?repo=lilliput&pr=65&range=01-02
Stats: 16 lines in 1 file changed: 0 ins; 16 del; 0 mod
Patch: https://git.openjdk.org/lilliput/pull/65.diff
Fetch: git fetch https://git.openjdk.org/lilliput pull/65/head:pull/65
PR: https://git.openjdk.org/lilliput/pull/65
From shade at openjdk.org Fri Jan 20 16:04:44 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 20 Jan 2023 16:04:44 GMT
Subject: [master] RFR: 8300573: [Lilliput] Properly set ZF on anon-check
path; avoid some conditional branches
In-Reply-To: <tKCv0ogPCMYVyC6ciJU8r1YC5CKpjb_rpq96Sx0TtN0=.bb38dc0a-5157-43f7-9902-095d87b77354@github.com>
References: <tKCv0ogPCMYVyC6ciJU8r1YC5CKpjb_rpq96Sx0TtN0=.bb38dc0a-5157-43f7-9902-095d87b77354@github.com>
Message-ID: <H-mv3xvRKXxvb9lGEQEXix4r1K4mVcGt2WgIVovApA4=.9854be1b-23b9-41e0-9b6b-6eb336158847@github.com>
On Wed, 18 Jan 2023 17:11:02 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
> In AArch64's fast_unlock(), we need to check if the monitor owner is ANONYMOUS (only with Lilliput/fast-locking), and if so, call the runtime to fix this before exiting the monitor. I tried to be smart and used tbnz there, but it turns out that tbnz does *not* set the zero flag, but we do need the ZF set correctly on exit of fast_unlock, so that C2 generated code would actually call the slow path. Therefore we need to use the longer tst/br instructions instead.
>
> The change also removes some conditional branches.
>
> All of the changes have already been integrated into the upstream proposed PR: https://github.com/openjdk/jdk/pull/10907/
>
> Testing:
> - [x] tier1
> - [x] tier2
Uff. `cont` and `count` look cunningly similar. Anyway!
-------------
Marked as reviewed by shade (Committer).
PR: https://git.openjdk.org/lilliput/pull/63
From shade at openjdk.org Fri Jan 20 18:02:58 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 20 Jan 2023 18:02:58 GMT
Subject: [master] RFR: 8300735: [Lilliput] Adjust GHA and jcheck config
[v3]
In-Reply-To: <4FOq4ZC3SDdt3eUIqTQ0v3qNyqzwn97aEuPJmU9yj-Y=.b6be22d5-e885-42c5-a09d-bbc3ef2a9abf@github.com>
References: <mfdyjuafMLmzehTuj80a3dgAw18hY9Z9vX75NWx8cEM=.4dae03d5-00a9-40c1-aec0-bcded98eb76a@github.com>
<4FOq4ZC3SDdt3eUIqTQ0v3qNyqzwn97aEuPJmU9yj-Y=.b6be22d5-e885-42c5-a09d-bbc3ef2a9abf@github.com>
Message-ID: <qj0cbqthETQJzcoMaHz6yu0F2-rgsXIalpUgKCpRRDY=.a87f7a22-786e-4766-b16b-447f48d7413c@github.com>
On Fri, 20 Jan 2023 12:28:16 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
>> I'd like to exclude not-yet-supported platforms that are failing in GHA (ppc64le, risc64, s390x). Also, we should remove a stale submit.yml.
>> I would also like to adjust jcheck to require a JBS issue for each PR, as I have recently begun to do. This improves traceability and discoverability of Lilliput work in JBS.
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>
> Remove unsupported x-compile includes
Marked as reviewed by shade (Committer).
-------------
PR: https://git.openjdk.org/lilliput/pull/65
From rkennke at openjdk.org Fri Jan 20 19:39:27 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 20 Jan 2023 19:39:27 GMT
Subject: [master] Integrated: 8300735: [Lilliput] Adjust GHA and jcheck config
In-Reply-To: <mfdyjuafMLmzehTuj80a3dgAw18hY9Z9vX75NWx8cEM=.4dae03d5-00a9-40c1-aec0-bcded98eb76a@github.com>
References: <mfdyjuafMLmzehTuj80a3dgAw18hY9Z9vX75NWx8cEM=.4dae03d5-00a9-40c1-aec0-bcded98eb76a@github.com>
Message-ID: <3YQBI1uDnOxDIMF7FqiP9r2Ev4sCxAGGqOf9UI3Jbbo=.b433e503-1517-4076-b5ed-0fab754ea8cf@github.com>
On Fri, 20 Jan 2023 09:33:04 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
> I'd like to exclude not-yet-supported platforms that are failing in GHA (ppc64le, risc64, s390x). Also, we should remove a stale submit.yml.
> I would also like to adjust jcheck to require a JBS issue for each PR, as I have recently begun to do. This improves traceability and discoverability of Lilliput work in JBS.
This pull request has now been integrated.
Changeset: c1f3eb2b
Author: Roman Kennke <rkennke at openjdk.org>
URL: https://git.openjdk.org/lilliput/commit/c1f3eb2b56e68ab3950360c6415fc7833cb353ff
Stats: 1786 lines in 3 files changed: 3 ins; 1782 del; 1 mod
8300735: [Lilliput] Adjust GHA and jcheck config
Reviewed-by: shade
-------------
PR: https://git.openjdk.org/lilliput/pull/65
From rkennke at openjdk.org Fri Jan 20 19:41:00 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 20 Jan 2023 19:41:00 GMT
Subject: [master] RFR: 8300733: [Lilliput] Enable fast-locking for Lilliput
[v2]
In-Reply-To: <sfg_8FSt-559lQcuMLjh7OheRgesUDsTwJv4pgMembU=.abd3f9c1-8fb6-4493-bccb-9ee3195fdc02@github.com>
References: <sfg_8FSt-559lQcuMLjh7OheRgesUDsTwJv4pgMembU=.abd3f9c1-8fb6-4493-bccb-9ee3195fdc02@github.com>
Message-ID: <UpmYDntS_FWu58bHRceRgdVUlGlCkt8nqPe8gW_j3m4=.770e5a78-4a9c-4efd-947c-0178dfc823b8@github.com>
> Fast-locking provides many advantages for Lilliput. Most importantly, it greatly simplifies the access of the mark word: we no longer need to handle the case of stack-locking which has been racy and complicated.
>
> This change enables fast-locking, but doesn't yet touch any of the improvements that it provides (simpler loading of Klass*, etc).
>
> Testing:
> - [x] tier1
> - [x] tier2
Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
- Merge branch 'master' into JDK-8300733
- [Lilliput] Enable fast-locking for Lilliput
-------------
Changes:
- all: https://git.openjdk.org/lilliput/pull/64/files
- new: https://git.openjdk.org/lilliput/pull/64/files/edffb491..4ced8f55
Webrevs:
- full: https://webrevs.openjdk.org/?repo=lilliput&pr=64&range=01
- incr: https://webrevs.openjdk.org/?repo=lilliput&pr=64&range=00-01
Stats: 1786 lines in 3 files changed: 3 ins; 1782 del; 1 mod
Patch: https://git.openjdk.org/lilliput/pull/64.diff
Fetch: git fetch https://git.openjdk.org/lilliput pull/64/head:pull/64
PR: https://git.openjdk.org/lilliput/pull/64
From rkennke at openjdk.org Fri Jan 20 19:41:04 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 20 Jan 2023 19:41:04 GMT
Subject: [master] RFR: 8300573: [Lilliput] Properly set ZF on anon-check
path; avoid some conditional branches [v2]
In-Reply-To: <tKCv0ogPCMYVyC6ciJU8r1YC5CKpjb_rpq96Sx0TtN0=.bb38dc0a-5157-43f7-9902-095d87b77354@github.com>
References: <tKCv0ogPCMYVyC6ciJU8r1YC5CKpjb_rpq96Sx0TtN0=.bb38dc0a-5157-43f7-9902-095d87b77354@github.com>
Message-ID: <YHaeLUja0ONFnxCWEeAgucvnmRykww_mR8-It7oiXlQ=.3306f66d-a47b-430b-8a9c-15ee1abaf270@github.com>
> In AArch64's fast_unlock(), we need to check if the monitor owner is ANONYMOUS (only with Lilliput/fast-locking), and if so, call the runtime to fix this before exiting the monitor. I tried to be smart and used tbnz there, but it turns out that tbnz does *not* set the zero flag, but we do need the ZF set correctly on exit of fast_unlock, so that C2 generated code would actually call the slow path. Therefore we need to use the longer tst/br instructions instead.
>
> The change also removes some conditional branches.
>
> All of the changes have already been integrated into the upstream proposed PR: https://github.com/openjdk/jdk/pull/10907/
>
> Testing:
> - [x] tier1
> - [x] tier2
Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
- Merge branch 'master' into JDK-8300573
- 8300573: [Lilliput] Properly set ZF on anon-check path; avoid some conditional branches
-------------
Changes:
- all: https://git.openjdk.org/lilliput/pull/63/files
- new: https://git.openjdk.org/lilliput/pull/63/files/c6726ed0..399b85f3
Webrevs:
- full: https://webrevs.openjdk.org/?repo=lilliput&pr=63&range=01
- incr: https://webrevs.openjdk.org/?repo=lilliput&pr=63&range=00-01
Stats: 1786 lines in 3 files changed: 3 ins; 1782 del; 1 mod
Patch: https://git.openjdk.org/lilliput/pull/63.diff
Fetch: git fetch https://git.openjdk.org/lilliput pull/63/head:pull/63
PR: https://git.openjdk.org/lilliput/pull/63
From rkennke at openjdk.org Mon Jan 23 08:02:23 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 23 Jan 2023 08:02:23 GMT
Subject: git: openjdk/lilliput-jdk17u: lilliput: 8300566: [Lilliput/JDK17]
Properly set ZF on anon-check path
Message-ID: <6ff9ca9d-2485-4e5d-a9a5-c90c26469308@openjdk.org>
Changeset: 685351d2
Author: Roman Kennke <rkennke at openjdk.org>
Date: 2023-01-23 07:57:45 +0000
URL: https://git.openjdk.org/lilliput-jdk17u/commit/685351d2897a53f93ed4b9fd765113386410a96e
8300566: [Lilliput/JDK17] Properly set ZF on anon-check path
Reviewed-by: shade
! src/hotspot/cpu/aarch64/aarch64.ad
From rkennke at openjdk.org Mon Jan 23 08:05:36 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 23 Jan 2023 08:05:36 GMT
Subject: [master] Integrated: 8300573: [Lilliput] Properly set ZF on anon-check
path; avoid some conditional branches
In-Reply-To: <tKCv0ogPCMYVyC6ciJU8r1YC5CKpjb_rpq96Sx0TtN0=.bb38dc0a-5157-43f7-9902-095d87b77354@github.com>
References: <tKCv0ogPCMYVyC6ciJU8r1YC5CKpjb_rpq96Sx0TtN0=.bb38dc0a-5157-43f7-9902-095d87b77354@github.com>
Message-ID: <I3qV4esXBLMQO05ZBODNRYXd-mQSYcuF5mol40Jmp_4=.3ec613ca-84f4-41ef-91fd-eda0ff51c445@github.com>
On Wed, 18 Jan 2023 17:11:02 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
> In AArch64's fast_unlock(), we need to check if the monitor owner is ANONYMOUS (only with Lilliput/fast-locking), and if so, call the runtime to fix this before exiting the monitor. I tried to be smart and used tbnz there, but it turns out that tbnz does *not* set the zero flag, but we do need the ZF set correctly on exit of fast_unlock, so that C2 generated code would actually call the slow path. Therefore we need to use the longer tst/br instructions instead.
>
> The change also removes some conditional branches.
>
> All of the changes have already been integrated into the upstream proposed PR: https://github.com/openjdk/jdk/pull/10907/
>
> Testing:
> - [x] tier1
> - [x] tier2
This pull request has now been integrated.
Changeset: 89bd889d
Author: Roman Kennke <rkennke at openjdk.org>
URL: https://git.openjdk.org/lilliput/commit/89bd889d0a1a115aba605726f70b07c8f222b0e0
Stats: 19 lines in 1 file changed: 12 ins; 2 del; 5 mod
8300573: [Lilliput] Properly set ZF on anon-check path; avoid some conditional branches
Reviewed-by: shade
-------------
PR: https://git.openjdk.org/lilliput/pull/63
From rkennke at openjdk.org Mon Jan 23 08:06:35 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 23 Jan 2023 08:06:35 GMT
Subject: [lilliput-jdk17u:lilliput] Integrated: 8300566: [Lilliput/JDK17]
Properly set ZF on anon-check path
In-Reply-To: <Hxy1fRse1ScHJk4zOwo_1u1NwUB1aK-zxVDwCYX_D88=.239987f6-9d0b-4234-90c0-f10c6071d21d@github.com>
References: <Hxy1fRse1ScHJk4zOwo_1u1NwUB1aK-zxVDwCYX_D88=.239987f6-9d0b-4234-90c0-f10c6071d21d@github.com>
Message-ID: <W14Ef2JeoJXwhHqYDuPUsk8LrX-D0a0-OFYAoX5wiF0=.9087edea-fdcc-423d-8291-3df892719f4d@github.com>
On Wed, 18 Jan 2023 16:07:01 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
> In AArch64's fast_unlock(), we need to check if the monitor owner is ANONYMOUS (only with Lilliput/fast-locking), and if so, call the runtime to fix this before exiting the monitor. I tried to be smart and used tbnz there, but it turns out that tbnz does *not* set the zero flag, but we do need the ZF set correctly on exit of fast_unlock, so that C2 generated code would actually call the slow path. Therefore we need to use the longer tst/br instructions instead.
This pull request has now been integrated.
Changeset: 685351d2
Author: Roman Kennke <rkennke at openjdk.org>
URL: https://git.openjdk.org/lilliput-jdk17u/commit/685351d2897a53f93ed4b9fd765113386410a96e
Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod
8300566: [Lilliput/JDK17] Properly set ZF on anon-check path
Reviewed-by: shade
-------------
PR: https://git.openjdk.org/lilliput-jdk17u/pull/4
From rkennke at openjdk.org Mon Jan 23 10:42:02 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 23 Jan 2023 10:42:02 GMT
Subject: [master] RFR: 8300733: [Lilliput] Enable fast-locking for Lilliput
[v3]
In-Reply-To: <sfg_8FSt-559lQcuMLjh7OheRgesUDsTwJv4pgMembU=.abd3f9c1-8fb6-4493-bccb-9ee3195fdc02@github.com>
References: <sfg_8FSt-559lQcuMLjh7OheRgesUDsTwJv4pgMembU=.abd3f9c1-8fb6-4493-bccb-9ee3195fdc02@github.com>
Message-ID: <6eLxxyS45b5wz7f5uGZ6pCqPrwGMx2cITY8l6GgzzEA=.c2f821f7-c6b5-4749-b8d0-f3b033c7d3c7@github.com>
> Fast-locking provides many advantages for Lilliput. Most importantly, it greatly simplifies the access of the mark word: we no longer need to handle the case of stack-locking which has been racy and complicated.
>
> This change enables fast-locking, but doesn't yet touch any of the improvements that it provides (simpler loading of Klass*, etc).
>
> Testing:
> - [x] tier1
> - [x] tier2
Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
Fix/revert Shenandoah forwarding protocol to not use INFLATING 2-step
-------------
Changes:
- all: https://git.openjdk.org/lilliput/pull/64/files
- new: https://git.openjdk.org/lilliput/pull/64/files/4ced8f55..45e13179
Webrevs:
- full: https://webrevs.openjdk.org/?repo=lilliput&pr=64&range=02
- incr: https://webrevs.openjdk.org/?repo=lilliput&pr=64&range=01-02
Stats: 20 lines in 1 file changed: 0 ins; 13 del; 7 mod
Patch: https://git.openjdk.org/lilliput/pull/64.diff
Fetch: git fetch https://git.openjdk.org/lilliput pull/64/head:pull/64
PR: https://git.openjdk.org/lilliput/pull/64
From shade at openjdk.org Mon Jan 23 17:03:50 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 23 Jan 2023 17:03:50 GMT
Subject: [master] RFR: 8300733: [Lilliput] Enable fast-locking for Lilliput
[v3]
In-Reply-To: <6eLxxyS45b5wz7f5uGZ6pCqPrwGMx2cITY8l6GgzzEA=.c2f821f7-c6b5-4749-b8d0-f3b033c7d3c7@github.com>
References: <sfg_8FSt-559lQcuMLjh7OheRgesUDsTwJv4pgMembU=.abd3f9c1-8fb6-4493-bccb-9ee3195fdc02@github.com>
<6eLxxyS45b5wz7f5uGZ6pCqPrwGMx2cITY8l6GgzzEA=.c2f821f7-c6b5-4749-b8d0-f3b033c7d3c7@github.com>
Message-ID: <kGg8jJGVixfxBqkg1_6guQqhz_6g8osC5Bl_Jp3ltoM=.c1a0b4de-95c1-4bf8-b503-3f659b7d831c@github.com>
On Mon, 23 Jan 2023 10:42:02 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
>> Fast-locking provides many advantages for Lilliput. Most importantly, it greatly simplifies the access of the mark word: we no longer need to handle the case of stack-locking which has been racy and complicated.
>>
>> This change enables fast-locking, but doesn't yet touch any of the improvements that it provides (simpler loading of Klass*, etc).
>>
>> Testing:
>> - [x] tier1
>> - [x] tier2
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>
> Fix/revert Shenandoah forwarding protocol to not use INFLATING 2-step
Marked as reviewed by shade (Committer).
-------------
PR: https://git.openjdk.org/lilliput/pull/64
From rkennke at openjdk.org Mon Jan 23 19:08:11 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 23 Jan 2023 19:08:11 GMT
Subject: [master] Integrated: 8300733: [Lilliput] Enable fast-locking for
Lilliput
In-Reply-To: <sfg_8FSt-559lQcuMLjh7OheRgesUDsTwJv4pgMembU=.abd3f9c1-8fb6-4493-bccb-9ee3195fdc02@github.com>
References: <sfg_8FSt-559lQcuMLjh7OheRgesUDsTwJv4pgMembU=.abd3f9c1-8fb6-4493-bccb-9ee3195fdc02@github.com>
Message-ID: <lNdgGfsqxLacm7L-RxsbzvMpoyOK1pdcSEXbZ3AaTZE=.e1ea3e39-492e-4e2a-99b5-da6905158009@github.com>
On Fri, 20 Jan 2023 09:19:06 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
> Fast-locking provides many advantages for Lilliput. Most importantly, it greatly simplifies the access of the mark word: we no longer need to handle the case of stack-locking which has been racy and complicated.
>
> This change enables fast-locking, but doesn't yet touch any of the improvements that it provides (simpler loading of Klass*, etc).
>
> Testing:
> - [x] tier1
> - [x] tier2
This pull request has now been integrated.
Changeset: bf6823a4
Author: Roman Kennke <rkennke at openjdk.org>
URL: https://git.openjdk.org/lilliput/commit/bf6823a470dabfb691d3837244d82c16a857e5ae
Stats: 27 lines in 5 files changed: 3 ins; 13 del; 11 mod
8300733: [Lilliput] Enable fast-locking for Lilliput
Reviewed-by: shade
-------------
PR: https://git.openjdk.org/lilliput/pull/64
From rkennke at openjdk.org Tue Jan 24 16:03:30 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 24 Jan 2023 16:03:30 GMT
Subject: [master] RFR: 8300888: [Lilliput] Remaining missing parts in the SA
Message-ID: <vMljM9ZzG-3_6UESbP5e-RQMz1UUvMXItVYQvOql4VM=.684d1166-223a-42f6-b86e-2a1bc0700984@github.com>
With fast-locking, it is now possible to provide a safe implementation of load-Klass* (following the same principle as in the runtime: load mark, check for monitor, possibly load real mark from monitor, decode Klass* from mark). This change also fixes array layout calculation and un-blocks a number of SA tests that did not work before.
-------------
Commit messages:
- X8300888: [Lilliput] Remaining missing parts in the SA
Changes: https://git.openjdk.org/lilliput/pull/67/files
Webrev: https://webrevs.openjdk.org/?repo=lilliput&pr=67&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8300888
Stats: 129 lines in 7 files changed: 39 ins; 77 del; 13 mod
Patch: https://git.openjdk.org/lilliput/pull/67.diff
Fetch: git fetch https://git.openjdk.org/lilliput pull/67/head:pull/67
PR: https://git.openjdk.org/lilliput/pull/67
From rkennke at openjdk.org Tue Jan 24 16:03:35 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 24 Jan 2023 16:03:35 GMT
Subject: [master] RFR: 8300527: [Lilliput] Simplify and optimize loading of
Klass*
Message-ID: <jO08HB3bSFI6XChuVluh3PNghUYJpZs-N0_wyAZVGcg=.34f90e2f-3d35-4442-b8af-14a23bf7c094@github.com>
With the new fast-locking, we can greatly simplify the loading of the Klass* from an object. We no longer have to call into the runtime to ensure that the header is changed under our feet (by installing the INFLATION marker). Instead, we can do a simple check for the object being monitor-locked, and safely load the displaced header, if that is the case.
-------------
Commit messages:
- Add missing includes
- Fix merge error
- Merge branch 'master' into JDK-8300527
- 8300527: [Lilliput] Simplify and optimize loading of Klass*
- Fix/revert Shenandoah forwarding protocol to not use INFLATING 2-step
- Merge branch 'master' into JDK-8300733
- [Lilliput] Enable fast-locking for Lilliput
Changes: https://git.openjdk.org/lilliput/pull/66/files
Webrev: https://webrevs.openjdk.org/?repo=lilliput&pr=66&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8300527
Stats: 390 lines in 28 files changed: 76 ins; 279 del; 35 mod
Patch: https://git.openjdk.org/lilliput/pull/66.diff
Fetch: git fetch https://git.openjdk.org/lilliput pull/66/head:pull/66
PR: https://git.openjdk.org/lilliput/pull/66
From duke at openjdk.org Tue Jan 24 16:05:06 2023
From: duke at openjdk.org (duke)
Date: Tue, 24 Jan 2023 16:05:06 GMT
Subject: git: openjdk/lilliput: created branch pr/66 based on the branch pr/67
containing 7 unique commits
Message-ID: <4dc8c560-f322-4a29-952e-93405234d75f@openjdk.org>
The following commits are unique to the pr/66 branch:
========================================================
edffb491: [Lilliput] Enable fast-locking for Lilliput
4ced8f55: Merge branch 'master' into JDK-8300733
45e13179: Fix/revert Shenandoah forwarding protocol to not use INFLATING 2-step
01627ba3: 8300527: [Lilliput] Simplify and optimize loading of Klass*
d8c3961a: Merge branch 'master' into JDK-8300527
828f3513: Fix merge error
83c65c16: Add missing includes
From duke at openjdk.org Tue Jan 24 16:05:08 2023
From: duke at openjdk.org (duke)
Date: Tue, 24 Jan 2023 16:05:08 GMT
Subject: git: openjdk/lilliput: created branch pr/67 based on the branch pr/66
containing 1 unique commit
Message-ID: <9d00a1f0-deb1-45d1-937d-31ae0ddb623e@openjdk.org>
The following commits are unique to the pr/67 branch:
========================================================
235bf525: X8300888: [Lilliput] Remaining missing parts in the SA
From shade at openjdk.org Tue Jan 24 17:02:53 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 24 Jan 2023 17:02:53 GMT
Subject: [master] RFR: 8300527: [Lilliput] Simplify and optimize loading of
Klass*
In-Reply-To: <jO08HB3bSFI6XChuVluh3PNghUYJpZs-N0_wyAZVGcg=.34f90e2f-3d35-4442-b8af-14a23bf7c094@github.com>
References: <jO08HB3bSFI6XChuVluh3PNghUYJpZs-N0_wyAZVGcg=.34f90e2f-3d35-4442-b8af-14a23bf7c094@github.com>
Message-ID: <2XrTnoHilsSKyWulrkPErspdv0aSBf0Dhpu9z5vgYvA=.56c7f308-4bb1-431b-92c3-c036ef85edb5@github.com>
On Mon, 23 Jan 2023 13:34:50 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
> With the new fast-locking, we can greatly simplify the loading of the Klass* from an object. We no longer have to call into the runtime to ensure that the header is changed under our feet (by installing the INFLATION marker). Instead, we can do a simple check for the object being monitor-locked, and safely load the displaced header, if that is the case.
Minor nits.
src/hotspot/share/c1/c1_LIR.cpp line 891:
> 889: do_input(opLoadKlass->_obj);
> 890: do_output(opLoadKlass->_result);
> 891: do_stub(opLoadKlass->stub());
Minor: why not leave `_stub`?
src/hotspot/share/runtime/synchronizer.cpp line 798:
> 796: static SharedGlobals GVars;
> 797:
> 798: static markWord read_stable_mark(oop obj) {
Do you still need this method, or? If you still need it, let's not put it outside the `ObjectSynchronizer` "namespace".
-------------
Marked as reviewed by shade (Committer).
PR: https://git.openjdk.org/lilliput/pull/66
From shade at openjdk.org Tue Jan 24 17:10:45 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 24 Jan 2023 17:10:45 GMT
Subject: [master] RFR: 8300888: [Lilliput] Remaining missing parts in the
SA
In-Reply-To: <vMljM9ZzG-3_6UESbP5e-RQMz1UUvMXItVYQvOql4VM=.684d1166-223a-42f6-b86e-2a1bc0700984@github.com>
References: <vMljM9ZzG-3_6UESbP5e-RQMz1UUvMXItVYQvOql4VM=.684d1166-223a-42f6-b86e-2a1bc0700984@github.com>
Message-ID: <tp2ZN4BjdW3nOodj7kYt-4Ngp7XL7zKnFZsyfa40wTQ=.6d65b15a-6fc5-4014-84d2-edea433ffe2d@github.com>
On Tue, 24 Jan 2023 15:13:29 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
> With fast-locking, it is now possible to provide a safe implementation of load-Klass* (following the same principle as in the runtime: load mark, check for monitor, possibly load real mark from monitor, decode Klass* from mark). This change also fixes array layout calculation and un-blocks a number of SA tests that did not work before.
Minor nits.
src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/DebuggerBase.java line 401:
> 399: // On 64 bit systems, the compressed Klass* is currently read from the mark
> 400: // word. We need to load the whole mark, and shift the upper parts.
> 401: long value = readCInteger(address, getJLongSize(), true);
`machDesc.getAddressSize()` might be a better fit here instead of `getJLongSize()`?
-------------
Marked as reviewed by shade (Committer).
PR: https://git.openjdk.org/lilliput/pull/67
From duke at openjdk.org Tue Jan 24 17:44:26 2023
From: duke at openjdk.org (duke)
Date: Tue, 24 Jan 2023 17:44:26 GMT
Subject: git: openjdk/lilliput: pr/66: Use _stub instead of stub()
Message-ID: <587296f8-7e98-446c-9219-106b6cc45179@openjdk.org>
Changeset: fcff6601
Author: Roman Kennke <rkennke at amazon.de>
Date: 2023-01-24 17:36:34 +0000
URL: https://git.openjdk.org/lilliput/commit/fcff6601f2361b5661e81e3c84e651c0af02c0ca
Use _stub instead of stub()
! src/hotspot/share/c1/c1_LIR.cpp
From rkennke at openjdk.org Tue Jan 24 17:45:45 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 24 Jan 2023 17:45:45 GMT
Subject: [master] RFR: 8300527: [Lilliput] Simplify and optimize loading of
Klass* [v2]
In-Reply-To: <jO08HB3bSFI6XChuVluh3PNghUYJpZs-N0_wyAZVGcg=.34f90e2f-3d35-4442-b8af-14a23bf7c094@github.com>
References: <jO08HB3bSFI6XChuVluh3PNghUYJpZs-N0_wyAZVGcg=.34f90e2f-3d35-4442-b8af-14a23bf7c094@github.com>
Message-ID: <8qPLdtZXiZ1qFFUK-nrp1Y-v6Ad2dcELFoBwZAMEnTs=.52cbd02b-abfb-4bb5-b0ab-7f70e9e95b91@github.com>
> With the new fast-locking, we can greatly simplify the loading of the Klass* from an object. We no longer have to call into the runtime to ensure that the header is changed under our feet (by installing the INFLATION marker). Instead, we can do a simple check for the object being monitor-locked, and safely load the displaced header, if that is the case.
Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
Use _stub instead of stub()
-------------
Changes:
- all: https://git.openjdk.org/lilliput/pull/66/files
- new: https://git.openjdk.org/lilliput/pull/66/files/83c65c16..fcff6601
Webrevs:
- full: https://webrevs.openjdk.org/?repo=lilliput&pr=66&range=01
- incr: https://webrevs.openjdk.org/?repo=lilliput&pr=66&range=00-01
Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
Patch: https://git.openjdk.org/lilliput/pull/66.diff
Fetch: git fetch https://git.openjdk.org/lilliput pull/66/head:pull/66
PR: https://git.openjdk.org/lilliput/pull/66
From rkennke at openjdk.org Tue Jan 24 17:45:46 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 24 Jan 2023 17:45:46 GMT
Subject: [master] RFR: 8300527: [Lilliput] Simplify and optimize loading of
Klass* [v2]
In-Reply-To: <2XrTnoHilsSKyWulrkPErspdv0aSBf0Dhpu9z5vgYvA=.56c7f308-4bb1-431b-92c3-c036ef85edb5@github.com>
References: <jO08HB3bSFI6XChuVluh3PNghUYJpZs-N0_wyAZVGcg=.34f90e2f-3d35-4442-b8af-14a23bf7c094@github.com>
<2XrTnoHilsSKyWulrkPErspdv0aSBf0Dhpu9z5vgYvA=.56c7f308-4bb1-431b-92c3-c036ef85edb5@github.com>
Message-ID: <a43hpjlUfL2x1Ev5Ryw1oII5Nw9KHw8mj5pCjnKoG0c=.e80f6317-ef0e-4602-b112-12035d82578b@github.com>
On Tue, 24 Jan 2023 16:56:17 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:
>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>>
>> Use _stub instead of stub()
>
> src/hotspot/share/c1/c1_LIR.cpp line 891:
>
>> 889: do_input(opLoadKlass->_obj);
>> 890: do_output(opLoadKlass->_result);
>> 891: do_stub(opLoadKlass->stub());
>
> Minor: why not leave `_stub`?
Right. I changed that back.
> src/hotspot/share/runtime/synchronizer.cpp line 798:
>
>> 796: static SharedGlobals GVars;
>> 797:
>> 798: static markWord read_stable_mark(oop obj) {
>
> Do you still need this method, or? If you still need it, let's not put it outside the `ObjectSynchronizer` "namespace".
Originally, read_stable_mark() is static in upstream. A while back I put it into the ObjectSynchronizer namespace to reuse it in Shenandoah, but that is no longer needed, so I reverted the scope back to compilation-unit-private. Yes, we will still need it, when we make Lilliput switchable, but I'd keep it compilation-unit-private for the reasons mentioned.
-------------
PR: https://git.openjdk.org/lilliput/pull/66
From shade at openjdk.org Tue Jan 24 17:52:39 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 24 Jan 2023 17:52:39 GMT
Subject: [master] RFR: 8300527: [Lilliput] Simplify and optimize loading of
Klass* [v2]
In-Reply-To: <a43hpjlUfL2x1Ev5Ryw1oII5Nw9KHw8mj5pCjnKoG0c=.e80f6317-ef0e-4602-b112-12035d82578b@github.com>
References: <jO08HB3bSFI6XChuVluh3PNghUYJpZs-N0_wyAZVGcg=.34f90e2f-3d35-4442-b8af-14a23bf7c094@github.com>
<2XrTnoHilsSKyWulrkPErspdv0aSBf0Dhpu9z5vgYvA=.56c7f308-4bb1-431b-92c3-c036ef85edb5@github.com>
<a43hpjlUfL2x1Ev5Ryw1oII5Nw9KHw8mj5pCjnKoG0c=.e80f6317-ef0e-4602-b112-12035d82578b@github.com>
Message-ID: <4FWDLh1ttW_16ew9KxDquIp8mHp2yzBZVAMxKBM_ngM=.286ff093-eb75-4992-84f2-f70ea24cffbe@github.com>
On Tue, 24 Jan 2023 17:42:11 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
>> src/hotspot/share/runtime/synchronizer.cpp line 798:
>>
>>> 796: static SharedGlobals GVars;
>>> 797:
>>> 798: static markWord read_stable_mark(oop obj) {
>>
>> Do you still need this method, or? If you still need it, let's not put it outside the `ObjectSynchronizer` "namespace".
>
> Originally, read_stable_mark() is static in upstream. A while back I put it into the ObjectSynchronizer namespace to reuse it in Shenandoah, but that is no longer needed, so I reverted the scope back to compilation-unit-private. Yes, we will still need it, when we make Lilliput switchable, but I'd keep it compilation-unit-private for the reasons mentioned.
All right then!
-------------
PR: https://git.openjdk.org/lilliput/pull/66
From duke at openjdk.org Tue Jan 24 18:10:50 2023
From: duke at openjdk.org (duke)
Date: Tue, 24 Jan 2023 18:10:50 GMT
Subject: git: openjdk/lilliput: pr/67: Use address size instead of long size to
read the mark word
Message-ID: <9109bdd4-02e2-4135-8ef5-4a4679fcc03f@openjdk.org>
Changeset: 5acc5e68
Author: Roman Kennke <rkennke at amazon.de>
Date: 2023-01-24 18:06:08 +0000
URL: https://git.openjdk.org/lilliput/commit/5acc5e68a261b3c16cde6e82dccfebc8cc0c48d3
Use address size instead of long size to read the mark word
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/DebuggerBase.java
From rkennke at openjdk.org Tue Jan 24 18:12:14 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 24 Jan 2023 18:12:14 GMT
Subject: [master] RFR: 8300888: [Lilliput] Remaining missing parts in the
SA [v2]
In-Reply-To: <vMljM9ZzG-3_6UESbP5e-RQMz1UUvMXItVYQvOql4VM=.684d1166-223a-42f6-b86e-2a1bc0700984@github.com>
References: <vMljM9ZzG-3_6UESbP5e-RQMz1UUvMXItVYQvOql4VM=.684d1166-223a-42f6-b86e-2a1bc0700984@github.com>
Message-ID: <jBMFkMqyUhz0QkqaoCqeURrtdJZ6z6U9y9unPwXt920=.0a5973ad-1888-4e6b-814e-b0cdbf09f47f@github.com>
> With fast-locking, it is now possible to provide a safe implementation of load-Klass* (following the same principle as in the runtime: load mark, check for monitor, possibly load real mark from monitor, decode Klass* from mark). This change also fixes array layout calculation and un-blocks a number of SA tests that did not work before.
Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
Use address size instead of long size to read the mark word
-------------
Changes:
- all: https://git.openjdk.org/lilliput/pull/67/files
- new: https://git.openjdk.org/lilliput/pull/67/files/235bf525..5acc5e68
Webrevs:
- full: https://webrevs.openjdk.org/?repo=lilliput&pr=67&range=01
- incr: https://webrevs.openjdk.org/?repo=lilliput&pr=67&range=00-01
Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
Patch: https://git.openjdk.org/lilliput/pull/67.diff
Fetch: git fetch https://git.openjdk.org/lilliput pull/67/head:pull/67
PR: https://git.openjdk.org/lilliput/pull/67
From rkennke at openjdk.org Tue Jan 24 18:12:17 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 24 Jan 2023 18:12:17 GMT
Subject: [master] RFR: 8300888: [Lilliput] Remaining missing parts in the
SA [v2]
In-Reply-To: <tp2ZN4BjdW3nOodj7kYt-4Ngp7XL7zKnFZsyfa40wTQ=.6d65b15a-6fc5-4014-84d2-edea433ffe2d@github.com>
References: <vMljM9ZzG-3_6UESbP5e-RQMz1UUvMXItVYQvOql4VM=.684d1166-223a-42f6-b86e-2a1bc0700984@github.com>
<tp2ZN4BjdW3nOodj7kYt-4Ngp7XL7zKnFZsyfa40wTQ=.6d65b15a-6fc5-4014-84d2-edea433ffe2d@github.com>
Message-ID: <0o6s--m1_SeIxXMiCOdxIWeQPn-l82W0ZjVIzvoYwYA=.c7cc4ec5-9b06-4b48-845b-6bca20efa664@github.com>
On Tue, 24 Jan 2023 17:06:36 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:
>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>>
>> Use address size instead of long size to read the mark word
>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/DebuggerBase.java line 401:
>
>> 399: // On 64 bit systems, the compressed Klass* is currently read from the mark
>> 400: // word. We need to load the whole mark, and shift the upper parts.
>> 401: long value = readCInteger(address, getJLongSize(), true);
>
> `machDesc.getAddressSize()` might be a better fit here instead of `getJLongSize()`?
Right. Both is not beautiful, but address size seems less ugly. At some point in the future all of this will go away, anyway.
-------------
PR: https://git.openjdk.org/lilliput/pull/67
From shade at openjdk.org Tue Jan 24 18:27:07 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 24 Jan 2023 18:27:07 GMT
Subject: [master] RFR: 8300888: [Lilliput] Remaining missing parts in the
SA [v2]
In-Reply-To: <jBMFkMqyUhz0QkqaoCqeURrtdJZ6z6U9y9unPwXt920=.0a5973ad-1888-4e6b-814e-b0cdbf09f47f@github.com>
References: <vMljM9ZzG-3_6UESbP5e-RQMz1UUvMXItVYQvOql4VM=.684d1166-223a-42f6-b86e-2a1bc0700984@github.com>
<jBMFkMqyUhz0QkqaoCqeURrtdJZ6z6U9y9unPwXt920=.0a5973ad-1888-4e6b-814e-b0cdbf09f47f@github.com>
Message-ID: <PGHDZwdgHGpgJmtkcHMtlQJT1QCjW_5TKcM0hzG2dzg=.066b67d0-f0a6-4207-ac13-1850cb1286be@github.com>
On Tue, 24 Jan 2023 18:12:14 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
>> With fast-locking, it is now possible to provide a safe implementation of load-Klass* (following the same principle as in the runtime: load mark, check for monitor, possibly load real mark from monitor, decode Klass* from mark). This change also fixes array layout calculation and un-blocks a number of SA tests that did not work before.
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>
> Use address size instead of long size to read the mark word
Marked as reviewed by shade (Committer).
-------------
PR: https://git.openjdk.org/lilliput/pull/67
From shade at openjdk.org Tue Jan 24 18:27:11 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 24 Jan 2023 18:27:11 GMT
Subject: [master] RFR: 8300888: [Lilliput] Remaining missing parts in the
SA [v2]
In-Reply-To: <0o6s--m1_SeIxXMiCOdxIWeQPn-l82W0ZjVIzvoYwYA=.c7cc4ec5-9b06-4b48-845b-6bca20efa664@github.com>
References: <vMljM9ZzG-3_6UESbP5e-RQMz1UUvMXItVYQvOql4VM=.684d1166-223a-42f6-b86e-2a1bc0700984@github.com>
<tp2ZN4BjdW3nOodj7kYt-4Ngp7XL7zKnFZsyfa40wTQ=.6d65b15a-6fc5-4014-84d2-edea433ffe2d@github.com>
<0o6s--m1_SeIxXMiCOdxIWeQPn-l82W0ZjVIzvoYwYA=.c7cc4ec5-9b06-4b48-845b-6bca20efa664@github.com>
Message-ID: <x3c7M3lIwA5ik1E9HCdesdM47uXgtzQbFlb_xpcl_MU=.14aefd17-7687-4ae1-89a9-70a9d980122a@github.com>
On Tue, 24 Jan 2023 18:07:02 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/DebuggerBase.java line 401:
>>
>>> 399: // On 64 bit systems, the compressed Klass* is currently read from the mark
>>> 400: // word. We need to load the whole mark, and shift the upper parts.
>>> 401: long value = readCInteger(address, getJLongSize(), true);
>>
>> `machDesc.getAddressSize()` might be a better fit here instead of `getJLongSize()`?
>
> Right. Both is not beautiful, but address size seems less ugly. At some point in the future all of this will go away, anyway.
`getAddressSize` does not over-read accidentally on 32-bit :)
-------------
PR: https://git.openjdk.org/lilliput/pull/67
From rkennke at openjdk.org Fri Jan 27 18:26:05 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 27 Jan 2023 18:26:05 GMT
Subject: [master] Integrated: 8300527: [Lilliput] Simplify and optimize loading
of Klass*
In-Reply-To: <jO08HB3bSFI6XChuVluh3PNghUYJpZs-N0_wyAZVGcg=.34f90e2f-3d35-4442-b8af-14a23bf7c094@github.com>
References: <jO08HB3bSFI6XChuVluh3PNghUYJpZs-N0_wyAZVGcg=.34f90e2f-3d35-4442-b8af-14a23bf7c094@github.com>
Message-ID: <JWvKn-F5TprN3IfMKJKAX6wnphMXr8E2Mx4JAaUByZQ=.6d9ec181-e75e-4245-a01e-9f1af6eeb46e@github.com>
On Mon, 23 Jan 2023 13:34:50 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
> With the new fast-locking, we can greatly simplify the loading of the Klass* from an object. We no longer have to call into the runtime to ensure that the header is changed under our feet (by installing the INFLATION marker). Instead, we can do a simple check for the object being monitor-locked, and safely load the displaced header, if that is the case.
This pull request has now been integrated.
Changeset: bf6d4f3b
Author: Roman Kennke <rkennke at openjdk.org>
URL: https://git.openjdk.org/lilliput/commit/bf6d4f3b7111bc75dad351546c4120f7dbc128f9
Stats: 389 lines in 27 files changed: 76 ins; 279 del; 34 mod
8300527: [Lilliput] Simplify and optimize loading of Klass*
Reviewed-by: shade
-------------
PR: https://git.openjdk.org/lilliput/pull/66
From rkennke at openjdk.org Fri Jan 27 18:30:58 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 27 Jan 2023 18:30:58 GMT
Subject: [master] Integrated: 8300888: [Lilliput] Remaining missing parts in
the SA
In-Reply-To: <vMljM9ZzG-3_6UESbP5e-RQMz1UUvMXItVYQvOql4VM=.684d1166-223a-42f6-b86e-2a1bc0700984@github.com>
References: <vMljM9ZzG-3_6UESbP5e-RQMz1UUvMXItVYQvOql4VM=.684d1166-223a-42f6-b86e-2a1bc0700984@github.com>
Message-ID: <zCqiTf4FbrS1a57TUSYanuk_GTtxdTBI7huDmglXQxo=.65ac1af3-3b51-4ae5-bcfe-a985959e2dc4@github.com>
On Tue, 24 Jan 2023 15:13:29 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
> With fast-locking, it is now possible to provide a safe implementation of load-Klass* (following the same principle as in the runtime: load mark, check for monitor, possibly load real mark from monitor, decode Klass* from mark). This change also fixes array layout calculation and un-blocks a number of SA tests that did not work before.
This pull request has now been integrated.
Changeset: 10e00d3d
Author: Roman Kennke <rkennke at openjdk.org>
URL: https://git.openjdk.org/lilliput/commit/10e00d3dfb9c608644d6550aa8b4decdd5076633
Stats: 129 lines in 7 files changed: 39 ins; 77 del; 13 mod
8300888: [Lilliput] Remaining missing parts in the SA
Reviewed-by: shade
-------------
PR: https://git.openjdk.org/lilliput/pull/67
From rkennke at openjdk.org Tue Jan 31 14:02:22 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 31 Jan 2023 14:02:22 GMT
Subject: [master] RFR: 8301545: [Lilliput] Fix aarch64 interpreter
load_nklass()
Message-ID: <ayM7VUwvD9EFvb_vzw8OmWWxAT6debAvrPKXuZzk5qI=.b2cd0210-8f6f-4162-90ec-f9163fd13ef0@github.com>
In #66 I made a mistake in a last-minute change and GHA hasn't caught it: I got a condition wrong. Let's fix it.
Testing:
- [x] tier1
- [ ] tier2
-------------
Commit messages:
- 8301545: [Lilliput] Fix aarch64 interpreter load_nklass()
Changes: https://git.openjdk.org/lilliput/pull/68/files
Webrev: https://webrevs.openjdk.org/?repo=lilliput&pr=68&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8301545
Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
Patch: https://git.openjdk.org/lilliput/pull/68.diff
Fetch: git fetch https://git.openjdk.org/lilliput pull/68/head:pull/68
PR: https://git.openjdk.org/lilliput/pull/68
From shade at openjdk.org Tue Jan 31 14:11:41 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 31 Jan 2023 14:11:41 GMT
Subject: [master] RFR: 8301545: [Lilliput] Fix aarch64 interpreter
load_nklass()
In-Reply-To: <ayM7VUwvD9EFvb_vzw8OmWWxAT6debAvrPKXuZzk5qI=.b2cd0210-8f6f-4162-90ec-f9163fd13ef0@github.com>
References: <ayM7VUwvD9EFvb_vzw8OmWWxAT6debAvrPKXuZzk5qI=.b2cd0210-8f6f-4162-90ec-f9163fd13ef0@github.com>
Message-ID: <e2_Ahxp_qosB9vppJYJoDedKQIBs4mnN2RbPTLbCEco=.cf08e66c-4b37-4c9f-b7dc-d2f04deec6e7@github.com>
On Tue, 31 Jan 2023 13:54:52 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
> In #66 I made a mistake in a last-minute change and GHA hasn't caught it: I got a condition wrong. Let's fix it.
>
> Testing:
> - [x] tier1
> - [ ] tier2
I remember looking at this during the original review, and I managed to convince myself `NE` is correct. But looking at it again, I think I flipped the meaning of ZF in my head.
Suppose the "monitor" bit is set in the mark. Then `tst` effectively ands and gets non-zero result, which sets internal ALU flag Z=0. Then `NE` checks for `Z=0` and branches to `fast`. This is not what we want, we instead want to go `EQ`, check for `Z=1` and branch to `fast` then.
-------------
Marked as reviewed by shade (Committer).
PR: https://git.openjdk.org/lilliput/pull/68
From rkennke at openjdk.org Tue Jan 31 14:23:34 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 31 Jan 2023 14:23:34 GMT
Subject: [master] RFR: 8301514: [Lilliput] Enable fast-locking with ZGC
Message-ID: <acUdHnGOIE7n-Xage_kCQAn3fA-ic5znQ5kdMOy0obY=.c2bfde21-32a5-4027-86d3-d4b363859642@github.com>
Previously, we disabled stack-locking in ZGC because it couldn't easily deal with racy header. Now that we have fast-locking (in place of stack-locking), we can re-enable it.
Testing:
- [x] tier1
- [ ] tier2
- [ ] hotspot_gc
-------------
Commit messages:
- 8301514: [Lilliput] Enable fast-locking with ZGC
Changes: https://git.openjdk.org/lilliput/pull/69/files
Webrev: https://webrevs.openjdk.org/?repo=lilliput&pr=69&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8301514
Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod
Patch: https://git.openjdk.org/lilliput/pull/69.diff
Fetch: git fetch https://git.openjdk.org/lilliput pull/69/head:pull/69
PR: https://git.openjdk.org/lilliput/pull/69
From shade at openjdk.org Tue Jan 31 14:23:35 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 31 Jan 2023 14:23:35 GMT
Subject: [master] RFR: 8301514: [Lilliput] Enable fast-locking with ZGC
In-Reply-To: <acUdHnGOIE7n-Xage_kCQAn3fA-ic5znQ5kdMOy0obY=.c2bfde21-32a5-4027-86d3-d4b363859642@github.com>
References: <acUdHnGOIE7n-Xage_kCQAn3fA-ic5znQ5kdMOy0obY=.c2bfde21-32a5-4027-86d3-d4b363859642@github.com>
Message-ID: <c5pfqRKGbBCMFjUMPyzPjCI4_E9v4Vm3w60RD0rQdl4=.b8ffc740-ae2a-42bd-9cac-07edd9c91884@github.com>
On Tue, 31 Jan 2023 14:16:59 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
> Previously, we disabled stack-locking in ZGC because it couldn't easily deal with racy header. Now that we have fast-locking (in place of stack-locking), we can re-enable it.
>
> Testing:
> - [x] tier1
> - [ ] tier2
> - [ ] hotspot_gc
Marked as reviewed by shade (Committer).
-------------
PR: https://git.openjdk.org/lilliput/pull/69
From duke at openjdk.org Tue Jan 31 14:27:30 2023
From: duke at openjdk.org (duke)
Date: Tue, 31 Jan 2023 14:27:30 GMT
Subject: git: openjdk/lilliput: created branch pr/69 based on the branch pr/68
containing 1 unique commit
Message-ID: <79480888-3de9-40a4-9a74-23bb50c25faa@openjdk.org>
The following commits are unique to the pr/69 branch:
========================================================
ac5305af: 8301514: [Lilliput] Enable fast-locking with ZGC
From rkennke at openjdk.org Tue Jan 31 19:41:25 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 31 Jan 2023 19:41:25 GMT
Subject: [master] RFR: 8301545: [Lilliput] Fix aarch64 interpreter
load_nklass()
In-Reply-To: <ayM7VUwvD9EFvb_vzw8OmWWxAT6debAvrPKXuZzk5qI=.b2cd0210-8f6f-4162-90ec-f9163fd13ef0@github.com>
References: <ayM7VUwvD9EFvb_vzw8OmWWxAT6debAvrPKXuZzk5qI=.b2cd0210-8f6f-4162-90ec-f9163fd13ef0@github.com>
Message-ID: <D1Ro6bynor42q--opxhQdJKam3T_ghfkVDsQ_sBGE_0=.b9ce171a-e4e9-473a-8a24-2e615907858d@github.com>
On Tue, 31 Jan 2023 13:54:52 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
> In #66 I made a mistake in a last-minute change and GHA hasn't caught it: I got a condition wrong. Let's fix it.
>
> Testing:
> - [x] tier1
> - [x] tier2
Thanks, Aleksey!
-------------
PR: https://git.openjdk.org/lilliput/pull/68
From rkennke at openjdk.org Tue Jan 31 19:41:25 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 31 Jan 2023 19:41:25 GMT
Subject: [master] Integrated: 8301545: [Lilliput] Fix aarch64 interpreter
load_nklass()
In-Reply-To: <ayM7VUwvD9EFvb_vzw8OmWWxAT6debAvrPKXuZzk5qI=.b2cd0210-8f6f-4162-90ec-f9163fd13ef0@github.com>
References: <ayM7VUwvD9EFvb_vzw8OmWWxAT6debAvrPKXuZzk5qI=.b2cd0210-8f6f-4162-90ec-f9163fd13ef0@github.com>
Message-ID: <3wC6PmhOYYFQsHlinRY9Z4byWUgdAIC-ukz1aTdLoow=.fd32c139-1d15-439c-8c00-d51404b97953@github.com>
On Tue, 31 Jan 2023 13:54:52 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
> In #66 I made a mistake in a last-minute change and GHA hasn't caught it: I got a condition wrong. Let's fix it.
>
> Testing:
> - [x] tier1
> - [x] tier2
This pull request has now been integrated.
Changeset: 38816146
Author: Roman Kennke <rkennke at openjdk.org>
URL: https://git.openjdk.org/lilliput/commit/388161467dc9fc99616161d7643600d5f523b554
Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
8301545: [Lilliput] Fix aarch64 interpreter load_nklass()
Reviewed-by: shade
-------------
PR: https://git.openjdk.org/lilliput/pull/68
From rkennke at openjdk.org Tue Jan 31 19:48:26 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 31 Jan 2023 19:48:26 GMT
Subject: [master] RFR: 8301514: [Lilliput] Enable fast-locking with ZGC
In-Reply-To: <acUdHnGOIE7n-Xage_kCQAn3fA-ic5znQ5kdMOy0obY=.c2bfde21-32a5-4027-86d3-d4b363859642@github.com>
References: <acUdHnGOIE7n-Xage_kCQAn3fA-ic5znQ5kdMOy0obY=.c2bfde21-32a5-4027-86d3-d4b363859642@github.com>
Message-ID: <ltq8dK2-oAT71dik43dFxNMZp86xVwaAzucUUU99SqE=.cd4a83b8-8e64-4183-b6c9-2386a7a59fa5@github.com>
On Tue, 31 Jan 2023 14:16:59 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
> Previously, we disabled stack-locking in ZGC because it couldn't easily deal with racy header. Now that we have fast-locking (in place of stack-locking), we can re-enable it.
>
> Testing:
> - [x] tier1
> - [x] tier2
> - [x] hotspot_gc
Thanks, Aleksey!
-------------
PR: https://git.openjdk.org/lilliput/pull/69
From rkennke at openjdk.org Tue Jan 31 19:48:26 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 31 Jan 2023 19:48:26 GMT
Subject: [master] Integrated: 8301514: [Lilliput] Enable fast-locking with ZGC
In-Reply-To: <acUdHnGOIE7n-Xage_kCQAn3fA-ic5znQ5kdMOy0obY=.c2bfde21-32a5-4027-86d3-d4b363859642@github.com>
References: <acUdHnGOIE7n-Xage_kCQAn3fA-ic5znQ5kdMOy0obY=.c2bfde21-32a5-4027-86d3-d4b363859642@github.com>
Message-ID: <sGrXuMlysIc3xRL6HZdDqbd1vLv5Hep5DmzagpiiHIs=.e362278e-b003-4bd0-ac4a-9db8c2bcdfde@github.com>
On Tue, 31 Jan 2023 14:16:59 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
> Previously, we disabled stack-locking in ZGC because it couldn't easily deal with racy header. Now that we have fast-locking (in place of stack-locking), we can re-enable it.
>
> Testing:
> - [x] tier1
> - [x] tier2
> - [x] hotspot_gc
This pull request has now been integrated.
Changeset: f9d0f393
Author: Roman Kennke <rkennke at openjdk.org>
URL: https://git.openjdk.org/lilliput/commit/f9d0f3933f55ec4ee503d651829d9e5e7e8f0b9c
Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod
8301514: [Lilliput] Enable fast-locking with ZGC
Reviewed-by: shade
-------------
PR: https://git.openjdk.org/lilliput/pull/69