From rkennke at openjdk.org  Thu Apr  4 12:06:15 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 4 Apr 2024 12:06:15 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: Merge jdk17u:jdk-17.0.11+7 [v2]
In-Reply-To: <GhtjLl5MeaVtG6DqmP_W8t2G_ttGaMwYxEuakWhLPgA=.869840ba-05e2-46e8-82cb-d98636bd2d8e@github.com>
References: <GhtjLl5MeaVtG6DqmP_W8t2G_ttGaMwYxEuakWhLPgA=.869840ba-05e2-46e8-82cb-d98636bd2d8e@github.com>
Message-ID: <eGWc8mpXZdtExfEbiKlp_KPukOvNnJaqR5HPKcajc6w=.5e4cc7ea-339b-4570-a54c-9677b05113b3@github.com>

> Let's merge the tag jdk-17.0.11+7. Merge has been clean.

Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 67 commits:

 - Merge tag 'jdk-17.0.11+7' into merge-jdk-17.0.11+7
   
   Added tag jdk-17.0.11+7 for changeset 5fb5ba651db3
 - 8321135: [Lilliput/JDK17] Fix repo permissions
   
   Reviewed-by: shade
 - 8320666: [Lilliput/JDK17] Add arrayOopDesc::base_offset() gtest
   
   Reviewed-by: shade
 - 8319524: [Lilliput] Only warn when compact headers are explicitly enabled
   
   Reviewed-by: shade
   Backport-of: 3f73f014097262455cc42a71c32af374b77b6efd
 - Merge
 - 8319135: [Lilliput] Fix objArrayOop gtest
   
   Reviewed-by: shade
   Backport-of: fc9020fbf193b1c6d2b2fb5d80192c3082dbcf2e
 - 8319724: [Lilliput] ParallelGC: Forwarded objects found during heap inspection
   
   Backport-of: 0568386e062474b1fc31e2e7106db0079ded7d76
 - 8318172: [Lilliput/JDK17] Disable Lilliput in TestZGCWithCDS
   
   Reviewed-by: shade
 - 8317957: [Lilliput/JDK17] Make C2 LoadNKlassCompactHeader more robust
   
   Reviewed-by: shade
 - Merge
 - ... and 57 more: https://git.openjdk.org/lilliput-jdk17u/compare/5fb5ba65...b82fdd0c

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

Changes: https://git.openjdk.org/lilliput-jdk17u/pull/68/files
  Webrev: https://webrevs.openjdk.org/?repo=lilliput-jdk17u&pr=68&range=01
  Stats: 7015 lines in 210 files changed: 5025 ins; 1025 del; 965 mod
  Patch: https://git.openjdk.org/lilliput-jdk17u/pull/68.diff
  Fetch: git fetch https://git.openjdk.org/lilliput-jdk17u.git pull/68/head:pull/68

PR: https://git.openjdk.org/lilliput-jdk17u/pull/68

From rkennke at openjdk.org  Thu Apr  4 12:06:16 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 4 Apr 2024 12:06:16 GMT
Subject: [lilliput-jdk17u:lilliput] Integrated: Merge jdk17u:jdk-17.0.11+7
In-Reply-To: <GhtjLl5MeaVtG6DqmP_W8t2G_ttGaMwYxEuakWhLPgA=.869840ba-05e2-46e8-82cb-d98636bd2d8e@github.com>
References: <GhtjLl5MeaVtG6DqmP_W8t2G_ttGaMwYxEuakWhLPgA=.869840ba-05e2-46e8-82cb-d98636bd2d8e@github.com>
Message-ID: <ge2WlOr8CZebbomlPrmddKJNOLJLKiDHF013tO1ao00=.04da2f32-8a7a-47db-9274-d0af2adbc8dc@github.com>

On Wed, 27 Mar 2024 14:42:19 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Let's merge the tag jdk-17.0.11+7. Merge has been clean.

This pull request has now been integrated.

Changeset: bf1e7ec7
Author:    Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.org/lilliput-jdk17u/commit/bf1e7ec7d3dead5a921d0300075de6ccf5032e0e
Stats:     46167 lines in 1078 files changed: 27851 ins; 8011 del; 10305 mod

Merge

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

PR: https://git.openjdk.org/lilliput-jdk17u/pull/68

From rkennke at openjdk.org  Thu Apr  4 12:54:34 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 4 Apr 2024 12:54:34 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8316179: Use consistent naming for
 lightweight locking in MacroAssembler
Message-ID: <R8jxVS_XyeGbqONZoqQx7vdd4MRERJAUEBRpLF8dpNA=.489b2840-e1be-4319-82fd-0cef1df059f6@github.com>

Backports https://github.com/openjdk/jdk/commit/639ba13c4b0ada1c2ae0a46e99ed707c219b3e53 to lilliput-jdk17u. Backport unclean, but mostly context diffs.

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

Commit messages:
 - Backport 639ba13c4b0ada1c2ae0a46e99ed707c219b3e53

Changes: https://git.openjdk.org/lilliput-jdk17u/pull/69/files
  Webrev: https://webrevs.openjdk.org/?repo=lilliput-jdk17u&pr=69&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8316179
  Stats: 30 lines in 13 files changed: 0 ins; 0 del; 30 mod
  Patch: https://git.openjdk.org/lilliput-jdk17u/pull/69.diff
  Fetch: git fetch https://git.openjdk.org/lilliput-jdk17u.git pull/69/head:pull/69

PR: https://git.openjdk.org/lilliput-jdk17u/pull/69

From shade at openjdk.org  Thu Apr  4 13:01:19 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 4 Apr 2024 13:01:19 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8316179: Use consistent naming for
 lightweight locking in MacroAssembler
In-Reply-To: <R8jxVS_XyeGbqONZoqQx7vdd4MRERJAUEBRpLF8dpNA=.489b2840-e1be-4319-82fd-0cef1df059f6@github.com>
References: <R8jxVS_XyeGbqONZoqQx7vdd4MRERJAUEBRpLF8dpNA=.489b2840-e1be-4319-82fd-0cef1df059f6@github.com>
Message-ID: <PenS5Pb2r4jAP9MP1sQ7EXnBt5Rum5hNmr19h-ZIKts=.91743506-5bfb-4c87-966f-706eb928e61b@github.com>

On Thu, 4 Apr 2024 12:48:34 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Backports https://github.com/openjdk/jdk/commit/639ba13c4b0ada1c2ae0a46e99ed707c219b3e53 to lilliput-jdk17u. Backport unclean, but mostly context diffs.

Existing hunks look good. For the record, what's the reason for skipping ARM32, PPC64, RISC-V hunks?

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

PR Review: https://git.openjdk.org/lilliput-jdk17u/pull/69#pullrequestreview-1979816527

From rkennke at openjdk.org  Thu Apr  4 13:42:21 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 4 Apr 2024 13:42:21 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8316179: Use consistent naming for
 lightweight locking in MacroAssembler
In-Reply-To: <R8jxVS_XyeGbqONZoqQx7vdd4MRERJAUEBRpLF8dpNA=.489b2840-e1be-4319-82fd-0cef1df059f6@github.com>
References: <R8jxVS_XyeGbqONZoqQx7vdd4MRERJAUEBRpLF8dpNA=.489b2840-e1be-4319-82fd-0cef1df059f6@github.com>
Message-ID: <y1xkAPpD4Ru3E5FO0iuIrGsG8Ob4IuM-w9DoWSFpXSM=.86b27c0d-c6d5-4737-8718-989eb76c0b27@github.com>

On Thu, 4 Apr 2024 12:48:34 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Backports https://github.com/openjdk/jdk/commit/639ba13c4b0ada1c2ae0a46e99ed707c219b3e53 to lilliput-jdk17u. Backport unclean, but mostly context diffs.

We never actually back-ported the LW locking parts of non x86/aarch64 arches.

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

PR Comment: https://git.openjdk.org/lilliput-jdk17u/pull/69#issuecomment-2037255146

From shade at openjdk.org  Thu Apr  4 13:45:30 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 4 Apr 2024 13:45:30 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8316179: Use consistent naming for
 lightweight locking in MacroAssembler
In-Reply-To: <R8jxVS_XyeGbqONZoqQx7vdd4MRERJAUEBRpLF8dpNA=.489b2840-e1be-4319-82fd-0cef1df059f6@github.com>
References: <R8jxVS_XyeGbqONZoqQx7vdd4MRERJAUEBRpLF8dpNA=.489b2840-e1be-4319-82fd-0cef1df059f6@github.com>
Message-ID: <bouroewh-5CIIsP9DrlpdqfNM9KGBHM9N5E38g0kOEs=.d1ce33e8-709f-4651-9ae4-4447cbc0342b@github.com>

On Thu, 4 Apr 2024 12:48:34 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Backports https://github.com/openjdk/jdk/commit/639ba13c4b0ada1c2ae0a46e99ed707c219b3e53 to lilliput-jdk17u. Backport unclean, but mostly context diffs.

All right then.

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

Marked as reviewed by shade (Committer).

PR Review: https://git.openjdk.org/lilliput-jdk17u/pull/69#pullrequestreview-1979947853

From rkennke at openjdk.org  Fri Apr  5 09:54:11 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 5 Apr 2024 09:54:11 GMT
Subject: [lilliput-jdk17u:lilliput] Integrated: 8316179: Use consistent naming
 for lightweight locking in MacroAssembler
In-Reply-To: <R8jxVS_XyeGbqONZoqQx7vdd4MRERJAUEBRpLF8dpNA=.489b2840-e1be-4319-82fd-0cef1df059f6@github.com>
References: <R8jxVS_XyeGbqONZoqQx7vdd4MRERJAUEBRpLF8dpNA=.489b2840-e1be-4319-82fd-0cef1df059f6@github.com>
Message-ID: <yVzI_aYWv0rTEdKNSSnexjMsndU0BA27CIdx_u5vdJY=.f5653e52-b055-49fb-9ba8-29423bf7ab73@github.com>

On Thu, 4 Apr 2024 12:48:34 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Backports https://github.com/openjdk/jdk/commit/639ba13c4b0ada1c2ae0a46e99ed707c219b3e53 to lilliput-jdk17u. Backport unclean, but mostly context diffs.

This pull request has now been integrated.

Changeset: 30596373
Author:    Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.org/lilliput-jdk17u/commit/30596373333610c2f2fb707a6bfd5378cbcff8d8
Stats:     30 lines in 13 files changed: 0 ins; 0 del; 30 mod

8316179: Use consistent naming for lightweight locking in MacroAssembler

Reviewed-by: shade
Backport-of: 639ba13c4b0ada1c2ae0a46e99ed707c219b3e53

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

PR: https://git.openjdk.org/lilliput-jdk17u/pull/69

From rkennke at openjdk.org  Fri Apr  5 10:00:34 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 5 Apr 2024 10:00:34 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8316735: Print LockStack in hs_err
 files
Message-ID: <WeJgRlBY_1Z496JFZPQX6lSk8SwyFzmBkirFKin7LJM=.fd1e9467-ddbd-4a4b-b10d-3dee36d8b484@github.com>

I'd like to backport https://github.com/openjdk/jdk/commit/20ff603108a52468dd41020cbf6c0bf669e23861, it is a nice improvement, and eases subsequent backports. The backport was not clean, there have been some context diffs and the macro structure in vmError.cpp is different.

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

Commit messages:
 - 8316735: Print LockStack in hs_err files

Changes: https://git.openjdk.org/lilliput-jdk17u/pull/70/files
  Webrev: https://webrevs.openjdk.org/?repo=lilliput-jdk17u&pr=70&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8316735
  Stats: 24 lines in 3 files changed: 23 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/lilliput-jdk17u/pull/70.diff
  Fetch: git fetch https://git.openjdk.org/lilliput-jdk17u.git pull/70/head:pull/70

PR: https://git.openjdk.org/lilliput-jdk17u/pull/70

From shade at openjdk.org  Fri Apr  5 10:07:17 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 5 Apr 2024 10:07:17 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8316735: Print LockStack in hs_err
 files
In-Reply-To: <WeJgRlBY_1Z496JFZPQX6lSk8SwyFzmBkirFKin7LJM=.fd1e9467-ddbd-4a4b-b10d-3dee36d8b484@github.com>
References: <WeJgRlBY_1Z496JFZPQX6lSk8SwyFzmBkirFKin7LJM=.fd1e9467-ddbd-4a4b-b10d-3dee36d8b484@github.com>
Message-ID: <4cLj121fXcp8ckzJVIAddkYDbHUx2kh5zcIIvFxV_DQ=.10d82517-3d1d-46fd-9ae1-9868d2007066@github.com>

On Fri, 5 Apr 2024 09:55:36 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> I'd like to backport https://github.com/openjdk/jdk/commit/20ff603108a52468dd41020cbf6c0bf669e23861, it is a nice improvement, and eases subsequent backports. The backport was not clean, there have been some context diffs and the macro structure in vmError.cpp is different.

src/hotspot/share/utilities/vmError.cpp line 953:

> 951:     if (_verbose && _thread != nullptr && _thread->is_Java_thread() && LockingMode == LM_LIGHTWEIGHT) {
> 952:       st->print_cr("Lock stack of current Java thread (top to bottom):");
> 953:       reinterpret_cast<JavaThread*>(_thread)->lock_stack().print_on(st);

I think this one is `_thread->as_Java_thread()`.

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

PR Review Comment: https://git.openjdk.org/lilliput-jdk17u/pull/70#discussion_r1553316033

From rkennke at openjdk.org  Fri Apr  5 11:43:24 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 5 Apr 2024 11:43:24 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8316735: Print LockStack in hs_err
 files [v2]
In-Reply-To: <WeJgRlBY_1Z496JFZPQX6lSk8SwyFzmBkirFKin7LJM=.fd1e9467-ddbd-4a4b-b10d-3dee36d8b484@github.com>
References: <WeJgRlBY_1Z496JFZPQX6lSk8SwyFzmBkirFKin7LJM=.fd1e9467-ddbd-4a4b-b10d-3dee36d8b484@github.com>
Message-ID: <DVTmaP6yk2To5EaYea0DFU3plsn3lDN45_mM9Ln1yzI=.f042959b-44a4-4006-9cdd-04b9ef71430a@github.com>

> I'd like to backport https://github.com/openjdk/jdk/commit/20ff603108a52468dd41020cbf6c0bf669e23861, it is a nice improvement, and eases subsequent backports. The backport was not clean, there have been some context diffs and the macro structure in vmError.cpp is different.

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Improve cast

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

Changes:
  - all: https://git.openjdk.org/lilliput-jdk17u/pull/70/files
  - new: https://git.openjdk.org/lilliput-jdk17u/pull/70/files/0697faa6..dee93c5e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=lilliput-jdk17u&pr=70&range=01
 - incr: https://webrevs.openjdk.org/?repo=lilliput-jdk17u&pr=70&range=00-01

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

PR: https://git.openjdk.org/lilliput-jdk17u/pull/70

From shade at openjdk.org  Fri Apr  5 11:50:10 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 5 Apr 2024 11:50:10 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8316735: Print LockStack in hs_err
 files [v2]
In-Reply-To: <DVTmaP6yk2To5EaYea0DFU3plsn3lDN45_mM9Ln1yzI=.f042959b-44a4-4006-9cdd-04b9ef71430a@github.com>
References: <WeJgRlBY_1Z496JFZPQX6lSk8SwyFzmBkirFKin7LJM=.fd1e9467-ddbd-4a4b-b10d-3dee36d8b484@github.com>
 <DVTmaP6yk2To5EaYea0DFU3plsn3lDN45_mM9Ln1yzI=.f042959b-44a4-4006-9cdd-04b9ef71430a@github.com>
Message-ID: <4kmiCTvBVvXOjtvjQOp8362zavUx_JYXpPJC0w1E04Q=.ed37ad3c-e9b7-4ab7-a4ca-d293ed329c2f@github.com>

On Fri, 5 Apr 2024 11:43:24 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> I'd like to backport https://github.com/openjdk/jdk/commit/20ff603108a52468dd41020cbf6c0bf669e23861, it is a nice improvement, and eases subsequent backports. The backport was not clean, there have been some context diffs and the macro structure in vmError.cpp is different.
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve cast

Marked as reviewed by shade (Committer).

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

PR Review: https://git.openjdk.org/lilliput-jdk17u/pull/70#pullrequestreview-1982950880

From rkennke at openjdk.org  Fri Apr  5 15:19:15 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 5 Apr 2024 15:19:15 GMT
Subject: [lilliput-jdk17u:lilliput] Integrated: 8316735: Print LockStack in
 hs_err files
In-Reply-To: <WeJgRlBY_1Z496JFZPQX6lSk8SwyFzmBkirFKin7LJM=.fd1e9467-ddbd-4a4b-b10d-3dee36d8b484@github.com>
References: <WeJgRlBY_1Z496JFZPQX6lSk8SwyFzmBkirFKin7LJM=.fd1e9467-ddbd-4a4b-b10d-3dee36d8b484@github.com>
Message-ID: <eyQxDHEkoA9ZatMGXRLM_QU50_msQCKDpquNZF-CBB0=.81f365b7-5426-44dd-b3da-fb5ff82eb827@github.com>

On Fri, 5 Apr 2024 09:55:36 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> I'd like to backport https://github.com/openjdk/jdk/commit/20ff603108a52468dd41020cbf6c0bf669e23861, it is a nice improvement, and eases subsequent backports. The backport was not clean, there have been some context diffs and the macro structure in vmError.cpp is different.

This pull request has now been integrated.

Changeset: 43cc86e3
Author:    Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.org/lilliput-jdk17u/commit/43cc86e3f03088b718c7674e425e86dc65d2ed8b
Stats:     24 lines in 3 files changed: 23 ins; 0 del; 1 mod

8316735: Print LockStack in hs_err files

Reviewed-by: shade
Backport-of: 20ff603108a52468dd41020cbf6c0bf669e23861

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

PR: https://git.openjdk.org/lilliput-jdk17u/pull/70

From rkennke at openjdk.org  Fri Apr  5 15:38:35 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 5 Apr 2024 15:38:35 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8316401:
 sun/tools/jhsdb/JStackStressTest.java failed with
 "InternalError: We should have found a thread that owns the anonymous lock"
Message-ID: <4Sirjm1nS4rpyDkcVkQF_9OdlXzxmnhfvLF3AOO6tEE=.7e67e31c-5204-4b48-80a2-0586915984f7@github.com>

I would like to backport this LW-locking-related bugfix to lilliput-17. Backport has been clean.

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

Commit messages:
 - 8316401: sun/tools/jhsdb/JStackStressTest.java failed with "InternalError: We should have found a thread that owns the anonymous lock"

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

PR: https://git.openjdk.org/lilliput-jdk17u/pull/71

From shade at openjdk.org  Fri Apr  5 15:38:35 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 5 Apr 2024 15:38:35 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8316401:
 sun/tools/jhsdb/JStackStressTest.java failed with
 "InternalError: We should have found a thread that owns the anonymous lock"
In-Reply-To: <4Sirjm1nS4rpyDkcVkQF_9OdlXzxmnhfvLF3AOO6tEE=.7e67e31c-5204-4b48-80a2-0586915984f7@github.com>
References: <4Sirjm1nS4rpyDkcVkQF_9OdlXzxmnhfvLF3AOO6tEE=.7e67e31c-5204-4b48-80a2-0586915984f7@github.com>
Message-ID: <eUQNlpYSKNYk7z4usZj5CUIjf0SnWaB1augY7RYLw-8=.3e22fa4d-564e-441b-ac27-829db15a1169@github.com>

On Fri, 5 Apr 2024 15:31:29 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> I would like to backport this LW-locking-related bugfix to lilliput-17. Backport has been clean.

Marked as reviewed by shade (Committer).

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

PR Review: https://git.openjdk.org/lilliput-jdk17u/pull/71#pullrequestreview-1983551724

From rkennke at openjdk.org  Mon Apr  8 08:21:31 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 8 Apr 2024 08:21:31 GMT
Subject: [lilliput-jdk17u:lilliput] Integrated: 8316401:
 sun/tools/jhsdb/JStackStressTest.java failed with
 "InternalError: We should have found a thread that owns the anonymous lock"
In-Reply-To: <4Sirjm1nS4rpyDkcVkQF_9OdlXzxmnhfvLF3AOO6tEE=.7e67e31c-5204-4b48-80a2-0586915984f7@github.com>
References: <4Sirjm1nS4rpyDkcVkQF_9OdlXzxmnhfvLF3AOO6tEE=.7e67e31c-5204-4b48-80a2-0586915984f7@github.com>
Message-ID: <PUWv4Ancq9t2tpL5BrgrPMzz6YnUE5oBVmmu2TeLu-w=.6efcaf8c-76f1-4aa9-8980-ee49e92d2599@github.com>

On Fri, 5 Apr 2024 15:31:29 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> I would like to backport this LW-locking-related bugfix to lilliput-17. Backport has been clean.

This pull request has now been integrated.

Changeset: ee5942af
Author:    Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.org/lilliput-jdk17u/commit/ee5942af30dfc8d89096b2369097e509843b5de0
Stats:     5 lines in 1 file changed: 4 ins; 0 del; 1 mod

8316401: sun/tools/jhsdb/JStackStressTest.java failed with "InternalError: We should have found a thread that owns the anonymous lock"

Reviewed-by: shade
Backport-of: bd918f49d29bcbc699e07b4ef8d23cfe1abd32df

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

PR: https://git.openjdk.org/lilliput-jdk17u/pull/71

From rkennke at openjdk.org  Mon Apr  8 08:28:21 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 8 Apr 2024 08:28:21 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8316181: Move the fast locking
 implementation out of the .ad files
Message-ID: <iB4t6cwdXaSrQy_ZOkQFVKmAEmebWSEwwDYgCDAmgew=.5ebb7e5a-dd74-41e7-9447-c4a801139297@github.com>

Backport of https://git.openjdk.org/jdk/commit/b48dbf6bfa652ef031c35f0a85a409142563aa72, to ease subsequent backport. Unclean because of context diffs, especially related to biased-locking.

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

Commit messages:
 - 8316181: Move the fast locking implementation out of the .ad files

Changes: https://git.openjdk.org/lilliput-jdk17u/pull/72/files
  Webrev: https://webrevs.openjdk.org/?repo=lilliput-jdk17u&pr=72&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8316181
  Stats: 398 lines in 3 files changed: 202 ins; 194 del; 2 mod
  Patch: https://git.openjdk.org/lilliput-jdk17u/pull/72.diff
  Fetch: git fetch https://git.openjdk.org/lilliput-jdk17u.git pull/72/head:pull/72

PR: https://git.openjdk.org/lilliput-jdk17u/pull/72

From shade at openjdk.org  Mon Apr  8 10:06:09 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 8 Apr 2024 10:06:09 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8316181: Move the fast locking
 implementation out of the .ad files
In-Reply-To: <iB4t6cwdXaSrQy_ZOkQFVKmAEmebWSEwwDYgCDAmgew=.5ebb7e5a-dd74-41e7-9447-c4a801139297@github.com>
References: <iB4t6cwdXaSrQy_ZOkQFVKmAEmebWSEwwDYgCDAmgew=.5ebb7e5a-dd74-41e7-9447-c4a801139297@github.com>
Message-ID: <mYFqMkwm_a7eNzyruxpIFydKm6pQJGE0GLyWX8bKTKQ=.4289c471-faee-41a9-9e31-f28282225d7d@github.com>

On Mon, 8 Apr 2024 08:23:57 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Backport of https://git.openjdk.org/jdk/commit/b48dbf6bfa652ef031c35f0a85a409142563aa72, to ease subsequent backport. Unclean because of context diffs, especially related to biased-locking.

Looks fine, assuming it was a mechanical move that does not change the code any substantially beyond dropping `__ -> ` everywhere.

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

Marked as reviewed by shade (Committer).

PR Review: https://git.openjdk.org/lilliput-jdk17u/pull/72#pullrequestreview-1985983518

From rkennke at openjdk.org  Mon Apr  8 15:36:13 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 8 Apr 2024 15:36:13 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8316181: Move the fast locking
 implementation out of the .ad files
In-Reply-To: <mYFqMkwm_a7eNzyruxpIFydKm6pQJGE0GLyWX8bKTKQ=.4289c471-faee-41a9-9e31-f28282225d7d@github.com>
References: <iB4t6cwdXaSrQy_ZOkQFVKmAEmebWSEwwDYgCDAmgew=.5ebb7e5a-dd74-41e7-9447-c4a801139297@github.com>
 <mYFqMkwm_a7eNzyruxpIFydKm6pQJGE0GLyWX8bKTKQ=.4289c471-faee-41a9-9e31-f28282225d7d@github.com>
Message-ID: <nZmg8H5SyLnqwxxEmF-wd18v0grspAT4qeGhrxFr-Ws=.eda963b5-f53a-40a0-b50b-f0a66a1d3938@github.com>

On Mon, 8 Apr 2024 10:03:53 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Looks fine, assuming it was a mechanical move that does not change the code any substantially beyond dropping `__ -> ` everywhere.

Yep, that's exactly how I did it. Thanks!

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

PR Comment: https://git.openjdk.org/lilliput-jdk17u/pull/72#issuecomment-2043069786

From rkennke at openjdk.org  Mon Apr  8 15:36:14 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 8 Apr 2024 15:36:14 GMT
Subject: [lilliput-jdk17u:lilliput] Integrated: 8316181: Move the fast locking
 implementation out of the .ad files
In-Reply-To: <iB4t6cwdXaSrQy_ZOkQFVKmAEmebWSEwwDYgCDAmgew=.5ebb7e5a-dd74-41e7-9447-c4a801139297@github.com>
References: <iB4t6cwdXaSrQy_ZOkQFVKmAEmebWSEwwDYgCDAmgew=.5ebb7e5a-dd74-41e7-9447-c4a801139297@github.com>
Message-ID: <xjBzKIn1RBtHjOvpqZ9KUpsFB5pdia5RWgdMjzNXpm0=.1c6a3316-0fd2-4ee7-95e1-ce60c129c134@github.com>

On Mon, 8 Apr 2024 08:23:57 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Backport of https://git.openjdk.org/jdk/commit/b48dbf6bfa652ef031c35f0a85a409142563aa72, to ease subsequent backport. Unclean because of context diffs, especially related to biased-locking.

This pull request has now been integrated.

Changeset: 263af2ec
Author:    Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.org/lilliput-jdk17u/commit/263af2ec67569e41eabe865e29742266d2df0c17
Stats:     398 lines in 3 files changed: 202 ins; 194 del; 2 mod

8316181: Move the fast locking implementation out of the .ad files

Reviewed-by: shade
Backport-of: b48dbf6bfa652ef031c35f0a85a409142563aa72

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

PR: https://git.openjdk.org/lilliput-jdk17u/pull/72

From rkennke at openjdk.org  Mon Apr  8 16:00:40 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 8 Apr 2024 16:00:40 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8316880: AArch64:
 "stop: Header is not fast-locked" with -XX:-UseLSE since JDK-8315880
Message-ID: <9B4w04Pw3T2IfbtOsh79GvekYZQxoeqpgF2XHnJfVCg=.f3fed49a-aea0-4006-b98d-793fcfc080c5@github.com>

Backport of https://github.com/openjdk/jdk/commit/b6a97c078043862b20bd8e1d1b8ccb8699995515

It's not clean and required some work because in a few places, biased-locking does the same thing as what this patch wants to do.

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

Commit messages:
 - 8316880: AArch64: "stop: Header is not fast-locked" with -XX:-UseLSE since JDK-8315880

Changes: https://git.openjdk.org/lilliput-jdk17u/pull/73/files
  Webrev: https://webrevs.openjdk.org/?repo=lilliput-jdk17u&pr=73&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8316880
  Stats: 50 lines in 10 files changed: 13 ins; 8 del; 29 mod
  Patch: https://git.openjdk.org/lilliput-jdk17u/pull/73.diff
  Fetch: git fetch https://git.openjdk.org/lilliput-jdk17u.git pull/73/head:pull/73

PR: https://git.openjdk.org/lilliput-jdk17u/pull/73

From shade at openjdk.org  Mon Apr  8 16:05:10 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 8 Apr 2024 16:05:10 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8316880: AArch64:
 "stop: Header is not fast-locked" with -XX:-UseLSE since JDK-8315880
In-Reply-To: <9B4w04Pw3T2IfbtOsh79GvekYZQxoeqpgF2XHnJfVCg=.f3fed49a-aea0-4006-b98d-793fcfc080c5@github.com>
References: <9B4w04Pw3T2IfbtOsh79GvekYZQxoeqpgF2XHnJfVCg=.f3fed49a-aea0-4006-b98d-793fcfc080c5@github.com>
Message-ID: <SgU02tZV0vdQx8oJ8AL0JhiaWWw_2EAG_lXqaQX3NNU=.83b5e9d6-c61e-4a79-95dd-4f9cc631ab28@github.com>

On Mon, 8 Apr 2024 15:55:16 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Backport of https://github.com/openjdk/jdk/commit/b6a97c078043862b20bd8e1d1b8ccb8699995515
> 
> It's not clean and required some work because in a few places, biased-locking does the same thing as what this patch wants to do.

Looks reasonable.

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

Marked as reviewed by shade (Committer).

PR Review: https://git.openjdk.org/lilliput-jdk17u/pull/73#pullrequestreview-1986861174

From rkennke at openjdk.org  Mon Apr  8 17:03:15 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 8 Apr 2024 17:03:15 GMT
Subject: [lilliput-jdk17u:lilliput] Integrated: 8316880: AArch64:
 "stop: Header is not fast-locked" with -XX:-UseLSE since JDK-8315880
In-Reply-To: <9B4w04Pw3T2IfbtOsh79GvekYZQxoeqpgF2XHnJfVCg=.f3fed49a-aea0-4006-b98d-793fcfc080c5@github.com>
References: <9B4w04Pw3T2IfbtOsh79GvekYZQxoeqpgF2XHnJfVCg=.f3fed49a-aea0-4006-b98d-793fcfc080c5@github.com>
Message-ID: <YqWQrFVXR1vF8-Fzn9WV2Vt51G3bOAg42BjqK-C-3jM=.d2711aea-82f1-4221-b5b2-f6b53862fa44@github.com>

On Mon, 8 Apr 2024 15:55:16 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Backport of https://github.com/openjdk/jdk/commit/b6a97c078043862b20bd8e1d1b8ccb8699995515
> 
> It's not clean and required some work because in a few places, biased-locking does the same thing as what this patch wants to do.

This pull request has now been integrated.

Changeset: 2db08b6f
Author:    Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.org/lilliput-jdk17u/commit/2db08b6fd549e6457e84b85a653a62dacef55c2c
Stats:     50 lines in 10 files changed: 13 ins; 8 del; 29 mod

8316880: AArch64: "stop: Header is not fast-locked" with -XX:-UseLSE since JDK-8315880

Reviewed-by: shade
Backport-of: b6a97c078043862b20bd8e1d1b8ccb8699995515

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

PR: https://git.openjdk.org/lilliput-jdk17u/pull/73

From rkennke at openjdk.org  Mon Apr  8 17:11:16 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 8 Apr 2024 17:11:16 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8317452: [JVMCI] Export symbols used
 by lightweight locking to JVMCI compilers.
Message-ID: <c_AFsvVFQ6AwbFWCpipAnzzX6Szk_SgTKXefUFJxPXs=.670c55cb-3fa1-4758-a5ac-fcda9e3e7261@github.com>

Backport of https://github.com/openjdk/jdk/commit/9718f490fb76f6712ac8f9c7f5248ca10bf83e6f

Eases subsequent backports and makes JVMCI compatible with future Graal LW locking impl.

Unclean because of context diff in vmStructs_jvmci.cpp, otherwise straightforward.

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

Commit messages:
 - 8317452: [JVMCI] Export symbols used by lightweight locking to JVMCI compilers.

Changes: https://git.openjdk.org/lilliput-jdk17u/pull/74/files
  Webrev: https://webrevs.openjdk.org/?repo=lilliput-jdk17u&pr=74&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8317452
  Stats: 19 lines in 6 files changed: 11 ins; 8 del; 0 mod
  Patch: https://git.openjdk.org/lilliput-jdk17u/pull/74.diff
  Fetch: git fetch https://git.openjdk.org/lilliput-jdk17u.git pull/74/head:pull/74

PR: https://git.openjdk.org/lilliput-jdk17u/pull/74

From shade at openjdk.org  Mon Apr  8 17:24:13 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 8 Apr 2024 17:24:13 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8317452: [JVMCI] Export symbols
 used by lightweight locking to JVMCI compilers.
In-Reply-To: <c_AFsvVFQ6AwbFWCpipAnzzX6Szk_SgTKXefUFJxPXs=.670c55cb-3fa1-4758-a5ac-fcda9e3e7261@github.com>
References: <c_AFsvVFQ6AwbFWCpipAnzzX6Szk_SgTKXefUFJxPXs=.670c55cb-3fa1-4758-a5ac-fcda9e3e7261@github.com>
Message-ID: <cO7r2U7eR-H8L_P8zKP_7fiJtaggYu9p8AXudFv_LZw=.28f711f3-7209-46f2-9ee7-f4eaa174b9a0@github.com>

On Mon, 8 Apr 2024 17:06:48 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Backport of https://github.com/openjdk/jdk/commit/9718f490fb76f6712ac8f9c7f5248ca10bf83e6f
> 
> Eases subsequent backports and makes JVMCI compatible with future Graal LW locking impl.
> 
> Unclean because of context diff in vmStructs_jvmci.cpp, otherwise straightforward.

Looks reasonable.

src/hotspot/share/runtime/arguments.cpp line 4073:

> 4071: #endif // COMPILER1
> 4072: #if INCLUDE_JVMCI
> 4073:       || !JVMCIUseFastLocking

I was a bit concerned this subtly changes the observable VM behavior by JVMCI compilers, but it looks like the flag is already `develop`, and so cannot really affect release binaries.

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

Marked as reviewed by shade (Committer).

PR Review: https://git.openjdk.org/lilliput-jdk17u/pull/74#pullrequestreview-1987004093
PR Review Comment: https://git.openjdk.org/lilliput-jdk17u/pull/74#discussion_r1556175410

From rkennke at openjdk.org  Mon Apr  8 18:14:08 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 8 Apr 2024 18:14:08 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8317452: [JVMCI] Export symbols
 used by lightweight locking to JVMCI compilers.
In-Reply-To: <c_AFsvVFQ6AwbFWCpipAnzzX6Szk_SgTKXefUFJxPXs=.670c55cb-3fa1-4758-a5ac-fcda9e3e7261@github.com>
References: <c_AFsvVFQ6AwbFWCpipAnzzX6Szk_SgTKXefUFJxPXs=.670c55cb-3fa1-4758-a5ac-fcda9e3e7261@github.com>
Message-ID: <MjaB_I7qw7dsPV3f4wKUKeDc42ylWv2IEUsrebOItl4=.fb04ad0a-7ae6-43c4-97cf-974c592d5309@github.com>

On Mon, 8 Apr 2024 17:06:48 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Backport of https://github.com/openjdk/jdk/commit/9718f490fb76f6712ac8f9c7f5248ca10bf83e6f
> 
> Eases subsequent backports and makes JVMCI compatible with future Graal LW locking impl.
> 
> Unclean because of context diff in vmStructs_jvmci.cpp, otherwise straightforward.

Thanks!

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

PR Comment: https://git.openjdk.org/lilliput-jdk17u/pull/74#issuecomment-2043383318

From rkennke at openjdk.org  Mon Apr  8 18:14:09 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 8 Apr 2024 18:14:09 GMT
Subject: [lilliput-jdk17u:lilliput] Integrated: 8317452: [JVMCI] Export symbols
 used by lightweight locking to JVMCI compilers.
In-Reply-To: <c_AFsvVFQ6AwbFWCpipAnzzX6Szk_SgTKXefUFJxPXs=.670c55cb-3fa1-4758-a5ac-fcda9e3e7261@github.com>
References: <c_AFsvVFQ6AwbFWCpipAnzzX6Szk_SgTKXefUFJxPXs=.670c55cb-3fa1-4758-a5ac-fcda9e3e7261@github.com>
Message-ID: <dD5q0eB4e57NGgMq7Abh-FsQ6PJuThwnZ7Gs-JhWecw=.98b39f68-bd01-41ac-86e0-b88983205369@github.com>

On Mon, 8 Apr 2024 17:06:48 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Backport of https://github.com/openjdk/jdk/commit/9718f490fb76f6712ac8f9c7f5248ca10bf83e6f
> 
> Eases subsequent backports and makes JVMCI compatible with future Graal LW locking impl.
> 
> Unclean because of context diff in vmStructs_jvmci.cpp, otherwise straightforward.

This pull request has now been integrated.

Changeset: 46c75ee9
Author:    Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.org/lilliput-jdk17u/commit/46c75ee9c06f04ae37814a1f9a1fdb45a0962044
Stats:     19 lines in 6 files changed: 11 ins; 8 del; 0 mod

8317452: [JVMCI] Export symbols used by lightweight locking to JVMCI compilers.

Reviewed-by: shade
Backport-of: 9718f490fb76f6712ac8f9c7f5248ca10bf83e6f

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

PR: https://git.openjdk.org/lilliput-jdk17u/pull/74

From rkennke at openjdk.org  Mon Apr  8 18:38:34 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 8 Apr 2024 18:38:34 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8317262: LockStack::contains(oop)
 fails "assert(t->is_Java_thread()) failed: incorrect cast to JavaThread"
Message-ID: <Or6Vs0Qz4pDs6J4AcGID5yzYfz2sDXeaKccleXzI6B0=.1f64cf84-0dc2-4203-8b56-b99aeddc2140@github.com>

Backports a bugfix related to lightweight locking and prepares for subsequent backport.

Not clean, but only very minor differences (e.g. the cast to JavaThread*)

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

Commit messages:
 - 8317262: LockStack::contains(oop) fails "assert(t->is_Java_thread()) failed: incorrect cast to JavaThread"

Changes: https://git.openjdk.org/lilliput-jdk17u/pull/75/files
  Webrev: https://webrevs.openjdk.org/?repo=lilliput-jdk17u&pr=75&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8317262
  Stats: 100 lines in 2 files changed: 96 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/lilliput-jdk17u/pull/75.diff
  Fetch: git fetch https://git.openjdk.org/lilliput-jdk17u.git pull/75/head:pull/75

PR: https://git.openjdk.org/lilliput-jdk17u/pull/75

From shade at openjdk.org  Mon Apr  8 18:53:09 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 8 Apr 2024 18:53:09 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8317262: LockStack::contains(oop)
 fails "assert(t->is_Java_thread()) failed: incorrect cast to
 JavaThread"
In-Reply-To: <Or6Vs0Qz4pDs6J4AcGID5yzYfz2sDXeaKccleXzI6B0=.1f64cf84-0dc2-4203-8b56-b99aeddc2140@github.com>
References: <Or6Vs0Qz4pDs6J4AcGID5yzYfz2sDXeaKccleXzI6B0=.1f64cf84-0dc2-4203-8b56-b99aeddc2140@github.com>
Message-ID: <Qas6b-8H8auK_qODsNwNeAOijyTPeCdZfmhHswG0FR8=.c4946481-0c30-44ed-85de-42d7fb33a0d9@github.com>

On Mon, 8 Apr 2024 18:32:54 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Backports a bugfix related to lightweight locking and prepares for subsequent backport.
> 
> Not clean, but only very minor differences (e.g. the cast to JavaThread*)

Looks fine.

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

Marked as reviewed by shade (Committer).

PR Review: https://git.openjdk.org/lilliput-jdk17u/pull/75#pullrequestreview-1987208206

From rkennke at openjdk.org  Mon Apr  8 20:58:15 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 8 Apr 2024 20:58:15 GMT
Subject: [lilliput-jdk17u:lilliput] Integrated: 8317262:
 LockStack::contains(oop) fails
 "assert(t->is_Java_thread()) failed: incorrect cast to JavaThread"
In-Reply-To: <Or6Vs0Qz4pDs6J4AcGID5yzYfz2sDXeaKccleXzI6B0=.1f64cf84-0dc2-4203-8b56-b99aeddc2140@github.com>
References: <Or6Vs0Qz4pDs6J4AcGID5yzYfz2sDXeaKccleXzI6B0=.1f64cf84-0dc2-4203-8b56-b99aeddc2140@github.com>
Message-ID: <smeFmRgpp_oQIDATrOerRomJl4TGB_aHzZqeOPy6fV0=.48e1d02c-6b89-4480-95b2-cd387b254b4c@github.com>

On Mon, 8 Apr 2024 18:32:54 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Backports a bugfix related to lightweight locking and prepares for subsequent backport.
> 
> Not clean, but only very minor differences (e.g. the cast to JavaThread*)

This pull request has now been integrated.

Changeset: 6e21edc3
Author:    Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.org/lilliput-jdk17u/commit/6e21edc32e5e6fad3791418ea085b75e9e56e593
Stats:     100 lines in 2 files changed: 96 ins; 0 del; 4 mod

8317262: LockStack::contains(oop) fails "assert(t->is_Java_thread()) failed: incorrect cast to JavaThread"

Reviewed-by: shade
Backport-of: 4ea1b99c1a6efe144af381ea538f93718e9baf74

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

PR: https://git.openjdk.org/lilliput-jdk17u/pull/75

From rkennke at openjdk.org  Mon Apr  8 21:08:20 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 8 Apr 2024 21:08:20 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8318015: Lock inflation not needed for
 OSR or Deopt for new locking modes
Message-ID: <HqjkIAh-H2h1Z3O-BMaXhn4LOUcKhsz1ZKW-jbGIq5I=.4750b0f9-8c6f-4764-bfa5-067584efcfb9@github.com>

Backports a nice improvement related to lightweight locking and OSR and deoptimization. https://github.com/openjdk/jdk/commit/d0ea2a51111bd5de5a6465e7de6a4950aae89c71

Backport has been clean.

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

Commit messages:
 - 8318015: Lock inflation not needed for OSR or Deopt for new locking modes

Changes: https://git.openjdk.org/lilliput-jdk17u/pull/76/files
  Webrev: https://webrevs.openjdk.org/?repo=lilliput-jdk17u&pr=76&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8318015
  Stats: 40 lines in 3 files changed: 16 ins; 0 del; 24 mod
  Patch: https://git.openjdk.org/lilliput-jdk17u/pull/76.diff
  Fetch: git fetch https://git.openjdk.org/lilliput-jdk17u.git pull/76/head:pull/76

PR: https://git.openjdk.org/lilliput-jdk17u/pull/76

From shade at openjdk.org  Tue Apr  9 06:28:10 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 9 Apr 2024 06:28:10 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8318015: Lock inflation not needed
 for OSR or Deopt for new locking modes
In-Reply-To: <HqjkIAh-H2h1Z3O-BMaXhn4LOUcKhsz1ZKW-jbGIq5I=.4750b0f9-8c6f-4764-bfa5-067584efcfb9@github.com>
References: <HqjkIAh-H2h1Z3O-BMaXhn4LOUcKhsz1ZKW-jbGIq5I=.4750b0f9-8c6f-4764-bfa5-067584efcfb9@github.com>
Message-ID: <GYE3ZLGaO2g8s4m98lbsShA2510MEAhMFtCIkifkcZo=.f3fdebd1-d12f-486a-b625-c9862a85de9c@github.com>

On Mon, 8 Apr 2024 21:02:21 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Backports a nice improvement related to lightweight locking and OSR and deoptimization. https://github.com/openjdk/jdk/commit/d0ea2a51111bd5de5a6465e7de6a4950aae89c71
> 
> Backport has been clean.

Marked as reviewed by shade (Committer).

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

PR Review: https://git.openjdk.org/lilliput-jdk17u/pull/76#pullrequestreview-1988197381

From rkennke at openjdk.org  Tue Apr  9 07:12:13 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 9 Apr 2024 07:12:13 GMT
Subject: [lilliput-jdk17u:lilliput] Integrated: 8318015: Lock inflation not
 needed for OSR or Deopt for new locking modes
In-Reply-To: <HqjkIAh-H2h1Z3O-BMaXhn4LOUcKhsz1ZKW-jbGIq5I=.4750b0f9-8c6f-4764-bfa5-067584efcfb9@github.com>
References: <HqjkIAh-H2h1Z3O-BMaXhn4LOUcKhsz1ZKW-jbGIq5I=.4750b0f9-8c6f-4764-bfa5-067584efcfb9@github.com>
Message-ID: <taewrWgDXzMPb994kdNIcAOLqgPVG0YWW6iByLXUn24=.f0b18fb4-2b76-4881-a6f2-aa14d9889b98@github.com>

On Mon, 8 Apr 2024 21:02:21 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Backports a nice improvement related to lightweight locking and OSR and deoptimization. https://github.com/openjdk/jdk/commit/d0ea2a51111bd5de5a6465e7de6a4950aae89c71
> 
> Backport has been clean.

This pull request has now been integrated.

Changeset: 71b6e9dc
Author:    Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.org/lilliput-jdk17u/commit/71b6e9dcece4f577550ff591cef2da81f7a80bb1
Stats:     40 lines in 3 files changed: 16 ins; 0 del; 24 mod

8318015: Lock inflation not needed for OSR or Deopt for new locking modes

Reviewed-by: shade
Backport-of: d0ea2a51111bd5de5a6465e7de6a4950aae89c71

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

PR: https://git.openjdk.org/lilliput-jdk17u/pull/76

From rkennke at openjdk.org  Tue Apr  9 07:21:33 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 9 Apr 2024 07:21:33 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8318895: Deoptimization results in
 incorrect lightweight locking stack
Message-ID: <ohYVUFRPPVBrSjVxFa0UYqN0pYUPuGp-lecpu1enlu0=.361fb9e9-894d-42cc-9934-c9925417468c@github.com>

Backport of https://github.com/openjdk/jdk/commit/ea1ffa34192448317ce9a61a3588b0dee3a2ef44

Fixes a bug related to lightweight locking and deoptimization.

Mostly clean, except for minor context diff in includes and missing -XX:+UnlockExperimentalVMOptions in tests.

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

Commit messages:
 - 8318895: Deoptimization results in incorrect lightweight locking stack

Changes: https://git.openjdk.org/lilliput-jdk17u/pull/77/files
  Webrev: https://webrevs.openjdk.org/?repo=lilliput-jdk17u&pr=77&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8318895
  Stats: 163 lines in 2 files changed: 160 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/lilliput-jdk17u/pull/77.diff
  Fetch: git fetch https://git.openjdk.org/lilliput-jdk17u.git pull/77/head:pull/77

PR: https://git.openjdk.org/lilliput-jdk17u/pull/77

From shade at openjdk.org  Tue Apr  9 07:27:15 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 9 Apr 2024 07:27:15 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8318895: Deoptimization results in
 incorrect lightweight locking stack
In-Reply-To: <ohYVUFRPPVBrSjVxFa0UYqN0pYUPuGp-lecpu1enlu0=.361fb9e9-894d-42cc-9934-c9925417468c@github.com>
References: <ohYVUFRPPVBrSjVxFa0UYqN0pYUPuGp-lecpu1enlu0=.361fb9e9-894d-42cc-9934-c9925417468c@github.com>
Message-ID: <drhqXr-wE9BdR9GD815UyOqKe-MiRl7ddqgCSrrl7Mw=.b3f2b428-6c1a-4cea-97e3-3b51e86783ac@github.com>

On Tue, 9 Apr 2024 07:17:10 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Backport of https://github.com/openjdk/jdk/commit/ea1ffa34192448317ce9a61a3588b0dee3a2ef44
> 
> Fixes a bug related to lightweight locking and deoptimization.
> 
> Mostly clean, except for minor context diff in includes and missing -XX:+UnlockExperimentalVMOptions in tests.

Marked as reviewed by shade (Committer).

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

PR Review: https://git.openjdk.org/lilliput-jdk17u/pull/77#pullrequestreview-1988303544

From rkennke at openjdk.org  Tue Apr  9 07:54:15 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 9 Apr 2024 07:54:15 GMT
Subject: [lilliput-jdk17u:lilliput] Integrated: 8318895: Deoptimization results
 in incorrect lightweight locking stack
In-Reply-To: <ohYVUFRPPVBrSjVxFa0UYqN0pYUPuGp-lecpu1enlu0=.361fb9e9-894d-42cc-9934-c9925417468c@github.com>
References: <ohYVUFRPPVBrSjVxFa0UYqN0pYUPuGp-lecpu1enlu0=.361fb9e9-894d-42cc-9934-c9925417468c@github.com>
Message-ID: <X_owdszK8nJAXQkENaXDk5gHwYoFy7U1ze1zs8EgWMY=.2fd57663-13a3-4199-87b8-1f2e356e9267@github.com>

On Tue, 9 Apr 2024 07:17:10 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Backport of https://github.com/openjdk/jdk/commit/ea1ffa34192448317ce9a61a3588b0dee3a2ef44
> 
> Fixes a bug related to lightweight locking and deoptimization.
> 
> Mostly clean, except for minor context diff in includes and missing -XX:+UnlockExperimentalVMOptions in tests.

This pull request has now been integrated.

Changeset: 17daee89
Author:    Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.org/lilliput-jdk17u/commit/17daee8931747aad47ecc8b520521f90f3f06e46
Stats:     163 lines in 2 files changed: 160 ins; 0 del; 3 mod

8318895: Deoptimization results in incorrect lightweight locking stack

Reviewed-by: shade
Backport-of: ea1ffa34192448317ce9a61a3588b0dee3a2ef44

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

PR: https://git.openjdk.org/lilliput-jdk17u/pull/77

From rkennke at openjdk.org  Tue Apr  9 08:00:16 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 9 Apr 2024 08:00:16 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8319897: Move StackWatermark handling
 out of LockStack::contains
Message-ID: <RGgyfLif_6ViJmTPdsJG6QWdcQB09wGTgCuxnr3lpAk=.215f6aae-0429-411c-b0ae-a90a47b4efc8@github.com>

Backport of https://github.com/openjdk/jdk/commit/bbf52e0e4cb76b4c6425e7d1266dcdbb4df556ea

It's an enhancement to LW locking, backported to keep lockStack code in sync, to ease subsequent backports.

Slightly unclean because of NULL vs nullptr diff.

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

Commit messages:
 - 8319897: Move StackWatermark handling out of LockStack::contains

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

PR: https://git.openjdk.org/lilliput-jdk17u/pull/78

From shade at openjdk.org  Tue Apr  9 09:18:11 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 9 Apr 2024 09:18:11 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8319897: Move StackWatermark
 handling out of LockStack::contains
In-Reply-To: <RGgyfLif_6ViJmTPdsJG6QWdcQB09wGTgCuxnr3lpAk=.215f6aae-0429-411c-b0ae-a90a47b4efc8@github.com>
References: <RGgyfLif_6ViJmTPdsJG6QWdcQB09wGTgCuxnr3lpAk=.215f6aae-0429-411c-b0ae-a90a47b4efc8@github.com>
Message-ID: <ABw9XfzR7RdoHi8EBDmMyYHH-nMRsK6ozKd9qLfmD-Q=.edfc9d35-671b-40d5-bbe0-f7beaaa70fd0@github.com>

On Tue, 9 Apr 2024 07:55:52 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Backport of https://github.com/openjdk/jdk/commit/bbf52e0e4cb76b4c6425e7d1266dcdbb4df556ea
> 
> It's an enhancement to LW locking, backported to keep lockStack code in sync, to ease subsequent backports.
> 
> Slightly unclean because of NULL vs nullptr diff.

Marked as reviewed by shade (Committer).

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

PR Review: https://git.openjdk.org/lilliput-jdk17u/pull/78#pullrequestreview-1988537633

From rkennke at openjdk.org  Tue Apr  9 10:20:12 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 9 Apr 2024 10:20:12 GMT
Subject: [lilliput-jdk17u:lilliput] Integrated: 8319897: Move StackWatermark
 handling out of LockStack::contains
In-Reply-To: <RGgyfLif_6ViJmTPdsJG6QWdcQB09wGTgCuxnr3lpAk=.215f6aae-0429-411c-b0ae-a90a47b4efc8@github.com>
References: <RGgyfLif_6ViJmTPdsJG6QWdcQB09wGTgCuxnr3lpAk=.215f6aae-0429-411c-b0ae-a90a47b4efc8@github.com>
Message-ID: <zqLWSPGpG_5ulyvGyW_W3v8DQfVihMEtyaj5WgUCpYU=.6400517d-0e00-44bb-9232-cab6d0a0c718@github.com>

On Tue, 9 Apr 2024 07:55:52 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Backport of https://github.com/openjdk/jdk/commit/bbf52e0e4cb76b4c6425e7d1266dcdbb4df556ea
> 
> It's an enhancement to LW locking, backported to keep lockStack code in sync, to ease subsequent backports.
> 
> Slightly unclean because of NULL vs nullptr diff.

This pull request has now been integrated.

Changeset: 6f943a01
Author:    Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.org/lilliput-jdk17u/commit/6f943a015088f1f6107365e811a38f42627b0fa6
Stats:     17 lines in 2 files changed: 6 ins; 6 del; 5 mod

8319897: Move StackWatermark handling out of LockStack::contains

Reviewed-by: shade
Backport-of: bbf52e0e4cb76b4c6425e7d1266dcdbb4df556ea

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

PR: https://git.openjdk.org/lilliput-jdk17u/pull/78

From rkennke at openjdk.org  Tue Apr  9 10:27:29 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 9 Apr 2024 10:27:29 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8319778: Remove unreachable code in
 ObjectSynchronizer::exit
Message-ID: <zWKCVPOIr5PUxp1qeGrv8R1NY4CbsEsqvWb6qEBlsss=.00df8179-dacb-4fb3-9ba1-ebec74834411@github.com>

Backport of https://github.com/openjdk/jdk/commit/91279fcf058a6bb16a7749c328179ab94227bb8d

For cleanliness and easier subsequent backports. Almost clean, except a nullptr vs NULL diff.

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

Commit messages:
 - 8319778: Remove unreachable code in ObjectSynchronizer::exit

Changes: https://git.openjdk.org/lilliput-jdk17u/pull/79/files
  Webrev: https://webrevs.openjdk.org/?repo=lilliput-jdk17u&pr=79&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8319778
  Stats: 23 lines in 3 files changed: 0 ins; 22 del; 1 mod
  Patch: https://git.openjdk.org/lilliput-jdk17u/pull/79.diff
  Fetch: git fetch https://git.openjdk.org/lilliput-jdk17u.git pull/79/head:pull/79

PR: https://git.openjdk.org/lilliput-jdk17u/pull/79

From shade at openjdk.org  Tue Apr  9 11:02:13 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 9 Apr 2024 11:02:13 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8319778: Remove unreachable code
 in ObjectSynchronizer::exit
In-Reply-To: <zWKCVPOIr5PUxp1qeGrv8R1NY4CbsEsqvWb6qEBlsss=.00df8179-dacb-4fb3-9ba1-ebec74834411@github.com>
References: <zWKCVPOIr5PUxp1qeGrv8R1NY4CbsEsqvWb6qEBlsss=.00df8179-dacb-4fb3-9ba1-ebec74834411@github.com>
Message-ID: <2fbUsuWtnrRSoqZk3ZtQQJamVXtDn-A66TGxu7Ck7WQ=.185b93f4-bc6d-432c-ad5e-b9cdec979cda@github.com>

On Tue, 9 Apr 2024 10:23:23 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Backport of https://github.com/openjdk/jdk/commit/91279fcf058a6bb16a7749c328179ab94227bb8d
> 
> For cleanliness and easier subsequent backports. Almost clean, except a nullptr vs NULL diff.

All right.

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

Marked as reviewed by shade (Committer).

PR Review: https://git.openjdk.org/lilliput-jdk17u/pull/79#pullrequestreview-1988743375

From rkennke at openjdk.org  Tue Apr  9 11:55:13 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 9 Apr 2024 11:55:13 GMT
Subject: [lilliput-jdk17u:lilliput] Integrated: 8319778: Remove unreachable
 code in ObjectSynchronizer::exit
In-Reply-To: <zWKCVPOIr5PUxp1qeGrv8R1NY4CbsEsqvWb6qEBlsss=.00df8179-dacb-4fb3-9ba1-ebec74834411@github.com>
References: <zWKCVPOIr5PUxp1qeGrv8R1NY4CbsEsqvWb6qEBlsss=.00df8179-dacb-4fb3-9ba1-ebec74834411@github.com>
Message-ID: <Sb_jbcSiDkzuZ_TFVzU4659PcT0tPzS6WSdeJFBJ8tg=.1850e5f8-8290-4e15-a95e-47e55f2a9faf@github.com>

On Tue, 9 Apr 2024 10:23:23 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Backport of https://github.com/openjdk/jdk/commit/91279fcf058a6bb16a7749c328179ab94227bb8d
> 
> For cleanliness and easier subsequent backports. Almost clean, except a nullptr vs NULL diff.

This pull request has now been integrated.

Changeset: 879f3e34
Author:    Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.org/lilliput-jdk17u/commit/879f3e34eee05b0efd0362050b3a679e18ef2ec8
Stats:     23 lines in 3 files changed: 0 ins; 22 del; 1 mod

8319778: Remove unreachable code in ObjectSynchronizer::exit

Reviewed-by: shade
Backport-of: 91279fcf058a6bb16a7749c328179ab94227bb8d

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

PR: https://git.openjdk.org/lilliput-jdk17u/pull/79

From rkennke at openjdk.org  Tue Apr  9 12:12:31 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 9 Apr 2024 12:12:31 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8319773: Avoid inflating monitors when
 installing hash codes for LM_LIGHTWEIGHT
Message-ID: <tTPar8vHiVod7OJ5rA5BXXDVWNi_2P00IRjwlto6Kkc=.c1e2a028-418b-49d3-8660-0b4808662411@github.com>

Backports https://github.com/openjdk/jdk/commit/65a0672791f868556776fc435b37319ed69f7c84

This is a useful enhancement that can avoid inflating monitors when installing i-hash-codes.

Backport has not been clean, but only context diffs.

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

Commit messages:
 - 8319773: Avoid inflating monitors when installing hash codes for LM_LIGHTWEIGHT

Changes: https://git.openjdk.org/lilliput-jdk17u/pull/80/files
  Webrev: https://webrevs.openjdk.org/?repo=lilliput-jdk17u&pr=80&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8319773
  Stats: 76 lines in 4 files changed: 29 ins; 23 del; 24 mod
  Patch: https://git.openjdk.org/lilliput-jdk17u/pull/80.diff
  Fetch: git fetch https://git.openjdk.org/lilliput-jdk17u.git pull/80/head:pull/80

PR: https://git.openjdk.org/lilliput-jdk17u/pull/80

From shade at openjdk.org  Tue Apr  9 12:25:12 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 9 Apr 2024 12:25:12 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8319773: Avoid inflating monitors
 when installing hash codes for LM_LIGHTWEIGHT
In-Reply-To: <tTPar8vHiVod7OJ5rA5BXXDVWNi_2P00IRjwlto6Kkc=.c1e2a028-418b-49d3-8660-0b4808662411@github.com>
References: <tTPar8vHiVod7OJ5rA5BXXDVWNi_2P00IRjwlto6Kkc=.c1e2a028-418b-49d3-8660-0b4808662411@github.com>
Message-ID: <r9irhkW3JIih8JCt8EMRw-iwWpJT6BfowU4Hd_-msJQ=.460b94ca-2991-434a-94f9-92f7cd7a4800@github.com>

On Tue, 9 Apr 2024 12:06:37 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Backports https://github.com/openjdk/jdk/commit/65a0672791f868556776fc435b37319ed69f7c84
> 
> This is a useful enhancement that can avoid inflating monitors when installing i-hash-codes.
> 
> Backport has not been clean, but only context diffs.

Looks right.

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

Marked as reviewed by shade (Committer).

PR Review: https://git.openjdk.org/lilliput-jdk17u/pull/80#pullrequestreview-1988897928

From rkennke at openjdk.org  Tue Apr  9 12:38:15 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 9 Apr 2024 12:38:15 GMT
Subject: [lilliput-jdk17u:lilliput] Integrated: 8319773: Avoid inflating
 monitors when installing hash codes for LM_LIGHTWEIGHT
In-Reply-To: <tTPar8vHiVod7OJ5rA5BXXDVWNi_2P00IRjwlto6Kkc=.c1e2a028-418b-49d3-8660-0b4808662411@github.com>
References: <tTPar8vHiVod7OJ5rA5BXXDVWNi_2P00IRjwlto6Kkc=.c1e2a028-418b-49d3-8660-0b4808662411@github.com>
Message-ID: <QIPEKHzXdz0fiPq_4XywTmPA3t56KcXcHixrHXYa-Vw=.c4272034-6eba-4ff1-b898-ac9be648e3d9@github.com>

On Tue, 9 Apr 2024 12:06:37 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Backports https://github.com/openjdk/jdk/commit/65a0672791f868556776fc435b37319ed69f7c84
> 
> This is a useful enhancement that can avoid inflating monitors when installing i-hash-codes.
> 
> Backport has not been clean, but only context diffs.

This pull request has now been integrated.

Changeset: 11a3cf92
Author:    Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.org/lilliput-jdk17u/commit/11a3cf929d19175340f8c98b82a9361af79f638e
Stats:     76 lines in 4 files changed: 29 ins; 23 del; 24 mod

8319773: Avoid inflating monitors when installing hash codes for LM_LIGHTWEIGHT

Reviewed-by: shade
Backport-of: 65a0672791f868556776fc435b37319ed69f7c84

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

PR: https://git.openjdk.org/lilliput-jdk17u/pull/80

From rkennke at openjdk.org  Tue Apr  9 12:53:34 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 9 Apr 2024 12:53:34 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8324881:
 ObjectSynchronizer::inflate(Thread* current...) is invoked for non-current
 thread
Message-ID: <7e80VvppyuFUuxRYialq5XFaMiL3tMFClWehTKCRlMk=.c08cc894-ea3c-44d5-bedc-55037d1baaa5@github.com>

Backport of https://github.com/openjdk/jdk/commit/a3a2b1fbbf00577ce1d0e3a44e9537e997b30b05

This is a bugfix related to lightweight locking. It's not clean due to various small diffs, e.g. thread-cast, nullptr vs NULL, -XX:+UnlockExperimentalVMOptions and context.

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

Commit messages:
 - 8324881: ObjectSynchronizer::inflate(Thread* current...) is invoked for non-current thread

Changes: https://git.openjdk.org/lilliput-jdk17u/pull/81/files
  Webrev: https://webrevs.openjdk.org/?repo=lilliput-jdk17u&pr=81&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8324881
  Stats: 361 lines in 6 files changed: 302 ins; 10 del; 49 mod
  Patch: https://git.openjdk.org/lilliput-jdk17u/pull/81.diff
  Fetch: git fetch https://git.openjdk.org/lilliput-jdk17u.git pull/81/head:pull/81

PR: https://git.openjdk.org/lilliput-jdk17u/pull/81

From shade at openjdk.org  Tue Apr  9 16:31:12 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 9 Apr 2024 16:31:12 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8324881:
 ObjectSynchronizer::inflate(Thread* current...) is invoked for non-current
 thread
In-Reply-To: <7e80VvppyuFUuxRYialq5XFaMiL3tMFClWehTKCRlMk=.c08cc894-ea3c-44d5-bedc-55037d1baaa5@github.com>
References: <7e80VvppyuFUuxRYialq5XFaMiL3tMFClWehTKCRlMk=.c08cc894-ea3c-44d5-bedc-55037d1baaa5@github.com>
Message-ID: <SsvTS6-4AAtETVp_g6gssobJtCAP85ulMNRd_eghaHM=.1c4a5d86-6c5f-4363-a93e-b78307a47598@github.com>

On Tue, 9 Apr 2024 12:48:45 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Backport of https://github.com/openjdk/jdk/commit/a3a2b1fbbf00577ce1d0e3a44e9537e997b30b05
> 
> This is a bugfix related to lightweight locking. It's not clean due to various small diffs, e.g. thread-cast, nullptr vs NULL, -XX:+UnlockExperimentalVMOptions and context.

This is somewhat scary, as it touches a lot of shared code. But it looks fine. We would need to comb through the diff with upstream 17u after all this...

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

Marked as reviewed by shade (Committer).

PR Review: https://git.openjdk.org/lilliput-jdk17u/pull/81#pullrequestreview-1989559102

From rkennke at openjdk.org  Tue Apr  9 16:42:16 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 9 Apr 2024 16:42:16 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8324881:
 ObjectSynchronizer::inflate(Thread* current...) is invoked for non-current
 thread
In-Reply-To: <7e80VvppyuFUuxRYialq5XFaMiL3tMFClWehTKCRlMk=.c08cc894-ea3c-44d5-bedc-55037d1baaa5@github.com>
References: <7e80VvppyuFUuxRYialq5XFaMiL3tMFClWehTKCRlMk=.c08cc894-ea3c-44d5-bedc-55037d1baaa5@github.com>
Message-ID: <9YB7mLpbbXDW82LWCjtvYdSqtiP0GeatBTW5jcYBaPE=.5b54192c-20cc-467e-a345-2c7f540ca3af@github.com>

On Tue, 9 Apr 2024 12:48:45 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Backport of https://github.com/openjdk/jdk/commit/a3a2b1fbbf00577ce1d0e3a44e9537e997b30b05
> 
> This is a bugfix related to lightweight locking. It's not clean due to various small diffs, e.g. thread-cast, nullptr vs NULL, -XX:+UnlockExperimentalVMOptions and context.

Thanks!

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

PR Comment: https://git.openjdk.org/lilliput-jdk17u/pull/81#issuecomment-2045628956

From rkennke at openjdk.org  Tue Apr  9 16:42:16 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 9 Apr 2024 16:42:16 GMT
Subject: [lilliput-jdk17u:lilliput] Integrated: 8324881:
 ObjectSynchronizer::inflate(Thread* current...) is invoked for non-current
 thread
In-Reply-To: <7e80VvppyuFUuxRYialq5XFaMiL3tMFClWehTKCRlMk=.c08cc894-ea3c-44d5-bedc-55037d1baaa5@github.com>
References: <7e80VvppyuFUuxRYialq5XFaMiL3tMFClWehTKCRlMk=.c08cc894-ea3c-44d5-bedc-55037d1baaa5@github.com>
Message-ID: <uVrbNGd1M4q7DzJIqzZ8wIy3yne4HPKJssjjGp2yrDc=.cd846e8a-d9ba-42e0-8852-504ef8fd2f53@github.com>

On Tue, 9 Apr 2024 12:48:45 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Backport of https://github.com/openjdk/jdk/commit/a3a2b1fbbf00577ce1d0e3a44e9537e997b30b05
> 
> This is a bugfix related to lightweight locking. It's not clean due to various small diffs, e.g. thread-cast, nullptr vs NULL, -XX:+UnlockExperimentalVMOptions and context.

This pull request has now been integrated.

Changeset: 517053dd
Author:    Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.org/lilliput-jdk17u/commit/517053ddc99c023455534949bfb57b26c4fa71e8
Stats:     361 lines in 6 files changed: 302 ins; 10 del; 49 mod

8324881: ObjectSynchronizer::inflate(Thread* current...) is invoked for non-current thread

Reviewed-by: shade
Backport-of: a3a2b1fbbf00577ce1d0e3a44e9537e997b30b05

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

PR: https://git.openjdk.org/lilliput-jdk17u/pull/81

From rkennke at openjdk.org  Tue Apr  9 16:51:32 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 9 Apr 2024 16:51:32 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8319797: Recursive lightweight
 locking: Runtime implementation
Message-ID: <9S9rfv34PyeSzqrrpTX9KVgYKzq2RsuhKWX_iISd0F4=.a0e30aff-d998-41e5-b46f-de22b9e917cb@github.com>

This backports https://github.com/openjdk/jdk/commit/5dbf13730ee2b57f089c57e9e7ee8ab65d4a67af

It's the runtime part of recursive lightweight locking.
Unclean, but mostly context diffs.

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

Commit messages:
 - 8319797: Recursive lightweight locking: Runtime implementation

Changes: https://git.openjdk.org/lilliput-jdk17u/pull/82/files
  Webrev: https://webrevs.openjdk.org/?repo=lilliput-jdk17u&pr=82&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8319797
  Stats: 864 lines in 13 files changed: 816 ins; 7 del; 41 mod
  Patch: https://git.openjdk.org/lilliput-jdk17u/pull/82.diff
  Fetch: git fetch https://git.openjdk.org/lilliput-jdk17u.git pull/82/head:pull/82

PR: https://git.openjdk.org/lilliput-jdk17u/pull/82

From shade at openjdk.org  Wed Apr 10 09:36:14 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 10 Apr 2024 09:36:14 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8319797: Recursive lightweight
 locking: Runtime implementation
In-Reply-To: <9S9rfv34PyeSzqrrpTX9KVgYKzq2RsuhKWX_iISd0F4=.a0e30aff-d998-41e5-b46f-de22b9e917cb@github.com>
References: <9S9rfv34PyeSzqrrpTX9KVgYKzq2RsuhKWX_iISd0F4=.a0e30aff-d998-41e5-b46f-de22b9e917cb@github.com>
Message-ID: <4AFguUptOS5gINh-5JjKmHCqFf6eIe6EEZ6aiFlE33M=.b93689c7-cc4f-4995-98ac-d08aa3a2d22d@github.com>

On Tue, 9 Apr 2024 16:45:31 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> This backports https://github.com/openjdk/jdk/commit/5dbf13730ee2b57f089c57e9e7ee8ab65d4a67af
> 
> It's the runtime part of recursive lightweight locking.
> Unclean, but mostly context diffs.

Looks fine.

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

Marked as reviewed by shade (Committer).

PR Review: https://git.openjdk.org/lilliput-jdk17u/pull/82#pullrequestreview-1991225545

From rkennke at openjdk.org  Wed Apr 10 10:42:14 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 10 Apr 2024 10:42:14 GMT
Subject: [lilliput-jdk17u:lilliput] Integrated: 8319797: Recursive lightweight
 locking: Runtime implementation
In-Reply-To: <9S9rfv34PyeSzqrrpTX9KVgYKzq2RsuhKWX_iISd0F4=.a0e30aff-d998-41e5-b46f-de22b9e917cb@github.com>
References: <9S9rfv34PyeSzqrrpTX9KVgYKzq2RsuhKWX_iISd0F4=.a0e30aff-d998-41e5-b46f-de22b9e917cb@github.com>
Message-ID: <jO5B8hsr7m0PEeVRkZ7QpxCECA_AOeHQYaBMRiYP5Lg=.b851a3db-13d5-4640-adf1-a7f50d1e12f8@github.com>

On Tue, 9 Apr 2024 16:45:31 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> This backports https://github.com/openjdk/jdk/commit/5dbf13730ee2b57f089c57e9e7ee8ab65d4a67af
> 
> It's the runtime part of recursive lightweight locking.
> Unclean, but mostly context diffs.

This pull request has now been integrated.

Changeset: b99d2f86
Author:    Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.org/lilliput-jdk17u/commit/b99d2f868cd82fd66005c2e4d2115c65f79ffe86
Stats:     864 lines in 13 files changed: 816 ins; 7 del; 41 mod

8319797: Recursive lightweight locking: Runtime implementation

Reviewed-by: shade
Backport-of: 5dbf13730ee2b57f089c57e9e7ee8ab65d4a67af

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

PR: https://git.openjdk.org/lilliput-jdk17u/pull/82

From rkennke at openjdk.org  Wed Apr 10 10:50:35 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 10 Apr 2024 10:50:35 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8319801: Recursive lightweight
 locking: aarch64 implementation
Message-ID: <WIDXmzFNjtZmbgGDLykCOZqW49OjcshcBJZ_0RSXBYs=.fcd90dd9-6d9e-428e-8c25-14b48da29737@github.com>

Backports https://github.com/openjdk/jdk/commit/18cea823a173e1b8b48d276daeca67b2a5cf3584

Implements the aarch64 parts of recursive lightweight locking.

Unclean, mostly because of biased locking.

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

Commit messages:
 - 8319801: Recursive lightweight locking: aarch64 implementation

Changes: https://git.openjdk.org/lilliput-jdk17u/pull/83/files
  Webrev: https://webrevs.openjdk.org/?repo=lilliput-jdk17u&pr=83&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8319801
  Stats: 488 lines in 9 files changed: 350 ins; 80 del; 58 mod
  Patch: https://git.openjdk.org/lilliput-jdk17u/pull/83.diff
  Fetch: git fetch https://git.openjdk.org/lilliput-jdk17u.git pull/83/head:pull/83

PR: https://git.openjdk.org/lilliput-jdk17u/pull/83

From rkennke at openjdk.org  Wed Apr 10 10:54:26 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 10 Apr 2024 10:54:26 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8319799: Recursive lightweight
 locking: x86 implementation
Message-ID: <uoxFDNVNgDmpZTsockYB1JKKxf0jNGJaVNZfNDmMGKY=.490dee41-3cac-4777-83fe-f817b323d14d@github.com>

Backports https://github.com/openjdk/jdk/commit/7f6bb71eb302e8388c959bdaa914b758a766d299

Implements the x86_64 parts of recursive lightweight locking.

Unclean, mostly because of biased locking.

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

Commit messages:
 - 8319799: Recursive lightweight locking: x86 implementation

Changes: https://git.openjdk.org/lilliput-jdk17u/pull/84/files
  Webrev: https://webrevs.openjdk.org/?repo=lilliput-jdk17u&pr=84&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8319799
  Stats: 579 lines in 13 files changed: 440 ins; 57 del; 82 mod
  Patch: https://git.openjdk.org/lilliput-jdk17u/pull/84.diff
  Fetch: git fetch https://git.openjdk.org/lilliput-jdk17u.git pull/84/head:pull/84

PR: https://git.openjdk.org/lilliput-jdk17u/pull/84

From stuefe at openjdk.org  Fri Apr 12 12:35:25 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 12 Apr 2024 12:35:25 GMT
Subject: [master] RFR: 8325104: Lilliput: Shrink Classpointers [v4]
In-Reply-To: <lm7SDOvsKA7Yt1yDQpYx5VPVjke0eAO0BB9ctkIA8qs=.206072f0-3274-492d-9224-d41adb3b842a@github.com>
References: <lm7SDOvsKA7Yt1yDQpYx5VPVjke0eAO0BB9ctkIA8qs=.206072f0-3274-492d-9224-d41adb3b842a@github.com>
Message-ID: <XPkVRH0lNoOtwzB5IUHDFmlRhs6QOJfY6Oi76UfTUJA=.52611a76-1b50-406a-b8b4-d9d165a1914a@github.com>

> Hi,
> 
> I wanted to get input on the following improvement for Lilliput. Testing is still ongoing, but things look really good, so this patch is hopefully near its final form (barring any objections from reviewers, of course).
> 
> Note: I have a companion patch prepared for upstream, minus the markword changes. I will attempt to get that one upstream quickly in order to not have a large delta between upstream and lilliput, especially in Metaspace.
> 
> ## High-Level Overview
> 
> (for a short sequence of slides, please see https://github.com/tstuefe/fosdem24/blob/master/classpointers-and-liliput.pdf - these accompanied a talk we held at FOSDEM 24).
> 
> We want to reduce the bit size of narrow Klass to free up bits in the MarkWord. 
> 
> We cannot just reduce the Klass encoding range size (well, we could, and maybe we will later, but for now we decided not to). We instead increase the alignment Klass is stored at, and use that alignment shadow to store other information.
> 
> In other words, this patch changes the narrow Klass Pointer to a Klass ID, since now (almost) every value in its value range points to a different class. Therefore, we use the value range of nKlass much more efficiently.
> 
> We then use the newly freed bits in the MarkWord to restore the iHash to 31 bits: 
> 
> 
> [ 22-bit nKlass | 31-bit iHash | 4 free bits | age | fwd | lck ]
> 
> nKlass gets reduced to 22 bits. Identity hash gets re-inflated to 31 bits. Preceding iHash are now 4 unused bits. Rest is unchanged.
> 
> (Note: I originally wanted to swap iHash and nKlass such that either of them could be loaded with a 32-bit load, but I found that tricky since C2 seems to rely on the nKlass offset in the Markword being > 0.)
> 
> ## nKlass reduction:
> 
> The reduction in nKlass size is made by only storing them at 10-bit aligned addresses. That alignment (1KB) works well in practice since Klass - although var sized - typically is between 512 bytes and 1KB in size. Outliers are possible, but the size distribution is bell-curvish [1], so far-away outliers are very rare. 
> 
> To not lose memory to alignment waste, metaspace is reshaped to handle arbitrarily aligned allocations efficiently. Basically, we allow the non-Klass arena of a class loader to steal the alignment waste storage from the class arena. So, alignment waste blocks are filled with non-Klass metadata. That works very well in practice since non-Klass metadata is numerous and fine-granular compared to the big Klass blocks. Total footprint loss in metaspace is, therefore, almost ...

Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:

 - fixes
 - Roman feedback - small stuff
 - revert COH archive generation
 - Remove files that accidentally slipped in
 - Fix Typo
 - Fixes
 - Fix Windows-Only bug that was caused by !INCLUDE_CDS_JAVA_HEAP
 - fix runtime/cds/appcds/TestCombinedCompressedFlags and runtime/cds/appcds/CommandLineFlagComboNegative.java
 - Fix CdsDifferentCompactObjectHeaders
 - hash->32bit
 - ... and 5 more: https://git.openjdk.org/lilliput/compare/e331ea1b...49d289e1

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

Changes: https://git.openjdk.org/lilliput/pull/128/files
  Webrev: https://webrevs.openjdk.org/?repo=lilliput&pr=128&range=03
  Stats: 2553 lines in 76 files changed: 1767 ins; 431 del; 355 mod
  Patch: https://git.openjdk.org/lilliput/pull/128.diff
  Fetch: git fetch https://git.openjdk.org/lilliput.git pull/128/head:pull/128

PR: https://git.openjdk.org/lilliput/pull/128

From stuefe at openjdk.org  Fri Apr 12 13:05:38 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 12 Apr 2024 13:05:38 GMT
Subject: [master] RFR: 8325104: Lilliput: Shrink Classpointers [v5]
In-Reply-To: <lm7SDOvsKA7Yt1yDQpYx5VPVjke0eAO0BB9ctkIA8qs=.206072f0-3274-492d-9224-d41adb3b842a@github.com>
References: <lm7SDOvsKA7Yt1yDQpYx5VPVjke0eAO0BB9ctkIA8qs=.206072f0-3274-492d-9224-d41adb3b842a@github.com>
Message-ID: <9f5FpCdDsYoACHqw9UsrrU7icfwHdUZiwdhWP7Hc6Bs=.ab702592-01ff-454c-82e0-0998fa5ae23f@github.com>

> Hi,
> 
> I wanted to get input on the following improvement for Lilliput. Testing is still ongoing, but things look really good, so this patch is hopefully near its final form (barring any objections from reviewers, of course).
> 
> Note: I have a companion patch prepared for upstream, minus the markword changes. I will attempt to get that one upstream quickly in order to not have a large delta between upstream and lilliput, especially in Metaspace.
> 
> ## High-Level Overview
> 
> (for a short sequence of slides, please see https://github.com/tstuefe/fosdem24/blob/master/classpointers-and-liliput.pdf - these accompanied a talk we held at FOSDEM 24).
> 
> We want to reduce the bit size of narrow Klass to free up bits in the MarkWord. 
> 
> We cannot just reduce the Klass encoding range size (well, we could, and maybe we will later, but for now we decided not to). We instead increase the alignment Klass is stored at, and use that alignment shadow to store other information.
> 
> In other words, this patch changes the narrow Klass Pointer to a Klass ID, since now (almost) every value in its value range points to a different class. Therefore, we use the value range of nKlass much more efficiently.
> 
> We then use the newly freed bits in the MarkWord to restore the iHash to 31 bits: 
> 
> 
> [ 22-bit nKlass | 31-bit iHash | 4 free bits | age | fwd | lck ]
> 
> nKlass gets reduced to 22 bits. Identity hash gets re-inflated to 31 bits. Preceding iHash are now 4 unused bits. Rest is unchanged.
> 
> (Note: I originally wanted to swap iHash and nKlass such that either of them could be loaded with a 32-bit load, but I found that tricky since C2 seems to rely on the nKlass offset in the Markword being > 0.)
> 
> ## nKlass reduction:
> 
> The reduction in nKlass size is made by only storing them at 10-bit aligned addresses. That alignment (1KB) works well in practice since Klass - although var sized - typically is between 512 bytes and 1KB in size. Outliers are possible, but the size distribution is bell-curvish [1], so far-away outliers are very rare. 
> 
> To not lose memory to alignment waste, metaspace is reshaped to handle arbitrarily aligned allocations efficiently. Basically, we allow the non-Klass arena of a class loader to steal the alignment waste storage from the class arena. So, alignment waste blocks are filled with non-Klass metadata. That works very well in practice since non-Klass metadata is numerous and fine-granular compared to the big Klass blocks. Total footprint loss in metaspace is, therefore, almost ...

Thomas Stuefe has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  Smaller Classpointers for Lilliput
  
  tinycp

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

Changes:
  - all: https://git.openjdk.org/lilliput/pull/128/files
  - new: https://git.openjdk.org/lilliput/pull/128/files/49d289e1..279f5321

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

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/lilliput/pull/128.diff
  Fetch: git fetch https://git.openjdk.org/lilliput.git pull/128/head:pull/128

PR: https://git.openjdk.org/lilliput/pull/128

From stuefe at openjdk.org  Fri Apr 12 13:37:33 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 12 Apr 2024 13:37:33 GMT
Subject: [master] RFR: 8325104: Lilliput: Shrink Classpointers [v6]
In-Reply-To: <lm7SDOvsKA7Yt1yDQpYx5VPVjke0eAO0BB9ctkIA8qs=.206072f0-3274-492d-9224-d41adb3b842a@github.com>
References: <lm7SDOvsKA7Yt1yDQpYx5VPVjke0eAO0BB9ctkIA8qs=.206072f0-3274-492d-9224-d41adb3b842a@github.com>
Message-ID: <i8MBZgiSx3T2VbzyQ-qjr5djQIJgSpbxBT3p4j3sr5Y=.426cf1a9-dfb9-4edf-85a8-c835826c5309@github.com>

> Hi,
> 
> I wanted to get input on the following improvement for Lilliput. Testing is still ongoing, but things look really good, so this patch is hopefully near its final form (barring any objections from reviewers, of course).
> 
> Note: I have a companion patch prepared for upstream, minus the markword changes. I will attempt to get that one upstream quickly in order to not have a large delta between upstream and lilliput, especially in Metaspace.
> 
> ## High-Level Overview
> 
> (for a short sequence of slides, please see https://github.com/tstuefe/fosdem24/blob/master/classpointers-and-liliput.pdf - these accompanied a talk we held at FOSDEM 24).
> 
> We want to reduce the bit size of narrow Klass to free up bits in the MarkWord. 
> 
> We cannot just reduce the Klass encoding range size (well, we could, and maybe we will later, but for now we decided not to). We instead increase the alignment Klass is stored at, and use that alignment shadow to store other information.
> 
> In other words, this patch changes the narrow Klass Pointer to a Klass ID, since now (almost) every value in its value range points to a different class. Therefore, we use the value range of nKlass much more efficiently.
> 
> We then use the newly freed bits in the MarkWord to restore the iHash to 31 bits: 
> 
> 
> [ 22-bit nKlass | 31-bit iHash | 4 free bits | age | fwd | lck ]
> 
> nKlass gets reduced to 22 bits. Identity hash gets re-inflated to 31 bits. Preceding iHash are now 4 unused bits. Rest is unchanged.
> 
> (Note: I originally wanted to swap iHash and nKlass such that either of them could be loaded with a 32-bit load, but I found that tricky since C2 seems to rely on the nKlass offset in the Markword being > 0.)
> 
> ## nKlass reduction:
> 
> The reduction in nKlass size is made by only storing them at 10-bit aligned addresses. That alignment (1KB) works well in practice since Klass - although var sized - typically is between 512 bytes and 1KB in size. Outliers are possible, but the size distribution is bell-curvish [1], so far-away outliers are very rare. 
> 
> To not lose memory to alignment waste, metaspace is reshaped to handle arbitrarily aligned allocations efficiently. Basically, we allow the non-Klass arena of a class loader to steal the alignment waste storage from the class arena. So, alignment waste blocks are filled with non-Klass metadata. That works very well in practice since non-Klass metadata is numerous and fine-granular compared to the big Klass blocks. Total footprint loss in metaspace is, therefore, almost ...

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

  remove COH generation parts from patch

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

Changes:
  - all: https://git.openjdk.org/lilliput/pull/128/files
  - new: https://git.openjdk.org/lilliput/pull/128/files/279f5321..ce59bb0e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=lilliput&pr=128&range=05
 - incr: https://webrevs.openjdk.org/?repo=lilliput&pr=128&range=04-05

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

PR: https://git.openjdk.org/lilliput/pull/128

From stuefe at openjdk.org  Fri Apr 12 14:34:43 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 12 Apr 2024 14:34:43 GMT
Subject: [master] RFR: 8325104: Lilliput: Shrink Classpointers [v7]
In-Reply-To: <lm7SDOvsKA7Yt1yDQpYx5VPVjke0eAO0BB9ctkIA8qs=.206072f0-3274-492d-9224-d41adb3b842a@github.com>
References: <lm7SDOvsKA7Yt1yDQpYx5VPVjke0eAO0BB9ctkIA8qs=.206072f0-3274-492d-9224-d41adb3b842a@github.com>
Message-ID: <fl9Jn5_DLQxCW4wabDDKWvUnSO_IdqsC8Bh1o95YZBg=.731a8757-738f-4267-a758-5aefab794b39@github.com>

> Hi,
> 
> I wanted to get input on the following improvement for Lilliput. Testing is still ongoing, but things look really good, so this patch is hopefully near its final form (barring any objections from reviewers, of course).
> 
> Note: I have a companion patch prepared for upstream, minus the markword changes. I will attempt to get that one upstream quickly in order to not have a large delta between upstream and lilliput, especially in Metaspace.
> 
> ## High-Level Overview
> 
> (for a short sequence of slides, please see https://github.com/tstuefe/fosdem24/blob/master/classpointers-and-liliput.pdf - these accompanied a talk we held at FOSDEM 24).
> 
> We want to reduce the bit size of narrow Klass to free up bits in the MarkWord. 
> 
> We cannot just reduce the Klass encoding range size (well, we could, and maybe we will later, but for now we decided not to). We instead increase the alignment Klass is stored at, and use that alignment shadow to store other information.
> 
> In other words, this patch changes the narrow Klass Pointer to a Klass ID, since now (almost) every value in its value range points to a different class. Therefore, we use the value range of nKlass much more efficiently.
> 
> We then use the newly freed bits in the MarkWord to restore the iHash to 31 bits: 
> 
> 
> [ 22-bit nKlass | 31-bit iHash | 4 free bits | age | fwd | lck ]
> 
> nKlass gets reduced to 22 bits. Identity hash gets re-inflated to 31 bits. Preceding iHash are now 4 unused bits. Rest is unchanged.
> 
> (Note: I originally wanted to swap iHash and nKlass such that either of them could be loaded with a 32-bit load, but I found that tricky since C2 seems to rely on the nKlass offset in the Markword being > 0.)
> 
> ## nKlass reduction:
> 
> The reduction in nKlass size is made by only storing them at 10-bit aligned addresses. That alignment (1KB) works well in practice since Klass - although var sized - typically is between 512 bytes and 1KB in size. Outliers are possible, but the size distribution is bell-curvish [1], so far-away outliers are very rare. 
> 
> To not lose memory to alignment waste, metaspace is reshaped to handle arbitrarily aligned allocations efficiently. Basically, we allow the non-Klass arena of a class loader to steal the alignment waste storage from the class arena. So, alignment waste blocks are filled with non-Klass metadata. That works very well in practice since non-Klass metadata is numerous and fine-granular compared to the big Klass blocks. Total footprint loss in metaspace is, therefore, almost ...

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

  reduce diffs to upstream

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

Changes:
  - all: https://git.openjdk.org/lilliput/pull/128/files
  - new: https://git.openjdk.org/lilliput/pull/128/files/ce59bb0e..ef750c91

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=lilliput&pr=128&range=06
 - incr: https://webrevs.openjdk.org/?repo=lilliput&pr=128&range=05-06

  Stats: 13 lines in 2 files changed: 0 ins; 0 del; 13 mod
  Patch: https://git.openjdk.org/lilliput/pull/128.diff
  Fetch: git fetch https://git.openjdk.org/lilliput.git pull/128/head:pull/128

PR: https://git.openjdk.org/lilliput/pull/128

From stuefe at openjdk.org  Fri Apr 12 14:44:19 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 12 Apr 2024 14:44:19 GMT
Subject: [master] RFR: 8325104: Lilliput: Shrink Classpointers [v8]
In-Reply-To: <lm7SDOvsKA7Yt1yDQpYx5VPVjke0eAO0BB9ctkIA8qs=.206072f0-3274-492d-9224-d41adb3b842a@github.com>
References: <lm7SDOvsKA7Yt1yDQpYx5VPVjke0eAO0BB9ctkIA8qs=.206072f0-3274-492d-9224-d41adb3b842a@github.com>
Message-ID: <LK9DvIp7Objx9ld75Os0qH-yLj5_W7xuA42vaQj9Y1s=.67e8c2a0-9d2c-4299-8bd7-2cb4b00b299b@github.com>

> Hi,
> 
> I wanted to get input on the following improvement for Lilliput. Testing is still ongoing, but things look really good, so this patch is hopefully near its final form (barring any objections from reviewers, of course).
> 
> Note: I have a companion patch prepared for upstream, minus the markword changes. I will attempt to get that one upstream quickly in order to not have a large delta between upstream and lilliput, especially in Metaspace.
> 
> ## High-Level Overview
> 
> (for a short sequence of slides, please see https://github.com/tstuefe/fosdem24/blob/master/classpointers-and-liliput.pdf - these accompanied a talk we held at FOSDEM 24).
> 
> We want to reduce the bit size of narrow Klass to free up bits in the MarkWord. 
> 
> We cannot just reduce the Klass encoding range size (well, we could, and maybe we will later, but for now we decided not to). We instead increase the alignment Klass is stored at, and use that alignment shadow to store other information.
> 
> In other words, this patch changes the narrow Klass Pointer to a Klass ID, since now (almost) every value in its value range points to a different class. Therefore, we use the value range of nKlass much more efficiently.
> 
> We then use the newly freed bits in the MarkWord to restore the iHash to 31 bits: 
> 
> 
> [ 22-bit nKlass | 31-bit iHash | 4 free bits | age | fwd | lck ]
> 
> nKlass gets reduced to 22 bits. Identity hash gets re-inflated to 31 bits. Preceding iHash are now 4 unused bits. Rest is unchanged.
> 
> (Note: I originally wanted to swap iHash and nKlass such that either of them could be loaded with a 32-bit load, but I found that tricky since C2 seems to rely on the nKlass offset in the Markword being > 0.)
> 
> ## nKlass reduction:
> 
> The reduction in nKlass size is made by only storing them at 10-bit aligned addresses. That alignment (1KB) works well in practice since Klass - although var sized - typically is between 512 bytes and 1KB in size. Outliers are possible, but the size distribution is bell-curvish [1], so far-away outliers are very rare. 
> 
> To not lose memory to alignment waste, metaspace is reshaped to handle arbitrarily aligned allocations efficiently. Basically, we allow the non-Klass arena of a class loader to steal the alignment waste storage from the class arena. So, alignment waste blocks are filled with non-Klass metadata. That works very well in practice since non-Klass metadata is numerous and fine-granular compared to the big Klass blocks. Total footprint loss in metaspace is, therefore, almost ...

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

  more of that

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

Changes:
  - all: https://git.openjdk.org/lilliput/pull/128/files
  - new: https://git.openjdk.org/lilliput/pull/128/files/ef750c91..f7c98b6f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=lilliput&pr=128&range=07
 - incr: https://webrevs.openjdk.org/?repo=lilliput&pr=128&range=06-07

  Stats: 19 lines in 7 files changed: 0 ins; 0 del; 19 mod
  Patch: https://git.openjdk.org/lilliput/pull/128.diff
  Fetch: git fetch https://git.openjdk.org/lilliput.git pull/128/head:pull/128

PR: https://git.openjdk.org/lilliput/pull/128

From stuefe at openjdk.org  Fri Apr 12 15:06:04 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 12 Apr 2024 15:06:04 GMT
Subject: [master] RFR: 8325104: Lilliput: Shrink Classpointers [v8]
In-Reply-To: <LK9DvIp7Objx9ld75Os0qH-yLj5_W7xuA42vaQj9Y1s=.67e8c2a0-9d2c-4299-8bd7-2cb4b00b299b@github.com>
References: <lm7SDOvsKA7Yt1yDQpYx5VPVjke0eAO0BB9ctkIA8qs=.206072f0-3274-492d-9224-d41adb3b842a@github.com>
 <LK9DvIp7Objx9ld75Os0qH-yLj5_W7xuA42vaQj9Y1s=.67e8c2a0-9d2c-4299-8bd7-2cb4b00b299b@github.com>
Message-ID: <i-2FUvpg1C1MHEHbWfnKCmrHZE4j3KpL7F3zUMhyuNk=.f5c4247e-2571-405e-8f1f-8731ef4b8a89@github.com>

On Fri, 12 Apr 2024 14:44:19 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Hi,
>> 
>> I wanted to get input on the following improvement for Lilliput. Testing is still ongoing, but things look really good, so this patch is hopefully near its final form (barring any objections from reviewers, of course).
>> 
>> Note: I have a companion patch prepared for upstream, minus the markword changes. I will attempt to get that one upstream quickly in order to not have a large delta between upstream and lilliput, especially in Metaspace.
>> 
>> ## High-Level Overview
>> 
>> (for a short sequence of slides, please see https://github.com/tstuefe/fosdem24/blob/master/classpointers-and-liliput.pdf - these accompanied a talk we held at FOSDEM 24).
>> 
>> We want to reduce the bit size of narrow Klass to free up bits in the MarkWord. 
>> 
>> We cannot just reduce the Klass encoding range size (well, we could, and maybe we will later, but for now we decided not to). We instead increase the alignment Klass is stored at, and use that alignment shadow to store other information.
>> 
>> In other words, this patch changes the narrow Klass Pointer to a Klass ID, since now (almost) every value in its value range points to a different class. Therefore, we use the value range of nKlass much more efficiently.
>> 
>> We then use the newly freed bits in the MarkWord to restore the iHash to 31 bits: 
>> 
>> 
>> [ 22-bit nKlass | 31-bit iHash | 4 free bits | age | fwd | lck ]
>> 
>> nKlass gets reduced to 22 bits. Identity hash gets re-inflated to 31 bits. Preceding iHash are now 4 unused bits. Rest is unchanged.
>> 
>> (Note: I originally wanted to swap iHash and nKlass such that either of them could be loaded with a 32-bit load, but I found that tricky since C2 seems to rely on the nKlass offset in the Markword being > 0.)
>> 
>> ## nKlass reduction:
>> 
>> The reduction in nKlass size is made by only storing them at 10-bit aligned addresses. That alignment (1KB) works well in practice since Klass - although var sized - typically is between 512 bytes and 1KB in size. Outliers are possible, but the size distribution is bell-curvish [1], so far-away outliers are very rare. 
>> 
>> To not lose memory to alignment waste, metaspace is reshaped to handle arbitrarily aligned allocations efficiently. Basically, we allow the non-Klass arena of a class loader to steal the alignment waste storage from the class arena. So, alignment waste blocks are filled with non-Klass metadata. That works very well in practice since non-Klass metadata is numerous and fine-granular compared to the big Klass bloc...
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more of that

I'm taking this back to draft to avoid further mail spamming.

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

PR Comment: https://git.openjdk.org/lilliput/pull/128#issuecomment-2051938666

From shade at openjdk.org  Thu Apr 18 12:00:26 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 18 Apr 2024 12:00:26 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8319799: Recursive lightweight
 locking: x86 implementation
In-Reply-To: <uoxFDNVNgDmpZTsockYB1JKKxf0jNGJaVNZfNDmMGKY=.490dee41-3cac-4777-83fe-f817b323d14d@github.com>
References: <uoxFDNVNgDmpZTsockYB1JKKxf0jNGJaVNZfNDmMGKY=.490dee41-3cac-4777-83fe-f817b323d14d@github.com>
Message-ID: <rhNr4nognQ7WtorOK5EbCF4alvS-L_9b_-UC5z0fZaU=.8fade7f3-0faa-4b16-a6a6-a7747d8a379d@github.com>

On Wed, 10 Apr 2024 10:48:43 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Backports https://github.com/openjdk/jdk/commit/7f6bb71eb302e8388c959bdaa914b758a766d299
> 
> Implements the x86_64 parts of recursive lightweight locking.
> 
> Unclean, mostly because of biased locking.

Looks okay, but I have a minor comment.

It looks like `lightweight_lock` does not need pre-loaded header anymore. Yet, some uses of it still load the header. I see the original commit moved header loading to `!LM_LIGHTWEIGHT` branches: https://github.com/openjdk/jdk/commit/7f6bb71eb302e8388c959bdaa914b758a766d299#diff-4ce1e880593668bead8462bc6b550bb21e11ad7dd1d8a43d77d5dac7510ba9c3L63

Seems like at least here we load the `hdr`: https://github.com/openjdk/lilliput-jdk17u/pull/84/files#diff-4ce1e880593668bead8462bc6b550bb21e11ad7dd1d8a43d77d5dac7510ba9c3R73-R74

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

Marked as reviewed by shade (Committer).

PR Review: https://git.openjdk.org/lilliput-jdk17u/pull/84#pullrequestreview-2008682373

From shade at openjdk.org  Thu Apr 18 12:08:29 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 18 Apr 2024 12:08:29 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8319801: Recursive lightweight
 locking: aarch64 implementation
In-Reply-To: <WIDXmzFNjtZmbgGDLykCOZqW49OjcshcBJZ_0RSXBYs=.fcd90dd9-6d9e-428e-8c25-14b48da29737@github.com>
References: <WIDXmzFNjtZmbgGDLykCOZqW49OjcshcBJZ_0RSXBYs=.fcd90dd9-6d9e-428e-8c25-14b48da29737@github.com>
Message-ID: <xVCCJ6F5QDqgPIe2D9i7gTqHs9uzwkxIhb2vtsjste4=.6f7d5dff-0ac6-4781-82e5-d50a3c434998@github.com>

On Wed, 10 Apr 2024 10:46:12 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Backports https://github.com/openjdk/jdk/commit/18cea823a173e1b8b48d276daeca67b2a5cf3584
> 
> Implements the aarch64 parts of recursive lightweight locking.
> 
> Unclean, mostly because of biased locking.

Looks fine.

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

Marked as reviewed by shade (Committer).

PR Review: https://git.openjdk.org/lilliput-jdk17u/pull/83#pullrequestreview-2008701741

From rkennke at openjdk.org  Thu Apr 18 13:51:32 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 18 Apr 2024 13:51:32 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8319799: Recursive lightweight
 locking: x86 implementation [v2]
In-Reply-To: <uoxFDNVNgDmpZTsockYB1JKKxf0jNGJaVNZfNDmMGKY=.490dee41-3cac-4777-83fe-f817b323d14d@github.com>
References: <uoxFDNVNgDmpZTsockYB1JKKxf0jNGJaVNZfNDmMGKY=.490dee41-3cac-4777-83fe-f817b323d14d@github.com>
Message-ID: <vII_ESTl8Xfmm7-Sz1-kmNqRsSQCo7TJH2iSmCwXc64=.7184e97f-cf93-4acb-b50f-b0a0bcd961de@github.com>

> Backports https://github.com/openjdk/jdk/commit/7f6bb71eb302e8388c959bdaa914b758a766d299
> 
> Implements the x86_64 parts of recursive lightweight locking.
> 
> Unclean, mostly because of biased locking.

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Remove superfluous loading of mark-word

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

Changes:
  - all: https://git.openjdk.org/lilliput-jdk17u/pull/84/files
  - new: https://git.openjdk.org/lilliput-jdk17u/pull/84/files/070ada8a..cfb057fc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=lilliput-jdk17u&pr=84&range=01
 - incr: https://webrevs.openjdk.org/?repo=lilliput-jdk17u&pr=84&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/lilliput-jdk17u/pull/84.diff
  Fetch: git fetch https://git.openjdk.org/lilliput-jdk17u.git pull/84/head:pull/84

PR: https://git.openjdk.org/lilliput-jdk17u/pull/84

From rkennke at openjdk.org  Thu Apr 18 14:02:33 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 18 Apr 2024 14:02:33 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8319799: Recursive lightweight
 locking: x86 implementation [v2]
In-Reply-To: <vII_ESTl8Xfmm7-Sz1-kmNqRsSQCo7TJH2iSmCwXc64=.7184e97f-cf93-4acb-b50f-b0a0bcd961de@github.com>
References: <uoxFDNVNgDmpZTsockYB1JKKxf0jNGJaVNZfNDmMGKY=.490dee41-3cac-4777-83fe-f817b323d14d@github.com>
 <vII_ESTl8Xfmm7-Sz1-kmNqRsSQCo7TJH2iSmCwXc64=.7184e97f-cf93-4acb-b50f-b0a0bcd961de@github.com>
Message-ID: <yIY0rkzOrGl9d0guaEd9NcePzOFibPPcceOwOQ84ijM=.aa0d3281-246a-46da-bbc6-feae2385b3c4@github.com>

On Thu, 18 Apr 2024 13:51:32 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Backports https://github.com/openjdk/jdk/commit/7f6bb71eb302e8388c959bdaa914b758a766d299
>> 
>> Implements the x86_64 parts of recursive lightweight locking.
>> 
>> Unclean, mostly because of biased locking.
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove superfluous loading of mark-word

> Looks okay, but I have a minor comment.
> 
> It looks like `lightweight_lock` does not need pre-loaded header anymore. Yet, some uses of it still load the header. I see the original commit moved header loading to `!LM_LIGHTWEIGHT` branches: [openjdk/jdk at 7f6bb71#diff-4ce1e880593668bead8462bc6b550bb21e11ad7dd1d8a43d77d5dac7510ba9c3L63](https://github.com/openjdk/jdk/commit/7f6bb71eb302e8388c959bdaa914b758a766d299#diff-4ce1e880593668bead8462bc6b550bb21e11ad7dd1d8a43d77d5dac7510ba9c3L63)
> 
> Seems like at least here we load the `hdr`: https://github.com/openjdk/lilliput-jdk17u/pull/84/files#diff-4ce1e880593668bead8462bc6b550bb21e11ad7dd1d8a43d77d5dac7510ba9c3R73-R74

Indeed, good catch. I removed that extra load and checked other places for similar oversights, but everything else seems ok.

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

PR Comment: https://git.openjdk.org/lilliput-jdk17u/pull/84#issuecomment-2063935681

From shade at openjdk.org  Thu Apr 18 17:17:20 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 18 Apr 2024 17:17:20 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8319799: Recursive lightweight
 locking: x86 implementation [v2]
In-Reply-To: <vII_ESTl8Xfmm7-Sz1-kmNqRsSQCo7TJH2iSmCwXc64=.7184e97f-cf93-4acb-b50f-b0a0bcd961de@github.com>
References: <uoxFDNVNgDmpZTsockYB1JKKxf0jNGJaVNZfNDmMGKY=.490dee41-3cac-4777-83fe-f817b323d14d@github.com>
 <vII_ESTl8Xfmm7-Sz1-kmNqRsSQCo7TJH2iSmCwXc64=.7184e97f-cf93-4acb-b50f-b0a0bcd961de@github.com>
Message-ID: <okm0C9vzVkeKXdl_U_cZ0373EFpqAcGC0Lh5p6dWfZA=.1c79e8bf-4c16-404c-8f99-cacdd44b02c8@github.com>

On Thu, 18 Apr 2024 13:51:32 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Backports https://github.com/openjdk/jdk/commit/7f6bb71eb302e8388c959bdaa914b758a766d299
>> 
>> Implements the x86_64 parts of recursive lightweight locking.
>> 
>> Unclean, mostly because of biased locking.
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove superfluous loading of mark-word

Marked as reviewed by shade (Committer).

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

PR Review: https://git.openjdk.org/lilliput-jdk17u/pull/84#pullrequestreview-2009463218

From rkennke at openjdk.org  Thu Apr 18 18:16:09 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 18 Apr 2024 18:16:09 GMT
Subject: [lilliput-jdk17u:lilliput] Integrated: 8319799: Recursive lightweight
 locking: x86 implementation
In-Reply-To: <uoxFDNVNgDmpZTsockYB1JKKxf0jNGJaVNZfNDmMGKY=.490dee41-3cac-4777-83fe-f817b323d14d@github.com>
References: <uoxFDNVNgDmpZTsockYB1JKKxf0jNGJaVNZfNDmMGKY=.490dee41-3cac-4777-83fe-f817b323d14d@github.com>
Message-ID: <peLZClc8o36J5ZVuFE4Fn5VlNGlVRMeetpDrFbLsdT8=.e888de9c-88d4-4200-9bca-1d6cc3def5ab@github.com>

On Wed, 10 Apr 2024 10:48:43 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Backports https://github.com/openjdk/jdk/commit/7f6bb71eb302e8388c959bdaa914b758a766d299
> 
> Implements the x86_64 parts of recursive lightweight locking.
> 
> Unclean, mostly because of biased locking.

This pull request has now been integrated.

Changeset: de840e28
Author:    Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.org/lilliput-jdk17u/commit/de840e286ce8196ae0ae562a95e62c6d37ca07de
Stats:     581 lines in 13 files changed: 440 ins; 59 del; 82 mod

8319799: Recursive lightweight locking: x86 implementation

Reviewed-by: shade
Backport-of: 7f6bb71eb302e8388c959bdaa914b758a766d299

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

PR: https://git.openjdk.org/lilliput-jdk17u/pull/84

From rkennke at openjdk.org  Thu Apr 18 18:20:12 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 18 Apr 2024 18:20:12 GMT
Subject: [lilliput-jdk17u:lilliput] Integrated: 8319801: Recursive lightweight
 locking: aarch64 implementation
In-Reply-To: <WIDXmzFNjtZmbgGDLykCOZqW49OjcshcBJZ_0RSXBYs=.fcd90dd9-6d9e-428e-8c25-14b48da29737@github.com>
References: <WIDXmzFNjtZmbgGDLykCOZqW49OjcshcBJZ_0RSXBYs=.fcd90dd9-6d9e-428e-8c25-14b48da29737@github.com>
Message-ID: <dU5uA_VlAbr5-9RFI-lYbB0lL4TlDtBw0sFvqxe-WGg=.5567182a-9a71-4200-8843-ab235644a4a1@github.com>

On Wed, 10 Apr 2024 10:46:12 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Backports https://github.com/openjdk/jdk/commit/18cea823a173e1b8b48d276daeca67b2a5cf3584
> 
> Implements the aarch64 parts of recursive lightweight locking.
> 
> Unclean, mostly because of biased locking.

This pull request has now been integrated.

Changeset: d57f3d16
Author:    Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.org/lilliput-jdk17u/commit/d57f3d16548a4d0d47a98a541f6bec1afc929f8b
Stats:     488 lines in 9 files changed: 350 ins; 80 del; 58 mod

8319801: Recursive lightweight locking: aarch64 implementation

Reviewed-by: shade
Backport-of: 18cea823a173e1b8b48d276daeca67b2a5cf3584

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

PR: https://git.openjdk.org/lilliput-jdk17u/pull/83

From stefank at openjdk.org  Fri Apr 19 13:34:32 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 19 Apr 2024 13:34:32 GMT
Subject: [master] RFR: Parallel: fix checks for forwarded objects
Message-ID: <rEoeH7QxTHIep0LQoHyop7214ueE_1bdpwEIiVVXeI8=.ffca9927-830f-4a4e-9e68-4b6694161181@github.com>

Fix so that we included self-forwarded objects when checking for forwarded objects.

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

Commit messages:
 - Parallel: fix checks for forwarded objects

Changes: https://git.openjdk.org/lilliput/pull/147/files
  Webrev: https://webrevs.openjdk.org/?repo=lilliput&pr=147&range=00
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/lilliput/pull/147.diff
  Fetch: git fetch https://git.openjdk.org/lilliput.git pull/147/head:pull/147

PR: https://git.openjdk.org/lilliput/pull/147

From rkennke at openjdk.org  Fri Apr 19 13:43:06 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 19 Apr 2024 13:43:06 GMT
Subject: [master] RFR: Parallel: fix checks for forwarded objects
In-Reply-To: <rEoeH7QxTHIep0LQoHyop7214ueE_1bdpwEIiVVXeI8=.ffca9927-830f-4a4e-9e68-4b6694161181@github.com>
References: <rEoeH7QxTHIep0LQoHyop7214ueE_1bdpwEIiVVXeI8=.ffca9927-830f-4a4e-9e68-4b6694161181@github.com>
Message-ID: <TC3doT8jwqCmXnWITia1CwicpZyo-pFyY47iM578dLA=.b8415548-f185-4df4-aac5-ce415e23a000@github.com>

On Fri, 19 Apr 2024 12:34:18 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> Fix so that we included self-forwarded objects when checking for forwarded objects.

Looks good! Thanks!

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

Marked as reviewed by rkennke (Lead).

PR Review: https://git.openjdk.org/lilliput/pull/147#pullrequestreview-2011464264

From stefank at openjdk.org  Fri Apr 19 13:43:06 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 19 Apr 2024 13:43:06 GMT
Subject: [master] RFR: Parallel: fix checks for forwarded objects
In-Reply-To: <rEoeH7QxTHIep0LQoHyop7214ueE_1bdpwEIiVVXeI8=.ffca9927-830f-4a4e-9e68-4b6694161181@github.com>
References: <rEoeH7QxTHIep0LQoHyop7214ueE_1bdpwEIiVVXeI8=.ffca9927-830f-4a4e-9e68-4b6694161181@github.com>
Message-ID: <NBPX47e3QiFtjD7UDEBYvA40jJXLcFWBE_ncVAb6kWM=.7b868ab3-e59e-4786-a9a3-0086b83a1258@github.com>

On Fri, 19 Apr 2024 12:34:18 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> Fix so that we included self-forwarded objects when checking for forwarded objects.

Thanks for the review!

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

PR Comment: https://git.openjdk.org/lilliput/pull/147#issuecomment-2066613373

From stefank at openjdk.org  Fri Apr 19 13:43:07 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 19 Apr 2024 13:43:07 GMT
Subject: [master] Integrated: Parallel: fix checks for forwarded objects
In-Reply-To: <rEoeH7QxTHIep0LQoHyop7214ueE_1bdpwEIiVVXeI8=.ffca9927-830f-4a4e-9e68-4b6694161181@github.com>
References: <rEoeH7QxTHIep0LQoHyop7214ueE_1bdpwEIiVVXeI8=.ffca9927-830f-4a4e-9e68-4b6694161181@github.com>
Message-ID: <RxWA4f9jOePbpfG440B5iH4jg1F67GHs8kdfKX5eDl4=.7b1eb0ba-5281-4c21-88ca-30ca00006174@github.com>

On Fri, 19 Apr 2024 12:34:18 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> Fix so that we included self-forwarded objects when checking for forwarded objects.

This pull request has now been integrated.

Changeset: 9ee00e0f
Author:    Stefan Karlsson <stefank at openjdk.org>
URL:       https://git.openjdk.org/lilliput/commit/9ee00e0fcec439d39681cc16bddca3ce0c41f581
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

Parallel: fix checks for forwarded objects

Reviewed-by: rkennke

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

PR: https://git.openjdk.org/lilliput/pull/147

From stefank at openjdk.org  Fri Apr 19 14:04:27 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 19 Apr 2024 14:04:27 GMT
Subject: [master] RFR: Parallel: modify to-space object in array chunking
Message-ID: <vWppDSfDayiixAmpHipWzMnBpiYtC8xfad0aMzBn6To=.ab53633e-f7e2-415a-8626-22b78e817dec@github.com>

The ParallelGC chunks arrays so that it can somewhat parallelize the array processing. This is done by rewriting the length field of the from-space object. This causes a problem for Lilliput when one thread copies an object, forwards it, and then rewrites the length of the from-space copy, while another thread tries to figure out if it should copy the object and tries to read the size of the object.

The second thread tries to stay away from calling 'oopDesc::klass()` on the from-space object, because the header might have been overwritten by another thread. So, it only reads the mark word, tries to figure out the object has been forwarded, and then calls `size_given_klass` to figure out the size.

The `size_given_klass` has some asserts that checks that the different ways to calculate array sizes are consistent, but since other threads could be updating the length field, there is an escape-hatch that makes that assert less strict. This is the assert:

assert(s == klass->oop_size(this) || size_might_change(), "wrong array object size");


The problem for Lilliput is that `size_might_change()` rereads the object's klass pointer, which will fail because the header is overwritten with a forwarding pointer.

This can be fixed by passing in the klass or maybe by following the forwarding pointer to find the to-space object and find the klass from there, but I wonder if this all wouldn't be safer if we left the from-space object unmodified and instead changed the length field of the to-space object. In fact, this is exactly what G1 does since many years (which also indicates that the `size_might_change()` really shouldn't be checking for UseG1GC).

The above is a proposal of what this would look like. I'm publishing this here for Lilliput because it fixes a real bug here, but if this is the right way to go forward, then this should likely be upstreamed as well.

I've run this through tier1-3 with both UseParallelGC and UseCompactObjectHeaders enabled, and I'm currently running this through higher Oracle tiers.

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

Commit messages:
 - Parallel: modify to-space object in array chunking

Changes: https://git.openjdk.org/lilliput/pull/149/files
  Webrev: https://webrevs.openjdk.org/?repo=lilliput&pr=149&range=00
  Stats: 26 lines in 4 files changed: 0 ins; 13 del; 13 mod
  Patch: https://git.openjdk.org/lilliput/pull/149.diff
  Fetch: git fetch https://git.openjdk.org/lilliput.git pull/149/head:pull/149

PR: https://git.openjdk.org/lilliput/pull/149

From rkennke at openjdk.org  Fri Apr 19 14:21:25 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 19 Apr 2024 14:21:25 GMT
Subject: [master] RFR: Parallel: modify to-space object in array chunking
In-Reply-To: <vWppDSfDayiixAmpHipWzMnBpiYtC8xfad0aMzBn6To=.ab53633e-f7e2-415a-8626-22b78e817dec@github.com>
References: <vWppDSfDayiixAmpHipWzMnBpiYtC8xfad0aMzBn6To=.ab53633e-f7e2-415a-8626-22b78e817dec@github.com>
Message-ID: <50idkk8ypVV_gHVUOEvihC52mxhluDqjlgd8Q1ouU9Q=.f742a83d-70c9-4280-ac22-82c1a34dc834@github.com>

On Fri, 19 Apr 2024 13:59:21 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> The ParallelGC chunks arrays so that it can somewhat parallelize the array processing. This is done by rewriting the length field of the from-space object. This causes a problem for Lilliput when one thread copies an object, forwards it, and then rewrites the length of the from-space copy, while another thread tries to figure out if it should copy the object and tries to read the size of the object.
> 
> The second thread tries to stay away from calling 'oopDesc::klass()` on the from-space object, because the header might have been overwritten by another thread. So, it only reads the mark word, tries to figure out the object has been forwarded, and then calls `size_given_klass` to figure out the size.
> 
> The `size_given_klass` has some asserts that checks that the different ways to calculate array sizes are consistent, but since other threads could be updating the length field, there is an escape-hatch that makes that assert less strict. This is the assert:
> 
> assert(s == klass->oop_size(this) || size_might_change(), "wrong array object size");
> 
> 
> The problem for Lilliput is that `size_might_change()` rereads the object's klass pointer, which will fail because the header is overwritten with a forwarding pointer.
> 
> This can be fixed by passing in the klass or maybe by following the forwarding pointer to find the to-space object and find the klass from there, but I wonder if this all wouldn't be safer if we left the from-space object unmodified and instead changed the length field of the to-space object. In fact, this is exactly what G1 does since many years (which also indicates that the `size_might_change()` really shouldn't be checking for UseG1GC).
> 
> The above is a proposal of what this would look like. I'm publishing this here for Lilliput because it fixes a real bug here, but if this is the right way to go forward, then this should likely be upstreamed as well.
> 
> I've run this through tier1-3 with both UseParallelGC and UseCompactObjectHeaders enabled, and I'm currently running this through higher Oracle tiers.

I think it's reasonable and correct.
I don't feel very comfortable messing with the length-field, though. Going forward, we might consider doing what's done in Shenandoah instead, and encode the chunking in the task object.
https://github.com/openjdk/jdk/blob/177092b952c2135c6f6872c6b64d1e210452d35a/src/hotspot/share/gc/shenandoah/shenandoahTaskqueue.hpp#L66

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

Marked as reviewed by rkennke (Lead).

PR Review: https://git.openjdk.org/lilliput/pull/149#pullrequestreview-2011564621

From stefank at openjdk.org  Fri Apr 19 14:39:17 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 19 Apr 2024 14:39:17 GMT
Subject: [master] RFR: Parallel: modify to-space object in array chunking
In-Reply-To: <vWppDSfDayiixAmpHipWzMnBpiYtC8xfad0aMzBn6To=.ab53633e-f7e2-415a-8626-22b78e817dec@github.com>
References: <vWppDSfDayiixAmpHipWzMnBpiYtC8xfad0aMzBn6To=.ab53633e-f7e2-415a-8626-22b78e817dec@github.com>
Message-ID: <GXhPIsBLso0XCKBwHWmWSLR6W_PfBm5OD4rEDu2Yduc=.c802eb43-9142-459e-b956-0bb85401759a@github.com>

On Fri, 19 Apr 2024 13:59:21 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> The ParallelGC chunks arrays so that it can somewhat parallelize the array processing. This is done by rewriting the length field of the from-space object. This causes a problem for Lilliput when one thread copies an object, forwards it, and then rewrites the length of the from-space copy, while another thread tries to figure out if it should copy the object and tries to read the size of the object.
> 
> The second thread tries to stay away from calling 'oopDesc::klass()` on the from-space object, because the header might have been overwritten by another thread. So, it only reads the mark word, tries to figure out the object has been forwarded, and then calls `size_given_klass` to figure out the size.
> 
> The `size_given_klass` has some asserts that checks that the different ways to calculate array sizes are consistent, but since other threads could be updating the length field, there is an escape-hatch that makes that assert less strict. This is the assert:
> 
> assert(s == klass->oop_size(this) || size_might_change(), "wrong array object size");
> 
> 
> The problem for Lilliput is that `size_might_change()` rereads the object's klass pointer, which will fail because the header is overwritten with a forwarding pointer.
> 
> This can be fixed by passing in the klass or maybe by following the forwarding pointer to find the to-space object and find the klass from there, but I wonder if this all wouldn't be safer if we left the from-space object unmodified and instead changed the length field of the to-space object. In fact, this is exactly what G1 does since many years (which also indicates that the `size_might_change()` really shouldn't be checking for UseG1GC).
> 
> The above is a proposal of what this would look like. I'm publishing this here for Lilliput because it fixes a real bug here, but if this is the right way to go forward, then this should likely be upstreamed as well.
> 
> I've run this through tier1-3 with both UseParallelGC and UseCompactObjectHeaders enabled, and I'm currently running this through higher Oracle tiers.

I took one step out the door for a walk and immediately realized that during promotion failure the from-space object becomes a to-space object and we're back to square one.

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

PR Comment: https://git.openjdk.org/lilliput/pull/149#issuecomment-2066719865

From stefank at openjdk.org  Fri Apr 19 14:42:10 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 19 Apr 2024 14:42:10 GMT
Subject: [master] RFR: Parallel: modify to-space object in array chunking
In-Reply-To: <50idkk8ypVV_gHVUOEvihC52mxhluDqjlgd8Q1ouU9Q=.f742a83d-70c9-4280-ac22-82c1a34dc834@github.com>
References: <vWppDSfDayiixAmpHipWzMnBpiYtC8xfad0aMzBn6To=.ab53633e-f7e2-415a-8626-22b78e817dec@github.com>
 <50idkk8ypVV_gHVUOEvihC52mxhluDqjlgd8Q1ouU9Q=.f742a83d-70c9-4280-ac22-82c1a34dc834@github.com>
Message-ID: <x9aOssUHsBgUCKPT9mqED_v5sb__a6gGy87ll_gbZxE=.b17b8c1a-04dd-425f-90b0-6b2e2b6df0bd@github.com>

On Fri, 19 Apr 2024 14:18:25 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> ... I don't feel very comfortable messing with the length-field, though. Going forward, we might consider doing what's done in Shenandoah instead, and encode the chunking in the task object. https://github.com/openjdk/jdk/blob/177092b952c2135c6f6872c6b64d1e210452d35a/src/hotspot/share/gc/shenandoah/shenandoahTaskqueue.hpp#L66

I agree. FWIW, ZGC also encodes the chunk in the "task":
https://github.com/openjdk/jdk/blob/177092b952c2135c6f6872c6b64d1e210452d35a/src/hotspot/share/gc/z/zMarkStackEntry.hpp#L56

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

PR Comment: https://git.openjdk.org/lilliput/pull/149#issuecomment-2066724754

From stefank at openjdk.org  Fri Apr 19 15:36:15 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 19 Apr 2024 15:36:15 GMT
Subject: [master] RFR: SA: Remove !hasMonitor() assert in getKlass()
Message-ID: <QqQOvaM0P2ICaP7GSPInP00pfbsKGr4BkNSZp9-AyOk=.f086be49-f678-476f-ab99-2d8394cb49f2@github.com>

Small patch to fix SA testing with UCOH.

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

Commit messages:
 - SA: Removing !monitor() assert in getKlass()

Changes: https://git.openjdk.org/lilliput/pull/150/files
  Webrev: https://webrevs.openjdk.org/?repo=lilliput&pr=150&range=00
  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/lilliput/pull/150.diff
  Fetch: git fetch https://git.openjdk.org/lilliput.git pull/150/head:pull/150

PR: https://git.openjdk.org/lilliput/pull/150

From rkennke at openjdk.org  Fri Apr 19 16:00:25 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 19 Apr 2024 16:00:25 GMT
Subject: [master] RFR: SA: Remove !hasMonitor() assert in getKlass()
In-Reply-To: <QqQOvaM0P2ICaP7GSPInP00pfbsKGr4BkNSZp9-AyOk=.f086be49-f678-476f-ab99-2d8394cb49f2@github.com>
References: <QqQOvaM0P2ICaP7GSPInP00pfbsKGr4BkNSZp9-AyOk=.f086be49-f678-476f-ab99-2d8394cb49f2@github.com>
Message-ID: <_2ffx3nHCRosoVl0iDOhEpeaQt_29FJGV8XrelQLp84=.2d0c0147-b6f0-4066-b126-f6757214c704@github.com>

On Fri, 19 Apr 2024 15:30:38 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> Small patch to fix SA testing with UCOH.

Oops. My oversight.
Looks good!

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

Marked as reviewed by rkennke (Lead).

PR Review: https://git.openjdk.org/lilliput/pull/150#pullrequestreview-2011809458

From stefank at openjdk.org  Mon Apr 22 07:34:59 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 22 Apr 2024 07:34:59 GMT
Subject: [master] RFR: SA: Remove !hasMonitor() assert in getKlass()
In-Reply-To: <QqQOvaM0P2ICaP7GSPInP00pfbsKGr4BkNSZp9-AyOk=.f086be49-f678-476f-ab99-2d8394cb49f2@github.com>
References: <QqQOvaM0P2ICaP7GSPInP00pfbsKGr4BkNSZp9-AyOk=.f086be49-f678-476f-ab99-2d8394cb49f2@github.com>
Message-ID: <ugDy17E-1u5zsMfaJMKqLgR01VJ_N_MYuF_HZCLWu8E=.0957991a-170f-4092-a892-0c70417edb45@github.com>

On Fri, 19 Apr 2024 15:30:38 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> Small patch to fix SA testing with UCOH.

Thanks for reviewing!

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

PR Comment: https://git.openjdk.org/lilliput/pull/150#issuecomment-2068682765

From stefank at openjdk.org  Mon Apr 22 07:35:00 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 22 Apr 2024 07:35:00 GMT
Subject: [master] Integrated: SA: Remove !hasMonitor() assert in getKlass()
In-Reply-To: <QqQOvaM0P2ICaP7GSPInP00pfbsKGr4BkNSZp9-AyOk=.f086be49-f678-476f-ab99-2d8394cb49f2@github.com>
References: <QqQOvaM0P2ICaP7GSPInP00pfbsKGr4BkNSZp9-AyOk=.f086be49-f678-476f-ab99-2d8394cb49f2@github.com>
Message-ID: <ysPomNWBloVOlIGiQRKm7Vx5iNoehHTky-t5FUcf--A=.690b7118-65dd-41a7-9b41-14b51a0d7728@github.com>

On Fri, 19 Apr 2024 15:30:38 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> Small patch to fix SA testing with UCOH.

This pull request has now been integrated.

Changeset: fd2c7f97
Author:    Stefan Karlsson <stefank at openjdk.org>
URL:       https://git.openjdk.org/lilliput/commit/fd2c7f970f09ae3ed75a9bfe90bfe87f5f6510b6
Stats:     1 line in 1 file changed: 0 ins; 1 del; 0 mod

SA: Remove !hasMonitor() assert in getKlass()

Reviewed-by: rkennke

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

PR: https://git.openjdk.org/lilliput/pull/150

From stefank at openjdk.org  Mon Apr 22 07:44:45 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 22 Apr 2024 07:44:45 GMT
Subject: [master] RFR: JVMCI: Don't call CompressedKlassPointers functions with
 -UCCP
Message-ID: <fJz0-aKZ5m3JsSTtH5-ShhPKWS7tRjpIYIUt5QskbbM=.b4b41662-377c-4393-a962-52cdf13f5a06@github.com>

We hit this assert when running JVMCI tests and -XX:-UseCompressedClassPointers:

#  Internal Error (/home/stefank/git/jdk/open/src/hotspot/share/oops/compressedKlass.hpp:95), pid=1496156, tid=1496350                                                                                                                                                                                                                                                                                                                     
#  assert(var != (T)-1) failed: Not yet initialized
...
V  [libjvm.so+0x10346ec]  CompilerToVM::Data::initialize(JVMCIEnv*)+0x44c  (compressedKlass.hpp:95)                                                                                                                                                                                                                                                                                                                                        
V  [libjvm.so+0x1057999]  readConfiguration0(JNIEnv_*, JVMCIEnv*)+0x159  (jvmciCompilerToVMInit.cpp:382) 


A simple fix is to stop calling the CompressedKlassPointers:: functions.

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

Commit messages:
 - JVMCI: Don't call CompressedKlassPointers functions with -UCCP

Changes: https://git.openjdk.org/lilliput/pull/151/files
  Webrev: https://webrevs.openjdk.org/?repo=lilliput&pr=151&range=00
  Stats: 8 lines in 1 file changed: 6 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/lilliput/pull/151.diff
  Fetch: git fetch https://git.openjdk.org/lilliput.git pull/151/head:pull/151

PR: https://git.openjdk.org/lilliput/pull/151

From rkennke at openjdk.org  Mon Apr 22 08:25:56 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 22 Apr 2024 08:25:56 GMT
Subject: [master] RFR: JVMCI: Don't call CompressedKlassPointers functions
 with -UCCP
In-Reply-To: <fJz0-aKZ5m3JsSTtH5-ShhPKWS7tRjpIYIUt5QskbbM=.b4b41662-377c-4393-a962-52cdf13f5a06@github.com>
References: <fJz0-aKZ5m3JsSTtH5-ShhPKWS7tRjpIYIUt5QskbbM=.b4b41662-377c-4393-a962-52cdf13f5a06@github.com>
Message-ID: <MUBk3Zmpx0uRTt9yYssy_js0uT7kUAzAufDmFMYeeqw=.dc76ebdd-1256-47ee-8338-1bdf14be0773@github.com>

On Mon, 22 Apr 2024 07:39:58 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> We hit this assert when running JVMCI tests and -XX:-UseCompressedClassPointers:
> 
> #  Internal Error (/home/stefank/git/jdk/open/src/hotspot/share/oops/compressedKlass.hpp:95), pid=1496156, tid=1496350                                                                                                                                                                                                                                                                                                                     
> #  assert(var != (T)-1) failed: Not yet initialized
> ...
> V  [libjvm.so+0x10346ec]  CompilerToVM::Data::initialize(JVMCIEnv*)+0x44c  (compressedKlass.hpp:95)                                                                                                                                                                                                                                                                                                                                        
> V  [libjvm.so+0x1057999]  readConfiguration0(JNIEnv_*, JVMCIEnv*)+0x159  (jvmciCompilerToVMInit.cpp:382) 
> 
> 
> A simple fix is to stop calling the CompressedKlassPointers:: functions.

How is this Lilliput-specific?

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

PR Comment: https://git.openjdk.org/lilliput/pull/151#issuecomment-2068787894

From rkennke at openjdk.org  Mon Apr 22 08:26:12 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 22 Apr 2024 08:26:12 GMT
Subject: [master] RFR: 8319185: [Lilliput] Enable and fix vectorization tests
Message-ID: <ZnI9tBlTse9_zsW3AKCOn3npi3vgMOZfbo-Eolh2fns=.63bf30ec-d43b-40e5-9b38-07312aefa403@github.com>

This re-instates #125 after it has been lost with the Great Reset. It's a clean cherry-pick of that other commit.

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

Commit messages:
 - 8319185: [Lilliput] Enable and fix vectorization tests

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

PR: https://git.openjdk.org/lilliput/pull/152

From stefank at openjdk.org  Mon Apr 22 08:34:47 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 22 Apr 2024 08:34:47 GMT
Subject: [master] RFR: JVMCI: Don't call CompressedKlassPointers functions
 with -UCCP
In-Reply-To: <fJz0-aKZ5m3JsSTtH5-ShhPKWS7tRjpIYIUt5QskbbM=.b4b41662-377c-4393-a962-52cdf13f5a06@github.com>
References: <fJz0-aKZ5m3JsSTtH5-ShhPKWS7tRjpIYIUt5QskbbM=.b4b41662-377c-4393-a962-52cdf13f5a06@github.com>
Message-ID: <-YAEPjuxSGTB2mG_D1HnrqPRDRah3C8k1x9AaYMkHzM=.addfdc64-80b4-42d1-a9f3-175643051a91@github.com>

On Mon, 22 Apr 2024 07:39:58 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> We hit this assert when running JVMCI tests and -XX:-UseCompressedClassPointers:
> 
> #  Internal Error (/home/stefank/git/jdk/open/src/hotspot/share/oops/compressedKlass.hpp:95), pid=1496156, tid=1496350                                                                                                                                                                                                                                                                                                                     
> #  assert(var != (T)-1) failed: Not yet initialized
> ...
> V  [libjvm.so+0x10346ec]  CompilerToVM::Data::initialize(JVMCIEnv*)+0x44c  (compressedKlass.hpp:95)                                                                                                                                                                                                                                                                                                                                        
> V  [libjvm.so+0x1057999]  readConfiguration0(JNIEnv_*, JVMCIEnv*)+0x159  (jvmciCompilerToVMInit.cpp:382) 
> 
> 
> A simple fix is to stop calling the CompressedKlassPointers:: functions.

@tstuefe added the asserting `check_init` function with the TinyCP patch. I agree  that this is something we could/should fix in the upstream repository.

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

PR Comment: https://git.openjdk.org/lilliput/pull/151#issuecomment-2068806446

From rkennke at openjdk.org  Mon Apr 22 08:52:56 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 22 Apr 2024 08:52:56 GMT
Subject: [master] RFR: JVMCI: Don't call CompressedKlassPointers functions
 with -UCCP
In-Reply-To: <fJz0-aKZ5m3JsSTtH5-ShhPKWS7tRjpIYIUt5QskbbM=.b4b41662-377c-4393-a962-52cdf13f5a06@github.com>
References: <fJz0-aKZ5m3JsSTtH5-ShhPKWS7tRjpIYIUt5QskbbM=.b4b41662-377c-4393-a962-52cdf13f5a06@github.com>
Message-ID: <AKr5zIGEus4qpvakWYzdIySj5FOZggupCGzImwuipMk=.bbe9f786-8586-4332-83b8-a815c37ba07e@github.com>

On Mon, 22 Apr 2024 07:39:58 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> We hit this assert when running JVMCI tests and -XX:-UseCompressedClassPointers:
> 
> #  Internal Error (/home/stefank/git/jdk/open/src/hotspot/share/oops/compressedKlass.hpp:95), pid=1496156, tid=1496350                                                                                                                                                                                                                                                                                                                     
> #  assert(var != (T)-1) failed: Not yet initialized
> ...
> V  [libjvm.so+0x10346ec]  CompilerToVM::Data::initialize(JVMCIEnv*)+0x44c  (compressedKlass.hpp:95)                                                                                                                                                                                                                                                                                                                                        
> V  [libjvm.so+0x1057999]  readConfiguration0(JNIEnv_*, JVMCIEnv*)+0x159  (jvmciCompilerToVMInit.cpp:382) 
> 
> 
> A simple fix is to stop calling the CompressedKlassPointers:: functions.

Marked as reviewed by rkennke (Lead).

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

PR Review: https://git.openjdk.org/lilliput/pull/151#pullrequestreview-2014168843

From rkennke at openjdk.org  Mon Apr 22 08:52:56 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 22 Apr 2024 08:52:56 GMT
Subject: [master] RFR: JVMCI: Don't call CompressedKlassPointers functions
 with -UCCP
In-Reply-To: <-YAEPjuxSGTB2mG_D1HnrqPRDRah3C8k1x9AaYMkHzM=.addfdc64-80b4-42d1-a9f3-175643051a91@github.com>
References: <fJz0-aKZ5m3JsSTtH5-ShhPKWS7tRjpIYIUt5QskbbM=.b4b41662-377c-4393-a962-52cdf13f5a06@github.com>
 <-YAEPjuxSGTB2mG_D1HnrqPRDRah3C8k1x9AaYMkHzM=.addfdc64-80b4-42d1-a9f3-175643051a91@github.com>
Message-ID: <biaDEc2ye5h09JgI0Qry1GGW3c4qAxyrjkskBDFYkoY=.bf331780-b65a-451f-a615-9fac82c867d9@github.com>

On Mon, 22 Apr 2024 08:32:06 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> @tstuefe added the asserting `check_init` function with the TinyCP patch. I agree that this is something we could/should fix in the upstream repository.

Ok then.

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

PR Comment: https://git.openjdk.org/lilliput/pull/151#issuecomment-2068844275

From rkennke at openjdk.org  Mon Apr 22 10:28:01 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 22 Apr 2024 10:28:01 GMT
Subject: [master] RFR: 8319185: [Lilliput] Enable and fix vectorization
 tests [v2]
In-Reply-To: <ZnI9tBlTse9_zsW3AKCOn3npi3vgMOZfbo-Eolh2fns=.63bf30ec-d43b-40e5-9b38-07312aefa403@github.com>
References: <ZnI9tBlTse9_zsW3AKCOn3npi3vgMOZfbo-Eolh2fns=.63bf30ec-d43b-40e5-9b38-07312aefa403@github.com>
Message-ID: <_uF7HfCyZJrIEUb6F9mAstPN-CW3wyaZO60xL5Gnshs=.2d032420-9cdf-4bfe-b9c7-52bf3660b32f@github.com>

> This re-instates #125 after it has been lost with the Great Reset. It's a clean cherry-pick of that other commit.
> 
> Compared to #125 this change also fixes compiler/loopopts/superword/TestAlignVector.java, which is new since then.

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 three additional commits since the last revision:

 - Fix TestAlignVector.java
 - Merge branch 'master' into fix-vector-tests
 - 8319185: [Lilliput] Enable and fix vectorization tests
   
   Reviewed-by: shade

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

Changes:
  - all: https://git.openjdk.org/lilliput/pull/152/files
  - new: https://git.openjdk.org/lilliput/pull/152/files/6f2c8f35..7846f7eb

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

  Stats: 9 lines in 2 files changed: 7 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/lilliput/pull/152.diff
  Fetch: git fetch https://git.openjdk.org/lilliput.git pull/152/head:pull/152

PR: https://git.openjdk.org/lilliput/pull/152

From stuefe at openjdk.org  Mon Apr 22 11:02:47 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 22 Apr 2024 11:02:47 GMT
Subject: [master] RFR: JVMCI: Don't call CompressedKlassPointers functions
 with -UCCP
In-Reply-To: <fJz0-aKZ5m3JsSTtH5-ShhPKWS7tRjpIYIUt5QskbbM=.b4b41662-377c-4393-a962-52cdf13f5a06@github.com>
References: <fJz0-aKZ5m3JsSTtH5-ShhPKWS7tRjpIYIUt5QskbbM=.b4b41662-377c-4393-a962-52cdf13f5a06@github.com>
Message-ID: <QCJaM3C2OmD0_tFmONMkjomP11fdlu5nYAX2HNePdig=.21c5c4d5-9ecb-4222-9197-8b16997bc062@github.com>

On Mon, 22 Apr 2024 07:39:58 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> We hit this assert when running JVMCI tests and -XX:-UseCompressedClassPointers:
> 
> #  Internal Error (/home/stefank/git/jdk/open/src/hotspot/share/oops/compressedKlass.hpp:95), pid=1496156, tid=1496350                                                                                                                                                                                                                                                                                                                     
> #  assert(var != (T)-1) failed: Not yet initialized
> ...
> V  [libjvm.so+0x10346ec]  CompilerToVM::Data::initialize(JVMCIEnv*)+0x44c  (compressedKlass.hpp:95)                                                                                                                                                                                                                                                                                                                                        
> V  [libjvm.so+0x1057999]  readConfiguration0(JNIEnv_*, JVMCIEnv*)+0x159  (jvmciCompilerToVMInit.cpp:382) 
> 
> 
> A simple fix is to stop calling the CompressedKlassPointers:: functions.

Okay, I'll fix it upstream

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

PR Comment: https://git.openjdk.org/lilliput/pull/151#issuecomment-2069100202

From stefank at openjdk.org  Mon Apr 22 11:37:38 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 22 Apr 2024 11:37:38 GMT
Subject: [master] RFR: 8319185: [Lilliput] Enable and fix vectorization
 tests [v2]
In-Reply-To: <_uF7HfCyZJrIEUb6F9mAstPN-CW3wyaZO60xL5Gnshs=.2d032420-9cdf-4bfe-b9c7-52bf3660b32f@github.com>
References: <ZnI9tBlTse9_zsW3AKCOn3npi3vgMOZfbo-Eolh2fns=.63bf30ec-d43b-40e5-9b38-07312aefa403@github.com>
 <_uF7HfCyZJrIEUb6F9mAstPN-CW3wyaZO60xL5Gnshs=.2d032420-9cdf-4bfe-b9c7-52bf3660b32f@github.com>
Message-ID: <fb0HpgWyjFmlRc73gMS70CxQIyGJHiFsdl8hvKW7U7U=.5d195fef-cb17-405c-92c1-e0fa261488ee@github.com>

On Mon, 22 Apr 2024 10:28:01 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This re-instates #125 after it has been lost with the Great Reset. It's a clean cherry-pick of that other commit.
>> 
>> Compared to #125 this change also fixes compiler/loopopts/superword/TestAlignVector.java, which is new since then.
>
> 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 three additional commits since the last revision:
> 
>  - Fix TestAlignVector.java
>  - Merge branch 'master' into fix-vector-tests
>  - 8319185: [Lilliput] Enable and fix vectorization tests
>    
>    Reviewed-by: shade

Seems reasonable to me, though I'm not really familiar with this test framework. If this makes the testing cleaner I'd prefer to get this integrated now instead of waiting for a perfect fix/review.

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

PR Comment: https://git.openjdk.org/lilliput/pull/152#issuecomment-2069167783

From stefank at openjdk.org  Mon Apr 22 11:40:51 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 22 Apr 2024 11:40:51 GMT
Subject: [master] RFR: JVMCI: Don't call CompressedKlassPointers functions
 with -UCCP
In-Reply-To: <fJz0-aKZ5m3JsSTtH5-ShhPKWS7tRjpIYIUt5QskbbM=.b4b41662-377c-4393-a962-52cdf13f5a06@github.com>
References: <fJz0-aKZ5m3JsSTtH5-ShhPKWS7tRjpIYIUt5QskbbM=.b4b41662-377c-4393-a962-52cdf13f5a06@github.com>
Message-ID: <WKgNoJ2sbWfnnvARw-9w87BtiPSvG2jRFPPAF0Zsk10=.cebdb23a-7571-454c-9595-12677f033098@github.com>

On Mon, 22 Apr 2024 07:39:58 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> We hit this assert when running JVMCI tests and -XX:-UseCompressedClassPointers:
> 
> #  Internal Error (/home/stefank/git/jdk/open/src/hotspot/share/oops/compressedKlass.hpp:95), pid=1496156, tid=1496350                                                                                                                                                                                                                                                                                                                     
> #  assert(var != (T)-1) failed: Not yet initialized
> ...
> V  [libjvm.so+0x10346ec]  CompilerToVM::Data::initialize(JVMCIEnv*)+0x44c  (compressedKlass.hpp:95)                                                                                                                                                                                                                                                                                                                                        
> V  [libjvm.so+0x1057999]  readConfiguration0(JNIEnv_*, JVMCIEnv*)+0x159  (jvmciCompilerToVMInit.cpp:382) 
> 
> 
> A simple fix is to stop calling the CompressedKlassPointers:: functions.

Thanks. I'm integrating this so that my testing stops asserting.

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

PR Comment: https://git.openjdk.org/lilliput/pull/151#issuecomment-2069170584

From stefank at openjdk.org  Mon Apr 22 11:40:51 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 22 Apr 2024 11:40:51 GMT
Subject: [master] Integrated: JVMCI: Don't call CompressedKlassPointers
 functions with -UCCP
In-Reply-To: <fJz0-aKZ5m3JsSTtH5-ShhPKWS7tRjpIYIUt5QskbbM=.b4b41662-377c-4393-a962-52cdf13f5a06@github.com>
References: <fJz0-aKZ5m3JsSTtH5-ShhPKWS7tRjpIYIUt5QskbbM=.b4b41662-377c-4393-a962-52cdf13f5a06@github.com>
Message-ID: <8pYqsnpWcXsjHWRGiOM1eniOTPp1CKNUgvFndcf0nxY=.fa125186-e634-4e68-a20d-c10ed3101333@github.com>

On Mon, 22 Apr 2024 07:39:58 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> We hit this assert when running JVMCI tests and -XX:-UseCompressedClassPointers:
> 
> #  Internal Error (/home/stefank/git/jdk/open/src/hotspot/share/oops/compressedKlass.hpp:95), pid=1496156, tid=1496350                                                                                                                                                                                                                                                                                                                     
> #  assert(var != (T)-1) failed: Not yet initialized
> ...
> V  [libjvm.so+0x10346ec]  CompilerToVM::Data::initialize(JVMCIEnv*)+0x44c  (compressedKlass.hpp:95)                                                                                                                                                                                                                                                                                                                                        
> V  [libjvm.so+0x1057999]  readConfiguration0(JNIEnv_*, JVMCIEnv*)+0x159  (jvmciCompilerToVMInit.cpp:382) 
> 
> 
> A simple fix is to stop calling the CompressedKlassPointers:: functions.

This pull request has now been integrated.

Changeset: 0da50882
Author:    Stefan Karlsson <stefank at openjdk.org>
URL:       https://git.openjdk.org/lilliput/commit/0da50882da089e7356a41df5a08319081ffa0ddf
Stats:     8 lines in 1 file changed: 6 ins; 0 del; 2 mod

JVMCI: Don't call CompressedKlassPointers functions with -UCCP

Reviewed-by: rkennke

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

PR: https://git.openjdk.org/lilliput/pull/151

From aboldtch at openjdk.org  Mon Apr 22 12:08:57 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 22 Apr 2024 12:08:57 GMT
Subject: [master] RFR: OMWorld: Remove JavaThread Sync Deflation Code
Message-ID: <8-eVhsX7Q-yQudVfIt9MZabMQY59Dt9jPKVaDgX39sw=.d0cf63ca-5565-4286-b7bc-89e9ad3e592b@github.com>

This removes the code that allows JavaThreads to deflate ObjectMonitors on self owned monitors on wait and exit. 

There currently is no good way to decide if a certain ObjectMonitor should be deflated. 

I propose removing the experimental code that relates to this feature, I will keep open a draft PR after this is integrated containing the JavaThread Sync Deflation Code in case it is something that is picked up at a later point.

This commit is currently based on ffc4c2fd5ba1c28432a5d5e84b8ada95fba7eeb8 without a merge. So GHA is not tested with lilliput. As long as this is mergable without conflicts (and no manual merge is performed) it will also be possible to move this commit down below lilliput on-top of OMWorld directly.

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

Commit messages:
 - OMWorld: Remove JavaThread Sync Deflation Code

Changes: https://git.openjdk.org/lilliput/pull/153/files
  Webrev: https://webrevs.openjdk.org/?repo=lilliput&pr=153&range=00
  Stats: 129 lines in 8 files changed: 0 ins; 128 del; 1 mod
  Patch: https://git.openjdk.org/lilliput/pull/153.diff
  Fetch: git fetch https://git.openjdk.org/lilliput.git pull/153/head:pull/153

PR: https://git.openjdk.org/lilliput/pull/153

From aboldtch at openjdk.org  Mon Apr 22 12:09:48 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 22 Apr 2024 12:09:48 GMT
Subject: [master] RFR: OMWorld: Cleanup ObjectSynchronizer::enter_fast_impl
Message-ID: <jslLO0Cb47AcmSKcEfij6jEppLQEz_-7lEK78VX7M2o=.12b38cfd-e023-473b-9364-a1f782807e59@github.com>

Cleanup of `ObjectSynchronizer::enter_fast_impl` after `LM_LIGHTWEIGHT` and `LM_PLACEHOLDER` got merged.

This commit is currently based on ffc4c2fd5ba1c28432a5d5e84b8ada95fba7eeb8 without a merge. So GHA is not tested with lilliput. As long as this is mergable without conflicts (and no manual merge is performed) it will also be possible to move this commit down below lilliput on-top of OMWorld directly.

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

Commit messages:
 - OMWorld: Cleanup ObjectSynchronizer::enter_fast_impl

Changes: https://git.openjdk.org/lilliput/pull/156/files
  Webrev: https://webrevs.openjdk.org/?repo=lilliput&pr=156&range=00
  Stats: 56 lines in 1 file changed: 1 ins; 54 del; 1 mod
  Patch: https://git.openjdk.org/lilliput/pull/156.diff
  Fetch: git fetch https://git.openjdk.org/lilliput.git pull/156/head:pull/156

PR: https://git.openjdk.org/lilliput/pull/156

From aboldtch at openjdk.org  Mon Apr 22 12:11:03 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 22 Apr 2024 12:11:03 GMT
Subject: [master] RFR: OMWorld: Cleanup ObjectSynchronizer::exit
Message-ID: <AQ1EeoINZrdWU7FQm-lX2Sq8x-DBZV79paDlgA37Iis=.0a7822ae-2d5b-4176-ac30-ddef8873d217@github.com>

Cleanup of `ObjectSynchronizer::exit` after `LM_LIGHTWEIGHT` and `LM_PLACEHOLDER` got merged.

This commit is currently based on ffc4c2fd5ba1c28432a5d5e84b8ada95fba7eeb8 without a merge. So GHA is not tested with lilliput. As long as this is mergable without conflicts (and no manual merge is performed) it will also be possible to move this commit down below lilliput on-top of OMWorld directly.

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

Commit messages:
 - OMWorld: Cleanup ObjectSynchronizer::exit

Changes: https://git.openjdk.org/lilliput/pull/154/files
  Webrev: https://webrevs.openjdk.org/?repo=lilliput&pr=154&range=00
  Stats: 26 lines in 1 file changed: 0 ins; 25 del; 1 mod
  Patch: https://git.openjdk.org/lilliput/pull/154.diff
  Fetch: git fetch https://git.openjdk.org/lilliput.git pull/154/head:pull/154

PR: https://git.openjdk.org/lilliput/pull/154

From aboldtch at openjdk.org  Mon Apr 22 12:10:11 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 22 Apr 2024 12:10:11 GMT
Subject: [master] RFR: OMWorld: Cleanup inflate
Message-ID: <zTYM7tLryIG_brrhXCyFoVab6t-LFH9GkxSOIgVq4Ls=.eac3ddf8-f073-4647-92e7-bd22ea8f1b2d@github.com>

Cleanup of inflate code after `LM_LIGHTWEIGHT` and `LM_PLACEHOLDER` got merged.

This commit is currently based on ffc4c2fd5ba1c28432a5d5e84b8ada95fba7eeb8 without a merge. So GHA is not tested with lilliput. As long as this is mergable without conflicts (and no manual merge is performed) it will also be possible to move this commit down below lilliput on-top of OMWorld directly.

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

Commit messages:
 - OMWorld: Cleanup inflate

Changes: https://git.openjdk.org/lilliput/pull/155/files
  Webrev: https://webrevs.openjdk.org/?repo=lilliput&pr=155&range=00
  Stats: 96 lines in 2 files changed: 2 ins; 78 del; 16 mod
  Patch: https://git.openjdk.org/lilliput/pull/155.diff
  Fetch: git fetch https://git.openjdk.org/lilliput.git pull/155/head:pull/155

PR: https://git.openjdk.org/lilliput/pull/155

From aboldtch at openjdk.org  Mon Apr 22 12:25:44 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 22 Apr 2024 12:25:44 GMT
Subject: [master] RFR: OMWorld: Cleanup quick_enter
Message-ID: <J1jzghXA4LOp-Gq6fEw_bhx15k9si2-wz2qunSLuGZM=.a9afdce3-bcff-49bf-8ba5-e01833bfba10@github.com>

Cleanup of `ObjectSynchronizer::quick_enter` after `LM_LIGHTWEIGHT` and `LM_PLACEHOLDER` got merged.

`LM_LIGHTWEIGHT` now makes use of `quick_enter`.  Doing a lookup in the hash table may be not be the best thing to do. Maybe just looking in thread local cache is enough. To avoid having to do multiple lookups.  Will add this change after I have tested it.

This commit is currently based on ffc4c2fd5ba1c28432a5d5e84b8ada95fba7eeb8 without a merge. So GHA is not tested with lilliput. As long as this is mergable without conflicts (and no manual merge is performed) it will also be possible to move this commit down below lilliput on-top of OMWorld directly.

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

Commit messages:
 - OMWorld: Cleanup quick_enter

Changes: https://git.openjdk.org/lilliput/pull/157/files
  Webrev: https://webrevs.openjdk.org/?repo=lilliput&pr=157&range=00
  Stats: 6 lines in 1 file changed: 0 ins; 4 del; 2 mod
  Patch: https://git.openjdk.org/lilliput/pull/157.diff
  Fetch: git fetch https://git.openjdk.org/lilliput.git pull/157/head:pull/157

PR: https://git.openjdk.org/lilliput/pull/157

From aboldtch at openjdk.org  Mon Apr 22 12:33:45 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 22 Apr 2024 12:33:45 GMT
Subject: [master] RFR: OMWorld: Fix javaVFrame::print_lock_info_on
Message-ID: <zC6WKabjkak_Lh2mK4ghcwICHwutbbwfe0g2fnpl53c=.84672ce8-94bf-4d1a-8de8-3a8b2fa14a74@github.com>

OMWorld: `Fix javaVFrame::print_lock_info_on` printing. If the ObjectMonitor is `nullptr` and the header is `has_monitor` then we must be in the process of locking. (We cannot have locked, as that would have prevented deflation). 

This commit is currently based on ffc4c2fd5ba1c28432a5d5e84b8ada95fba7eeb8 without a merge. So GHA is not tested with lilliput. As long as this is mergable without conflicts (and no manual merge is performed) it will also be possible to move this commit down below lilliput on-top of OMWorld directly.

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

Commit messages:
 - OMWorld: Fix javaVFrame::print_lock_info_on

Changes: https://git.openjdk.org/lilliput/pull/158/files
  Webrev: https://webrevs.openjdk.org/?repo=lilliput&pr=158&range=00
  Stats: 4 lines in 1 file changed: 2 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/lilliput/pull/158.diff
  Fetch: git fetch https://git.openjdk.org/lilliput.git pull/158/head:pull/158

PR: https://git.openjdk.org/lilliput/pull/158

From rkennke at openjdk.org  Mon Apr 22 12:40:58 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 22 Apr 2024 12:40:58 GMT
Subject: [lilliput-jdk21u:lilliput] RFR: 8324174:
 assert(m->is_entered(current)) failed: invariant
Message-ID: <POKN1eK2vTcLd_tnwzSHmfV4CCH151uLwBb5s3F-7oA=.e09e6903-b128-40f2-ad83-64eb516ad024@github.com>

Hi all,

This pull request contains a backport of commit [5b9b176c](https://github.com/openjdk/jdk/commit/5b9b176c6729aeff2a70d304a1ef57da3965fb53) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Vladimir Kozlov on 31 Jan 2024 and was reviewed by Emanuel Peter, Dean Long and Tobias Hartmann.

Thanks!

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

Commit messages:
 - Backport 5b9b176c6729aeff2a70d304a1ef57da3965fb53

Changes: https://git.openjdk.org/lilliput-jdk21u/pull/30/files
  Webrev: https://webrevs.openjdk.org/?repo=lilliput-jdk21u&pr=30&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8324174
  Stats: 150 lines in 2 files changed: 148 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/lilliput-jdk21u/pull/30.diff
  Fetch: git fetch https://git.openjdk.org/lilliput-jdk21u.git pull/30/head:pull/30

PR: https://git.openjdk.org/lilliput-jdk21u/pull/30

From rkennke at openjdk.org  Mon Apr 22 12:48:38 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 22 Apr 2024 12:48:38 GMT
Subject: [master] RFR: 8319185: [Lilliput] Enable and fix vectorization
 tests [v2]
In-Reply-To: <fb0HpgWyjFmlRc73gMS70CxQIyGJHiFsdl8hvKW7U7U=.5d195fef-cb17-405c-92c1-e0fa261488ee@github.com>
References: <ZnI9tBlTse9_zsW3AKCOn3npi3vgMOZfbo-Eolh2fns=.63bf30ec-d43b-40e5-9b38-07312aefa403@github.com>
 <_uF7HfCyZJrIEUb6F9mAstPN-CW3wyaZO60xL5Gnshs=.2d032420-9cdf-4bfe-b9c7-52bf3660b32f@github.com>
 <fb0HpgWyjFmlRc73gMS70CxQIyGJHiFsdl8hvKW7U7U=.5d195fef-cb17-405c-92c1-e0fa261488ee@github.com>
Message-ID: <5C2pVRZNNolamOipMrJn5YybJfe9e2VWHjeXRVQ9h0A=.c9c5d4c0-d4e8-498c-b24f-8aefbcf77a0f@github.com>

On Mon, 22 Apr 2024 11:35:32 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> Seems reasonable to me, though I'm not really familiar with this test framework. If this makes the testing cleaner I'd prefer to get this integrated now instead of waiting for a perfect fix/review.

I had some discussions with Emmanuel Peter and Maurizio Cimadamore somewhere else (perhaps in the array base alignment discussions, but I don't remember, tbh), and this seemed to be the most preferable way forward. None of it is catastrophic or can be done much about, it might result in performance nuisances in some corner cases (e.g. when alignment of src and dst arrays don't match, e.g. when arraycopying from a byte[] to a long[] or such). If/when we do 4-byte-headers, the problem will disappear.

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

PR Comment: https://git.openjdk.org/lilliput/pull/152#issuecomment-2069307103

From aboldtch at openjdk.org  Mon Apr 22 12:48:46 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 22 Apr 2024 12:48:46 GMT
Subject: [master] RFR: OMWorld: ObjectMonitor:enter
Message-ID: <0TMzcFtjTfYVwItU3Uek6MSeFLUBmD43yJoNyx_PvPo=.4ad2f946-0cab-4dc2-b1db-f4f23c64d3f6@github.com>

This restructures `ObjectMonitor:enter` to fit better with the `LightweightSynchronizer`. Some parts of this could be upstreamed separately. 

This effectively splits up `ObjectMonitor::enter` into three parts. Which LightweightSynchronizer can weave into its `inflate_and_enter`. 

```c++
bool ObjectMonitor::enter(JavaThread* current) {
  // 1. Spinning without blocking out deflation
  if (spin_enter(current)) {
    return true;
  }

  // 2. Try to block deflation
  ObjectMonitorContentionMark contention_mark(this);
  if (enter_is_async_deflating()) {
    return false;
  }

  // 3. Enter while blocking out deflation
  enter_with_contention_mark(current, contention_mark);
  return true;
}


It may be worth the effort to document these new methods, and also add better documentation to `inflate_and_enter` which describes the invariants and how `ObjectMonitorContentionMark`, markWord transitions and ObjectMonitor::_owner field (on newly inserted monitors) plays together to guarantee correctness and works. 

This commit is currently based on ffc4c2fd5ba1c28432a5d5e84b8ada95fba7eeb8 without a merge. So GHA is not tested with lilliput. As long as this is mergable without conflicts (and no manual merge is performed) it will also be possible to move this commit down below lilliput on-top of OMWorld directly.

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

Commit messages:
 - Cleanup ObjectMonitor::enter and LightweightSynchronizer::inflate_and_enter
 - Cleanup and fix enter / enter_for distinction

Changes: https://git.openjdk.org/lilliput/pull/159/files
  Webrev: https://webrevs.openjdk.org/?repo=lilliput&pr=159&range=00
  Stats: 246 lines in 6 files changed: 119 ins; 58 del; 69 mod
  Patch: https://git.openjdk.org/lilliput/pull/159.diff
  Fetch: git fetch https://git.openjdk.org/lilliput.git pull/159/head:pull/159

PR: https://git.openjdk.org/lilliput/pull/159

From rkennke at openjdk.org  Mon Apr 22 13:22:52 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 22 Apr 2024 13:22:52 GMT
Subject: [lilliput-jdk21u:lilliput] Integrated: 8324174:
 assert(m->is_entered(current)) failed: invariant
In-Reply-To: <POKN1eK2vTcLd_tnwzSHmfV4CCH151uLwBb5s3F-7oA=.e09e6903-b128-40f2-ad83-64eb516ad024@github.com>
References: <POKN1eK2vTcLd_tnwzSHmfV4CCH151uLwBb5s3F-7oA=.e09e6903-b128-40f2-ad83-64eb516ad024@github.com>
Message-ID: <1JYiPuEMvPsCPGKnvqNKwLmuGwnY600LU1J6fX7sEMs=.9f8e76a0-2502-498a-81c5-8f172381eac9@github.com>

On Mon, 22 Apr 2024 12:35:58 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [5b9b176c](https://github.com/openjdk/jdk/commit/5b9b176c6729aeff2a70d304a1ef57da3965fb53) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Vladimir Kozlov on 31 Jan 2024 and was reviewed by Emanuel Peter, Dean Long and Tobias Hartmann.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 71b33877
Author:    Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.org/lilliput-jdk21u/commit/71b33877638084c5946c033292972a566e7dfc45
Stats:     150 lines in 2 files changed: 148 ins; 0 del; 2 mod

8324174: assert(m->is_entered(current)) failed: invariant

Backport-of: 5b9b176c6729aeff2a70d304a1ef57da3965fb53

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

PR: https://git.openjdk.org/lilliput-jdk21u/pull/30

From aboldtch at openjdk.org  Mon Apr 22 13:26:05 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 22 Apr 2024 13:26:05 GMT
Subject: [master] RFR: OMWorld: Cleanup ObjectMonitor::_header
Message-ID: <T9Kl7-okmXHWJrQOcIlvCf9r3bk6KL0mn_jGdFvVnKw=.fc73986b-1c44-4bb5-b7bc-5283cb047431@github.com>

This changes the `ObjectMonitor::_header` to `ObjectMonitor::_metadata` and cleans up the surrounding terminology. 

Parts of this could be upstreamed, but the distinction of this field between the different locking modes is introduced in OMWorld. 

This patch will conflict with Lilliput if rebased on-top of OMWorld because Lilliput introduces `static ByteSize header_offset()` which is not used after OMWorld.  They could probably be removed in both these patches.

This also changes all the fields to have the same access level (private) so that this can be a standard layout type.

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

Commit messages:
 - Cleanup ObjectMonitor::_header

Changes: https://git.openjdk.org/lilliput/pull/161/files
  Webrev: https://webrevs.openjdk.org/?repo=lilliput&pr=161&range=00
  Stats: 95 lines in 8 files changed: 23 ins; 10 del; 62 mod
  Patch: https://git.openjdk.org/lilliput/pull/161.diff
  Fetch: git fetch https://git.openjdk.org/lilliput.git pull/161/head:pull/161

PR: https://git.openjdk.org/lilliput/pull/161

From aboldtch at openjdk.org  Mon Apr 22 13:33:01 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 22 Apr 2024 13:33:01 GMT
Subject: [master] RFR: OMWorld: ObjectMonitor:enter [v2]
In-Reply-To: <0TMzcFtjTfYVwItU3Uek6MSeFLUBmD43yJoNyx_PvPo=.4ad2f946-0cab-4dc2-b1db-f4f23c64d3f6@github.com>
References: <0TMzcFtjTfYVwItU3Uek6MSeFLUBmD43yJoNyx_PvPo=.4ad2f946-0cab-4dc2-b1db-f4f23c64d3f6@github.com>
Message-ID: <3tLz_lbtQAArvzCaNQGDOeLCtuvj6PsoboSHlXo0gLU=.50b3b25b-b358-4316-a586-4cef7165b11b@github.com>

> This restructures `ObjectMonitor:enter` to fit better with the `LightweightSynchronizer`. Some parts of this could be upstreamed separately. 
> 
> This effectively splits up `ObjectMonitor::enter` into three parts. Which LightweightSynchronizer can weave into its `inflate_and_enter`. 
> 
> ```c++
> bool ObjectMonitor::enter(JavaThread* current) {
>   // 1. Spinning without blocking out deflation
>   if (spin_enter(current)) {
>     return true;
>   }
> 
>   // 2. Try to block deflation
>   ObjectMonitorContentionMark contention_mark(this);
>   if (enter_is_async_deflating()) {
>     return false;
>   }
> 
>   // 3. Enter while blocking out deflation
>   enter_with_contention_mark(current, contention_mark);
>   return true;
> }
> 
> 
> It may be worth the effort to document these new methods, and also add better documentation to `inflate_and_enter` which describes the invariants and how `ObjectMonitorContentionMark`, markWord transitions and ObjectMonitor::_owner field (on newly inserted monitors) plays together to guarantee correctness and works. 
> 
> This commit is currently based on ffc4c2fd5ba1c28432a5d5e84b8ada95fba7eeb8 without a merge. So GHA is not tested with lilliput. As long as this is mergable without conflicts (and no manual merge is performed) it will also be possible to move this commit down below lilliput on-top of OMWorld directly.

Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:

  Fix missed lock change

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

Changes:
  - all: https://git.openjdk.org/lilliput/pull/159/files
  - new: https://git.openjdk.org/lilliput/pull/159/files/6a26947a..24ed7d73

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

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

PR: https://git.openjdk.org/lilliput/pull/159

From rkennke at openjdk.org  Mon Apr 22 13:44:40 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 22 Apr 2024 13:44:40 GMT
Subject: [master] RFR: OMWorld: Remove JavaThread Sync Deflation Code
In-Reply-To: <8-eVhsX7Q-yQudVfIt9MZabMQY59Dt9jPKVaDgX39sw=.d0cf63ca-5565-4286-b7bc-89e9ad3e592b@github.com>
References: <8-eVhsX7Q-yQudVfIt9MZabMQY59Dt9jPKVaDgX39sw=.d0cf63ca-5565-4286-b7bc-89e9ad3e592b@github.com>
Message-ID: <iLtXCLEuKQj2_Hc0ZK8CA9kDSlHo4fzZr-aoi1j_mNk=.0767ac41-59ef-4a6b-9605-244a59acca21@github.com>

On Mon, 22 Apr 2024 12:04:17 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> This removes the code that allows JavaThreads to deflate ObjectMonitors on self owned monitors on wait and exit. 
> 
> There currently is no good way to decide if a certain ObjectMonitor should be deflated. 
> 
> I propose removing the experimental code that relates to this feature, I will keep open a draft PR after this is integrated containing the JavaThread Sync Deflation Code in case it is something that is picked up at a later point.
> 
> This commit is currently based on ffc4c2fd5ba1c28432a5d5e84b8ada95fba7eeb8 without a merge. So GHA is not tested with lilliput. As long as this is mergable without conflicts (and no manual merge is performed) it will also be possible to move this commit down below lilliput on-top of OMWorld directly.

Ok! Thank you!

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

Marked as reviewed by rkennke (Lead).

PR Review: https://git.openjdk.org/lilliput/pull/153#pullrequestreview-2014799548

From rkennke at openjdk.org  Mon Apr 22 13:45:05 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 22 Apr 2024 13:45:05 GMT
Subject: [lilliput-jdk21u:lilliput] RFR: 8329757: Crash with fatal error: DEBUG
 MESSAGE: Fast Unlock lock on stack
Message-ID: <g0KMm_e5rvJHl70Np3eubkjz1JpCcPAlk5FNdiYqK0M=.a5f186e5-b6d4-4d29-934c-8e578dd29e21@github.com>

Hi all,

This pull request contains a backport of commit [e45fea5a](https://github.com/openjdk/jdk/commit/e45fea5a801ac09c3d572ac07d6179e80c422942) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Axel Boldt-Christmas on 12 Apr 2024 and was reviewed by Patricio Chilano Mateo and Vladimir Kozlov.

Thanks!

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

Commit messages:
 - Backport e45fea5a801ac09c3d572ac07d6179e80c422942

Changes: https://git.openjdk.org/lilliput-jdk21u/pull/31/files
  Webrev: https://webrevs.openjdk.org/?repo=lilliput-jdk21u&pr=31&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8329757
  Stats: 149 lines in 4 files changed: 148 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/lilliput-jdk21u/pull/31.diff
  Fetch: git fetch https://git.openjdk.org/lilliput-jdk21u.git pull/31/head:pull/31

PR: https://git.openjdk.org/lilliput-jdk21u/pull/31

From rkennke at openjdk.org  Mon Apr 22 13:45:40 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 22 Apr 2024 13:45:40 GMT
Subject: [master] RFR: OMWorld: Cleanup ObjectSynchronizer::enter_fast_impl
In-Reply-To: <jslLO0Cb47AcmSKcEfij6jEppLQEz_-7lEK78VX7M2o=.12b38cfd-e023-473b-9364-a1f782807e59@github.com>
References: <jslLO0Cb47AcmSKcEfij6jEppLQEz_-7lEK78VX7M2o=.12b38cfd-e023-473b-9364-a1f782807e59@github.com>
Message-ID: <23WfsfAaxRPaH6_sxOYvwadKPZ5uiG1LPS1yPF5aXyc=.f249f3b6-52c6-46e3-8b31-7863ce0774af@github.com>

On Mon, 22 Apr 2024 12:06:26 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Cleanup of `ObjectSynchronizer::enter_fast_impl` after `LM_LIGHTWEIGHT` and `LM_PLACEHOLDER` got merged.
> 
> This commit is currently based on ffc4c2fd5ba1c28432a5d5e84b8ada95fba7eeb8 without a merge. So GHA is not tested with lilliput. As long as this is mergable without conflicts (and no manual merge is performed) it will also be possible to move this commit down below lilliput on-top of OMWorld directly.

Makes sense! Thank you!

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

Marked as reviewed by rkennke (Lead).

PR Review: https://git.openjdk.org/lilliput/pull/156#pullrequestreview-2014803183

From rkennke at openjdk.org  Mon Apr 22 14:03:40 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 22 Apr 2024 14:03:40 GMT
Subject: [master] RFR: OMWorld: Cleanup inflate
In-Reply-To: <zTYM7tLryIG_brrhXCyFoVab6t-LFH9GkxSOIgVq4Ls=.eac3ddf8-f073-4647-92e7-bd22ea8f1b2d@github.com>
References: <zTYM7tLryIG_brrhXCyFoVab6t-LFH9GkxSOIgVq4Ls=.eac3ddf8-f073-4647-92e7-bd22ea8f1b2d@github.com>
Message-ID: <61J5qRKTxHNJ_UMt3F8Ld8h6iORV89k68nIoAAl_MwU=.22a8e9d2-e08e-4fe6-9138-a37573a93507@github.com>

On Mon, 22 Apr 2024 12:06:03 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Cleanup of inflate code after `LM_LIGHTWEIGHT` and `LM_PLACEHOLDER` got merged.
> 
> This commit is currently based on ffc4c2fd5ba1c28432a5d5e84b8ada95fba7eeb8 without a merge. So GHA is not tested with lilliput. As long as this is mergable without conflicts (and no manual merge is performed) it will also be possible to move this commit down below lilliput on-top of OMWorld directly.

Ok! Thanks!

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

Marked as reviewed by rkennke (Lead).

PR Review: https://git.openjdk.org/lilliput/pull/155#pullrequestreview-2014850137

From rkennke at openjdk.org  Mon Apr 22 14:04:41 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 22 Apr 2024 14:04:41 GMT
Subject: [master] RFR: OMWorld: Cleanup ObjectSynchronizer::exit
In-Reply-To: <AQ1EeoINZrdWU7FQm-lX2Sq8x-DBZV79paDlgA37Iis=.0a7822ae-2d5b-4176-ac30-ddef8873d217@github.com>
References: <AQ1EeoINZrdWU7FQm-lX2Sq8x-DBZV79paDlgA37Iis=.0a7822ae-2d5b-4176-ac30-ddef8873d217@github.com>
Message-ID: <8IzjelSh1e6fmVpygeWmcK5u8qVgbiRyeNyvjDnb4qw=.b3032257-6c90-4bbe-b816-41fd4e958e94@github.com>

On Mon, 22 Apr 2024 12:05:11 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Cleanup of `ObjectSynchronizer::exit` after `LM_LIGHTWEIGHT` and `LM_PLACEHOLDER` got merged.
> 
> This commit is currently based on ffc4c2fd5ba1c28432a5d5e84b8ada95fba7eeb8 without a merge. So GHA is not tested with lilliput. As long as this is mergable without conflicts (and no manual merge is performed) it will also be possible to move this commit down below lilliput on-top of OMWorld directly.

Yup! Thanks!

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

Marked as reviewed by rkennke (Lead).

PR Review: https://git.openjdk.org/lilliput/pull/154#pullrequestreview-2014851869

From rkennke at openjdk.org  Mon Apr 22 14:05:39 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 22 Apr 2024 14:05:39 GMT
Subject: [master] RFR: OMWorld: Cleanup quick_enter
In-Reply-To: <J1jzghXA4LOp-Gq6fEw_bhx15k9si2-wz2qunSLuGZM=.a9afdce3-bcff-49bf-8ba5-e01833bfba10@github.com>
References: <J1jzghXA4LOp-Gq6fEw_bhx15k9si2-wz2qunSLuGZM=.a9afdce3-bcff-49bf-8ba5-e01833bfba10@github.com>
Message-ID: <Pnd4Tv513kBTAFwzHpHbVNlZvR9xhRAIURaooJMdrp0=.3731acb8-cbbf-4b56-8963-fa11711fdb8f@github.com>

On Mon, 22 Apr 2024 12:21:05 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Cleanup of `ObjectSynchronizer::quick_enter` after `LM_LIGHTWEIGHT` and `LM_PLACEHOLDER` got merged.
> 
> `LM_LIGHTWEIGHT` now makes use of `quick_enter`.  Doing a lookup in the hash table may be not be the best thing to do. Maybe just looking in thread local cache is enough. To avoid having to do multiple lookups.  Will add this change after I have tested it.
> 
> This commit is currently based on ffc4c2fd5ba1c28432a5d5e84b8ada95fba7eeb8 without a merge. So GHA is not tested with lilliput. As long as this is mergable without conflicts (and no manual merge is performed) it will also be possible to move this commit down below lilliput on-top of OMWorld directly.

Makes sense! Thanks!

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

Marked as reviewed by rkennke (Lead).

PR Review: https://git.openjdk.org/lilliput/pull/157#pullrequestreview-2014855081

From rkennke at openjdk.org  Mon Apr 22 14:06:37 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 22 Apr 2024 14:06:37 GMT
Subject: [master] RFR: OMWorld: Fix javaVFrame::print_lock_info_on
In-Reply-To: <zC6WKabjkak_Lh2mK4ghcwICHwutbbwfe0g2fnpl53c=.84672ce8-94bf-4d1a-8de8-3a8b2fa14a74@github.com>
References: <zC6WKabjkak_Lh2mK4ghcwICHwutbbwfe0g2fnpl53c=.84672ce8-94bf-4d1a-8de8-3a8b2fa14a74@github.com>
Message-ID: <P1dp2peF81V2ZiFsRMIDhs2yfGGeHQPGTcEsUjRX7OM=.3e5ce962-33fa-43b2-9d67-4c93988ddf4b@github.com>

On Mon, 22 Apr 2024 12:30:24 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> OMWorld: `Fix javaVFrame::print_lock_info_on` printing. If the ObjectMonitor is `nullptr` and the header is `has_monitor` then we must be in the process of locking. (We cannot have locked, as that would have prevented deflation). 
> 
> This commit is currently based on ffc4c2fd5ba1c28432a5d5e84b8ada95fba7eeb8 without a merge. So GHA is not tested with lilliput. As long as this is mergable without conflicts (and no manual merge is performed) it will also be possible to move this commit down below lilliput on-top of OMWorld directly.

Ok! Thanks!

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

Marked as reviewed by rkennke (Lead).

PR Review: https://git.openjdk.org/lilliput/pull/158#pullrequestreview-2014858131

From rkennke at openjdk.org  Mon Apr 22 14:19:37 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 22 Apr 2024 14:19:37 GMT
Subject: [master] RFR: OMWorld: Cleanup ObjectMonitor::_header
In-Reply-To: <T9Kl7-okmXHWJrQOcIlvCf9r3bk6KL0mn_jGdFvVnKw=.fc73986b-1c44-4bb5-b7bc-5283cb047431@github.com>
References: <T9Kl7-okmXHWJrQOcIlvCf9r3bk6KL0mn_jGdFvVnKw=.fc73986b-1c44-4bb5-b7bc-5283cb047431@github.com>
Message-ID: <fYYFBchQHVxLCDcS77GehoyLyCAs437uG3Vb-SFgr7k=.fd9dbb54-3ea3-4e85-89a1-5bc667d7e514@github.com>

On Mon, 22 Apr 2024 13:20:33 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> This changes the `ObjectMonitor::_header` to `ObjectMonitor::_metadata` and cleans up the surrounding terminology. 
> 
> Parts of this could be upstreamed, but the distinction of this field between the different locking modes is introduced in OMWorld. 
> 
> This patch will conflict with Lilliput if rebased on-top of OMWorld because Lilliput introduces `static ByteSize header_offset()` which is not used after OMWorld.  They could probably be removed in both these patches.
> 
> This also changes all the fields to have the same access level (private) so that this can be a standard layout type.

Makes sense! Thanks!

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

Marked as reviewed by rkennke (Lead).

PR Review: https://git.openjdk.org/lilliput/pull/161#pullrequestreview-2014902073

From rkennke at openjdk.org  Mon Apr 22 14:25:47 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 22 Apr 2024 14:25:47 GMT
Subject: [master] RFR: OMWorld: ObjectMonitor:enter [v2]
In-Reply-To: <3tLz_lbtQAArvzCaNQGDOeLCtuvj6PsoboSHlXo0gLU=.50b3b25b-b358-4316-a586-4cef7165b11b@github.com>
References: <0TMzcFtjTfYVwItU3Uek6MSeFLUBmD43yJoNyx_PvPo=.4ad2f946-0cab-4dc2-b1db-f4f23c64d3f6@github.com>
 <3tLz_lbtQAArvzCaNQGDOeLCtuvj6PsoboSHlXo0gLU=.50b3b25b-b358-4316-a586-4cef7165b11b@github.com>
Message-ID: <OdBoSul6Q6HYbPdaKs5ib7MQMoKw_lhIEqxIdKdiVSs=.ac65e6b4-42d9-4fc6-9f70-b121acb1bff3@github.com>

On Mon, 22 Apr 2024 13:33:01 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> This restructures `ObjectMonitor:enter` to fit better with the `LightweightSynchronizer`. Some parts of this could be upstreamed separately. 
>> 
>> This effectively splits up `ObjectMonitor::enter` into three parts. Which LightweightSynchronizer can weave into its `inflate_and_enter`. 
>> 
>> ```c++
>> bool ObjectMonitor::enter(JavaThread* current) {
>>   // 1. Spinning without blocking out deflation
>>   if (spin_enter(current)) {
>>     return true;
>>   }
>> 
>>   // 2. Try to block deflation
>>   ObjectMonitorContentionMark contention_mark(this);
>>   if (enter_is_async_deflating()) {
>>     return false;
>>   }
>> 
>>   // 3. Enter while blocking out deflation
>>   enter_with_contention_mark(current, contention_mark);
>>   return true;
>> }
>> 
>> 
>> It may be worth the effort to document these new methods, and also add better documentation to `inflate_and_enter` which describes the invariants and how `ObjectMonitorContentionMark`, markWord transitions and ObjectMonitor::_owner field (on newly inserted monitors) plays together to guarantee correctness and works. 
>> 
>> This commit is currently based on ffc4c2fd5ba1c28432a5d5e84b8ada95fba7eeb8 without a merge. So GHA is not tested with lilliput. As long as this is mergable without conflicts (and no manual merge is performed) it will also be possible to move this commit down below lilliput on-top of OMWorld directly.
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix missed lock change

Looks ok. Thank you!

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

Marked as reviewed by rkennke (Lead).

PR Review: https://git.openjdk.org/lilliput/pull/159#pullrequestreview-2014919469

From stefank at openjdk.org  Mon Apr 22 14:32:41 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 22 Apr 2024 14:32:41 GMT
Subject: [master] RFR: OMWorld: ObjectMonitor:enter [v2]
In-Reply-To: <3tLz_lbtQAArvzCaNQGDOeLCtuvj6PsoboSHlXo0gLU=.50b3b25b-b358-4316-a586-4cef7165b11b@github.com>
References: <0TMzcFtjTfYVwItU3Uek6MSeFLUBmD43yJoNyx_PvPo=.4ad2f946-0cab-4dc2-b1db-f4f23c64d3f6@github.com>
 <3tLz_lbtQAArvzCaNQGDOeLCtuvj6PsoboSHlXo0gLU=.50b3b25b-b358-4316-a586-4cef7165b11b@github.com>
Message-ID: <NBRrGxwryAmNeiFGv49bvymad5SNUVFOnwpdIiKM2MQ=.832c96db-6996-4346-b464-767951450d91@github.com>

On Mon, 22 Apr 2024 13:33:01 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> This restructures `ObjectMonitor:enter` to fit better with the `LightweightSynchronizer`. Some parts of this could be upstreamed separately. 
>> 
>> This effectively splits up `ObjectMonitor::enter` into three parts. Which LightweightSynchronizer can weave into its `inflate_and_enter`. 
>> 
>> ```c++
>> bool ObjectMonitor::enter(JavaThread* current) {
>>   // 1. Spinning without blocking out deflation
>>   if (spin_enter(current)) {
>>     return true;
>>   }
>> 
>>   // 2. Try to block deflation
>>   ObjectMonitorContentionMark contention_mark(this);
>>   if (enter_is_async_deflating()) {
>>     return false;
>>   }
>> 
>>   // 3. Enter while blocking out deflation
>>   enter_with_contention_mark(current, contention_mark);
>>   return true;
>> }
>> 
>> 
>> It may be worth the effort to document these new methods, and also add better documentation to `inflate_and_enter` which describes the invariants and how `ObjectMonitorContentionMark`, markWord transitions and ObjectMonitor::_owner field (on newly inserted monitors) plays together to guarantee correctness and works. 
>> 
>> This commit is currently based on ffc4c2fd5ba1c28432a5d5e84b8ada95fba7eeb8 without a merge. So GHA is not tested with lilliput. As long as this is mergable without conflicts (and no manual merge is performed) it will also be possible to move this commit down below lilliput on-top of OMWorld directly.
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix missed lock change

src/hotspot/share/runtime/lightweightSynchronizer.cpp line 980:

> 978:   locking_thread->om_set_monitor_cache(monitor);
> 979:   if (lock != nullptr) {
> 980:     lock->set_displaced_header(monitor);

We might want to consider extracting these into the callers.

src/hotspot/share/runtime/lightweightSynchronizer.hpp line 57:

> 55: 
> 56:   static void enter_for(Handle obj, BasicLock* lock, JavaThread* locking_thread);
> 57:   static void enter(Handle obj, BasicLock* lock, JavaThread* locking_thread);

Suggestion:

  static void enter(Handle obj, BasicLock* lock, JavaThread* current);

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

PR Review Comment: https://git.openjdk.org/lilliput/pull/159#discussion_r1574854116
PR Review Comment: https://git.openjdk.org/lilliput/pull/159#discussion_r1574844949

From stefank at openjdk.org  Mon Apr 22 15:08:39 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 22 Apr 2024 15:08:39 GMT
Subject: [master] RFR: 8319185: [Lilliput] Enable and fix vectorization
 tests [v2]
In-Reply-To: <_uF7HfCyZJrIEUb6F9mAstPN-CW3wyaZO60xL5Gnshs=.2d032420-9cdf-4bfe-b9c7-52bf3660b32f@github.com>
References: <ZnI9tBlTse9_zsW3AKCOn3npi3vgMOZfbo-Eolh2fns=.63bf30ec-d43b-40e5-9b38-07312aefa403@github.com>
 <_uF7HfCyZJrIEUb6F9mAstPN-CW3wyaZO60xL5Gnshs=.2d032420-9cdf-4bfe-b9c7-52bf3660b32f@github.com>
Message-ID: <y2PHBB0sic-1El2CL6XjxK-7lbEh3N1wVzOG9UpckMU=.dc13308d-0dc1-4296-8b73-4412e247f446@github.com>

On Mon, 22 Apr 2024 10:28:01 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This re-instates #125 after it has been lost with the Great Reset. It's a clean cherry-pick of that other commit.
>> 
>> Compared to #125 this change also fixes compiler/loopopts/superword/TestAlignVector.java, which is new since then.
>
> 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 three additional commits since the last revision:
> 
>  - Fix TestAlignVector.java
>  - Merge branch 'master' into fix-vector-tests
>  - 8319185: [Lilliput] Enable and fix vectorization tests
>    
>    Reviewed-by: shade

Marked as reviewed by stefank (Committer).

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

PR Review: https://git.openjdk.org/lilliput/pull/152#pullrequestreview-2015042916

From rkennke at openjdk.org  Mon Apr 22 15:08:51 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 22 Apr 2024 15:08:51 GMT
Subject: [lilliput-jdk21u:lilliput] Integrated: 8329757: Crash with fatal
 error: DEBUG MESSAGE: Fast Unlock lock on stack
In-Reply-To: <g0KMm_e5rvJHl70Np3eubkjz1JpCcPAlk5FNdiYqK0M=.a5f186e5-b6d4-4d29-934c-8e578dd29e21@github.com>
References: <g0KMm_e5rvJHl70Np3eubkjz1JpCcPAlk5FNdiYqK0M=.a5f186e5-b6d4-4d29-934c-8e578dd29e21@github.com>
Message-ID: <UCSFx60_WYo1gthENmdiGgd5emAP_gwM1Q7MS09izbY=.67b0021f-4aef-4f70-9cc9-1beacb209a45@github.com>

On Mon, 22 Apr 2024 13:39:48 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [e45fea5a](https://github.com/openjdk/jdk/commit/e45fea5a801ac09c3d572ac07d6179e80c422942) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Axel Boldt-Christmas on 12 Apr 2024 and was reviewed by Patricio Chilano Mateo and Vladimir Kozlov.
> 
> Thanks!

This pull request has now been integrated.

Changeset: acde1a99
Author:    Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.org/lilliput-jdk21u/commit/acde1a9977529de6bdb642f126da8c1195af539a
Stats:     149 lines in 4 files changed: 148 ins; 0 del; 1 mod

8329757: Crash with fatal error: DEBUG MESSAGE: Fast Unlock lock on stack

Backport-of: e45fea5a801ac09c3d572ac07d6179e80c422942

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

PR: https://git.openjdk.org/lilliput-jdk21u/pull/31

From aboldtch at openjdk.org  Tue Apr 23 06:06:45 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 23 Apr 2024 06:06:45 GMT
Subject: [master] Integrated: OMWorld: Remove JavaThread Sync Deflation Code
In-Reply-To: <8-eVhsX7Q-yQudVfIt9MZabMQY59Dt9jPKVaDgX39sw=.d0cf63ca-5565-4286-b7bc-89e9ad3e592b@github.com>
References: <8-eVhsX7Q-yQudVfIt9MZabMQY59Dt9jPKVaDgX39sw=.d0cf63ca-5565-4286-b7bc-89e9ad3e592b@github.com>
Message-ID: <qP6LgGuBZN4fOiK6CdIwDMwzZkDcqEWj6V9auSGgQaU=.50aff5d3-6857-4aa4-b9ac-b4571b3c9ad1@github.com>

On Mon, 22 Apr 2024 12:04:17 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> This removes the code that allows JavaThreads to deflate ObjectMonitors on self owned monitors on wait and exit. 
> 
> There currently is no good way to decide if a certain ObjectMonitor should be deflated. 
> 
> I propose removing the experimental code that relates to this feature, I will keep open a draft PR after this is integrated containing the JavaThread Sync Deflation Code in case it is something that is picked up at a later point.
> 
> This commit is currently based on ffc4c2fd5ba1c28432a5d5e84b8ada95fba7eeb8 without a merge. So GHA is not tested with lilliput. As long as this is mergable without conflicts (and no manual merge is performed) it will also be possible to move this commit down below lilliput on-top of OMWorld directly.

This pull request has now been integrated.

Changeset: 837b2672
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
URL:       https://git.openjdk.org/lilliput/commit/837b26722c655a18152faabcc7e314909b11ba64
Stats:     129 lines in 8 files changed: 0 ins; 128 del; 1 mod

OMWorld: Remove JavaThread Sync Deflation Code

Reviewed-by: rkennke

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

PR: https://git.openjdk.org/lilliput/pull/153

From aboldtch at openjdk.org  Tue Apr 23 06:07:42 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 23 Apr 2024 06:07:42 GMT
Subject: [master] Integrated: OMWorld: Cleanup
 ObjectSynchronizer::enter_fast_impl
In-Reply-To: <jslLO0Cb47AcmSKcEfij6jEppLQEz_-7lEK78VX7M2o=.12b38cfd-e023-473b-9364-a1f782807e59@github.com>
References: <jslLO0Cb47AcmSKcEfij6jEppLQEz_-7lEK78VX7M2o=.12b38cfd-e023-473b-9364-a1f782807e59@github.com>
Message-ID: <du58T_LlLiXJku2C-VPwe6jyZ2scmOi0Qkgl_n6X6Ak=.04910226-c553-4ee6-8e10-30c578eea9c7@github.com>

On Mon, 22 Apr 2024 12:06:26 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Cleanup of `ObjectSynchronizer::enter_fast_impl` after `LM_LIGHTWEIGHT` and `LM_PLACEHOLDER` got merged.
> 
> This commit is currently based on ffc4c2fd5ba1c28432a5d5e84b8ada95fba7eeb8 without a merge. So GHA is not tested with lilliput. As long as this is mergable without conflicts (and no manual merge is performed) it will also be possible to move this commit down below lilliput on-top of OMWorld directly.

This pull request has now been integrated.

Changeset: 47d6eae8
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
URL:       https://git.openjdk.org/lilliput/commit/47d6eae8f36d26b32a0cd3001cfb20fb5121db9e
Stats:     56 lines in 1 file changed: 1 ins; 54 del; 1 mod

OMWorld: Cleanup ObjectSynchronizer::enter_fast_impl

Reviewed-by: rkennke

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

PR: https://git.openjdk.org/lilliput/pull/156

From aboldtch at openjdk.org  Tue Apr 23 06:10:39 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 23 Apr 2024 06:10:39 GMT
Subject: [master] Integrated: OMWorld: Cleanup ObjectSynchronizer::exit
In-Reply-To: <AQ1EeoINZrdWU7FQm-lX2Sq8x-DBZV79paDlgA37Iis=.0a7822ae-2d5b-4176-ac30-ddef8873d217@github.com>
References: <AQ1EeoINZrdWU7FQm-lX2Sq8x-DBZV79paDlgA37Iis=.0a7822ae-2d5b-4176-ac30-ddef8873d217@github.com>
Message-ID: <tFh3h78SvQg5GAVWhtPv_3LIbLCSfeqM1h3MQyVl2HY=.f602b892-2437-42f3-9ebc-e6d515fcb5e6@github.com>

On Mon, 22 Apr 2024 12:05:11 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Cleanup of `ObjectSynchronizer::exit` after `LM_LIGHTWEIGHT` and `LM_PLACEHOLDER` got merged.
> 
> This commit is currently based on ffc4c2fd5ba1c28432a5d5e84b8ada95fba7eeb8 without a merge. So GHA is not tested with lilliput. As long as this is mergable without conflicts (and no manual merge is performed) it will also be possible to move this commit down below lilliput on-top of OMWorld directly.

This pull request has now been integrated.

Changeset: 99d35e89
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
URL:       https://git.openjdk.org/lilliput/commit/99d35e899ce0f464f0880cd3ae6dc8fce71a2a71
Stats:     26 lines in 1 file changed: 0 ins; 25 del; 1 mod

OMWorld: Cleanup ObjectSynchronizer::exit

Reviewed-by: rkennke

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

PR: https://git.openjdk.org/lilliput/pull/154

From aboldtch at openjdk.org  Tue Apr 23 06:10:43 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 23 Apr 2024 06:10:43 GMT
Subject: [master] Integrated: OMWorld: Cleanup inflate
In-Reply-To: <zTYM7tLryIG_brrhXCyFoVab6t-LFH9GkxSOIgVq4Ls=.eac3ddf8-f073-4647-92e7-bd22ea8f1b2d@github.com>
References: <zTYM7tLryIG_brrhXCyFoVab6t-LFH9GkxSOIgVq4Ls=.eac3ddf8-f073-4647-92e7-bd22ea8f1b2d@github.com>
Message-ID: <xTpnV5maaFI6eog-HVdYZ_M6yxyq7mUL4Gh9GchkeG0=.454ba4e1-cae4-46ef-91f9-8288408fbcbf@github.com>

On Mon, 22 Apr 2024 12:06:03 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Cleanup of inflate code after `LM_LIGHTWEIGHT` and `LM_PLACEHOLDER` got merged.
> 
> This commit is currently based on ffc4c2fd5ba1c28432a5d5e84b8ada95fba7eeb8 without a merge. So GHA is not tested with lilliput. As long as this is mergable without conflicts (and no manual merge is performed) it will also be possible to move this commit down below lilliput on-top of OMWorld directly.

This pull request has now been integrated.

Changeset: 83218b05
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
URL:       https://git.openjdk.org/lilliput/commit/83218b05a21b218e2ba4720a483814e1acc32478
Stats:     96 lines in 2 files changed: 2 ins; 78 del; 16 mod

OMWorld: Cleanup inflate

Reviewed-by: rkennke

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

PR: https://git.openjdk.org/lilliput/pull/155

From aboldtch at openjdk.org  Tue Apr 23 06:11:45 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 23 Apr 2024 06:11:45 GMT
Subject: [master] Integrated: OMWorld: Fix javaVFrame::print_lock_info_on
In-Reply-To: <zC6WKabjkak_Lh2mK4ghcwICHwutbbwfe0g2fnpl53c=.84672ce8-94bf-4d1a-8de8-3a8b2fa14a74@github.com>
References: <zC6WKabjkak_Lh2mK4ghcwICHwutbbwfe0g2fnpl53c=.84672ce8-94bf-4d1a-8de8-3a8b2fa14a74@github.com>
Message-ID: <F4DtgLSy6e-MUGT9cnbJRF7L2Hhtj0k5NoBbBHHIWmU=.c9631a3e-bb7e-4564-8c7f-51817f504beb@github.com>

On Mon, 22 Apr 2024 12:30:24 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> OMWorld: `Fix javaVFrame::print_lock_info_on` printing. If the ObjectMonitor is `nullptr` and the header is `has_monitor` then we must be in the process of locking. (We cannot have locked, as that would have prevented deflation). 
> 
> This commit is currently based on ffc4c2fd5ba1c28432a5d5e84b8ada95fba7eeb8 without a merge. So GHA is not tested with lilliput. As long as this is mergable without conflicts (and no manual merge is performed) it will also be possible to move this commit down below lilliput on-top of OMWorld directly.

This pull request has now been integrated.

Changeset: 8e25cd67
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
URL:       https://git.openjdk.org/lilliput/commit/8e25cd67307e84ba1ffd0b404d906c2f04e67ea2
Stats:     4 lines in 1 file changed: 2 ins; 1 del; 1 mod

OMWorld: Fix javaVFrame::print_lock_info_on

Reviewed-by: rkennke

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

PR: https://git.openjdk.org/lilliput/pull/158

From aboldtch at openjdk.org  Tue Apr 23 08:02:12 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 23 Apr 2024 08:02:12 GMT
Subject: [master] RFR: OMWorld: ObjectMonitor:enter [v3]
In-Reply-To: <0TMzcFtjTfYVwItU3Uek6MSeFLUBmD43yJoNyx_PvPo=.4ad2f946-0cab-4dc2-b1db-f4f23c64d3f6@github.com>
References: <0TMzcFtjTfYVwItU3Uek6MSeFLUBmD43yJoNyx_PvPo=.4ad2f946-0cab-4dc2-b1db-f4f23c64d3f6@github.com>
Message-ID: <cCkvbTdnwKA5fGFzf7hYnM8UVliYvc51Wq9NJ-R0-OY=.44b1dd30-bb6c-4411-9f64-31344a6f18ab@github.com>

> This restructures `ObjectMonitor:enter` to fit better with the `LightweightSynchronizer`. Some parts of this could be upstreamed separately. 
> 
> This effectively splits up `ObjectMonitor::enter` into three parts. Which LightweightSynchronizer can weave into its `inflate_and_enter`. 
> 
> ```c++
> bool ObjectMonitor::enter(JavaThread* current) {
>   // 1. Spinning without blocking out deflation
>   if (spin_enter(current)) {
>     return true;
>   }
> 
>   // 2. Try to block deflation
>   ObjectMonitorContentionMark contention_mark(this);
>   if (enter_is_async_deflating()) {
>     return false;
>   }
> 
>   // 3. Enter while blocking out deflation
>   enter_with_contention_mark(current, contention_mark);
>   return true;
> }
> 
> 
> It may be worth the effort to document these new methods, and also add better documentation to `inflate_and_enter` which describes the invariants and how `ObjectMonitorContentionMark`, markWord transitions and ObjectMonitor::_owner field (on newly inserted monitors) plays together to guarantee correctness and works. 
> 
> This commit is currently based on ffc4c2fd5ba1c28432a5d5e84b8ada95fba7eeb8 without a merge. So GHA is not tested with lilliput. As long as this is mergable without conflicts (and no manual merge is performed) it will also be possible to move this commit down below lilliput on-top of OMWorld directly.

Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:

  Update src/hotspot/share/runtime/lightweightSynchronizer.hpp
  
  Co-authored-by: Stefan Karlsson <stefan.karlsson at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/lilliput/pull/159/files
  - new: https://git.openjdk.org/lilliput/pull/159/files/24ed7d73..fef4a24d

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

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

PR: https://git.openjdk.org/lilliput/pull/159

From aboldtch at openjdk.org  Tue Apr 23 10:04:12 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 23 Apr 2024 10:04:12 GMT
Subject: [master] RFR: OMWorld: ObjectMonitor:enter [v4]
In-Reply-To: <0TMzcFtjTfYVwItU3Uek6MSeFLUBmD43yJoNyx_PvPo=.4ad2f946-0cab-4dc2-b1db-f4f23c64d3f6@github.com>
References: <0TMzcFtjTfYVwItU3Uek6MSeFLUBmD43yJoNyx_PvPo=.4ad2f946-0cab-4dc2-b1db-f4f23c64d3f6@github.com>
Message-ID: <qz5cZpd1Dns8gukF7Ijt3bFPfzM6BcvOvxzrjq9wGwE=.6e30a268-31ce-45c6-b884-6df4d04ec76f@github.com>

> This restructures `ObjectMonitor:enter` to fit better with the `LightweightSynchronizer`. Some parts of this could be upstreamed separately. 
> 
> This effectively splits up `ObjectMonitor::enter` into three parts. Which LightweightSynchronizer can weave into its `inflate_and_enter`. 
> 
> ```c++
> bool ObjectMonitor::enter(JavaThread* current) {
>   // 1. Spinning without blocking out deflation
>   if (spin_enter(current)) {
>     return true;
>   }
> 
>   // 2. Try to block deflation
>   ObjectMonitorContentionMark contention_mark(this);
>   if (enter_is_async_deflating()) {
>     return false;
>   }
> 
>   // 3. Enter while blocking out deflation
>   enter_with_contention_mark(current, contention_mark);
>   return true;
> }
> 
> 
> It may be worth the effort to document these new methods, and also add better documentation to `inflate_and_enter` which describes the invariants and how `ObjectMonitorContentionMark`, markWord transitions and ObjectMonitor::_owner field (on newly inserted monitors) plays together to guarantee correctness and works. 
> 
> This commit is currently based on ffc4c2fd5ba1c28432a5d5e84b8ada95fba7eeb8 without a merge. So GHA is not tested with lilliput. As long as this is mergable without conflicts (and no manual merge is performed) it will also be possible to move this commit down below lilliput on-top of OMWorld directly.

Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:

  Introduce CacheSetter and move cache updates out of inflate_and_enter

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

Changes:
  - all: https://git.openjdk.org/lilliput/pull/159/files
  - new: https://git.openjdk.org/lilliput/pull/159/files/fef4a24d..bb474806

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

  Stats: 94 lines in 3 files changed: 39 ins; 36 del; 19 mod
  Patch: https://git.openjdk.org/lilliput/pull/159.diff
  Fetch: git fetch https://git.openjdk.org/lilliput.git pull/159/head:pull/159

PR: https://git.openjdk.org/lilliput/pull/159

From aboldtch at openjdk.org  Tue Apr 23 10:15:12 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 23 Apr 2024 10:15:12 GMT
Subject: [master] RFR: OMWorld: Cleanup quick_enter [v2]
In-Reply-To: <J1jzghXA4LOp-Gq6fEw_bhx15k9si2-wz2qunSLuGZM=.a9afdce3-bcff-49bf-8ba5-e01833bfba10@github.com>
References: <J1jzghXA4LOp-Gq6fEw_bhx15k9si2-wz2qunSLuGZM=.a9afdce3-bcff-49bf-8ba5-e01833bfba10@github.com>
Message-ID: <sgdXfbMbR7TEdLriqYKiVn2xEyBWYTDLmFJZXMnjeWw=.0566dd25-4aa8-42c5-bfe1-c630e7cfd48e@github.com>

> Cleanup of `ObjectSynchronizer::quick_enter` after `LM_LIGHTWEIGHT` and `LM_PLACEHOLDER` got merged.
> 
> `LM_LIGHTWEIGHT` now makes use of `quick_enter`.  Doing a lookup in the hash table may be not be the best thing to do. Maybe just looking in thread local cache is enough. To avoid having to do multiple lookups.  Will add this change after I have tested it.
> 
> This commit is currently based on ffc4c2fd5ba1c28432a5d5e84b8ada95fba7eeb8 without a merge. So GHA is not tested with lilliput. As long as this is mergable without conflicts (and no manual merge is performed) it will also be possible to move this commit down below lilliput on-top of OMWorld directly.

Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:

  Use cache instead of table

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

Changes:
  - all: https://git.openjdk.org/lilliput/pull/157/files
  - new: https://git.openjdk.org/lilliput/pull/157/files/ecc164d8..611ff1a7

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

  Stats: 11 lines in 1 file changed: 9 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/lilliput/pull/157.diff
  Fetch: git fetch https://git.openjdk.org/lilliput.git pull/157/head:pull/157

PR: https://git.openjdk.org/lilliput/pull/157

From stefank at openjdk.org  Tue Apr 23 11:48:47 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 23 Apr 2024 11:48:47 GMT
Subject: [master] RFR: Parallel: modify to-space object in array chunking
In-Reply-To: <vWppDSfDayiixAmpHipWzMnBpiYtC8xfad0aMzBn6To=.ab53633e-f7e2-415a-8626-22b78e817dec@github.com>
References: <vWppDSfDayiixAmpHipWzMnBpiYtC8xfad0aMzBn6To=.ab53633e-f7e2-415a-8626-22b78e817dec@github.com>
Message-ID: <kPNA2uIl2vo4qB4VT2oHWDmT_QJBfM8wYSIszgFm-k8=.3bc97f50-20fe-4df6-9773-b57cdd55e040@github.com>

On Fri, 19 Apr 2024 13:59:21 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> The ParallelGC chunks arrays so that it can somewhat parallelize the array processing. This is done by rewriting the length field of the from-space object. This causes a problem for Lilliput when one thread copies an object, forwards it, and then rewrites the length of the from-space copy, while another thread tries to figure out if it should copy the object and tries to read the size of the object.
> 
> The second thread tries to stay away from calling `oopDesc::klass()` on the from-space object, because the header might have been overwritten by another thread. So, it only reads the mark word, tries to figure out the object has been forwarded, and then calls `size_given_klass` to figure out the size.
> 
> The `size_given_klass` has some asserts that checks that the different ways to calculate array sizes are consistent, but since other threads could be updating the length field, there is an escape-hatch that makes that assert less strict. This is the assert:
> 
> assert(s == klass->oop_size(this) || size_might_change(), "wrong array object size");
> 
> 
> The problem for Lilliput is that `size_might_change()` rereads the object's klass pointer, which will fail because the header is overwritten with a forwarding pointer.
> 
> This can be fixed by passing in the klass or maybe by following the forwarding pointer to find the to-space object and find the klass from there, but I wonder if this all wouldn't be safer if we left the from-space object unmodified and instead changed the length field of the to-space object. In fact, this is exactly what G1 does since many years (which also indicates that the `size_might_change()` really shouldn't be checking for UseG1GC).
> 
> The above is a proposal of what this would look like. I'm publishing this here for Lilliput because it fixes a real bug here, but if this is the right way to go forward, then this should likely be upstreamed as well.
> 
> I've run this through tier1-3 with both UseParallelGC and UseCompactObjectHeaders enabled, and I'm currently running this through higher Oracle tiers.

I'm closing this PR and suggest that we fix this with #163 instead.

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

PR Comment: https://git.openjdk.org/lilliput/pull/149#issuecomment-2072082543

From stefank at openjdk.org  Tue Apr 23 11:48:47 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 23 Apr 2024 11:48:47 GMT
Subject: [master] Withdrawn: Parallel: modify to-space object in array chunking
In-Reply-To: <vWppDSfDayiixAmpHipWzMnBpiYtC8xfad0aMzBn6To=.ab53633e-f7e2-415a-8626-22b78e817dec@github.com>
References: <vWppDSfDayiixAmpHipWzMnBpiYtC8xfad0aMzBn6To=.ab53633e-f7e2-415a-8626-22b78e817dec@github.com>
Message-ID: <v6eZi3tPr_xBQ6QvhDO73J8VE-oMWbKZnB8flx10QQ0=.7a248616-beb7-4979-a68d-09f2041dda15@github.com>

On Fri, 19 Apr 2024 13:59:21 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> The ParallelGC chunks arrays so that it can somewhat parallelize the array processing. This is done by rewriting the length field of the from-space object. This causes a problem for Lilliput when one thread copies an object, forwards it, and then rewrites the length of the from-space copy, while another thread tries to figure out if it should copy the object and tries to read the size of the object.
> 
> The second thread tries to stay away from calling `oopDesc::klass()` on the from-space object, because the header might have been overwritten by another thread. So, it only reads the mark word, tries to figure out the object has been forwarded, and then calls `size_given_klass` to figure out the size.
> 
> The `size_given_klass` has some asserts that checks that the different ways to calculate array sizes are consistent, but since other threads could be updating the length field, there is an escape-hatch that makes that assert less strict. This is the assert:
> 
> assert(s == klass->oop_size(this) || size_might_change(), "wrong array object size");
> 
> 
> The problem for Lilliput is that `size_might_change()` rereads the object's klass pointer, which will fail because the header is overwritten with a forwarding pointer.
> 
> This can be fixed by passing in the klass or maybe by following the forwarding pointer to find the to-space object and find the klass from there, but I wonder if this all wouldn't be safer if we left the from-space object unmodified and instead changed the length field of the to-space object. In fact, this is exactly what G1 does since many years (which also indicates that the `size_might_change()` really shouldn't be checking for UseG1GC).
> 
> The above is a proposal of what this would look like. I'm publishing this here for Lilliput because it fixes a real bug here, but if this is the right way to go forward, then this should likely be upstreamed as well.
> 
> I've run this through tier1-3 with both UseParallelGC and UseCompactObjectHeaders enabled, and I'm currently running this through higher Oracle tiers.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/lilliput/pull/149

From stefank at openjdk.org  Tue Apr 23 11:50:57 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 23 Apr 2024 11:50:57 GMT
Subject: [master] RFR: Parallel: fix size_given_klass
Message-ID: <siCQC-MHQaXPfWGTr7ecL597qcqzNcrij_7cdCBIGHE=.726ecedf-02b1-4010-998e-8fd18c3c6c18@github.com>

The Parallel scavenge threads compete to copy and forward objects, and the winning object is the one that managed to update the the forwarding pointer. For Lilliput, this code needs to be extra carefully written because installing the forwarding pointer destroys the klass pointer. The threads need to read the object header once, and then use that information when figuring out the size of the object. The code has been changed to do this, but there's a place in an assert were the code tries to reread the klass pointer, and then crash because it has been racingly been overwritten by another thread.

I had an idea that we could fix this by simplifying the assert with #149, but that has a problem with self-forwarded objects. There are ways to fix the problem listed in that PR, but for now the suggestion is to just make sure that the asserting code doesn't reread the klass pointer.

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

Commit messages:
 - Parallel: fix size_given_klass

Changes: https://git.openjdk.org/lilliput/pull/163/files
  Webrev: https://webrevs.openjdk.org/?repo=lilliput&pr=163&range=00
  Stats: 4 lines in 3 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/lilliput/pull/163.diff
  Fetch: git fetch https://git.openjdk.org/lilliput.git pull/163/head:pull/163

PR: https://git.openjdk.org/lilliput/pull/163

From stefank at openjdk.org  Tue Apr 23 11:50:57 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 23 Apr 2024 11:50:57 GMT
Subject: [master] RFR: Parallel: fix size_given_klass
In-Reply-To: <siCQC-MHQaXPfWGTr7ecL597qcqzNcrij_7cdCBIGHE=.726ecedf-02b1-4010-998e-8fd18c3c6c18@github.com>
References: <siCQC-MHQaXPfWGTr7ecL597qcqzNcrij_7cdCBIGHE=.726ecedf-02b1-4010-998e-8fd18c3c6c18@github.com>
Message-ID: <M0d4XzPo6Rbi8KCrBKhqzoMrM3-hRdhTffe4r2UmgRI=.aa2d081d-d416-4406-9eba-1f875b299683@github.com>

On Tue, 23 Apr 2024 11:45:13 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> The Parallel scavenge threads compete to copy and forward objects, and the winning object is the one that managed to update the the forwarding pointer. For Lilliput, this code needs to be extra carefully written because installing the forwarding pointer destroys the klass pointer. The threads need to read the object header once, and then use that information when figuring out the size of the object. The code has been changed to do this, but there's a place in an assert were the code tries to reread the klass pointer, and then crash because it has been racingly been overwritten by another thread.
> 
> I had an idea that we could fix this by simplifying the assert with #149, but that has a problem with self-forwarded objects. There are ways to fix the problem listed in that PR, but for now the suggestion is to just make sure that the asserting code doesn't reread the klass pointer.

I've tested this by running tier1-3 with UCOH and UseParallelGC enabled by default in the code.

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

PR Comment: https://git.openjdk.org/lilliput/pull/163#issuecomment-2072085638

From aboldtch at openjdk.org  Tue Apr 23 11:52:45 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 23 Apr 2024 11:52:45 GMT
Subject: [master] Integrated: OMWorld: Cleanup quick_enter
In-Reply-To: <J1jzghXA4LOp-Gq6fEw_bhx15k9si2-wz2qunSLuGZM=.a9afdce3-bcff-49bf-8ba5-e01833bfba10@github.com>
References: <J1jzghXA4LOp-Gq6fEw_bhx15k9si2-wz2qunSLuGZM=.a9afdce3-bcff-49bf-8ba5-e01833bfba10@github.com>
Message-ID: <f_xnMId0BPuf5rWtmgjq4nDuiStTxIZckAAu89LnyCM=.78e5cf62-9c6b-4712-88bb-dd722672ef19@github.com>

On Mon, 22 Apr 2024 12:21:05 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Cleanup of `ObjectSynchronizer::quick_enter` after `LM_LIGHTWEIGHT` and `LM_PLACEHOLDER` got merged.
> 
> `LM_LIGHTWEIGHT` now makes use of `quick_enter`.  Doing a lookup in the hash table may be not be the best thing to do. Maybe just looking in thread local cache is enough. To avoid having to do multiple lookups.  Will add this change after I have tested it.
> 
> This commit is currently based on ffc4c2fd5ba1c28432a5d5e84b8ada95fba7eeb8 without a merge. So GHA is not tested with lilliput. As long as this is mergable without conflicts (and no manual merge is performed) it will also be possible to move this commit down below lilliput on-top of OMWorld directly.

This pull request has now been integrated.

Changeset: a4388a3c
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
URL:       https://git.openjdk.org/lilliput/commit/a4388a3c1147084f40fa8695e2ffffda62bb735a
Stats:     14 lines in 1 file changed: 9 ins; 4 del; 1 mod

OMWorld: Cleanup quick_enter

Reviewed-by: rkennke

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

PR: https://git.openjdk.org/lilliput/pull/157

From aboldtch at openjdk.org  Tue Apr 23 11:53:39 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 23 Apr 2024 11:53:39 GMT
Subject: [master] RFR: Parallel: fix size_given_klass
In-Reply-To: <siCQC-MHQaXPfWGTr7ecL597qcqzNcrij_7cdCBIGHE=.726ecedf-02b1-4010-998e-8fd18c3c6c18@github.com>
References: <siCQC-MHQaXPfWGTr7ecL597qcqzNcrij_7cdCBIGHE=.726ecedf-02b1-4010-998e-8fd18c3c6c18@github.com>
Message-ID: <xAZ3vJYr0ANLVewovGzFZL7y6pUdaRSuV2qpe4TQf0k=.b2ef9e45-f936-436c-be92-da964ae1c338@github.com>

On Tue, 23 Apr 2024 11:45:13 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> The Parallel scavenge threads compete to copy and forward objects, and the winning object is the one that managed to update the the forwarding pointer. For Lilliput, this code needs to be extra carefully written because installing the forwarding pointer destroys the klass pointer. The threads need to read the object header once, and then use that information when figuring out the size of the object. The code has been changed to do this, but there's a place in an assert were the code tries to reread the klass pointer, and then crash because it has been racingly been overwritten by another thread.
> 
> I had an idea that we could fix this by simplifying the assert with #149, but that has a problem with self-forwarded objects. There are ways to fix the problem listed in that PR, but for now the suggestion is to just make sure that the asserting code doesn't reread the klass pointer.

lgtm.

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

Marked as reviewed by aboldtch (Committer).

PR Review: https://git.openjdk.org/lilliput/pull/163#pullrequestreview-2017017785

From aboldtch at openjdk.org  Tue Apr 23 11:54:40 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 23 Apr 2024 11:54:40 GMT
Subject: [master] Integrated: OMWorld: ObjectMonitor:enter
In-Reply-To: <0TMzcFtjTfYVwItU3Uek6MSeFLUBmD43yJoNyx_PvPo=.4ad2f946-0cab-4dc2-b1db-f4f23c64d3f6@github.com>
References: <0TMzcFtjTfYVwItU3Uek6MSeFLUBmD43yJoNyx_PvPo=.4ad2f946-0cab-4dc2-b1db-f4f23c64d3f6@github.com>
Message-ID: <PS5BhRhZOmfnSOiOzNUP82Ga9Xrj-84rUgrdPpW3Kbo=.bc2d0c89-dcfe-472c-b169-42087005da73@github.com>

On Mon, 22 Apr 2024 12:44:38 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> This restructures `ObjectMonitor:enter` to fit better with the `LightweightSynchronizer`. Some parts of this could be upstreamed separately. 
> 
> This effectively splits up `ObjectMonitor::enter` into three parts. Which LightweightSynchronizer can weave into its `inflate_and_enter`. 
> 
> ```c++
> bool ObjectMonitor::enter(JavaThread* current) {
>   // 1. Spinning without blocking out deflation
>   if (spin_enter(current)) {
>     return true;
>   }
> 
>   // 2. Try to block deflation
>   ObjectMonitorContentionMark contention_mark(this);
>   if (enter_is_async_deflating()) {
>     return false;
>   }
> 
>   // 3. Enter while blocking out deflation
>   enter_with_contention_mark(current, contention_mark);
>   return true;
> }
> 
> 
> It may be worth the effort to document these new methods, and also add better documentation to `inflate_and_enter` which describes the invariants and how `ObjectMonitorContentionMark`, markWord transitions and ObjectMonitor::_owner field (on newly inserted monitors) plays together to guarantee correctness and works. 
> 
> This commit is currently based on ffc4c2fd5ba1c28432a5d5e84b8ada95fba7eeb8 without a merge. So GHA is not tested with lilliput. As long as this is mergable without conflicts (and no manual merge is performed) it will also be possible to move this commit down below lilliput on-top of OMWorld directly.

This pull request has now been integrated.

Changeset: 44f1b602
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
URL:       https://git.openjdk.org/lilliput/commit/44f1b602e4750f3ad3ec137b0eadbfb7a4d88e24
Stats:     292 lines in 6 files changed: 141 ins; 73 del; 78 mod

OMWorld: ObjectMonitor:enter

Reviewed-by: rkennke

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

PR: https://git.openjdk.org/lilliput/pull/159

From aboldtch at openjdk.org  Tue Apr 23 11:59:04 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 23 Apr 2024 11:59:04 GMT
Subject: [master] RFR: OMWorld: Remove BasicLock* restrictions
Message-ID: <naGlOEh4z8uIieF35vhrpKFGnmpYU4fzAQX2Fwz_y6w=.e2317f22-c6d6-4922-9371-4e94c6b681dc@github.com>

This is based on #159 

The main idea is to remove the restrictions where the `BasicLock*` may be missing when calling into the runtime. This is only an issue on x86_32. For now simply call into the runtime at the places where the registers are lacking. `quick_enter` should take care of the cases where we otherwise would have skipped calling into the runtime, as x86_32 calls into the runtime regardless (to get the thread) this may even be performance neutral.

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

Commit messages:
 - Merge branch 'usptream_lilliput:pr/159' into lilliput-om-always-take-basiclock
 - Introduce CacheSetter and move cache updates out of inflate_and_enter
 - Update src/hotspot/share/runtime/lightweightSynchronizer.hpp
 - Cleanup after 24ed7d7: Fix missed lock change
 - Remove x86_32 imposed limitations on BasicLock*
 - Unify x86 and x64 C2_MacroAssembler::fast_unlock_lightweight
 - Remove monitorenter_obj
 - Fix missed lock change
 - Cleanup ObjectMonitor::enter and LightweightSynchronizer::inflate_and_enter
 - Cleanup and fix enter / enter_for distinction

Changes: https://git.openjdk.org/lilliput/pull/160/files
  Webrev: https://webrevs.openjdk.org/?repo=lilliput&pr=160&range=00
  Stats: 404 lines in 16 files changed: 143 ins; 148 del; 113 mod
  Patch: https://git.openjdk.org/lilliput/pull/160.diff
  Fetch: git fetch https://git.openjdk.org/lilliput.git pull/160/head:pull/160

PR: https://git.openjdk.org/lilliput/pull/160

From rkennke at openjdk.org  Tue Apr 23 11:59:05 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 23 Apr 2024 11:59:05 GMT
Subject: [master] RFR: OMWorld: Remove BasicLock* restrictions
In-Reply-To: <naGlOEh4z8uIieF35vhrpKFGnmpYU4fzAQX2Fwz_y6w=.e2317f22-c6d6-4922-9371-4e94c6b681dc@github.com>
References: <naGlOEh4z8uIieF35vhrpKFGnmpYU4fzAQX2Fwz_y6w=.e2317f22-c6d6-4922-9371-4e94c6b681dc@github.com>
Message-ID: <55av6WncaCeekFObvca19TtPP9Av0IGnrFsQtxhFCxg=.4544447b-6436-4213-938d-70e7daf7f43d@github.com>

On Mon, 22 Apr 2024 12:58:26 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> This is based on #159 
> 
> The main idea is to remove the restrictions where the `BasicLock*` may be missing when calling into the runtime. This is only an issue on x86_32. For now simply call into the runtime at the places where the registers are lacking. `quick_enter` should take care of the cases where we otherwise would have skipped calling into the runtime, as x86_32 calls into the runtime regardless (to get the thread) this may even be performance neutral.

Nice! Looks reasonable. Yeah I've been thinking the same: if we need to call runtime to fetch the Thread* anyway, we might as well do all the locking stuff there.

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

Marked as reviewed by rkennke (Lead).

PR Review: https://git.openjdk.org/lilliput/pull/160#pullrequestreview-2014934931

From aboldtch at openjdk.org  Tue Apr 23 12:22:08 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 23 Apr 2024 12:22:08 GMT
Subject: [master] RFR: OMWorld: Remove BasicLock* restrictions [v2]
In-Reply-To: <naGlOEh4z8uIieF35vhrpKFGnmpYU4fzAQX2Fwz_y6w=.e2317f22-c6d6-4922-9371-4e94c6b681dc@github.com>
References: <naGlOEh4z8uIieF35vhrpKFGnmpYU4fzAQX2Fwz_y6w=.e2317f22-c6d6-4922-9371-4e94c6b681dc@github.com>
Message-ID: <mZNgD7MbVvHqHO0Di9g33XkOIZljv0NxbggYctGFqZA=.4058620a-168c-41aa-83ae-263a6aa46ecc@github.com>

> This is based on #159 
> 
> The main idea is to remove the restrictions where the `BasicLock*` may be missing when calling into the runtime. This is only an issue on x86_32. For now simply call into the runtime at the places where the registers are lacking. `quick_enter` should take care of the cases where we otherwise would have skipped calling into the runtime, as x86_32 calls into the runtime regardless (to get the thread) this may even be performance neutral.

Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:

 - Merge remote-tracking branch 'upstream_lilliput/master' into lilliput-om-always-take-basiclock
 - Merge branch 'usptream_lilliput:pr/159' into lilliput-om-always-take-basiclock
 - Introduce CacheSetter and move cache updates out of inflate_and_enter
 - Update src/hotspot/share/runtime/lightweightSynchronizer.hpp
   
   Co-authored-by: Stefan Karlsson <stefan.karlsson at oracle.com>
 - Cleanup after 24ed7d7: Fix missed lock change
 - Remove x86_32 imposed limitations on BasicLock*
 - Unify x86 and x64 C2_MacroAssembler::fast_unlock_lightweight
 - Remove monitorenter_obj
 - Fix missed lock change
 - Cleanup ObjectMonitor::enter and LightweightSynchronizer::inflate_and_enter
 - ... and 1 more: https://git.openjdk.org/lilliput/compare/44f1b602...d5472ef3

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

Changes: https://git.openjdk.org/lilliput/pull/160/files
  Webrev: https://webrevs.openjdk.org/?repo=lilliput&pr=160&range=01
  Stats: 122 lines in 11 files changed: 6 ins; 79 del; 37 mod
  Patch: https://git.openjdk.org/lilliput/pull/160.diff
  Fetch: git fetch https://git.openjdk.org/lilliput.git pull/160/head:pull/160

PR: https://git.openjdk.org/lilliput/pull/160

From rkennke at openjdk.org  Tue Apr 23 12:30:41 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 23 Apr 2024 12:30:41 GMT
Subject: [master] RFR: Parallel: fix size_given_klass
In-Reply-To: <siCQC-MHQaXPfWGTr7ecL597qcqzNcrij_7cdCBIGHE=.726ecedf-02b1-4010-998e-8fd18c3c6c18@github.com>
References: <siCQC-MHQaXPfWGTr7ecL597qcqzNcrij_7cdCBIGHE=.726ecedf-02b1-4010-998e-8fd18c3c6c18@github.com>
Message-ID: <D5fg4Nbit0oBGl5Ab6rj9IqGawqULpIxfhA6gUjGkrY=.7a1b129e-7497-4b1c-915f-810920edf274@github.com>

On Tue, 23 Apr 2024 11:45:13 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> The Parallel scavenge threads compete to copy and forward objects, and the winning object is the one that managed to update the the forwarding pointer. For Lilliput, this code needs to be extra carefully written because installing the forwarding pointer destroys the klass pointer. The threads need to read the object header once, and then use that information when figuring out the size of the object. The code has been changed to do this, but there's a place in an assert were the code tries to reread the klass pointer, and then crash because it has been racingly been overwritten by another thread.
> 
> I had an idea that we could fix this by simplifying the assert with #149, but that has a problem with self-forwarded objects. There are ways to fix the problem listed in that PR, but for now the suggestion is to just make sure that the asserting code doesn't reread the klass pointer.

Looks good. (well, except that this size_might_change() is an ugly cludge, but this needs to be addressed elsewhere)

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

Marked as reviewed by rkennke (Lead).

PR Review: https://git.openjdk.org/lilliput/pull/163#pullrequestreview-2017102495

From rkennke at openjdk.org  Tue Apr 23 12:45:41 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 23 Apr 2024 12:45:41 GMT
Subject: [master] Integrated: 8319185: [Lilliput] Enable and fix vectorization
 tests
In-Reply-To: <ZnI9tBlTse9_zsW3AKCOn3npi3vgMOZfbo-Eolh2fns=.63bf30ec-d43b-40e5-9b38-07312aefa403@github.com>
References: <ZnI9tBlTse9_zsW3AKCOn3npi3vgMOZfbo-Eolh2fns=.63bf30ec-d43b-40e5-9b38-07312aefa403@github.com>
Message-ID: <ok0rwcgPdnB-_KWQEeV0WRK-H7g0UmTYODQDeLtrJfM=.90a2c15c-2bda-4291-858c-11c0f437ae44@github.com>

On Mon, 22 Apr 2024 08:21:17 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> This re-instates #125 after it has been lost with the Great Reset. It's a clean cherry-pick of that other commit.
> 
> Compared to #125 this change also fixes compiler/loopopts/superword/TestAlignVector.java, which is new since then.

This pull request has now been integrated.

Changeset: 2f9af340
Author:    Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.org/lilliput/commit/2f9af340ef031372450e42449b7fc66422c667bf
Stats:     26 lines in 5 files changed: 16 ins; 0 del; 10 mod

8319185: [Lilliput] Enable and fix vectorization tests

Reviewed-by: stefank

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

PR: https://git.openjdk.org/lilliput/pull/152

From stefank at openjdk.org  Tue Apr 23 12:57:43 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 23 Apr 2024 12:57:43 GMT
Subject: [master] RFR: Parallel: fix size_given_klass
In-Reply-To: <siCQC-MHQaXPfWGTr7ecL597qcqzNcrij_7cdCBIGHE=.726ecedf-02b1-4010-998e-8fd18c3c6c18@github.com>
References: <siCQC-MHQaXPfWGTr7ecL597qcqzNcrij_7cdCBIGHE=.726ecedf-02b1-4010-998e-8fd18c3c6c18@github.com>
Message-ID: <XgtMpsEsvFEfAYsH3B3XIqzEDoIb0zRR9ehXC85b9Rc=.4741024e-7176-4338-bcea-8b19148fafc6@github.com>

On Tue, 23 Apr 2024 11:45:13 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> The Parallel scavenge threads compete to copy and forward objects, and the winning object is the one that managed to update the the forwarding pointer. For Lilliput, this code needs to be extra carefully written because installing the forwarding pointer destroys the klass pointer. The threads need to read the object header once, and then use that information when figuring out the size of the object. The code has been changed to do this, but there's a place in an assert were the code tries to reread the klass pointer, and then crash because it has been racingly been overwritten by another thread.
> 
> I had an idea that we could fix this by simplifying the assert with #149, but that has a problem with self-forwarded objects. There are ways to fix the problem listed in that PR, but for now the suggestion is to just make sure that the asserting code doesn't reread the klass pointer.

Thanks for reviewing!

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

PR Comment: https://git.openjdk.org/lilliput/pull/163#issuecomment-2072225403

From stefank at openjdk.org  Tue Apr 23 12:57:43 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 23 Apr 2024 12:57:43 GMT
Subject: [master] Integrated: Parallel: fix size_given_klass
In-Reply-To: <siCQC-MHQaXPfWGTr7ecL597qcqzNcrij_7cdCBIGHE=.726ecedf-02b1-4010-998e-8fd18c3c6c18@github.com>
References: <siCQC-MHQaXPfWGTr7ecL597qcqzNcrij_7cdCBIGHE=.726ecedf-02b1-4010-998e-8fd18c3c6c18@github.com>
Message-ID: <dVQ4WGbbTWDagqrMm4hBWFJUgbV9T_Jp0BL2VYblD5A=.17e2e25e-6f8f-4ea1-a4cf-b547a5b82197@github.com>

On Tue, 23 Apr 2024 11:45:13 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> The Parallel scavenge threads compete to copy and forward objects, and the winning object is the one that managed to update the the forwarding pointer. For Lilliput, this code needs to be extra carefully written because installing the forwarding pointer destroys the klass pointer. The threads need to read the object header once, and then use that information when figuring out the size of the object. The code has been changed to do this, but there's a place in an assert were the code tries to reread the klass pointer, and then crash because it has been racingly been overwritten by another thread.
> 
> I had an idea that we could fix this by simplifying the assert with #149, but that has a problem with self-forwarded objects. There are ways to fix the problem listed in that PR, but for now the suggestion is to just make sure that the asserting code doesn't reread the klass pointer.

This pull request has now been integrated.

Changeset: da6ad59e
Author:    Stefan Karlsson <stefank at openjdk.org>
URL:       https://git.openjdk.org/lilliput/commit/da6ad59ec45c04a2b79c156861c2244a72766f7c
Stats:     4 lines in 3 files changed: 0 ins; 0 del; 4 mod

Parallel: fix size_given_klass

Reviewed-by: aboldtch, rkennke

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

PR: https://git.openjdk.org/lilliput/pull/163

From stefank at openjdk.org  Tue Apr 23 13:09:47 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 23 Apr 2024 13:09:47 GMT
Subject: [master] RFR: OMWorld: Cleanup ObjectMonitor::_header
In-Reply-To: <T9Kl7-okmXHWJrQOcIlvCf9r3bk6KL0mn_jGdFvVnKw=.fc73986b-1c44-4bb5-b7bc-5283cb047431@github.com>
References: <T9Kl7-okmXHWJrQOcIlvCf9r3bk6KL0mn_jGdFvVnKw=.fc73986b-1c44-4bb5-b7bc-5283cb047431@github.com>
Message-ID: <WbMGg9G2tWYgcga_AgnP98HZQ2A-lAhweCmy6WJIgCM=.83fb41bb-e1d7-4d05-818d-23ba9d03a048@github.com>

On Mon, 22 Apr 2024 13:20:33 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> This changes the `ObjectMonitor::_header` to `ObjectMonitor::_metadata` and cleans up the surrounding terminology. 
> 
> Parts of this could be upstreamed, but the distinction of this field between the different locking modes is introduced in OMWorld. 
> 
> This patch will conflict with Lilliput if rebased on-top of OMWorld because Lilliput introduces `static ByteSize header_offset()` which is not used after OMWorld.  They could probably be removed in both these patches.
> 
> This also changes all the fields to have the same access level (private) so that this can be a standard layout type.

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

> 135:   // Enforced by the assert() in metadata_addr().
> 136:   // * LM_LIGHTWEIGHT
> 137:   // Contains the _objects hashCode.

Suggestion:

  // Contains the _object's hashCode.

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

> 144:   // inflation. The _object does not change, so it is a good choice to share
> 145:   // its cache line with _metadata.
> 146:   DEFINE_PAD_MINUS_SIZE(0, OM_CACHE_LINE_SIZE, sizeof(volatile uintptr_t) +

Could this be using `sizeof(_metadata)` instead?

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

PR Review Comment: https://git.openjdk.org/lilliput/pull/161#discussion_r1576211448
PR Review Comment: https://git.openjdk.org/lilliput/pull/161#discussion_r1576220813

From stefank at openjdk.org  Tue Apr 23 13:11:43 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 23 Apr 2024 13:11:43 GMT
Subject: [master] RFR: OMWorld: Remove BasicLock* restrictions [v2]
In-Reply-To: <mZNgD7MbVvHqHO0Di9g33XkOIZljv0NxbggYctGFqZA=.4058620a-168c-41aa-83ae-263a6aa46ecc@github.com>
References: <naGlOEh4z8uIieF35vhrpKFGnmpYU4fzAQX2Fwz_y6w=.e2317f22-c6d6-4922-9371-4e94c6b681dc@github.com>
 <mZNgD7MbVvHqHO0Di9g33XkOIZljv0NxbggYctGFqZA=.4058620a-168c-41aa-83ae-263a6aa46ecc@github.com>
Message-ID: <CHiSYYD_qbRSeIsK9zWgq01kyqk13EbejgisXOIkPWU=.a195c962-acf4-428c-b239-039ef527ee8f@github.com>

On Tue, 23 Apr 2024 12:22:08 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> This is based on #159 
>> 
>> The main idea is to remove the restrictions where the `BasicLock*` may be missing when calling into the runtime. This is only an issue on x86_32. For now simply call into the runtime at the places where the registers are lacking. `quick_enter` should take care of the cases where we otherwise would have skipped calling into the runtime, as x86_32 calls into the runtime regardless (to get the thread) this may even be performance neutral.
>
> Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - Merge remote-tracking branch 'upstream_lilliput/master' into lilliput-om-always-take-basiclock
>  - Merge branch 'usptream_lilliput:pr/159' into lilliput-om-always-take-basiclock
>  - Introduce CacheSetter and move cache updates out of inflate_and_enter
>  - Update src/hotspot/share/runtime/lightweightSynchronizer.hpp
>    
>    Co-authored-by: Stefan Karlsson <stefan.karlsson at oracle.com>
>  - Cleanup after 24ed7d7: Fix missed lock change
>  - Remove x86_32 imposed limitations on BasicLock*
>  - Unify x86 and x64 C2_MacroAssembler::fast_unlock_lightweight
>  - Remove monitorenter_obj
>  - Fix missed lock change
>  - Cleanup ObjectMonitor::enter and LightweightSynchronizer::inflate_and_enter
>  - ... and 1 more: https://git.openjdk.org/lilliput/compare/44f1b602...d5472ef3

src/hotspot/cpu/x86/c1_MacroAssembler_x86.cpp line 72:

> 70:     lightweight_lock(disp_hdr, obj, hdr, thread, tmp, slow_case);
> 71: #else
> 72:     movptr(hdr, Address(obj, oopDesc::mark_offset_in_bytes()));

Maybe add a comment about this null-check?

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1215:

> 1213: 
> 1214:       // Check if recursive.
> 1215:       cmpptr(Address(monitor,ObjectMonitor::recursions_offset()),0);

Suggestion:

      cmpptr(Address(monitor,ObjectMonitor::recursions_offset()), 0);

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

PR Review Comment: https://git.openjdk.org/lilliput/pull/160#discussion_r1576228602
PR Review Comment: https://git.openjdk.org/lilliput/pull/160#discussion_r1576229484

From aboldtch at openjdk.org  Tue Apr 23 13:15:54 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 23 Apr 2024 13:15:54 GMT
Subject: [master] RFR: OMWorld: Cleanup ObjectMonitor::_header [v2]
In-Reply-To: <T9Kl7-okmXHWJrQOcIlvCf9r3bk6KL0mn_jGdFvVnKw=.fc73986b-1c44-4bb5-b7bc-5283cb047431@github.com>
References: <T9Kl7-okmXHWJrQOcIlvCf9r3bk6KL0mn_jGdFvVnKw=.fc73986b-1c44-4bb5-b7bc-5283cb047431@github.com>
Message-ID: <7e1v0odASpI_c9FuawxLbTuRt57sMES9v9CWQKfV9aU=.13d0b0b6-f630-4800-9b20-3c1280c4ea45@github.com>

> This changes the `ObjectMonitor::_header` to `ObjectMonitor::_metadata` and cleans up the surrounding terminology. 
> 
> Parts of this could be upstreamed, but the distinction of this field between the different locking modes is introduced in OMWorld. 
> 
> This patch will conflict with Lilliput if rebased on-top of OMWorld because Lilliput introduces `static ByteSize header_offset()` which is not used after OMWorld.  They could probably be removed in both these patches.
> 
> This also changes all the fields to have the same access level (private) so that this can be a standard layout type.

Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:

  Update src/hotspot/share/runtime/objectMonitor.hpp
  
  Co-authored-by: Stefan Karlsson <stefan.karlsson at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/lilliput/pull/161/files
  - new: https://git.openjdk.org/lilliput/pull/161/files/b1b80eb1..18b0f07e

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

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

PR: https://git.openjdk.org/lilliput/pull/161

From aboldtch at openjdk.org  Tue Apr 23 13:16:56 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 23 Apr 2024 13:16:56 GMT
Subject: [master] RFR: OMWorld: Remove BasicLock* restrictions [v3]
In-Reply-To: <naGlOEh4z8uIieF35vhrpKFGnmpYU4fzAQX2Fwz_y6w=.e2317f22-c6d6-4922-9371-4e94c6b681dc@github.com>
References: <naGlOEh4z8uIieF35vhrpKFGnmpYU4fzAQX2Fwz_y6w=.e2317f22-c6d6-4922-9371-4e94c6b681dc@github.com>
Message-ID: <cQTb0WuNlo57nCpXDiMWUSCDVIxSHY5QlF8ImjyVQcE=.c6190a67-1683-45ba-90fe-e905af124cd1@github.com>

> This is based on #159 
> 
> The main idea is to remove the restrictions where the `BasicLock*` may be missing when calling into the runtime. This is only an issue on x86_32. For now simply call into the runtime at the places where the registers are lacking. `quick_enter` should take care of the cases where we otherwise would have skipped calling into the runtime, as x86_32 calls into the runtime regardless (to get the thread) this may even be performance neutral.

Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:

  Update src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp
  
  Co-authored-by: Stefan Karlsson <stefan.karlsson at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/lilliput/pull/160/files
  - new: https://git.openjdk.org/lilliput/pull/160/files/d5472ef3..6778ef66

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

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

PR: https://git.openjdk.org/lilliput/pull/160

From aboldtch at openjdk.org  Tue Apr 23 13:43:56 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 23 Apr 2024 13:43:56 GMT
Subject: [master] RFR: OMWorld: Cleanup ObjectMonitor::_header [v3]
In-Reply-To: <T9Kl7-okmXHWJrQOcIlvCf9r3bk6KL0mn_jGdFvVnKw=.fc73986b-1c44-4bb5-b7bc-5283cb047431@github.com>
References: <T9Kl7-okmXHWJrQOcIlvCf9r3bk6KL0mn_jGdFvVnKw=.fc73986b-1c44-4bb5-b7bc-5283cb047431@github.com>
Message-ID: <s0a35Ly9uy6PrUIGdJLISWQR19AUIZuKYqVuR3vvC9g=.1772798e-cade-4cb4-b86e-0515cc1b71c9@github.com>

> This changes the `ObjectMonitor::_header` to `ObjectMonitor::_metadata` and cleans up the surrounding terminology. 
> 
> Parts of this could be upstreamed, but the distinction of this field between the different locking modes is introduced in OMWorld. 
> 
> This patch will conflict with Lilliput if rebased on-top of OMWorld because Lilliput introduces `static ByteSize header_offset()` which is not used after OMWorld.  They could probably be removed in both these patches.
> 
> This also changes all the fields to have the same access level (private) so that this can be a standard layout type.

Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:

  Use variable directly in sizeof

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

Changes:
  - all: https://git.openjdk.org/lilliput/pull/161/files
  - new: https://git.openjdk.org/lilliput/pull/161/files/18b0f07e..79a30ebe

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

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

PR: https://git.openjdk.org/lilliput/pull/161

From aboldtch at openjdk.org  Tue Apr 23 13:48:05 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 23 Apr 2024 13:48:05 GMT
Subject: [master] RFR: OMWorld: Remove BasicLock* restrictions [v4]
In-Reply-To: <naGlOEh4z8uIieF35vhrpKFGnmpYU4fzAQX2Fwz_y6w=.e2317f22-c6d6-4922-9371-4e94c6b681dc@github.com>
References: <naGlOEh4z8uIieF35vhrpKFGnmpYU4fzAQX2Fwz_y6w=.e2317f22-c6d6-4922-9371-4e94c6b681dc@github.com>
Message-ID: <FeN0QhI0pXq6vfxEBJoEHvPfSBaXa0b6oj5-mNPHSdg=.0a19115d-1941-4eff-82b3-6a9e8c473848@github.com>

> This is based on #159 
> 
> The main idea is to remove the restrictions where the `BasicLock*` may be missing when calling into the runtime. This is only an issue on x86_32. For now simply call into the runtime at the places where the registers are lacking. `quick_enter` should take care of the cases where we otherwise would have skipped calling into the runtime, as x86_32 calls into the runtime regardless (to get the thread) this may even be performance neutral.

Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:

  Add null check comment.

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

Changes:
  - all: https://git.openjdk.org/lilliput/pull/160/files
  - new: https://git.openjdk.org/lilliput/pull/160/files/6778ef66..8dd759a4

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

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

PR: https://git.openjdk.org/lilliput/pull/160

From coleenp at openjdk.org  Tue Apr 23 13:48:05 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 23 Apr 2024 13:48:05 GMT
Subject: [master] RFR: OMWorld: Remove BasicLock* restrictions [v4]
In-Reply-To: <FeN0QhI0pXq6vfxEBJoEHvPfSBaXa0b6oj5-mNPHSdg=.0a19115d-1941-4eff-82b3-6a9e8c473848@github.com>
References: <naGlOEh4z8uIieF35vhrpKFGnmpYU4fzAQX2Fwz_y6w=.e2317f22-c6d6-4922-9371-4e94c6b681dc@github.com>
 <FeN0QhI0pXq6vfxEBJoEHvPfSBaXa0b6oj5-mNPHSdg=.0a19115d-1941-4eff-82b3-6a9e8c473848@github.com>
Message-ID: <A6x4-U3diirpVCu953GPW80IV6T3YrvlMHTVeypRxfs=.cc7b69b1-d766-49df-a9c3-d56439f4812d@github.com>

On Tue, 23 Apr 2024 13:45:11 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> This is based on #159 
>> 
>> The main idea is to remove the restrictions where the `BasicLock*` may be missing when calling into the runtime. This is only an issue on x86_32. For now simply call into the runtime at the places where the registers are lacking. `quick_enter` should take care of the cases where we otherwise would have skipped calling into the runtime, as x86_32 calls into the runtime regardless (to get the thread) this may even be performance neutral.
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add null check comment.

This looks applicable to mainline, can it be pushed there?

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

PR Review: https://git.openjdk.org/lilliput/pull/160#pullrequestreview-2017321146

From aboldtch at openjdk.org  Tue Apr 23 14:26:45 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 23 Apr 2024 14:26:45 GMT
Subject: [master] RFR: OMWorld: Remove BasicLock* restrictions [v4]
In-Reply-To: <A6x4-U3diirpVCu953GPW80IV6T3YrvlMHTVeypRxfs=.cc7b69b1-d766-49df-a9c3-d56439f4812d@github.com>
References: <naGlOEh4z8uIieF35vhrpKFGnmpYU4fzAQX2Fwz_y6w=.e2317f22-c6d6-4922-9371-4e94c6b681dc@github.com>
 <FeN0QhI0pXq6vfxEBJoEHvPfSBaXa0b6oj5-mNPHSdg=.0a19115d-1941-4eff-82b3-6a9e8c473848@github.com>
 <A6x4-U3diirpVCu953GPW80IV6T3YrvlMHTVeypRxfs=.cc7b69b1-d766-49df-a9c3-d56439f4812d@github.com>
Message-ID: <KZKAgLSwGPDLZBig5SW1Li3tOmANG4BCxI6ZAJEZDlA=.27039a93-f5f7-433c-9c58-e15cfef9e06f@github.com>

On Tue, 23 Apr 2024 13:45:11 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This looks applicable to mainline, can it be pushed there?

Yes. 

There are some other changes that could be split out into upstream patches as well. The plan for now is to get this patch queue in, rebase and squash together into one OMWorld commit and then look at what can / should be broken out into upstream patches.

The hope is that after this patch queue the runtime changes are close to final (with exception of the hash table grow and shrinking code).

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

PR Comment: https://git.openjdk.org/lilliput/pull/160#issuecomment-2072449480

From aboldtch at openjdk.org  Tue Apr 23 14:26:45 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 23 Apr 2024 14:26:45 GMT
Subject: [master] Integrated: OMWorld: Remove BasicLock* restrictions
In-Reply-To: <naGlOEh4z8uIieF35vhrpKFGnmpYU4fzAQX2Fwz_y6w=.e2317f22-c6d6-4922-9371-4e94c6b681dc@github.com>
References: <naGlOEh4z8uIieF35vhrpKFGnmpYU4fzAQX2Fwz_y6w=.e2317f22-c6d6-4922-9371-4e94c6b681dc@github.com>
Message-ID: <gTYEG1LnP27i2RquBAhR86gdHyCPsKcJPs_hbMxkyyo=.243b402c-c160-4337-9487-5d5923799ddd@github.com>

On Mon, 22 Apr 2024 12:58:26 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> This is based on #159 
> 
> The main idea is to remove the restrictions where the `BasicLock*` may be missing when calling into the runtime. This is only an issue on x86_32. For now simply call into the runtime at the places where the registers are lacking. `quick_enter` should take care of the cases where we otherwise would have skipped calling into the runtime, as x86_32 calls into the runtime regardless (to get the thread) this may even be performance neutral.

This pull request has now been integrated.

Changeset: 95bad08f
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
URL:       https://git.openjdk.org/lilliput/commit/95bad08f01a595ba662cac38050fb830e3ec1056
Stats:     123 lines in 11 files changed: 7 ins; 79 del; 37 mod

OMWorld: Remove BasicLock* restrictions

Reviewed-by: rkennke

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

PR: https://git.openjdk.org/lilliput/pull/160

From aboldtch at openjdk.org  Tue Apr 23 16:33:04 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 23 Apr 2024 16:33:04 GMT
Subject: [master] RFR: OMWorld: Cleanup BasicLock header
Message-ID: <zPLTPXQVkm_dphhgoSxySsBDTHZi8Xo-hQ5A3yPJAzY=.9d0b6dba-2cda-4250-88bc-71c0fb1015c0@github.com>

Cleanup the usage of the header field in BasicLock. Because the asserts are stronger now I also cleanup the zero usage of the BasicLock. Because https://bugs.openjdk.org/browse/JDK-8307532 is not yet implemented I have not tested this interaction but as this now restricts the displaced header in the BasicLock to only LM_LEGACY something had to be done for LM_MONITOR support. 

This also changes symbols exposed through JVMCI so it may take extra effort to get this through. 

Similarly to #161 some changes could be upstreamed, and here there is already a distinction as neither `LM_LIGHTWEIGHT` nor `LM_MONITOR` uses the displaced header.

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

Commit messages:
 - BasicLock Restructure (includes JVMCI and zero changes)

Changes: https://git.openjdk.org/lilliput/pull/162/files
  Webrev: https://webrevs.openjdk.org/?repo=lilliput&pr=162&range=00
  Stats: 253 lines in 17 files changed: 125 ins; 6 del; 122 mod
  Patch: https://git.openjdk.org/lilliput/pull/162.diff
  Fetch: git fetch https://git.openjdk.org/lilliput.git pull/162/head:pull/162

PR: https://git.openjdk.org/lilliput/pull/162

From aboldtch at openjdk.org  Tue Apr 23 17:24:50 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 23 Apr 2024 17:24:50 GMT
Subject: [master] RFR: OMWorld: Cleanup ObjectMonitor::_header [v4]
In-Reply-To: <T9Kl7-okmXHWJrQOcIlvCf9r3bk6KL0mn_jGdFvVnKw=.fc73986b-1c44-4bb5-b7bc-5283cb047431@github.com>
References: <T9Kl7-okmXHWJrQOcIlvCf9r3bk6KL0mn_jGdFvVnKw=.fc73986b-1c44-4bb5-b7bc-5283cb047431@github.com>
Message-ID: <DCWzUI4ZzZZAGR0zxCqyB09hhh9nBmKi2Tgjfn0Ktrc=.26a11738-9655-4070-9cae-078f22cc8841@github.com>

> This changes the `ObjectMonitor::_header` to `ObjectMonitor::_metadata` and cleans up the surrounding terminology. 
> 
> Parts of this could be upstreamed, but the distinction of this field between the different locking modes is introduced in OMWorld. 
> 
> This patch will conflict with Lilliput if rebased on-top of OMWorld because Lilliput introduces `static ByteSize header_offset()` which is not used after OMWorld.  They could probably be removed in both these patches.
> 
> This also changes all the fields to have the same access level (private) so that this can be a standard layout type.

Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - Merge remote-tracking branch 'upstream_lilliput/master' into lilliput-om-cleanup-objectmonitor-header
 - Use variable directly in sizeof
 - Update src/hotspot/share/runtime/objectMonitor.hpp
   
   Co-authored-by: Stefan Karlsson <stefan.karlsson at oracle.com>
 - Cleanup ObjectMonitor::_header

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

Changes: https://git.openjdk.org/lilliput/pull/161/files
  Webrev: https://webrevs.openjdk.org/?repo=lilliput&pr=161&range=03
  Stats: 94 lines in 8 files changed: 21 ins; 10 del; 63 mod
  Patch: https://git.openjdk.org/lilliput/pull/161.diff
  Fetch: git fetch https://git.openjdk.org/lilliput.git pull/161/head:pull/161

PR: https://git.openjdk.org/lilliput/pull/161

From rkennke at openjdk.org  Tue Apr 23 17:36:40 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 23 Apr 2024 17:36:40 GMT
Subject: [master] RFR: OMWorld: Cleanup ObjectMonitor::_header [v4]
In-Reply-To: <DCWzUI4ZzZZAGR0zxCqyB09hhh9nBmKi2Tgjfn0Ktrc=.26a11738-9655-4070-9cae-078f22cc8841@github.com>
References: <T9Kl7-okmXHWJrQOcIlvCf9r3bk6KL0mn_jGdFvVnKw=.fc73986b-1c44-4bb5-b7bc-5283cb047431@github.com>
 <DCWzUI4ZzZZAGR0zxCqyB09hhh9nBmKi2Tgjfn0Ktrc=.26a11738-9655-4070-9cae-078f22cc8841@github.com>
Message-ID: <uYcPrYBUF-WFWbW1we5SNoWsYUUuJJxF_EzXpPpDGk0=.5b49abea-7dd9-4e35-9a81-ca7e75f460a0@github.com>

On Tue, 23 Apr 2024 17:24:50 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> This changes the `ObjectMonitor::_header` to `ObjectMonitor::_metadata` and cleans up the surrounding terminology. 
>> 
>> Parts of this could be upstreamed, but the distinction of this field between the different locking modes is introduced in OMWorld. 
>> 
>> This patch will conflict with Lilliput if rebased on-top of OMWorld because Lilliput introduces `static ByteSize header_offset()` which is not used after OMWorld.  They could probably be removed in both these patches.
>> 
>> This also changes all the fields to have the same access level (private) so that this can be a standard layout type.
>
> Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - Merge remote-tracking branch 'upstream_lilliput/master' into lilliput-om-cleanup-objectmonitor-header
>  - Use variable directly in sizeof
>  - Update src/hotspot/share/runtime/objectMonitor.hpp
>    
>    Co-authored-by: Stefan Karlsson <stefan.karlsson at oracle.com>
>  - Cleanup ObjectMonitor::_header

Marked as reviewed by rkennke (Lead).

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

PR Review: https://git.openjdk.org/lilliput/pull/161#pullrequestreview-2017875848

From stuefe at openjdk.org  Tue Apr 23 18:04:01 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 23 Apr 2024 18:04:01 GMT
Subject: [master] RFR: Fix CompressedClassPointersEncodingScheme for aarch64
 with -UseCOH
Message-ID: <oMgy5alXvMGh0Ijo2geO9Ne_3ZWPOFU9on-pW6q4TDY=.88a8149b-fb7e-4a40-b1cb-3743ab061f57@github.com>

There had been two errors.

- the literal was missing the L to make it long
- the first test that tests mapping below the 32g boundary was using a far too low address.

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

Commit messages:
 - fix CompressedClassPointersEncodingScheme for aarch64 with -UseCOH

Changes: https://git.openjdk.org/lilliput/pull/164/files
  Webrev: https://webrevs.openjdk.org/?repo=lilliput&pr=164&range=00
  Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/lilliput/pull/164.diff
  Fetch: git fetch https://git.openjdk.org/lilliput.git pull/164/head:pull/164

PR: https://git.openjdk.org/lilliput/pull/164

From stefank at openjdk.org  Tue Apr 23 18:04:01 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 23 Apr 2024 18:04:01 GMT
Subject: [master] RFR: Fix CompressedClassPointersEncodingScheme for
 aarch64 with -UseCOH
In-Reply-To: <oMgy5alXvMGh0Ijo2geO9Ne_3ZWPOFU9on-pW6q4TDY=.88a8149b-fb7e-4a40-b1cb-3743ab061f57@github.com>
References: <oMgy5alXvMGh0Ijo2geO9Ne_3ZWPOFU9on-pW6q4TDY=.88a8149b-fb7e-4a40-b1cb-3743ab061f57@github.com>
Message-ID: <_K3me_c2mN2NcXsMf8ROWKLDF3Ljwo9q3eM0NUeVOT4=.8ae6ca51-4fa2-407f-a0a8-5a33d3a0cb8d@github.com>

On Tue, 23 Apr 2024 16:28:53 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> There had been two errors.
> 
> - the literal was missing the L to make it long
> - the first test that tests mapping below the 32g boundary was using a far too low address.

Marked as reviewed by stefank (Committer).

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

PR Review: https://git.openjdk.org/lilliput/pull/164#pullrequestreview-2017810236

From rkennke at openjdk.org  Tue Apr 23 18:04:01 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 23 Apr 2024 18:04:01 GMT
Subject: [master] RFR: Fix CompressedClassPointersEncodingScheme for
 aarch64 with -UseCOH
In-Reply-To: <oMgy5alXvMGh0Ijo2geO9Ne_3ZWPOFU9on-pW6q4TDY=.88a8149b-fb7e-4a40-b1cb-3743ab061f57@github.com>
References: <oMgy5alXvMGh0Ijo2geO9Ne_3ZWPOFU9on-pW6q4TDY=.88a8149b-fb7e-4a40-b1cb-3743ab061f57@github.com>
Message-ID: <0ODkh6Lkko68u9N5X7idwl6v7dYyiBi8_cu4UMupZQs=.52ee9c86-3116-4323-a566-91360ffd1bf3@github.com>

On Tue, 23 Apr 2024 16:28:53 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> There had been two errors.
> 
> - the literal was missing the L to make it long
> - the first test that tests mapping below the 32g boundary was using a far too low address.

Looks good, thanks!

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

Marked as reviewed by rkennke (Lead).

PR Review: https://git.openjdk.org/lilliput/pull/164#pullrequestreview-2017873902

From stuefe at openjdk.org  Wed Apr 24 04:26:41 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 24 Apr 2024 04:26:41 GMT
Subject: [master] RFR: Fix CompressedClassPointersEncodingScheme for
 aarch64 with -UseCOH
In-Reply-To: <oMgy5alXvMGh0Ijo2geO9Ne_3ZWPOFU9on-pW6q4TDY=.88a8149b-fb7e-4a40-b1cb-3743ab061f57@github.com>
References: <oMgy5alXvMGh0Ijo2geO9Ne_3ZWPOFU9on-pW6q4TDY=.88a8149b-fb7e-4a40-b1cb-3743ab061f57@github.com>
Message-ID: <bO8G81rOfF8gSWdKBkUkjrKdKxuGS7kRtkq3RTFgXEU=.f8a5d53b-856a-461a-97de-9543d627a084@github.com>

On Tue, 23 Apr 2024 16:28:53 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> There had been two errors.
> 
> - the literal was missing the L to make it long
> - the first test that tests mapping below the 32g boundary was using a far too low address.

x86 errors unrelated

Thanks @rkennke and @stefank

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

PR Comment: https://git.openjdk.org/lilliput/pull/164#issuecomment-2073998505

From stuefe at openjdk.org  Wed Apr 24 04:26:42 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 24 Apr 2024 04:26:42 GMT
Subject: [master] Integrated: Fix CompressedClassPointersEncodingScheme for
 aarch64 with -UseCOH
In-Reply-To: <oMgy5alXvMGh0Ijo2geO9Ne_3ZWPOFU9on-pW6q4TDY=.88a8149b-fb7e-4a40-b1cb-3743ab061f57@github.com>
References: <oMgy5alXvMGh0Ijo2geO9Ne_3ZWPOFU9on-pW6q4TDY=.88a8149b-fb7e-4a40-b1cb-3743ab061f57@github.com>
Message-ID: <WG2shq6RJ7V2Uqb7syZSMBoWY81lfL-hvkgB8VXx_G4=.b104d4f4-cd4e-4cce-8226-70099e2bbe38@github.com>

On Tue, 23 Apr 2024 16:28:53 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> There had been two errors.
> 
> - the literal was missing the L to make it long
> - the first test that tests mapping below the 32g boundary was using a far too low address.

This pull request has now been integrated.

Changeset: 131e47b0
Author:    Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.org/lilliput/commit/131e47b026f88ef5cb3443459388b5e9577eaa9c
Stats:     5 lines in 1 file changed: 2 ins; 0 del; 3 mod

Fix CompressedClassPointersEncodingScheme for aarch64 with -UseCOH

Reviewed-by: stefank, rkennke

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

PR: https://git.openjdk.org/lilliput/pull/164

From stefank at openjdk.org  Wed Apr 24 05:27:52 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 24 Apr 2024 05:27:52 GMT
Subject: [master] RFR: Don't warn when UCOH is on by default
Message-ID: <3h81O91hf9xoURs_lFNN4rXtXUW4eaY6-mlov5kZkL4=.e79101fe-d4b2-4d92-9545-dc987928283b@github.com>

When running testing with UCOH enabled by default in the code and non-generational ZGC the JVM prints this warning, which causes multiple failures in the testing. I'd like to propose that we  (at least temporarily) only write this warning if the user explicitly asked for UCOH.

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

Commit messages:
 - Don't warn when UCOH is on by default

Changes: https://git.openjdk.org/lilliput/pull/165/files
  Webrev: https://webrevs.openjdk.org/?repo=lilliput&pr=165&range=00
  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/lilliput/pull/165.diff
  Fetch: git fetch https://git.openjdk.org/lilliput.git pull/165/head:pull/165

PR: https://git.openjdk.org/lilliput/pull/165

From rkennke at openjdk.org  Wed Apr 24 05:48:44 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 24 Apr 2024 05:48:44 GMT
Subject: [master] RFR: Don't warn when UCOH is on by default
In-Reply-To: <3h81O91hf9xoURs_lFNN4rXtXUW4eaY6-mlov5kZkL4=.e79101fe-d4b2-4d92-9545-dc987928283b@github.com>
References: <3h81O91hf9xoURs_lFNN4rXtXUW4eaY6-mlov5kZkL4=.e79101fe-d4b2-4d92-9545-dc987928283b@github.com>
Message-ID: <NzygEi1fsDzDAUtMHjVObtB0db7GS1LGlZPz0S5lPr8=.dad792ec-e2eb-47b6-b395-e3918f2e86db@github.com>

On Wed, 24 Apr 2024 05:23:30 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> When running testing with UCOH enabled by default in the code and non-generational ZGC the JVM prints this warning, which causes multiple failures in the testing. I'd like to propose that we  (at least temporarily) only write this warning if the user explicitly asked for UCOH.

Oh I believe this can be removed altogether. The reason why ZGC had problems was bad interaction/races with displaced headers, but with OMWorld this should no longer be the case.

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

Changes requested by rkennke (Lead).

PR Review: https://git.openjdk.org/lilliput/pull/165#pullrequestreview-2018895847

From stefank at openjdk.org  Wed Apr 24 06:03:47 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 24 Apr 2024 06:03:47 GMT
Subject: [master] RFR: Disable UseCompressedOops tests for 32-bits JVMs
Message-ID: <WRE3YHmIqXGoSxVsSeWXZ5YQc2XQHDONuk5dJTcWBAE=.cf3e83c2-5fa4-4dc2-aedd-1f670ec72060@github.com>

Fix failures in GHA. Stop running tests using UseCompressedOops on 32-bit JVMs.

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

Commit messages:
 - Disable UseCompressedOops tests for 32-bits JVMs

Changes: https://git.openjdk.org/lilliput/pull/166/files
  Webrev: https://webrevs.openjdk.org/?repo=lilliput&pr=166&range=00
  Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/lilliput/pull/166.diff
  Fetch: git fetch https://git.openjdk.org/lilliput.git pull/166/head:pull/166

PR: https://git.openjdk.org/lilliput/pull/166

From rkennke at openjdk.org  Wed Apr 24 06:13:41 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 24 Apr 2024 06:13:41 GMT
Subject: [master] RFR: Disable UseCompressedOops tests for 32-bits JVMs
In-Reply-To: <WRE3YHmIqXGoSxVsSeWXZ5YQc2XQHDONuk5dJTcWBAE=.cf3e83c2-5fa4-4dc2-aedd-1f670ec72060@github.com>
References: <WRE3YHmIqXGoSxVsSeWXZ5YQc2XQHDONuk5dJTcWBAE=.cf3e83c2-5fa4-4dc2-aedd-1f670ec72060@github.com>
Message-ID: <vw63RhIlzvT3u9xBUnx4PIG0gBaXDmMp0yMafTdHPnQ=.dce14211-488c-424d-99a9-ac04bc5cab0a@github.com>

On Wed, 24 Apr 2024 05:59:43 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> Fix failures in GHA. Stop running tests using UseCompressedOops on 32-bit JVMs.

Looks good. Thanks!

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

Marked as reviewed by rkennke (Lead).

PR Review: https://git.openjdk.org/lilliput/pull/166#pullrequestreview-2018929413

From rkennke at openjdk.org  Wed Apr 24 06:18:53 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 24 Apr 2024 06:18:53 GMT
Subject: [master] RFR: 8330631: Lilliput: Modify
 runtime/CompressedOops/CompressedClassPointers for tinycp
Message-ID: <T-94XVofjCF_L5tUxYXy85nNL1au4QFS3W9dS0-GQeg=.523e9d0a-d322-4e89-93ba-01bc1a6d3771@github.com>

A patch that got lost in the Great Reset. Fixes test failure in runtime/CompressedOops/CompressedClassPointers.java. Originally done by @tstuefe .

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

Commit messages:
 - 8330631: Lilliput: Modify runtime/CompressedOops/CompressedClassPointers for tinycp

Changes: https://git.openjdk.org/lilliput/pull/167/files
  Webrev: https://webrevs.openjdk.org/?repo=lilliput&pr=167&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8330631
  Stats: 21 lines in 2 files changed: 10 ins; 6 del; 5 mod
  Patch: https://git.openjdk.org/lilliput/pull/167.diff
  Fetch: git fetch https://git.openjdk.org/lilliput.git pull/167/head:pull/167

PR: https://git.openjdk.org/lilliput/pull/167

From stefank at openjdk.org  Wed Apr 24 06:25:43 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 24 Apr 2024 06:25:43 GMT
Subject: [master] RFR: Disable UseCompressedOops tests for 32-bits JVMs
In-Reply-To: <WRE3YHmIqXGoSxVsSeWXZ5YQc2XQHDONuk5dJTcWBAE=.cf3e83c2-5fa4-4dc2-aedd-1f670ec72060@github.com>
References: <WRE3YHmIqXGoSxVsSeWXZ5YQc2XQHDONuk5dJTcWBAE=.cf3e83c2-5fa4-4dc2-aedd-1f670ec72060@github.com>
Message-ID: <lFyA4fvOL-7Luyk-hby1KBtO1l0Yo0sAQM0zdwiWOLA=.9c42462a-a273-46c8-b80c-11a975051d09@github.com>

On Wed, 24 Apr 2024 05:59:43 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> Fix failures in GHA. Stop running tests using UseCompressedOops on 32-bit JVMs.

Thanks for reviewing!

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

PR Comment: https://git.openjdk.org/lilliput/pull/166#issuecomment-2074157951

From stefank at openjdk.org  Wed Apr 24 06:25:43 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 24 Apr 2024 06:25:43 GMT
Subject: [master] Integrated: Disable UseCompressedOops tests for 32-bits JVMs
In-Reply-To: <WRE3YHmIqXGoSxVsSeWXZ5YQc2XQHDONuk5dJTcWBAE=.cf3e83c2-5fa4-4dc2-aedd-1f670ec72060@github.com>
References: <WRE3YHmIqXGoSxVsSeWXZ5YQc2XQHDONuk5dJTcWBAE=.cf3e83c2-5fa4-4dc2-aedd-1f670ec72060@github.com>
Message-ID: <-xZKnQsGeGECUDuP98nVFF34mFKGaJ8zTCuOrxefSRk=.c19ceb98-d864-49b3-841c-adc7b5a59c96@github.com>

On Wed, 24 Apr 2024 05:59:43 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> Fix failures in GHA. Stop running tests using UseCompressedOops on 32-bit JVMs.

This pull request has now been integrated.

Changeset: 80abb98d
Author:    Stefan Karlsson <stefank at openjdk.org>
URL:       https://git.openjdk.org/lilliput/commit/80abb98d830fa26c8381b09c71857f0276c031b9
Stats:     6 lines in 1 file changed: 6 ins; 0 del; 0 mod

Disable UseCompressedOops tests for 32-bits JVMs

Reviewed-by: rkennke

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

PR: https://git.openjdk.org/lilliput/pull/166

From stefank at openjdk.org  Wed Apr 24 06:26:37 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 24 Apr 2024 06:26:37 GMT
Subject: [master] RFR: Don't warn when UCOH is on by default
In-Reply-To: <3h81O91hf9xoURs_lFNN4rXtXUW4eaY6-mlov5kZkL4=.e79101fe-d4b2-4d92-9545-dc987928283b@github.com>
References: <3h81O91hf9xoURs_lFNN4rXtXUW4eaY6-mlov5kZkL4=.e79101fe-d4b2-4d92-9545-dc987928283b@github.com>
Message-ID: <-dJL07lZrbks0F_EkEhWHdUZ-VtJyPhZbLZ-_7s8zaM=.7d6f28bb-539b-4481-95d1-99724ca4debd@github.com>

On Wed, 24 Apr 2024 05:23:30 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> When running testing with UCOH enabled by default in the code and non-generational ZGC the JVM prints this warning, which causes multiple failures in the testing. I'd like to propose that we  (at least temporarily) only write this warning if the user explicitly asked for UCOH.

OK. Let me think about that a bit and I'll update the PR later.

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

PR Comment: https://git.openjdk.org/lilliput/pull/165#issuecomment-2074159262

From stefank at openjdk.org  Wed Apr 24 06:29:51 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 24 Apr 2024 06:29:51 GMT
Subject: [master] RFR: OMWorld: Fix enter_for is_value_based bug
Message-ID: <hSUTMV-KY-UJkk2czPnkK-ZlMlngYtkvX6Ch66ZhuWE=.ae437a29-cb19-4f5f-a43a-9980dccd5af9@github.com>

There was a copy-n-paste error in one of the previous OMWorld patches. `handle_sync_on_value_based_class` expects the `locking_thread` and not the `current` thread.

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

Commit messages:
 - OMWorld: Fix enter_for is_value_based bug

Changes: https://git.openjdk.org/lilliput/pull/168/files
  Webrev: https://webrevs.openjdk.org/?repo=lilliput&pr=168&range=00
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/lilliput/pull/168.diff
  Fetch: git fetch https://git.openjdk.org/lilliput.git pull/168/head:pull/168

PR: https://git.openjdk.org/lilliput/pull/168

From aboldtch at openjdk.org  Wed Apr 24 06:29:51 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 24 Apr 2024 06:29:51 GMT
Subject: [master] RFR: OMWorld: Fix enter_for is_value_based bug
In-Reply-To: <hSUTMV-KY-UJkk2czPnkK-ZlMlngYtkvX6Ch66ZhuWE=.ae437a29-cb19-4f5f-a43a-9980dccd5af9@github.com>
References: <hSUTMV-KY-UJkk2czPnkK-ZlMlngYtkvX6Ch66ZhuWE=.ae437a29-cb19-4f5f-a43a-9980dccd5af9@github.com>
Message-ID: <p7OKHbujibMYurPrCYk1p89RdZrfG73CMddjztTxo6s=.2442316a-c3f2-438d-bf01-78090a492a9a@github.com>

On Wed, 24 Apr 2024 06:22:35 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> There was a copy-n-paste error in one of the previous OMWorld patches. `handle_sync_on_value_based_class` expects the `locking_thread` and not the `current` thread.

Marked as reviewed by aboldtch (Committer).

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

PR Review: https://git.openjdk.org/lilliput/pull/168#pullrequestreview-2018952282

From aboldtch at openjdk.org  Wed Apr 24 08:43:46 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 24 Apr 2024 08:43:46 GMT
Subject: [master] RFR: OMWorld: Add LightweightSynchronizer::quick_enter - fix
 incorrectly setup cache
Message-ID: <Fpu23FsqHLCpBShfAotjLrsVD0ahTG0PAtQQHqUSUW4=.93f5e71e-2d8e-4447-911c-48199e9479a4@github.com>

`ObjectSynchronizer::quick_enter` did not setup the BasicLock cache correctly when successful. When x86_32 started calling directly into the VM there are paths which never cleared the cache. Add `LightweightSynchronizer::quick_enter` which correctly clears or sets the cache in all paths.

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

Commit messages:
 - OMWorld: Add LightweightSynchronizer::quick_enter - fix incorrectly setup cache

Changes: https://git.openjdk.org/lilliput/pull/169/files
  Webrev: https://webrevs.openjdk.org/?repo=lilliput&pr=169&range=00
  Stats: 77 lines in 3 files changed: 45 ins; 20 del; 12 mod
  Patch: https://git.openjdk.org/lilliput/pull/169.diff
  Fetch: git fetch https://git.openjdk.org/lilliput.git pull/169/head:pull/169

PR: https://git.openjdk.org/lilliput/pull/169

From aboldtch at openjdk.org  Wed Apr 24 08:48:05 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 24 Apr 2024 08:48:05 GMT
Subject: [master] RFR: OMWorld: Add LightweightSynchronizer::quick_enter -
 fix incorrectly setup cache [v2]
In-Reply-To: <Fpu23FsqHLCpBShfAotjLrsVD0ahTG0PAtQQHqUSUW4=.93f5e71e-2d8e-4447-911c-48199e9479a4@github.com>
References: <Fpu23FsqHLCpBShfAotjLrsVD0ahTG0PAtQQHqUSUW4=.93f5e71e-2d8e-4447-911c-48199e9479a4@github.com>
Message-ID: <pgN6ACwq-6JqWCgMHM-o5UZYHCl0bPXoPEstmeAxXvI=.96890d1e-4e75-4f31-9c99-19de2f86d258@github.com>

> `ObjectSynchronizer::quick_enter` did not setup the BasicLock cache correctly when successful. When x86_32 started calling directly into the VM there are paths which never cleared the cache. Add `LightweightSynchronizer::quick_enter` which correctly clears or sets the cache in all paths.

Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:

  Remove extra newline

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

Changes:
  - all: https://git.openjdk.org/lilliput/pull/169/files
  - new: https://git.openjdk.org/lilliput/pull/169/files/bd5f1b74..3201e2be

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

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

PR: https://git.openjdk.org/lilliput/pull/169

From stefank at openjdk.org  Wed Apr 24 13:11:53 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 24 Apr 2024 13:11:53 GMT
Subject: [master] RFR: OMWorld: Add LightweightSynchronizer::quick_enter -
 fix incorrectly setup cache [v2]
In-Reply-To: <pgN6ACwq-6JqWCgMHM-o5UZYHCl0bPXoPEstmeAxXvI=.96890d1e-4e75-4f31-9c99-19de2f86d258@github.com>
References: <Fpu23FsqHLCpBShfAotjLrsVD0ahTG0PAtQQHqUSUW4=.93f5e71e-2d8e-4447-911c-48199e9479a4@github.com>
 <pgN6ACwq-6JqWCgMHM-o5UZYHCl0bPXoPEstmeAxXvI=.96890d1e-4e75-4f31-9c99-19de2f86d258@github.com>
Message-ID: <9w7EM330kQy4BZ1qxPEKCCZILm7_uP0eA5PnTA830Os=.f4558c8b-4423-4ced-a748-75533d97e182@github.com>

On Wed, 24 Apr 2024 08:48:05 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> `ObjectSynchronizer::quick_enter` did not setup the BasicLock cache correctly when successful. When x86_32 started calling directly into the VM there are paths which never cleared the cache. Add `LightweightSynchronizer::quick_enter` which correctly clears or sets the cache in all paths.
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove extra newline

Looks good. At some point we need to add some comments explaining why `CacheSetter cache_setter(current, lock)` is placed where it is.

src/hotspot/share/runtime/lightweightSynchronizer.cpp line 1022:

> 1020: }
> 1021: 
> 1022: bool LightweightSynchronizer::quick_enter(oop obj, JavaThread* current, BasicLock * lock) {

Suggestion:

bool LightweightSynchronizer::quick_enter(oop obj, JavaThread* current, BasicLock* lock) {

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

Marked as reviewed by stefank (Committer).

PR Review: https://git.openjdk.org/lilliput/pull/169#pullrequestreview-2019291040
PR Review Comment: https://git.openjdk.org/lilliput/pull/169#discussion_r1577535717

From stefank at openjdk.org  Wed Apr 24 13:13:41 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 24 Apr 2024 13:13:41 GMT
Subject: [master] RFR: OMWorld: Cleanup BasicLock header
In-Reply-To: <zPLTPXQVkm_dphhgoSxySsBDTHZi8Xo-hQ5A3yPJAzY=.9d0b6dba-2cda-4250-88bc-71c0fb1015c0@github.com>
References: <zPLTPXQVkm_dphhgoSxySsBDTHZi8Xo-hQ5A3yPJAzY=.9d0b6dba-2cda-4250-88bc-71c0fb1015c0@github.com>
Message-ID: <8vXTJgR5vHwdO9FsBlqNgQhWexn2QLaMtedZO0vPvHM=.fc64069a-2560-4b15-bf2a-cb1fdfd3a5ab@github.com>

On Mon, 22 Apr 2024 13:50:04 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Cleanup the usage of the header field in BasicLock. Because the asserts are stronger now I also cleanup the zero usage of the BasicLock. Because https://bugs.openjdk.org/browse/JDK-8307532 is not yet implemented I have not tested this interaction but as this now restricts the displaced header in the BasicLock to only LM_LEGACY something had to be done for LM_MONITOR support. 
> 
> This also changes symbols exposed through JVMCI so it may take extra effort to get this through. 
> 
> Similarly to #161 some changes could be upstreamed, and here there is already a distinction as neither `LM_LIGHTWEIGHT` nor `LM_MONITOR` uses the displaced header.

Marked as reviewed by stefank (Committer).

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

PR Review: https://git.openjdk.org/lilliput/pull/162#pullrequestreview-2019819149

From rkennke at openjdk.org  Wed Apr 24 14:41:48 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 24 Apr 2024 14:41:48 GMT
Subject: [master] RFR: Fix arrays-equals intrinsic on AArch64
Message-ID: <Oh19qEf5IsHCAMq7hUDxXTnD3tHHZMCgCJeEYCV1TKQ=.6f2ce6dd-059e-46c6-a1bb-deea05c28de0@github.com>

The arrays-equals intrinsic on AArch64 assumes that array elements start at 8-byte-aligned boundary. There are several problems with that:
- Doing unaligned loads is likely rather slow.
- I believe it may give wrong results when comparing some junk after the end of the array.
- We may crash when loading beyond the heap boundary.

The proposed fix is to start the comparison at the array-length field. When the array base is unaligned (that is really 4-byte-aligned), then the array-length is at 8-byte-aligned location. And since we want to compare the lengths anyway, we can just as well use word-sized loads to compare the length and first elements in a single step, and elide the separate cmp+branch for the length.

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

Commit messages:
 - Fix arrays-equals intrinsic on AArch64

Changes: https://git.openjdk.org/lilliput/pull/170/files
  Webrev: https://webrevs.openjdk.org/?repo=lilliput&pr=170&range=00
  Stats: 42 lines in 1 file changed: 33 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/lilliput/pull/170.diff
  Fetch: git fetch https://git.openjdk.org/lilliput.git pull/170/head:pull/170

PR: https://git.openjdk.org/lilliput/pull/170

From aboldtch at openjdk.org  Wed Apr 24 15:30:42 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 24 Apr 2024 15:30:42 GMT
Subject: [master] RFR: Fix arrays-equals intrinsic on AArch64
In-Reply-To: <Oh19qEf5IsHCAMq7hUDxXTnD3tHHZMCgCJeEYCV1TKQ=.6f2ce6dd-059e-46c6-a1bb-deea05c28de0@github.com>
References: <Oh19qEf5IsHCAMq7hUDxXTnD3tHHZMCgCJeEYCV1TKQ=.6f2ce6dd-059e-46c6-a1bb-deea05c28de0@github.com>
Message-ID: <-nK4s5FUL0dHKKY34pqOcr1w7upM1-n-Q4dTUafUfsQ=.6691196f-0ae6-4603-9fa1-20509284a343@github.com>

On Wed, 24 Apr 2024 14:36:31 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> The arrays-equals intrinsic on AArch64 assumes that array elements start at 8-byte-aligned boundary. There are several problems with that:
> - Doing unaligned loads is likely rather slow.
> - I believe it may give wrong results when comparing some junk after the end of the array.
> - We may crash when loading beyond the heap boundary.
> 
> The proposed fix is to start the comparison at the array-length field. When the array base is unaligned (that is really 4-byte-aligned), then the array-length is at 8-byte-aligned location. And since we want to compare the lengths anyway, we can just as well use word-sized loads to compare the length and first elements in a single step, and elide the separate cmp+branch for the length.

This seems resonable. 

But some initial comments.

It seems like the `UseSimpleArrayEquals` above suffers from the unaligned access issues, it seems to be off by default except on Cortex A73. However it should probably be handled as well.

This was also broken for large arrays which assumes that the pointers are 8 byte aligned. The whole over-aligning in there to 16 bytes is just wrong when these are not aligned.
This seems to be the only use of the large array stub, but it seems like all of these have to be evaluated for correctness, have comments and requirements updated. E.g.
https://github.com/openjdk/lilliput/blob/80abb98d830fa26c8381b09c71857f0276c031b9/src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp#L5253-L5254

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

> 5361:     } else {
> 5362:       ldr(tmp3, Address(pre(a1, length_offset)));
> 5363:     }

Something like this could avoid the ifs. Also the `const int start_offset = is_8aligned ? base_offset : length_offset;` could be pushed up and shared for the simple implementation, which probably should be fixed as well.
Suggestion:

    const int start_offset = is_8aligned ? base_offset : length_offset;
    ldr(tmp3, Address(pre(a1, start_offset)));

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

> 5436:       br(NE, DONE);
> 5437:     }
> 5438:     cbz(cnt1, SAME);

Was this an optimization? The `cbz` would never be taken if `!is_8aligned `  as it implies `cnt1 > 0`

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

PR Review: https://git.openjdk.org/lilliput/pull/170#pullrequestreview-2020197726
PR Review Comment: https://git.openjdk.org/lilliput/pull/170#discussion_r1578083395
PR Review Comment: https://git.openjdk.org/lilliput/pull/170#discussion_r1578083521

From aph at openjdk.org  Wed Apr 24 15:37:41 2024
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 24 Apr 2024 15:37:41 GMT
Subject: [master] RFR: Fix arrays-equals intrinsic on AArch64
In-Reply-To: <Oh19qEf5IsHCAMq7hUDxXTnD3tHHZMCgCJeEYCV1TKQ=.6f2ce6dd-059e-46c6-a1bb-deea05c28de0@github.com>
References: <Oh19qEf5IsHCAMq7hUDxXTnD3tHHZMCgCJeEYCV1TKQ=.6f2ce6dd-059e-46c6-a1bb-deea05c28de0@github.com>
Message-ID: <yZp9fK-M75tzzDc1JPdIV6YgLLgcepSrIHqXVDNSJQg=.61284b62-bb52-43e3-853f-d7f84fe46f6b@github.com>

On Wed, 24 Apr 2024 14:36:31 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> The arrays-equals intrinsic on AArch64 assumes that array elements start at 8-byte-aligned boundary. There are several problems with that:
> 
>     * Doing unaligned loads is likely rather slow.

I doubt that. The design goal for AArch64 was that unaligned loads that don't cross cache-line boundaries shouldn't be penalized.

>     * I believe it may give wrong results when comparing some junk after the end of the array.
> 
>     * We may crash when loading beyond the heap boundary.

The resulting code is really pretty ugly and hard to follow. We should be able to use an array comparison that doesn't have all of those `if (is_8aligned)`, surely? If we need to align, then we just check the first sub-words, then compare as many full-size words as we have, then check any remaining sub-words.

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

PR Comment: https://git.openjdk.org/lilliput/pull/170#issuecomment-2075234109

From rkennke at openjdk.org  Wed Apr 24 16:06:05 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 24 Apr 2024 16:06:05 GMT
Subject: [master] RFR: Fix arrays-equals intrinsic on AArch64 [v2]
In-Reply-To: <Oh19qEf5IsHCAMq7hUDxXTnD3tHHZMCgCJeEYCV1TKQ=.6f2ce6dd-059e-46c6-a1bb-deea05c28de0@github.com>
References: <Oh19qEf5IsHCAMq7hUDxXTnD3tHHZMCgCJeEYCV1TKQ=.6f2ce6dd-059e-46c6-a1bb-deea05c28de0@github.com>
Message-ID: <5TYQVXi79UbVVPvLBDjr_AbxrisoEv-vQEMlAqWaHfI=.d0f7aa00-1199-4cd9-859f-cf6c862629fb@github.com>

> The arrays-equals intrinsic on AArch64 assumes that array elements start at 8-byte-aligned boundary. There are several problems with that:
> - Doing unaligned loads is likely rather slow.
> - I believe it may give wrong results when comparing some junk after the end of the array.
> - We may crash when loading beyond the heap boundary.
> 
> The proposed fix is to start the comparison at the array-length field. When the array base is unaligned (that is really 4-byte-aligned), then the array-length is at 8-byte-aligned location. And since we want to compare the lengths anyway, we can just as well use word-sized loads to compare the length and first elements in a single step, and elide the separate cmp+branch for the length.

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Simplify

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

Changes:
  - all: https://git.openjdk.org/lilliput/pull/170/files
  - new: https://git.openjdk.org/lilliput/pull/170/files/6d1ea5f5..93adb1e1

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

  Stats: 55 lines in 1 file changed: 13 ins; 28 del; 14 mod
  Patch: https://git.openjdk.org/lilliput/pull/170.diff
  Fetch: git fetch https://git.openjdk.org/lilliput.git pull/170/head:pull/170

PR: https://git.openjdk.org/lilliput/pull/170

From rkennke at openjdk.org  Wed Apr 24 16:15:43 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 24 Apr 2024 16:15:43 GMT
Subject: [master] RFR: Fix arrays-equals intrinsic on AArch64 [v2]
In-Reply-To: <-nK4s5FUL0dHKKY34pqOcr1w7upM1-n-Q4dTUafUfsQ=.6691196f-0ae6-4603-9fa1-20509284a343@github.com>
References: <Oh19qEf5IsHCAMq7hUDxXTnD3tHHZMCgCJeEYCV1TKQ=.6f2ce6dd-059e-46c6-a1bb-deea05c28de0@github.com>
 <-nK4s5FUL0dHKKY34pqOcr1w7upM1-n-Q4dTUafUfsQ=.6691196f-0ae6-4603-9fa1-20509284a343@github.com>
Message-ID: <3tjTYXYnF0eWIQlc0G4u5tWb7ugudAd6DJjpn2aLLOg=.3879e567-3c6d-47cd-874e-ac0d43409161@github.com>

On Wed, 24 Apr 2024 15:24:54 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Simplify
>
> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5438:
> 
>> 5436:       br(NE, DONE);
>> 5437:     }
>> 5438:     cbz(cnt1, SAME);
> 
> Was this an optimization? The `cbz` would never be taken if `!is_8aligned `  as it implies `cnt1 > 0`

Yes. The idea is that if the main loop also compares the lenghts, then we don't need to explicitely compare them before the main loop and save a bunch of instructions. I removed the special-handling there for now, for simplicity.

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

PR Review Comment: https://git.openjdk.org/lilliput/pull/170#discussion_r1578171005

From aboldtch at openjdk.org  Thu Apr 25 05:38:09 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 25 Apr 2024 05:38:09 GMT
Subject: [master] RFR: OMWorld: Add LightweightSynchronizer::quick_enter -
 fix incorrectly setup cache [v3]
In-Reply-To: <Fpu23FsqHLCpBShfAotjLrsVD0ahTG0PAtQQHqUSUW4=.93f5e71e-2d8e-4447-911c-48199e9479a4@github.com>
References: <Fpu23FsqHLCpBShfAotjLrsVD0ahTG0PAtQQHqUSUW4=.93f5e71e-2d8e-4447-911c-48199e9479a4@github.com>
Message-ID: <A13gNI8LzAqXeWmMn9gp3CubjN-Hd3BKIeuqI8rN2gc=.18096423-b096-4501-9232-99e6e7357137@github.com>

> `ObjectSynchronizer::quick_enter` did not setup the BasicLock cache correctly when successful. When x86_32 started calling directly into the VM there are paths which never cleared the cache. Add `LightweightSynchronizer::quick_enter` which correctly clears or sets the cache in all paths.

Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:

  Update src/hotspot/share/runtime/lightweightSynchronizer.cpp
  
  Co-authored-by: Stefan Karlsson <stefan.karlsson at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/lilliput/pull/169/files
  - new: https://git.openjdk.org/lilliput/pull/169/files/3201e2be..4d7a60bc

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

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

PR: https://git.openjdk.org/lilliput/pull/169

From aboldtch at openjdk.org  Thu Apr 25 05:38:10 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 25 Apr 2024 05:38:10 GMT
Subject: [master] Integrated: OMWorld: Add LightweightSynchronizer::quick_enter
 - fix incorrectly setup cache
In-Reply-To: <Fpu23FsqHLCpBShfAotjLrsVD0ahTG0PAtQQHqUSUW4=.93f5e71e-2d8e-4447-911c-48199e9479a4@github.com>
References: <Fpu23FsqHLCpBShfAotjLrsVD0ahTG0PAtQQHqUSUW4=.93f5e71e-2d8e-4447-911c-48199e9479a4@github.com>
Message-ID: <I-a2uRQHibQhwZBbQfW2wrOweKIcZThkvtPNeee5ohg=.67ab0761-6741-4007-8b76-db07e5dbeb07@github.com>

On Wed, 24 Apr 2024 08:39:42 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> `ObjectSynchronizer::quick_enter` did not setup the BasicLock cache correctly when successful. When x86_32 started calling directly into the VM there are paths which never cleared the cache. Add `LightweightSynchronizer::quick_enter` which correctly clears or sets the cache in all paths.

This pull request has now been integrated.

Changeset: c4f84409
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
URL:       https://git.openjdk.org/lilliput/commit/c4f844090b9952a6242329123628781d8981215c
Stats:     76 lines in 3 files changed: 44 ins; 20 del; 12 mod

OMWorld: Add LightweightSynchronizer::quick_enter - fix incorrectly setup cache

Reviewed-by: stefank

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

PR: https://git.openjdk.org/lilliput/pull/169

From aboldtch at openjdk.org  Thu Apr 25 05:42:55 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 25 Apr 2024 05:42:55 GMT
Subject: [master] RFR: OMWorld: Cleanup BasicLock header [v2]
In-Reply-To: <zPLTPXQVkm_dphhgoSxySsBDTHZi8Xo-hQ5A3yPJAzY=.9d0b6dba-2cda-4250-88bc-71c0fb1015c0@github.com>
References: <zPLTPXQVkm_dphhgoSxySsBDTHZi8Xo-hQ5A3yPJAzY=.9d0b6dba-2cda-4250-88bc-71c0fb1015c0@github.com>
Message-ID: <sH306ifTA9oArfOEnLgXbyLDGhsWUDV5H-wDT3XoZ0o=.fc017ec2-ec2a-4b25-9b36-338783855f52@github.com>

> Cleanup the usage of the header field in BasicLock. Because the asserts are stronger now I also cleanup the zero usage of the BasicLock. Because https://bugs.openjdk.org/browse/JDK-8307532 is not yet implemented I have not tested this interaction but as this now restricts the displaced header in the BasicLock to only LM_LEGACY something had to be done for LM_MONITOR support. 
> 
> This also changes symbols exposed through JVMCI so it may take extra effort to get this through. 
> 
> Similarly to #161 some changes could be upstreamed, and here there is already a distinction as neither `LM_LIGHTWEIGHT` nor `LM_MONITOR` uses the displaced header.

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

 - Merge remote-tracking branch 'upstream_lilliput/master' into lilliput-om-cleanup-basiclock-header
 - Fix condition
 - BasicLock Restructure (includes JVMCI and zero changes)

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

Changes:
  - all: https://git.openjdk.org/lilliput/pull/162/files
  - new: https://git.openjdk.org/lilliput/pull/162/files/b54babc1..ca28a78a

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

  Stats: 76 lines in 5 files changed: 52 ins; 18 del; 6 mod
  Patch: https://git.openjdk.org/lilliput/pull/162.diff
  Fetch: git fetch https://git.openjdk.org/lilliput.git pull/162/head:pull/162

PR: https://git.openjdk.org/lilliput/pull/162

From aboldtch at openjdk.org  Thu Apr 25 05:43:02 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 25 Apr 2024 05:43:02 GMT
Subject: [master] RFR: OMWorld: Cleanup ObjectMonitor::_header [v5]
In-Reply-To: <T9Kl7-okmXHWJrQOcIlvCf9r3bk6KL0mn_jGdFvVnKw=.fc73986b-1c44-4bb5-b7bc-5283cb047431@github.com>
References: <T9Kl7-okmXHWJrQOcIlvCf9r3bk6KL0mn_jGdFvVnKw=.fc73986b-1c44-4bb5-b7bc-5283cb047431@github.com>
Message-ID: <14Pka6yJd0qPIy6glqFJ9W5sC2xpk-l-_m5IiYZyIvE=.d6d1da8a-73a6-41d9-99ee-415ca1fd9298@github.com>

> This changes the `ObjectMonitor::_header` to `ObjectMonitor::_metadata` and cleans up the surrounding terminology. 
> 
> Parts of this could be upstreamed, but the distinction of this field between the different locking modes is introduced in OMWorld. 
> 
> This patch will conflict with Lilliput if rebased on-top of OMWorld because Lilliput introduces `static ByteSize header_offset()` which is not used after OMWorld.  They could probably be removed in both these patches.
> 
> This also changes all the fields to have the same access level (private) so that this can be a standard layout type.

Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:

 - Merge remote-tracking branch 'upstream_lilliput/master' into lilliput-om-cleanup-objectmonitor-header
 - Merge remote-tracking branch 'upstream_lilliput/master' into lilliput-om-cleanup-objectmonitor-header
 - Use variable directly in sizeof
 - Update src/hotspot/share/runtime/objectMonitor.hpp
   
   Co-authored-by: Stefan Karlsson <stefan.karlsson at oracle.com>
 - Cleanup ObjectMonitor::_header

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

Changes: https://git.openjdk.org/lilliput/pull/161/files
  Webrev: https://webrevs.openjdk.org/?repo=lilliput&pr=161&range=04
  Stats: 94 lines in 8 files changed: 21 ins; 10 del; 63 mod
  Patch: https://git.openjdk.org/lilliput/pull/161.diff
  Fetch: git fetch https://git.openjdk.org/lilliput.git pull/161/head:pull/161

PR: https://git.openjdk.org/lilliput/pull/161

From aboldtch at openjdk.org  Thu Apr 25 07:39:38 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 25 Apr 2024 07:39:38 GMT
Subject: [master] RFR: Fix arrays-equals intrinsic on AArch64 [v2]
In-Reply-To: <5TYQVXi79UbVVPvLBDjr_AbxrisoEv-vQEMlAqWaHfI=.d0f7aa00-1199-4cd9-859f-cf6c862629fb@github.com>
References: <Oh19qEf5IsHCAMq7hUDxXTnD3tHHZMCgCJeEYCV1TKQ=.6f2ce6dd-059e-46c6-a1bb-deea05c28de0@github.com>
 <5TYQVXi79UbVVPvLBDjr_AbxrisoEv-vQEMlAqWaHfI=.d0f7aa00-1199-4cd9-859f-cf6c862629fb@github.com>
Message-ID: <oohf9sqhyIc3Gc2A-AGWV7nLwMHCV8cg9_yb1GBVDpI=.8c48e593-e4bc-45c4-882a-9b9082781938@github.com>

On Wed, 24 Apr 2024 16:06:05 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> The arrays-equals intrinsic on AArch64 assumes that array elements start at 8-byte-aligned boundary. There are several problems with that:
>> - I believe it may give wrong results when comparing some junk after the end of the array.
>> - We may crash when loading beyond the heap boundary.
>> 
>> The proposed fix is to start the comparison at the array-length field. When the array base is unaligned (that is really 4-byte-aligned), then the array-length is at 8-byte-aligned location. And since we want to compare the lengths anyway, we can just as well use word-sized loads to compare the length and first elements in a single step, and elide the separate cmp+branch for the length.
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify

I think this is fine for getting this fixed in Lilliput. T

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

Marked as reviewed by aboldtch (Committer).

PR Review: https://git.openjdk.org/lilliput/pull/170#pullrequestreview-2021761992

From aboldtch at openjdk.org  Thu Apr 25 08:22:40 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 25 Apr 2024 08:22:40 GMT
Subject: [master] Integrated: OMWorld: Cleanup ObjectMonitor::_header
In-Reply-To: <T9Kl7-okmXHWJrQOcIlvCf9r3bk6KL0mn_jGdFvVnKw=.fc73986b-1c44-4bb5-b7bc-5283cb047431@github.com>
References: <T9Kl7-okmXHWJrQOcIlvCf9r3bk6KL0mn_jGdFvVnKw=.fc73986b-1c44-4bb5-b7bc-5283cb047431@github.com>
Message-ID: <S9J99Jo_qfQUSumG6jUek6dmFpagCgaO8UBee2Y0Dhg=.0321904c-4c17-4b05-8399-77beb0b6a162@github.com>

On Mon, 22 Apr 2024 13:20:33 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> This changes the `ObjectMonitor::_header` to `ObjectMonitor::_metadata` and cleans up the surrounding terminology. 
> 
> Parts of this could be upstreamed, but the distinction of this field between the different locking modes is introduced in OMWorld. 
> 
> This patch will conflict with Lilliput if rebased on-top of OMWorld because Lilliput introduces `static ByteSize header_offset()` which is not used after OMWorld.  They could probably be removed in both these patches.
> 
> This also changes all the fields to have the same access level (private) so that this can be a standard layout type.

This pull request has now been integrated.

Changeset: 1061cd4f
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
URL:       https://git.openjdk.org/lilliput/commit/1061cd4f3148d0d201cf223cdcf57eba159a4b1f
Stats:     94 lines in 8 files changed: 21 ins; 10 del; 63 mod

OMWorld: Cleanup ObjectMonitor::_header

Reviewed-by: rkennke

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

PR: https://git.openjdk.org/lilliput/pull/161

From rkennke at openjdk.org  Thu Apr 25 08:31:39 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 25 Apr 2024 08:31:39 GMT
Subject: [master] RFR: Fix arrays-equals intrinsic on AArch64 [v2]
In-Reply-To: <5TYQVXi79UbVVPvLBDjr_AbxrisoEv-vQEMlAqWaHfI=.d0f7aa00-1199-4cd9-859f-cf6c862629fb@github.com>
References: <Oh19qEf5IsHCAMq7hUDxXTnD3tHHZMCgCJeEYCV1TKQ=.6f2ce6dd-059e-46c6-a1bb-deea05c28de0@github.com>
 <5TYQVXi79UbVVPvLBDjr_AbxrisoEv-vQEMlAqWaHfI=.d0f7aa00-1199-4cd9-859f-cf6c862629fb@github.com>
Message-ID: <GQABEwXc8PqTPtcDjG8pDtRF5ZFUG3vQDNqBd4qnESY=.dae7b821-ff84-4bda-8f0f-058785f78a73@github.com>

On Wed, 24 Apr 2024 16:06:05 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> The arrays-equals intrinsic on AArch64 assumes that array elements start at 8-byte-aligned boundary. There are several problems with that:
>> - I believe it may give wrong results when comparing some junk after the end of the array.
>> - We may crash when loading beyond the heap boundary.
>> 
>> The proposed fix is to start the comparison at the array-length field. When the array base is unaligned (that is really 4-byte-aligned), then the array-length is at 8-byte-aligned location. And since we want to compare the lengths anyway, we can just as well use word-sized loads to compare the length and first elements in a single step, and elide the separate cmp+branch for the length.
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify

Thanks! Let's refine and optimize the change in upstream.

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

PR Comment: https://git.openjdk.org/lilliput/pull/170#issuecomment-2076648040

From rkennke at openjdk.org  Thu Apr 25 08:31:40 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 25 Apr 2024 08:31:40 GMT
Subject: [master] Integrated: Fix arrays-equals intrinsic on AArch64
In-Reply-To: <Oh19qEf5IsHCAMq7hUDxXTnD3tHHZMCgCJeEYCV1TKQ=.6f2ce6dd-059e-46c6-a1bb-deea05c28de0@github.com>
References: <Oh19qEf5IsHCAMq7hUDxXTnD3tHHZMCgCJeEYCV1TKQ=.6f2ce6dd-059e-46c6-a1bb-deea05c28de0@github.com>
Message-ID: <O0kx6Kw2zl7IbAJnBWAhpIgJNW29D7aaC-6U_PGiDlM=.80cb8d66-0d46-4317-baa6-5e78ce9c75bb@github.com>

On Wed, 24 Apr 2024 14:36:31 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> The arrays-equals intrinsic on AArch64 assumes that array elements start at 8-byte-aligned boundary. There are several problems with that:
> - I believe it may give wrong results when comparing some junk after the end of the array.
> - We may crash when loading beyond the heap boundary.
> 
> The proposed fix is to start the comparison at the array-length field. When the array base is unaligned (that is really 4-byte-aligned), then the array-length is at 8-byte-aligned location. And since we want to compare the lengths anyway, we can just as well use word-sized loads to compare the length and first elements in a single step, and elide the separate cmp+branch for the length.

This pull request has now been integrated.

Changeset: a512b0a0
Author:    Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.org/lilliput/commit/a512b0a0884ebec8819512d9f8006663cfcfee17
Stats:     25 lines in 1 file changed: 18 ins; 0 del; 7 mod

Fix arrays-equals intrinsic on AArch64

Reviewed-by: aboldtch

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

PR: https://git.openjdk.org/lilliput/pull/170

From aboldtch at openjdk.org  Thu Apr 25 09:24:42 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 25 Apr 2024 09:24:42 GMT
Subject: [master] Integrated: OMWorld: Cleanup BasicLock header
In-Reply-To: <zPLTPXQVkm_dphhgoSxySsBDTHZi8Xo-hQ5A3yPJAzY=.9d0b6dba-2cda-4250-88bc-71c0fb1015c0@github.com>
References: <zPLTPXQVkm_dphhgoSxySsBDTHZi8Xo-hQ5A3yPJAzY=.9d0b6dba-2cda-4250-88bc-71c0fb1015c0@github.com>
Message-ID: <hTXbcCyKbX1MIg_kzLGUeuYJHPpyw-JnTV_vax9d5RI=.7adf9088-f81c-4f83-93a1-e927dd22a32f@github.com>

On Mon, 22 Apr 2024 13:50:04 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Cleanup the usage of the header field in BasicLock. Because the asserts are stronger now I also cleanup the zero usage of the BasicLock. Because https://bugs.openjdk.org/browse/JDK-8307532 is not yet implemented I have not tested this interaction but as this now restricts the displaced header in the BasicLock to only LM_LEGACY something had to be done for LM_MONITOR support. 
> 
> This also changes symbols exposed through JVMCI so it may take extra effort to get this through. 
> 
> Similarly to #161 some changes could be upstreamed, and here there is already a distinction as neither `LM_LIGHTWEIGHT` nor `LM_MONITOR` uses the displaced header.

This pull request has now been integrated.

Changeset: a06a8ad7
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
URL:       https://git.openjdk.org/lilliput/commit/a06a8ad744ee1e6a4b8d10a6eb35c6ccb908761b
Stats:     265 lines in 17 files changed: 127 ins; 6 del; 132 mod

OMWorld: Cleanup BasicLock header

Reviewed-by: stefank

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

PR: https://git.openjdk.org/lilliput/pull/162

From stefank at openjdk.org  Thu Apr 25 11:27:42 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 25 Apr 2024 11:27:42 GMT
Subject: [master] RFR: OMWorld: Fix enter_for is_value_based bug
In-Reply-To: <hSUTMV-KY-UJkk2czPnkK-ZlMlngYtkvX6Ch66ZhuWE=.ae437a29-cb19-4f5f-a43a-9980dccd5af9@github.com>
References: <hSUTMV-KY-UJkk2czPnkK-ZlMlngYtkvX6Ch66ZhuWE=.ae437a29-cb19-4f5f-a43a-9980dccd5af9@github.com>
Message-ID: <g3rvyZmu0YiXBm320GHOA9KDFfIcUXhe2IF5m7fLH9w=.dd8ecc81-9123-47cb-9c6c-71f3006c0ee0@github.com>

On Wed, 24 Apr 2024 06:22:35 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> There was a copy-n-paste error in one of the previous OMWorld patches. `handle_sync_on_value_based_class` expects the `locking_thread` and not the `current` thread.

Thanks for the review!

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

PR Comment: https://git.openjdk.org/lilliput/pull/168#issuecomment-2076957154

From stefank at openjdk.org  Thu Apr 25 11:27:42 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 25 Apr 2024 11:27:42 GMT
Subject: [master] Integrated: OMWorld: Fix enter_for is_value_based bug
In-Reply-To: <hSUTMV-KY-UJkk2czPnkK-ZlMlngYtkvX6Ch66ZhuWE=.ae437a29-cb19-4f5f-a43a-9980dccd5af9@github.com>
References: <hSUTMV-KY-UJkk2czPnkK-ZlMlngYtkvX6Ch66ZhuWE=.ae437a29-cb19-4f5f-a43a-9980dccd5af9@github.com>
Message-ID: <NwYwqlAKax5hYY2MM5lllczGVi3mDTVHAzTEvIkcUXg=.118a92de-8af3-4c84-8aa3-00dae2492449@github.com>

On Wed, 24 Apr 2024 06:22:35 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> There was a copy-n-paste error in one of the previous OMWorld patches. `handle_sync_on_value_based_class` expects the `locking_thread` and not the `current` thread.

This pull request has now been integrated.

Changeset: eddacbe7
Author:    Stefan Karlsson <stefank at openjdk.org>
URL:       https://git.openjdk.org/lilliput/commit/eddacbe776adf029f6f9d04cc800042c56f643e7
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

OMWorld: Fix enter_for is_value_based bug

Reviewed-by: aboldtch

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

PR: https://git.openjdk.org/lilliput/pull/168

From stefank at openjdk.org  Thu Apr 25 11:28:04 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 25 Apr 2024 11:28:04 GMT
Subject: [master] RFR: Don't warn when UCOH is on by default [v2]
In-Reply-To: <3h81O91hf9xoURs_lFNN4rXtXUW4eaY6-mlov5kZkL4=.e79101fe-d4b2-4d92-9545-dc987928283b@github.com>
References: <3h81O91hf9xoURs_lFNN4rXtXUW4eaY6-mlov5kZkL4=.e79101fe-d4b2-4d92-9545-dc987928283b@github.com>
Message-ID: <fK-aEwRhI7_xOhNVymK5GJ8qjLcRpDkdYCtnw8e9hKk=.c78c962a-07f5-41f2-a0bd-6ab18255af49@github.com>

> When running testing with UCOH enabled by default in the code and non-generational ZGC the JVM prints this warning, which causes multiple failures in the testing. I'd like to propose that we  (at least temporarily) only write this warning if the user explicitly asked for UCOH.

Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:

  Re-enable Non-generational ZGC

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

Changes:
  - all: https://git.openjdk.org/lilliput/pull/165/files
  - new: https://git.openjdk.org/lilliput/pull/165/files/823fa4ba..d6f58052

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

  Stats: 6 lines in 1 file changed: 0 ins; 6 del; 0 mod
  Patch: https://git.openjdk.org/lilliput/pull/165.diff
  Fetch: git fetch https://git.openjdk.org/lilliput.git pull/165/head:pull/165

PR: https://git.openjdk.org/lilliput/pull/165

From stefank at openjdk.org  Thu Apr 25 11:31:50 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 25 Apr 2024 11:31:50 GMT
Subject: [master] RFR: 8330631: Lilliput: Modify
 runtime/CompressedOops/CompressedClassPointers for tinycp
In-Reply-To: <T-94XVofjCF_L5tUxYXy85nNL1au4QFS3W9dS0-GQeg=.523e9d0a-d322-4e89-93ba-01bc1a6d3771@github.com>
References: <T-94XVofjCF_L5tUxYXy85nNL1au4QFS3W9dS0-GQeg=.523e9d0a-d322-4e89-93ba-01bc1a6d3771@github.com>
Message-ID: <26CiH66iViDYDWH2Vat5g_-2OPdXSJFnC0rA5EHRk5E=.cd5ffa9d-5260-4c2e-90f1-74d90da17fa8@github.com>

On Wed, 24 Apr 2024 06:14:11 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> A patch that got lost in the Great Reset. Fixes test failure in runtime/CompressedOops/CompressedClassPointers.java. Originally done by @tstuefe .

Marked as reviewed by stefank (Committer).

test/hotspot/jtreg/runtime/CompressedOops/CompressedClassPointers.java line 67:

> 65:         } else {
> 66:             return false;
> 67:         }

Maybe just:
Suggestion:

        return output.getOutput().contains(usesCompactObjectHeadersPat);

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

PR Review: https://git.openjdk.org/lilliput/pull/167#pullrequestreview-2018952757
PR Review Comment: https://git.openjdk.org/lilliput/pull/167#discussion_r1577334884

From rkennke at openjdk.org  Thu Apr 25 11:48:42 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 25 Apr 2024 11:48:42 GMT
Subject: [master] RFR: Don't warn when UCOH is on by default [v2]
In-Reply-To: <fK-aEwRhI7_xOhNVymK5GJ8qjLcRpDkdYCtnw8e9hKk=.c78c962a-07f5-41f2-a0bd-6ab18255af49@github.com>
References: <3h81O91hf9xoURs_lFNN4rXtXUW4eaY6-mlov5kZkL4=.e79101fe-d4b2-4d92-9545-dc987928283b@github.com>
 <fK-aEwRhI7_xOhNVymK5GJ8qjLcRpDkdYCtnw8e9hKk=.c78c962a-07f5-41f2-a0bd-6ab18255af49@github.com>
Message-ID: <aUkGx5vkxBmXdzgp4kIT46FUgX16WlKGTwrBhic0hG4=.1c9eaf07-ef56-4dcc-8984-4b997e5b8b1c@github.com>

On Thu, 25 Apr 2024 11:28:04 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> When running testing with UCOH enabled by default in the code and non-generational ZGC the JVM prints this warning, which causes multiple failures in the testing. I'd like to propose that we  (at least temporarily) only write this warning if the user explicitly asked for UCOH.
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Re-enable Non-generational ZGC

Looks good! Thanks!

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

Marked as reviewed by rkennke (Lead).

PR Review: https://git.openjdk.org/lilliput/pull/165#pullrequestreview-2022271420

From rkennke at openjdk.org  Thu Apr 25 12:02:58 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 25 Apr 2024 12:02:58 GMT
Subject: [master] RFR: 8330631: Lilliput: Modify
 runtime/CompressedOops/CompressedClassPointers for tinycp [v2]
In-Reply-To: <T-94XVofjCF_L5tUxYXy85nNL1au4QFS3W9dS0-GQeg=.523e9d0a-d322-4e89-93ba-01bc1a6d3771@github.com>
References: <T-94XVofjCF_L5tUxYXy85nNL1au4QFS3W9dS0-GQeg=.523e9d0a-d322-4e89-93ba-01bc1a6d3771@github.com>
Message-ID: <qL-n8o459Pg5dZmxJXTAh8EtFalreD3-agscLxXkoLQ=.b64dcdc1-a3b5-4127-8a60-aee7066ed516@github.com>

> A patch that got lost in the Great Reset. Fixes test failure in runtime/CompressedOops/CompressedClassPointers.java. Originally done by @tstuefe .

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Simplify return

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

Changes:
  - all: https://git.openjdk.org/lilliput/pull/167/files
  - new: https://git.openjdk.org/lilliput/pull/167/files/84860699..6ead3584

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

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

PR: https://git.openjdk.org/lilliput/pull/167

From stefank at openjdk.org  Thu Apr 25 13:55:57 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 25 Apr 2024 13:55:57 GMT
Subject: [master] RFR: Don't warn when UCOH is on by default [v2]
In-Reply-To: <fK-aEwRhI7_xOhNVymK5GJ8qjLcRpDkdYCtnw8e9hKk=.c78c962a-07f5-41f2-a0bd-6ab18255af49@github.com>
References: <3h81O91hf9xoURs_lFNN4rXtXUW4eaY6-mlov5kZkL4=.e79101fe-d4b2-4d92-9545-dc987928283b@github.com>
 <fK-aEwRhI7_xOhNVymK5GJ8qjLcRpDkdYCtnw8e9hKk=.c78c962a-07f5-41f2-a0bd-6ab18255af49@github.com>
Message-ID: <9d83J7hJxvcCkA54BUuQ08UUuVumtwoL99WYpnpTljY=.ce534c90-4a71-4bf1-a262-41b3ebc92f3b@github.com>

On Thu, 25 Apr 2024 11:28:04 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> When running testing with UCOH enabled by default in the code and non-generational ZGC the JVM prints this warning, which causes multiple failures in the testing. I'd like to propose that we  (at least temporarily) only write this warning if the user explicitly asked for UCOH.
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Re-enable Non-generational ZGC

Thanks for reviewing!

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

PR Comment: https://git.openjdk.org/lilliput/pull/165#issuecomment-2077248383

From stefank at openjdk.org  Thu Apr 25 13:55:57 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 25 Apr 2024 13:55:57 GMT
Subject: [master] Integrated: Don't warn when UCOH is on by default
In-Reply-To: <3h81O91hf9xoURs_lFNN4rXtXUW4eaY6-mlov5kZkL4=.e79101fe-d4b2-4d92-9545-dc987928283b@github.com>
References: <3h81O91hf9xoURs_lFNN4rXtXUW4eaY6-mlov5kZkL4=.e79101fe-d4b2-4d92-9545-dc987928283b@github.com>
Message-ID: <oG8smI8W6x9UzFelilkAYPlo_CVl5B2I9Z05RjpYA8I=.965aed7b-e334-447e-96d8-a9fc98e93186@github.com>

On Wed, 24 Apr 2024 05:23:30 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> When running testing with UCOH enabled by default in the code and non-generational ZGC the JVM prints this warning, which causes multiple failures in the testing. I'd like to propose that we  (at least temporarily) only write this warning if the user explicitly asked for UCOH.

This pull request has now been integrated.

Changeset: a599676a
Author:    Stefan Karlsson <stefank at openjdk.org>
URL:       https://git.openjdk.org/lilliput/commit/a599676a9721a5f9d14aafd2e46696688b93eb1a
Stats:     4 lines in 1 file changed: 0 ins; 4 del; 0 mod

Don't warn when UCOH is on by default

Reviewed-by: rkennke

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

PR: https://git.openjdk.org/lilliput/pull/165

From stuefe at openjdk.org  Fri Apr 26 07:03:00 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 26 Apr 2024 07:03:00 GMT
Subject: [master] RFR: 8330631: Lilliput: Modify
 runtime/CompressedOops/CompressedClassPointers for tinycp [v2]
In-Reply-To: <qL-n8o459Pg5dZmxJXTAh8EtFalreD3-agscLxXkoLQ=.b64dcdc1-a3b5-4127-8a60-aee7066ed516@github.com>
References: <T-94XVofjCF_L5tUxYXy85nNL1au4QFS3W9dS0-GQeg=.523e9d0a-d322-4e89-93ba-01bc1a6d3771@github.com>
 <qL-n8o459Pg5dZmxJXTAh8EtFalreD3-agscLxXkoLQ=.b64dcdc1-a3b5-4127-8a60-aee7066ed516@github.com>
Message-ID: <wBzWxj2PNPpp_QkTMP_zmiB8tSsv7OcyMy41B6DCeuw=.3ddcabf0-a5c0-4146-98bc-0cc41311714b@github.com>

On Thu, 25 Apr 2024 12:02:58 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> A patch that got lost in the Great Reset. Fixes test failure in runtime/CompressedOops/CompressedClassPointers.java. Originally done by @tstuefe .
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify return

Good

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

Marked as reviewed by stuefe (Committer).

PR Review: https://git.openjdk.org/lilliput/pull/167#pullrequestreview-2024259372

From rkennke at openjdk.org  Fri Apr 26 07:59:55 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 26 Apr 2024 07:59:55 GMT
Subject: [master] RFR: 8330631: Lilliput: Modify
 runtime/CompressedOops/CompressedClassPointers for tinycp [v2]
In-Reply-To: <qL-n8o459Pg5dZmxJXTAh8EtFalreD3-agscLxXkoLQ=.b64dcdc1-a3b5-4127-8a60-aee7066ed516@github.com>
References: <T-94XVofjCF_L5tUxYXy85nNL1au4QFS3W9dS0-GQeg=.523e9d0a-d322-4e89-93ba-01bc1a6d3771@github.com>
 <qL-n8o459Pg5dZmxJXTAh8EtFalreD3-agscLxXkoLQ=.b64dcdc1-a3b5-4127-8a60-aee7066ed516@github.com>
Message-ID: <YSWTLzu3r06eihrqE6OtlOSRSz-of2Ao-bDT2EdwHDc=.d62e53d3-16b6-4393-ba10-686bd52a5cb6@github.com>

On Thu, 25 Apr 2024 12:02:58 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> A patch that got lost in the Great Reset. Fixes test failure in runtime/CompressedOops/CompressedClassPointers.java. Originally done by @tstuefe .
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify return

Thanks!

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

PR Comment: https://git.openjdk.org/lilliput/pull/167#issuecomment-2078834269

From rkennke at openjdk.org  Fri Apr 26 07:59:55 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 26 Apr 2024 07:59:55 GMT
Subject: [master] Integrated: 8330631: Lilliput: Modify
 runtime/CompressedOops/CompressedClassPointers for tinycp
In-Reply-To: <T-94XVofjCF_L5tUxYXy85nNL1au4QFS3W9dS0-GQeg=.523e9d0a-d322-4e89-93ba-01bc1a6d3771@github.com>
References: <T-94XVofjCF_L5tUxYXy85nNL1au4QFS3W9dS0-GQeg=.523e9d0a-d322-4e89-93ba-01bc1a6d3771@github.com>
Message-ID: <RmV3QJKXwm-gvWeMckPrczCuj7lnlljicqKaajOku2g=.f29244e0-cb8c-4b32-bae8-41b6fcaabd4e@github.com>

On Wed, 24 Apr 2024 06:14:11 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> A patch that got lost in the Great Reset. Fixes test failure in runtime/CompressedOops/CompressedClassPointers.java. Originally done by @tstuefe .

This pull request has now been integrated.

Changeset: 2bea8586
Author:    Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.org/lilliput/commit/2bea8586e7ec70848f636a7e7ee9810a2d536be6
Stats:     17 lines in 2 files changed: 6 ins; 6 del; 5 mod

8330631: Lilliput: Modify runtime/CompressedOops/CompressedClassPointers for tinycp

Reviewed-by: stefank, stuefe

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

PR: https://git.openjdk.org/lilliput/pull/167

From stuefe at openjdk.org  Sat Apr 27 07:50:34 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sat, 27 Apr 2024 07:50:34 GMT
Subject: [master] RFR: Prepare for smaller-than-22-bit class pointers
Message-ID: <7yND0YMWK_w99G29XAIZAGWvzM_hi5K3Mr8fBx2ZOeY=.da05e2bc-77ff-4fee-9830-d2f6c04f737c@github.com>

This PR prepares using arbitrary klass pointer sizes (e.g. 16). It cleans up a few places and corrects comments.

The changes in detail:

- exposes a new function `CompressedKlassPointers::max_encoding_range_size()` that returns the maximum possible size of the encoding range given the current nKlass geometry (e.g. 16 bit klass pointers with a max. shift of 10 bits can encode 64MB of class space). 

- In Metaspace::ergo_initialize(), where we ergo-adjust the CompressedClassSpaceSize, the maximum possible encoding range size flows into this adjustment now. We also print clearer warnings in case the user specified CCS size explicitly and we override that decision.

- removed any hard-wiredness of a "max class space size/encoding range size of 4GB" since with smaller geometries that does not hold true anymore. Instead, we now use `CompressedKlassPointers::max_encoding_range_size()`.

- made the requirements on klass_alignment_in_bytes clearer when setting up class space

- removed remnant code (TinyClassPointerShift) left over from development


Note: one still unsolved problem - unsolved in Lilliput as well as upstream - is to correctly limit the compressed class space size in the presence of CDS. Upstream "solves" this by capping CCS size at 3GB, which leaves 1GB for CDS archives. There is no solution for when the CDS archives would exceed this limit, and its a waste of space for CCS. 

In Lilliput, if we limit the class pointer size such that we end up with drastically reduces klass encoding range size, we need to be better at splitting that klass encoding range between CDS and class space. E.g., to map CDS and then use the remaining space completely for class space. But that would need more serious reshuffling for initialization code and CDS setup is horrendously complex.

For this patch it means, if one wants to reduce class pointer size, one may have to disable CDS to run.

Tested: Mac m1, fastdebug, with 32, 22 and 16 bit class pointers. GHAs in process.

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

Commit messages:
 - start

Changes: https://git.openjdk.org/lilliput/pull/172/files
  Webrev: https://webrevs.openjdk.org/?repo=lilliput&pr=172&range=00
  Stats: 92 lines in 4 files changed: 48 ins; 26 del; 18 mod
  Patch: https://git.openjdk.org/lilliput/pull/172.diff
  Fetch: git fetch https://git.openjdk.org/lilliput.git pull/172/head:pull/172

PR: https://git.openjdk.org/lilliput/pull/172

From stuefe at openjdk.org  Tue Apr 30 09:00:48 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 30 Apr 2024 09:00:48 GMT
Subject: [master] RFR: Prepare for smaller-than-22-bit class pointers [v2]
In-Reply-To: <7yND0YMWK_w99G29XAIZAGWvzM_hi5K3Mr8fBx2ZOeY=.da05e2bc-77ff-4fee-9830-d2f6c04f737c@github.com>
References: <7yND0YMWK_w99G29XAIZAGWvzM_hi5K3Mr8fBx2ZOeY=.da05e2bc-77ff-4fee-9830-d2f6c04f737c@github.com>
Message-ID: <nD__yMSzzx-5k-QpKVH3gYPlKhRRO6HqqE27-txcCc8=.7ee86069-ef33-402d-a520-fea382db310d@github.com>

> This PR prepares using arbitrary klass pointer sizes (e.g. 16). It cleans up a few places and corrects comments.
> 
> The changes in detail:
> 
> - exposes a new function `CompressedKlassPointers::max_encoding_range_size()` that returns the maximum possible size of the encoding range given the current nKlass geometry (e.g. 16 bit klass pointers with a max. shift of 10 bits can encode 64MB of class space). 
> 
> - In Metaspace::ergo_initialize(), where we ergo-adjust the CompressedClassSpaceSize, the maximum possible encoding range size flows into this adjustment now. We also print clearer warnings in case the user specifies CCS size explicitly, and we override that decision.
> 
> - removed any hard-wiredness of a "max class space size/encoding range size of 4GB" since with smaller geometries that does not hold true anymore. Instead, we now use `CompressedKlassPointers::max_encoding_range_size()`.
> 
> - made the requirements on klass_alignment_in_bytes clearer when setting up class space
> 
> - removed remnant code (TinyClassPointerShift) left over from development
> 
> 
> Note: One still unsolved problem?unsolved in Lilliput as well as upstream?is to correctly limit the compressed class space size in the presence of CDS. Upstream "solves" this by capping CCS size at 3GB, which leaves 1GB for CDS archives. There is no solution if CDS would ever exceed this limit,  and it's a waste of space for CCS. 
> 
> In Lilliput, if we limit the class pointer size such that we drastically reduce the klass encoding range size, we need to be better at splitting that klass encoding range between CDS and class space. For example, we could map CDS and then use the remaining space completely for class space. But that would require more serious reshuffling for initialization code, and CDS setup is horrendously complex.
> 
> For this patch, if one wants to reduce class pointer size, one may have to disable CDS to run.
> 
> Tested: Mac m1, fastdebug, with 32, 22 and 16 bit class pointers. GHAs in process.

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

 - Merge branch 'master' into preparation-for-arbitrary-cp-sizes
 - Fix behavior when running with a very small MaxMetaspaceSize
 - start

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

Changes:
  - all: https://git.openjdk.org/lilliput/pull/172/files
  - new: https://git.openjdk.org/lilliput/pull/172/files/af521964..71c3230e

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

  Stats: 607 lines in 38 files changed: 234 ins; 130 del; 243 mod
  Patch: https://git.openjdk.org/lilliput/pull/172.diff
  Fetch: git fetch https://git.openjdk.org/lilliput.git pull/172/head:pull/172

PR: https://git.openjdk.org/lilliput/pull/172

From stuefe at openjdk.org  Tue Apr 30 09:00:49 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 30 Apr 2024 09:00:49 GMT
Subject: [master] RFR: Prepare for smaller-than-22-bit class pointers
In-Reply-To: <7yND0YMWK_w99G29XAIZAGWvzM_hi5K3Mr8fBx2ZOeY=.da05e2bc-77ff-4fee-9830-d2f6c04f737c@github.com>
References: <7yND0YMWK_w99G29XAIZAGWvzM_hi5K3Mr8fBx2ZOeY=.da05e2bc-77ff-4fee-9830-d2f6c04f737c@github.com>
Message-ID: <QCk0YVtQp0f0pgQHaE6vdmQDoDohqOp7lJKiljnasfc=.d73405f6-551d-43ef-87e0-ef53a3fa2722@github.com>

On Sat, 27 Apr 2024 07:43:22 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> This PR prepares using arbitrary klass pointer sizes (e.g. 16). It cleans up a few places and corrects comments.
> 
> The changes in detail:
> 
> - exposes a new function `CompressedKlassPointers::max_encoding_range_size()` that returns the maximum possible size of the encoding range given the current nKlass geometry (e.g. 16 bit klass pointers with a max. shift of 10 bits can encode 64MB of class space). 
> 
> - In Metaspace::ergo_initialize(), where we ergo-adjust the CompressedClassSpaceSize, the maximum possible encoding range size flows into this adjustment now. We also print clearer warnings in case the user specifies CCS size explicitly, and we override that decision.
> 
> - removed any hard-wiredness of a "max class space size/encoding range size of 4GB" since with smaller geometries that does not hold true anymore. Instead, we now use `CompressedKlassPointers::max_encoding_range_size()`.
> 
> - made the requirements on klass_alignment_in_bytes clearer when setting up class space
> 
> - removed remnant code (TinyClassPointerShift) left over from development
> 
> 
> Note: One still unsolved problem?unsolved in Lilliput as well as upstream?is to correctly limit the compressed class space size in the presence of CDS. Upstream "solves" this by capping CCS size at 3GB, which leaves 1GB for CDS archives. There is no solution if CDS would ever exceed this limit,  and it's a waste of space for CCS. 
> 
> In Lilliput, if we limit the class pointer size such that we drastically reduce the klass encoding range size, we need to be better at splitting that klass encoding range between CDS and class space. For example, we could map CDS and then use the remaining space completely for class space. But that would require more serious reshuffling for initialization code, and CDS setup is horrendously complex.
> 
> For this patch, if one wants to reduce class pointer size, one may have to disable CDS to run.
> 
> Tested: Mac m1, fastdebug, with 32, 22 and 16 bit class pointers. GHAs in process.

All test errors stem from the fact that we call the JVM with a very small MaxMetaspaceSize, and the CCS size - which is set to 80% of MaxMetaspaceSize - then is down-aligned by root chunk size (16MB). That causes CCS size to be 0 now.

Before, we were aligning CCS size by root chunk size. With Lilliput, that is a bug, since we may have a smaller-than-4GB encoding range, which in turn means that CCS sticks its feet out of the encoding range cover. Upstream this bug is only theoretical since CCS is limited to 3GB and encoding range is 4GB.

Okay, I now just require the max encoding range to be at least the size of a root chunk (16 MB) and otherwise revert the behavior to before, meaning we round up CCS size to root chunk size. That means that we cannot have < 14 bit  nKlass pointers for now with a 10 bit shift. I think we can live with that.

Mac x64 errors unrelated.

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

PR Comment: https://git.openjdk.org/lilliput/pull/172#issuecomment-2082375585
PR Comment: https://git.openjdk.org/lilliput/pull/172#issuecomment-2082402196
PR Comment: https://git.openjdk.org/lilliput/pull/172#issuecomment-2084758295

From rkennke at openjdk.org  Tue Apr 30 16:32:37 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 30 Apr 2024 16:32:37 GMT
Subject: [lilliput-jdk21u:lilliput] RFR: 8330849: Add test to verify memory
 usage with recursive locking
Message-ID: <KAeiHwymVXeIyORn7I-Lo7UeZGfr3eZ5QL9dVNvgPFY=.933f394d-a8c5-48b5-8f3d-dd35aa7419c0@github.com>

Hi all,

This pull request contains a backport of commit [7b2560b4](https://github.com/openjdk/jdk/commit/7b2560b4904d80629d3f4f25c65d9b96eee9bdb6) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Roman Kennke on 24 Apr 2024 and was reviewed by Leonid Mesnik and Aleksey Shipilev.

Thanks!

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

Commit messages:
 - Backport 7b2560b4904d80629d3f4f25c65d9b96eee9bdb6

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

PR: https://git.openjdk.org/lilliput-jdk21u/pull/32