From stuefe at openjdk.org  Tue May  2 07:23:33 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 2 May 2023 07:23:33 GMT
Subject: [master] RFR: Merge jdk:jdk-21+20 [v4]
In-Reply-To: <8NjUikY2GD94qTUM43aad4Q2fkQHda8_Ok7R_BoC0Q0=.da5cd8ee-b283-4715-9c6a-05a69f848aed@github.com>
References: <8NjUikY2GD94qTUM43aad4Q2fkQHda8_Ok7R_BoC0Q0=.da5cd8ee-b283-4715-9c6a-05a69f848aed@github.com>
Message-ID: <WlUc4V6UTsTzRks1dPnfKis-PzE5wrpjlnyug5KwZpQ=.f464e2b2-b947-43fd-a8bd-37c5d74ebae0@github.com>

> Merge jdk21+20

Thomas Stuefe has updated the pull request incrementally with two additional commits since the last revision:

 - compiler/loopopts/superword/TestIndependentPacksWithCyclicDependency.java
 - fix/workaround compiler/c2/irTests/TestVectorizationMismatchedAccess

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

Changes:
  - all: https://git.openjdk.org/lilliput/pull/87/files
  - new: https://git.openjdk.org/lilliput/pull/87/files/a27f147b..e278ee30

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

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

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

From stuefe at openjdk.org  Tue May  2 12:28:58 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 2 May 2023 12:28:58 GMT
Subject: [master] Integrated: Merge jdk:jdk-21+20
In-Reply-To: <8NjUikY2GD94qTUM43aad4Q2fkQHda8_Ok7R_BoC0Q0=.da5cd8ee-b283-4715-9c6a-05a69f848aed@github.com>
References: <8NjUikY2GD94qTUM43aad4Q2fkQHda8_Ok7R_BoC0Q0=.da5cd8ee-b283-4715-9c6a-05a69f848aed@github.com>
Message-ID: <LaS_txfJ8bnht__e6L4tQFiUfv-L5Qhuj1mXI24TuB4=.5b110d39-a68c-403b-a268-4143800663b3@github.com>

On Thu, 27 Apr 2023 19:04:27 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Merge jdk21+20

This pull request has now been integrated.

Changeset: b55b9248
Author:    Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.org/lilliput/commit/b55b92483958327ba544ac6ee04cf99a61c3de3f
Stats:     502214 lines in 5003 files changed: 393495 ins; 71533 del; 37186 mod

Merge jdk:jdk-21+20

Reviewed-by: rkennke

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

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

From stuefe at openjdk.org  Tue May  2 12:30:44 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 2 May 2023 12:30:44 GMT
Subject: [master] RFR: JDK-8307002: [Lilliput] [Metaspace] Make use of
 Klass alignment gaps [v2]
In-Reply-To: <5sLl4o4TcgXbG37aibf5ZDq0nJqQkRuyd3UXPXehLPQ=.a031f83d-f009-423b-8943-e2a2b7e0d2db@github.com>
References: <5sLl4o4TcgXbG37aibf5ZDq0nJqQkRuyd3UXPXehLPQ=.a031f83d-f009-423b-8943-e2a2b7e0d2db@github.com>
Message-ID: <-kivZIwlfAbnBWbR3dsKjAuxoIszALHkwLXXV97I_tE=.ed0f0d64-b8b4-47e2-8be9-ca375c654d98@github.com>

> https://github.com/openjdk/lilliput/pull/13 changed nKlass encoding by increasing the Klass alignment gap to 512. Works fine and gives us a nKlass-value-point-to-class ratio of about 1.5:1, which means we get close to the goal of representing each class with a single value of nKlass without changing Klass to a fixed-sized Layout. It has two disadvantages, though. The most obvious one - the memory waste caused by alignment shadows - is addressed by this issue. 
> 
> (The second disadvantage that I don't address in this issue is what John Rose called "naive overalignment", but it has effects on the patch, see below)
> 
> That waste matters little for normal programs: the average waste is 256 bytes per class, and if Lilliput saves 4 bytes per object, we break even if we create more than 64 objects per class on average. We usually do that.
> 
> But class-generation scenarios are a different matter. There, we often only have a single or very few objects per class, and many many more classes, so the numbers don't add up anymore. So we need a way to eliminate the gaps.
> 
> The simple solution is to save non-class metadata from the same class loader into these gaps. This works fine since much of our non-class metadata is very fine granular. Like sand into cracks, they settle into the gaps and fill them nicely. And it is not even complicated since we already have the machinery (the descendant of Coleen's original dark-matter-prevention-structure that we use to manage prematurely deallocated metaspace). 
> 
> ----
> 
> Numbers:
> 
> Memory usage is almost back to baseline now. Volkers insane lambda generation test from JDK-8302154, loading 1 million lambdas, -Xshare:off, shows a reduction of 1.74GB->1.32GB, very close to the original 1.31GB baseline:
> 
> (interesting because scenarios like these will be the worst case from a metaspace perspective - metaspace usage of normal apps is unexciting with or without Lilliput):
> 
> 
> Lilliput unpatched:
> Virtual space:                                    
>   Non-class space:      832,00 MB reserved,     807,12 MB ( 97%) committed,  13 nodes.
>       Class space:        1,00 GB reserved,     977,31 MB ( 95%) committed,  1 nodes.                                                     
>              Both:        1,81 GB reserved,       1,74 GB ( 96%) committed. 
> 
> Lilliput patched:
> Virtual space:                                    
>   Non-class space:      384,00 MB reserved,     370,75 MB ( 97%) committed,  6 nodes.
>       Class space:        1,00 GB reserved,     977,31 MB ( 95%) committed,  1 nodes.                                                     
>              Both:        1,38 GB reserved,       1,32 GB ( 96%) committed. 
> 
> Stock VM:
> Virtual space:                                    
>   Non-class space:      832,00 MB reserved,     822,44 MB ( 99%) committed,  13 nodes.
>       Class space:        1,00 GB reserved,     521,31 MB ( 51%) committed,  1 nodes.
>              Both:        1,81 GB reserved,       1,31 GB ( 72%) committed. 
> 
> 
> ----
> 
> Patch:
> 
> https://github.com/openjdk/lilliput/pull/13 introduced the notion that every MetaspaceArena has an alignment - instead, as in the stock VM - working with one global alignment. This patch reverts much of this code (makes it easier to merge too). Instead, it treats alignment as an allocation option. An arena can satisfy allocations with different alignment requirements and will do its best to salvage the alignment waste.
> 
> That is the core of the patch. The rest is fluff and tests.
> 
> ---
> 
> Notes:
> 
> Numbers are somewhat fluid: at the moment, we use a Klass alignment of 512 and a nKlass size of 21 bits. We will probably change nKlass width to 24 or 26 bits for Lilliputs first milestone.
> 
> And once this patch is in, the disadvantage of memory waste is eliminated, so we could increase the Klass alignment. Both 512 and 1K are good values: on average a Klass is between 400b...1K. A 1K alignment would spread out the nKlass value points more. Shift the nKlass-value-point-to-class ratio closer to 1:1.
> 
> The still unsolved problem is naive overalignment. We may change the encoding scheme of Klass*->nKlass to take that into account. But not in this patch. But this uncertainty is the reason why I opted for a new method `MetaspaceArena::allocate_for_klass` instead of just giving the existing `Metaspace::allocate` method an alignment parameter.

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

  reuse-class-space-alignment-gaps

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

Changes: https://git.openjdk.org/lilliput/pull/86/files
 Webrev: https://webrevs.openjdk.org/?repo=lilliput&pr=86&range=01
  Stats: 422 lines in 18 files changed: 321 ins; 40 del; 61 mod
  Patch: https://git.openjdk.org/lilliput/pull/86.diff
  Fetch: git fetch https://git.openjdk.org/lilliput.git pull/86/head:pull/86

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

From stuefe at openjdk.org  Tue May  2 16:20:05 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 2 May 2023 16:20:05 GMT
Subject: [master] RFR: JDK-8307002: [Lilliput] [Metaspace] Make use of
 Klass alignment gaps [v3]
In-Reply-To: <5sLl4o4TcgXbG37aibf5ZDq0nJqQkRuyd3UXPXehLPQ=.a031f83d-f009-423b-8943-e2a2b7e0d2db@github.com>
References: <5sLl4o4TcgXbG37aibf5ZDq0nJqQkRuyd3UXPXehLPQ=.a031f83d-f009-423b-8943-e2a2b7e0d2db@github.com>
Message-ID: <gl9Eg4PZYbRGYUtZILLx96uQQMNsmw_32f7RU1uG0Aw=.c54475be-e8e8-449e-a504-7fed711fda5d@github.com>

> https://github.com/openjdk/lilliput/pull/13 changed nKlass encoding by increasing the Klass alignment gap to 512. Works fine and gives us a nKlass-value-point-to-class ratio of about 1.5:1, which means we get close to the goal of representing each class with a single value of nKlass without changing Klass to a fixed-sized Layout. It has two disadvantages, though. The most obvious one - the memory waste caused by alignment shadows - is addressed by this issue. 
> 
> (The second disadvantage that I don't address in this issue is what John Rose called "naive overalignment", but it has effects on the patch, see below)
> 
> That waste matters little for normal programs: the average waste is 256 bytes per class, and if Lilliput saves 4 bytes per object, we break even if we create more than 64 objects per class on average. We usually do that.
> 
> But class-generation scenarios are a different matter. There, we often only have a single or very few objects per class, and many many more classes, so the numbers don't add up anymore. So we need a way to eliminate the gaps.
> 
> The simple solution is to save non-class metadata from the same class loader into these gaps. This works fine since much of our non-class metadata is very fine granular. Like sand into cracks, they settle into the gaps and fill them nicely. And it is not even complicated since we already have the machinery (the descendant of Coleen's original dark-matter-prevention-structure that we use to manage prematurely deallocated metaspace). 
> 
> ----
> 
> Numbers:
> 
> Memory usage is almost back to baseline now. Volkers insane lambda generation test from JDK-8302154, loading 1 million lambdas, -Xshare:off, shows a reduction of 1.74GB->1.32GB, very close to the original 1.31GB baseline:
> 
> (interesting because scenarios like these will be the worst case from a metaspace perspective - metaspace usage of normal apps is unexciting with or without Lilliput):
> 
> 
> Lilliput unpatched:
> Virtual space:                                    
>   Non-class space:      832,00 MB reserved,     807,12 MB ( 97%) committed,  13 nodes.
>       Class space:        1,00 GB reserved,     977,31 MB ( 95%) committed,  1 nodes.                                                     
>              Both:        1,81 GB reserved,       1,74 GB ( 96%) committed. 
> 
> Lilliput patched:
> Virtual space:                                    
>   Non-class space:      384,00 MB reserved,     370,75 MB ( 97%) committed,  6 nodes.
>       Class space:        1,00 GB reserved,     977,31 MB ( 95%) committed,  1 nodes.                                                     
>              Both:        1,38 GB reserved,       1,32 GB ( 96%) committed. 
> 
> Stock VM:
> Virtual space:                                    
>   Non-class space:      832,00 MB reserved,     822,44 MB ( 99%) committed,  13 nodes.
>       Class space:        1,00 GB reserved,     521,31 MB ( 51%) committed,  1 nodes.
>              Both:        1,81 GB reserved,       1,31 GB ( 72%) committed. 
> 
> 
> ----
> 
> Patch:
> 
> https://github.com/openjdk/lilliput/pull/13 introduced the notion that every MetaspaceArena has an alignment - instead, as in the stock VM - working with one global alignment. This patch reverts much of this code (makes it easier to merge too). Instead, it treats alignment as an allocation option. An arena can satisfy allocations with different alignment requirements and will do its best to salvage the alignment waste.
> 
> That is the core of the patch. The rest is fluff and tests.
> 
> ---
> 
> Notes:
> 
> Numbers are somewhat fluid: at the moment, we use a Klass alignment of 512 and a nKlass size of 21 bits. We will probably change nKlass width to 24 or 26 bits for Lilliputs first milestone.
> 
> And once this patch is in, the disadvantage of memory waste is eliminated, so we could increase the Klass alignment. Both 512 and 1K are good values: on average a Klass is between 400b...1K. A 1K alignment would spread out the nKlass value points more. Shift the nKlass-value-point-to-class ratio closer to 1:1.
> 
> The still unsolved problem is naive overalignment. We may change the encoding scheme of Klass*->nKlass to take that into account. But not in this patch. But this uncertainty is the reason why I opted for a new method `MetaspaceArena::allocate_for_klass` instead of just giving the existing `Metaspace::allocate` method an alignment parameter.

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

  Fix gtests

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

Changes:
  - all: https://git.openjdk.org/lilliput/pull/86/files
  - new: https://git.openjdk.org/lilliput/pull/86/files/8f142f82..050d6b57

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

  Stats: 32 lines in 3 files changed: 18 ins; 10 del; 4 mod
  Patch: https://git.openjdk.org/lilliput/pull/86.diff
  Fetch: git fetch https://git.openjdk.org/lilliput.git pull/86/head:pull/86

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

From rkennke at openjdk.org  Wed May  3 19:40:00 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 3 May 2023 19:40:00 GMT
Subject: [master] RFR: 8307392: [Lilliput] Revert deflation of dead object's
 monitors
Message-ID: <X1Tohth8G_hZ_bJ7Rce9a5_oWTdH9AawmDc1efwoprE=.14557e3a-84ed-4c58-bf78-cf918a4c0f96@github.com>

In https://github.com/openjdk/lilliput/pull/28, I introduced some code that forces deflation of monitors on objects that are about to die. Discussions around a possible upstreaming of this code (https://github.com/openjdk/jdk/pull/13721) comes to the conclusion that this should not be necessary, and indeed, I could not reproduce the original problem that I was having in Lilliput with the code removed. I assume some changes in upstream and/or Lilliput since then have fixed the root cause. Let's remove that code and see what explodes.

Testing: (All with -XX:+UseHeavyMonitors to amplify monitor traffic)
 - [x] hotspot_gc
 - [x] tier1
 - [x] tier2
 - [x] SPECjvm workloads

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

Commit messages:
 - 8307392: [Lilliput] Revert deflation of dead object's monitors

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

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

From rkennke at openjdk.org  Wed May  3 19:56:47 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 3 May 2023 19:56:47 GMT
Subject: [master] RFR: 8307395: [Lilliput] Add missing STS to Shenandoah
Message-ID: <7uNlY70EgW_yd9vV4ix_SJviPZ06vaihvqmft2w3g1k=.57ad623c-a2d1-4dc8-83f7-03aea50f65bf@github.com>

Testing has revealed that Shenandoah GC is lacking one STS. This causes a reliable crash when running TestGCBasherWithShenandoah.java with -XX:+UseHeavyMonitors because it touches an already deflated monitor.

Testing:
 - [x] TestGCBasherWithShenandoah.java +UseHeavyMonitors
 - [x] hotspot_gc_shenandoah +UseHeavyMonitors

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

Commit messages:
 - 8307395: [Lilliput] Add missing STS to Shenandoah

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

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

From shade at openjdk.org  Thu May  4 08:27:43 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 4 May 2023 08:27:43 GMT
Subject: [master] RFR: 8307392: [Lilliput] Revert deflation of dead
 object's monitors
In-Reply-To: <X1Tohth8G_hZ_bJ7Rce9a5_oWTdH9AawmDc1efwoprE=.14557e3a-84ed-4c58-bf78-cf918a4c0f96@github.com>
References: <X1Tohth8G_hZ_bJ7Rce9a5_oWTdH9AawmDc1efwoprE=.14557e3a-84ed-4c58-bf78-cf918a4c0f96@github.com>
Message-ID: <4A1tCLybNA663Ju9QXSyUGtzWya3-cQrY-lXUEi7lwg=.76a1af50-75ad-4f08-8f27-29a499350be3@github.com>

On Wed, 3 May 2023 19:33:35 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> In https://github.com/openjdk/lilliput/pull/28, I introduced some code that forces deflation of monitors on objects that are about to die. Discussions around a possible upstreaming of this code (https://github.com/openjdk/jdk/pull/13721) comes to the conclusion that this should not be necessary, and indeed, I could not reproduce the original problem that I was having in Lilliput with the code removed. I assume some changes in upstream and/or Lilliput since then have fixed the root cause. Let's remove that code and see what explodes.
> 
> Testing: (All with -XX:+UseHeavyMonitors to amplify monitor traffic)
>  - [x] hotspot_gc
>  - [x] tier1
>  - [x] tier2
>  - [x] SPECjvm workloads

But we know this would not be safe without the GC threads rendezvous-ing, right? Also, this seems to include #90.

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

PR Review: https://git.openjdk.org/lilliput/pull/88#pullrequestreview-1412565627

From shade at openjdk.org  Thu May  4 08:28:50 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 4 May 2023 08:28:50 GMT
Subject: [master] RFR: 8307395: [Lilliput] Add missing STS to Shenandoah
In-Reply-To: <7uNlY70EgW_yd9vV4ix_SJviPZ06vaihvqmft2w3g1k=.57ad623c-a2d1-4dc8-83f7-03aea50f65bf@github.com>
References: <7uNlY70EgW_yd9vV4ix_SJviPZ06vaihvqmft2w3g1k=.57ad623c-a2d1-4dc8-83f7-03aea50f65bf@github.com>
Message-ID: <Jlw_dTiV34u0GTJ5AawVHm-tWWEcW2rle6ChfC5NzHg=.2575df9a-2238-4785-9551-61acff65bfb6@github.com>

On Wed, 3 May 2023 19:51:00 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Testing has revealed that Shenandoah GC is lacking one STS. This causes a reliable crash when running TestGCBasherWithShenandoah.java with -XX:+UseHeavyMonitors because it touches an already deflated monitor.
> 
> Testing:
>  - [x] TestGCBasherWithShenandoah.java +UseHeavyMonitors
>  - [x] hotspot_gc_shenandoah +UseHeavyMonitors

Looks fine, but don't you want to upstream it right away?

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

Marked as reviewed by shade (Committer).

PR Review: https://git.openjdk.org/lilliput/pull/90#pullrequestreview-1412566020

From stuefe at openjdk.org  Thu May  4 11:02:57 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 4 May 2023 11:02:57 GMT
Subject: [master] RFR: JDK-8307002: [Lilliput] [Metaspace] Make use of
 Klass alignment gaps [v4]
In-Reply-To: <5sLl4o4TcgXbG37aibf5ZDq0nJqQkRuyd3UXPXehLPQ=.a031f83d-f009-423b-8943-e2a2b7e0d2db@github.com>
References: <5sLl4o4TcgXbG37aibf5ZDq0nJqQkRuyd3UXPXehLPQ=.a031f83d-f009-423b-8943-e2a2b7e0d2db@github.com>
Message-ID: <0u32WS1Fdjjh4Vcl7LgOkvst43ZsF5Fu532j9JhaBu4=.34d89732-ffc2-4e05-a54a-72fdfb4b9b32@github.com>

> https://github.com/openjdk/lilliput/pull/13 changed nKlass encoding by increasing the Klass alignment gap to 512. Works fine and gives us a nKlass-value-point-to-class ratio of about 1.5:1, which means we get close to the goal of representing each class with a single value of nKlass without changing Klass to a fixed-sized Layout. It has two disadvantages, though. The most obvious one - the memory waste caused by alignment shadows - is addressed by this issue. 
> 
> (The second disadvantage that I don't address in this issue is what John Rose called "naive overalignment", but it has effects on the patch, see below)
> 
> That waste matters little for normal programs: the average waste is 256 bytes per class, and if Lilliput saves 4 bytes per object, we break even if we create more than 64 objects per class on average. We usually do that.
> 
> But class-generation scenarios are a different matter. There, we often only have a single or very few objects per class, and many many more classes, so the numbers don't add up anymore. So we need a way to eliminate the gaps.
> 
> The simple solution is to save non-class metadata from the same class loader into these gaps. This works fine since much of our non-class metadata is very fine granular. Like sand into cracks, they settle into the gaps and fill them nicely. And it is not even complicated since we already have the machinery (the descendant of Coleen's original dark-matter-prevention-structure that we use to manage prematurely deallocated metaspace). 
> 
> ----
> 
> Numbers:
> 
> Memory usage is almost back to baseline now. Volkers insane lambda generation test from JDK-8302154, loading 1 million lambdas, -Xshare:off, shows a reduction of 1.74GB->1.32GB, very close to the original 1.31GB baseline:
> 
> (interesting because scenarios like these will be the worst case from a metaspace perspective - metaspace usage of normal apps is unexciting with or without Lilliput):
> 
> 
> Lilliput unpatched:
> Virtual space:                                    
>   Non-class space:      832,00 MB reserved,     807,12 MB ( 97%) committed,  13 nodes.
>       Class space:        1,00 GB reserved,     977,31 MB ( 95%) committed,  1 nodes.                                                     
>              Both:        1,81 GB reserved,       1,74 GB ( 96%) committed. 
> 
> Lilliput patched:
> Virtual space:                                    
>   Non-class space:      384,00 MB reserved,     370,75 MB ( 97%) committed,  6 nodes.
>       Class space:        1,00 GB reserved,     977,31 MB ( 95%) committed,  1 nodes.                                                     
>              Both:        1,38 GB reserved,       1,32 GB ( 96%) committed. 
> 
> Stock VM:
> Virtual space:                                    
>   Non-class space:      832,00 MB reserved,     822,44 MB ( 99%) committed,  13 nodes.
>       Class space:        1,00 GB reserved,     521,31 MB ( 51%) committed,  1 nodes.
>              Both:        1,81 GB reserved,       1,31 GB ( 72%) committed. 
> 
> 
> ----
> 
> Patch:
> 
> https://github.com/openjdk/lilliput/pull/13 introduced the notion that every MetaspaceArena has an alignment - instead, as in the stock VM - working with one global alignment. This patch reverts much of this code (makes it easier to merge too). Instead, it treats alignment as an allocation option. An arena can satisfy allocations with different alignment requirements and will do its best to salvage the alignment waste.
> 
> That is the core of the patch. The rest is fluff and tests.
> 
> ---
> 
> Notes:
> 
> Numbers are somewhat fluid: at the moment, we use a Klass alignment of 512 and a nKlass size of 21 bits. We will probably change nKlass width to 24 or 26 bits for Lilliputs first milestone.
> 
> And once this patch is in, the disadvantage of memory waste is eliminated, so we could increase the Klass alignment. Both 512 and 1K are good values: on average a Klass is between 400b...1K. A 1K alignment would spread out the nKlass value points more. Shift the nKlass-value-point-to-class ratio closer to 1:1.
> 
> The still unsolved problem is naive overalignment. We may change the encoding scheme of Klass*->nKlass to take that into account. But not in this patch. But this uncertainty is the reason why I opted for a new method `MetaspaceArena::allocate_for_klass` instead of just giving the existing `Metaspace::allocate` method an alignment parameter.

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:

  Fix gtests

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

Changes:
  - all: https://git.openjdk.org/lilliput/pull/86/files
  - new: https://git.openjdk.org/lilliput/pull/86/files/050d6b57..5f340e05

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

  Stats: 90 lines in 5 files changed: 25 ins; 31 del; 34 mod
  Patch: https://git.openjdk.org/lilliput/pull/86.diff
  Fetch: git fetch https://git.openjdk.org/lilliput.git pull/86/head:pull/86

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

From rkennke at openjdk.org  Thu May  4 11:32:32 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 4 May 2023 11:32:32 GMT
Subject: [master] RFR: 8307392: [Lilliput] Revert deflation of dead
 object's monitors [v2]
In-Reply-To: <X1Tohth8G_hZ_bJ7Rce9a5_oWTdH9AawmDc1efwoprE=.14557e3a-84ed-4c58-bf78-cf918a4c0f96@github.com>
References: <X1Tohth8G_hZ_bJ7Rce9a5_oWTdH9AawmDc1efwoprE=.14557e3a-84ed-4c58-bf78-cf918a4c0f96@github.com>
Message-ID: <7zoOIXOwcBbPmqnwaAy1Yx_IlQCPSgbFUPBDy0hGmm8=.91541087-59ac-4846-b7f8-fdb51aa29834@github.com>

> In https://github.com/openjdk/lilliput/pull/28, I introduced some code that forces deflation of monitors on objects that are about to die. Discussions around a possible upstreaming of this code (https://github.com/openjdk/jdk/pull/13721) comes to the conclusion that this should not be necessary, and indeed, I could not reproduce the original problem that I was having in Lilliput with the code removed. I assume some changes in upstream and/or Lilliput since then have fixed the root cause. Let's remove that code and see what explodes.
> 
> Testing: (All with -XX:+UseHeavyMonitors to amplify monitor traffic)
>  - [x] hotspot_gc
>  - [x] tier1
>  - [x] tier2
>  - [x] SPECjvm workloads

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

  Cleanup

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

Changes:
  - all: https://git.openjdk.org/lilliput/pull/88/files
  - new: https://git.openjdk.org/lilliput/pull/88/files/f82d25e8..0a3ef027

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

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

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

From rkennke at openjdk.org  Thu May  4 11:32:34 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 4 May 2023 11:32:34 GMT
Subject: [master] RFR: 8307392: [Lilliput] Revert deflation of dead
 object's monitors [v2]
In-Reply-To: <4A1tCLybNA663Ju9QXSyUGtzWya3-cQrY-lXUEi7lwg=.76a1af50-75ad-4f08-8f27-29a499350be3@github.com>
References: <X1Tohth8G_hZ_bJ7Rce9a5_oWTdH9AawmDc1efwoprE=.14557e3a-84ed-4c58-bf78-cf918a4c0f96@github.com>
 <4A1tCLybNA663Ju9QXSyUGtzWya3-cQrY-lXUEi7lwg=.76a1af50-75ad-4f08-8f27-29a499350be3@github.com>
Message-ID: <WboSq5G9MuAl70RuAfWjn46DPo0n_az1G3AyRwVig3s=.c0b04fea-8b03-45da-9d64-5b10dd1f329e@github.com>

On Thu, 4 May 2023 08:25:23 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> But we know this would not be safe without the GC threads rendezvous-ing, right? Also, this seems to include #90.

Yes, but in Lilliput we rendezous GC threads since #27. This PR essentially reverts that earlier PR. I removed the Shenandoah part.

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

PR Comment: https://git.openjdk.org/lilliput/pull/88#issuecomment-1534603166

From rkennke at openjdk.org  Thu May  4 11:34:47 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 4 May 2023 11:34:47 GMT
Subject: [master] RFR: 8307395: [Lilliput] Add missing STS to Shenandoah
In-Reply-To: <Jlw_dTiV34u0GTJ5AawVHm-tWWEcW2rle6ChfC5NzHg=.2575df9a-2238-4785-9551-61acff65bfb6@github.com>
References: <7uNlY70EgW_yd9vV4ix_SJviPZ06vaihvqmft2w3g1k=.57ad623c-a2d1-4dc8-83f7-03aea50f65bf@github.com>
 <Jlw_dTiV34u0GTJ5AawVHm-tWWEcW2rle6ChfC5NzHg=.2575df9a-2238-4785-9551-61acff65bfb6@github.com>
Message-ID: <cNDUlCy0o0BdqdegDGfQ4UkTLRizkAKqmoI9DDubDxU=.d7d31104-d7ec-4e4b-8376-c23f07339a2a@github.com>

On Thu, 4 May 2023 08:25:38 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Looks fine, but don't you want to upstream it right away?

Right. Let's close this PR and redirect it to an upstream PR.

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

PR Comment: https://git.openjdk.org/lilliput/pull/90#issuecomment-1534608185

From rkennke at openjdk.org  Thu May  4 11:34:47 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 4 May 2023 11:34:47 GMT
Subject: [master] Withdrawn: 8307395: [Lilliput] Add missing STS to Shenandoah
In-Reply-To: <7uNlY70EgW_yd9vV4ix_SJviPZ06vaihvqmft2w3g1k=.57ad623c-a2d1-4dc8-83f7-03aea50f65bf@github.com>
References: <7uNlY70EgW_yd9vV4ix_SJviPZ06vaihvqmft2w3g1k=.57ad623c-a2d1-4dc8-83f7-03aea50f65bf@github.com>
Message-ID: <0k9wB_SzZkHjt2bm4M4e7L1_fici1mcPOAfs6_KQ7jk=.e5818beb-ece5-4fd2-bd8a-6e398414d904@github.com>

On Wed, 3 May 2023 19:51:00 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Testing has revealed that Shenandoah GC is lacking one STS. This causes a reliable crash when running TestGCBasherWithShenandoah.java with -XX:+UseHeavyMonitors because it touches an already deflated monitor.
> 
> Testing:
>  - [x] TestGCBasherWithShenandoah.java +UseHeavyMonitors
>  - [x] hotspot_gc_shenandoah +UseHeavyMonitors

This pull request has been closed without being integrated.

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

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

From shade at openjdk.org  Thu May  4 11:49:44 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 4 May 2023 11:49:44 GMT
Subject: [master] RFR: 8307392: [Lilliput] Revert deflation of dead
 object's monitors [v2]
In-Reply-To: <7zoOIXOwcBbPmqnwaAy1Yx_IlQCPSgbFUPBDy0hGmm8=.91541087-59ac-4846-b7f8-fdb51aa29834@github.com>
References: <X1Tohth8G_hZ_bJ7Rce9a5_oWTdH9AawmDc1efwoprE=.14557e3a-84ed-4c58-bf78-cf918a4c0f96@github.com>
 <7zoOIXOwcBbPmqnwaAy1Yx_IlQCPSgbFUPBDy0hGmm8=.91541087-59ac-4846-b7f8-fdb51aa29834@github.com>
Message-ID: <_EkhY7EfBdeSJOrBbQJx370jMb-OwMcJ0YSLc2qk6YI=.fe0e156b-a96f-4699-ae33-ceafcc60596a@github.com>

On Thu, 4 May 2023 11:32:32 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> In https://github.com/openjdk/lilliput/pull/28, I introduced some code that forces deflation of monitors on objects that are about to die. Discussions around a possible upstreaming of this code (https://github.com/openjdk/jdk/pull/13721) comes to the conclusion that this should not be necessary, and indeed, I could not reproduce the original problem that I was having in Lilliput with the code removed. I assume some changes in upstream and/or Lilliput since then have fixed the root cause. Let's remove that code and see what explodes.
>> 
>> Testing: (All with -XX:+UseHeavyMonitors to amplify monitor traffic)
>>  - [x] hotspot_gc
>>  - [x] tier1
>>  - [x] tier2
>>  - [x] SPECjvm workloads
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup

Okay then!

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

Marked as reviewed by shade (Committer).

PR Review: https://git.openjdk.org/lilliput/pull/88#pullrequestreview-1412916545

From rkennke at openjdk.org  Thu May  4 15:15:05 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 4 May 2023 15:15:05 GMT
Subject: [master] Integrated: 8307392: [Lilliput] Revert deflation of dead
 object's monitors
In-Reply-To: <X1Tohth8G_hZ_bJ7Rce9a5_oWTdH9AawmDc1efwoprE=.14557e3a-84ed-4c58-bf78-cf918a4c0f96@github.com>
References: <X1Tohth8G_hZ_bJ7Rce9a5_oWTdH9AawmDc1efwoprE=.14557e3a-84ed-4c58-bf78-cf918a4c0f96@github.com>
Message-ID: <iJa1jYNFBn8KCNouStqbLdwgw4AhGz74An2iryDubxg=.d523e4a2-f23c-45fa-b263-4d3ba55a5ad8@github.com>

On Wed, 3 May 2023 19:33:35 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> In https://github.com/openjdk/lilliput/pull/28, I introduced some code that forces deflation of monitors on objects that are about to die. Discussions around a possible upstreaming of this code (https://github.com/openjdk/jdk/pull/13721) comes to the conclusion that this should not be necessary, and indeed, I could not reproduce the original problem that I was having in Lilliput with the code removed. I assume some changes in upstream and/or Lilliput since then have fixed the root cause. Let's remove that code and see what explodes.
> 
> Testing: (All with -XX:+UseHeavyMonitors to amplify monitor traffic)
>  - [x] hotspot_gc
>  - [x] tier1
>  - [x] tier2
>  - [x] SPECjvm workloads

This pull request has now been integrated.

Changeset: e1d1a11d
Author:    Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.org/lilliput/commit/e1d1a11dde0973c70094eae992f8c657e741982d
Stats:     21 lines in 4 files changed: 0 ins; 21 del; 0 mod

8307392: [Lilliput] Revert deflation of dead object's monitors

Reviewed-by: shade

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

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

From stuefe at openjdk.org  Fri May  5 05:51:07 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 5 May 2023 05:51:07 GMT
Subject: [master] RFR: JDK-8307002: [Lilliput] [Metaspace] Make use of
 Klass alignment gaps [v5]
In-Reply-To: <5sLl4o4TcgXbG37aibf5ZDq0nJqQkRuyd3UXPXehLPQ=.a031f83d-f009-423b-8943-e2a2b7e0d2db@github.com>
References: <5sLl4o4TcgXbG37aibf5ZDq0nJqQkRuyd3UXPXehLPQ=.a031f83d-f009-423b-8943-e2a2b7e0d2db@github.com>
Message-ID: <RNEFvxkWlQjRS859eTriwUWHuqNxalgaK5e87gTYzX0=.4c251a5f-2e89-47e3-b990-f4947408f3af@github.com>

> https://github.com/openjdk/lilliput/pull/13 changed nKlass encoding by increasing the Klass alignment gap to 512. Works fine and gives us a nKlass-value-point-to-class ratio of about 1.5:1, which means we get close to the goal of representing each class with a single value of nKlass without changing Klass to a fixed-sized Layout. It has two disadvantages, though. The most obvious one - the memory waste caused by alignment shadows - is addressed by this issue. 
> 
> (The second disadvantage that I don't address in this issue is what John Rose called "naive overalignment", but it has effects on the patch, see below)
> 
> That waste matters little for normal programs: the average waste is 256 bytes per class, and if Lilliput saves 4 bytes per object, we break even if we create more than 64 objects per class on average. We usually do that.
> 
> But class-generation scenarios are a different matter. There, we often only have a single or very few objects per class, and many many more classes, so the numbers don't add up anymore. So we need a way to eliminate the gaps.
> 
> The simple solution is to save non-class metadata from the same class loader into these gaps. This works fine since much of our non-class metadata is very fine granular. Like sand into cracks, they settle into the gaps and fill them nicely. And it is not even complicated since we already have the machinery (the descendant of Coleen's original dark-matter-prevention-structure that we use to manage prematurely deallocated metaspace). 
> 
> ----
> 
> Numbers:
> 
> Memory usage is almost back to baseline now. Volkers insane lambda generation test from JDK-8302154, loading 1 million lambdas, -Xshare:off, shows a reduction of 1.74GB->1.32GB, very close to the original 1.31GB baseline:
> 
> (interesting because scenarios like these will be the worst case from a metaspace perspective - metaspace usage of normal apps is unexciting with or without Lilliput):
> 
> 
> Lilliput unpatched:
> Virtual space:                                    
>   Non-class space:      832,00 MB reserved,     807,12 MB ( 97%) committed,  13 nodes.
>       Class space:        1,00 GB reserved,     977,31 MB ( 95%) committed,  1 nodes.                                                     
>              Both:        1,81 GB reserved,       1,74 GB ( 96%) committed. 
> 
> Lilliput patched:
> Virtual space:                                    
>   Non-class space:      384,00 MB reserved,     370,75 MB ( 97%) committed,  6 nodes.
>       Class space:        1,00 GB reserved,     977,31 MB ( 95%) committed,  1 nodes.                                                     
>              Both:        1,38 GB reserved,       1,32 GB ( 96%) committed. 
> 
> Stock VM:
> Virtual space:                                    
>   Non-class space:      832,00 MB reserved,     822,44 MB ( 99%) committed,  13 nodes.
>       Class space:        1,00 GB reserved,     521,31 MB ( 51%) committed,  1 nodes.
>              Both:        1,81 GB reserved,       1,31 GB ( 72%) committed. 
> 
> 
> ----
> 
> Patch:
> 
> https://github.com/openjdk/lilliput/pull/13 introduced the notion that every MetaspaceArena has an alignment - instead, as in the stock VM - working with one global alignment. This patch reverts much of this code (makes it easier to merge too). Instead, it treats alignment as an allocation option. An arena can satisfy allocations with different alignment requirements and will do its best to salvage the alignment waste.
> 
> That is the core of the patch. The rest is fluff and tests.
> 
> ---
> 
> Notes:
> 
> Numbers are somewhat fluid: at the moment, we use a Klass alignment of 512 and a nKlass size of 21 bits. We will probably change nKlass width to 24 or 26 bits for Lilliputs first milestone.
> 
> And once this patch is in, the disadvantage of memory waste is eliminated, so we could increase the Klass alignment. Both 512 and 1K are good values: on average a Klass is between 400b...1K. A 1K alignment would spread out the nKlass value points more. Shift the nKlass-value-point-to-class ratio closer to 1:1.
> 
> The still unsolved problem is naive overalignment. We may change the encoding scheme of Klass*->nKlass to take that into account. But not in this patch. But this uncertainty is the reason why I opted for a new method `MetaspaceArena::allocate_for_klass` instead of just giving the existing `Metaspace::allocate` method an alignment parameter.

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

  fix tests

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

Changes:
  - all: https://git.openjdk.org/lilliput/pull/86/files
  - new: https://git.openjdk.org/lilliput/pull/86/files/5f340e05..3338fb0e

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

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

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

From rkennke at openjdk.org  Fri May  5 06:06:44 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 5 May 2023 06:06:44 GMT
Subject: [master] RFR: JDK-8307002: [Lilliput] [Metaspace] Make use of
 Klass alignment gaps [v5]
In-Reply-To: <RNEFvxkWlQjRS859eTriwUWHuqNxalgaK5e87gTYzX0=.4c251a5f-2e89-47e3-b990-f4947408f3af@github.com>
References: <5sLl4o4TcgXbG37aibf5ZDq0nJqQkRuyd3UXPXehLPQ=.a031f83d-f009-423b-8943-e2a2b7e0d2db@github.com>
 <RNEFvxkWlQjRS859eTriwUWHuqNxalgaK5e87gTYzX0=.4c251a5f-2e89-47e3-b990-f4947408f3af@github.com>
Message-ID: <4qizbZpnXKW2DDQxxrk21bVhSPaQB-Wl8_NatsLBi8M=.a7508714-c94e-4502-9cd9-f7c4c8c0d024@github.com>

On Fri, 5 May 2023 05:51:07 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> https://github.com/openjdk/lilliput/pull/13 changed nKlass encoding by increasing the Klass alignment gap to 512. Works fine and gives us a nKlass-value-point-to-class ratio of about 1.5:1, which means we get close to the goal of representing each class with a single value of nKlass without changing Klass to a fixed-sized Layout. It has two disadvantages, though. The most obvious one - the memory waste caused by alignment shadows - is addressed by this issue. 
>> 
>> (The second disadvantage that I don't address in this issue is what John Rose called "naive overalignment", but it has effects on the patch, see below)
>> 
>> That waste matters little for normal programs: the average waste is 256 bytes per class, and if Lilliput saves 4 bytes per object, we break even if we create more than 64 objects per class on average. We usually do that.
>> 
>> But class-generation scenarios are a different matter. There, we often only have a single or very few objects per class, and many many more classes, so the numbers don't add up anymore. So we need a way to eliminate the gaps.
>> 
>> The simple solution is to save non-class metadata from the same class loader into these gaps. This works fine since much of our non-class metadata is very fine granular. Like sand into cracks, they settle into the gaps and fill them nicely. And it is not even complicated since we already have the machinery (the descendant of Coleen's original dark-matter-prevention-structure that we use to manage prematurely deallocated metaspace). 
>> 
>> ----
>> 
>> Numbers:
>> 
>> Memory usage is almost back to baseline now. Volkers insane lambda generation test from JDK-8302154, loading 1 million lambdas, -Xshare:off, shows a reduction of 1.74GB->1.32GB, very close to the original 1.31GB baseline:
>> 
>> (interesting because scenarios like these will be the worst case from a metaspace perspective - metaspace usage of normal apps is unexciting with or without Lilliput):
>> 
>> 
>> Lilliput unpatched:
>> Virtual space:                                    
>>   Non-class space:      832,00 MB reserved,     807,12 MB ( 97%) committed,  13 nodes.
>>       Class space:        1,00 GB reserved,     977,31 MB ( 95%) committed,  1 nodes.                                                     
>>              Both:        1,81 GB reserved,       1,74 GB ( 96%) committed. 
>> 
>> Lilliput patched:
>> Virtual space:                                    
>>   Non-class space:      384,00 MB reserved,     370,75 MB ( 97%) committed,  6 nodes.
>>       Class space:        1,00 GB reserved,     977,31 MB ( 95%) committed,  1 nodes.                                                     
>>              Both:        1,38 GB reserved,       1,32 GB ( 96%) committed. 
>> 
>> Stock VM:
>> Virtual space:                                    
>>   Non-class space:      832,00 MB reserved,     822,44 MB ( 99%) committed,  13 nodes.
>>       Class space:        1,00 GB reserved,     521,31 MB ( 51%) committed,  1 nodes.
>>              Both:        1,81 GB reserved,       1,31 GB ( 72%) committed. 
>> 
>> 
>> ----
>> 
>> Patch:
>> 
>> https://github.com/openjdk/lilliput/pull/13 introduced the notion that every MetaspaceArena has an alignment - instead, as in the stock VM - working with one global alignment. This patch reverts much of this code (makes it easier to merge too). Instead, it treats alignment as an allocation option. An arena can satisfy allocations with different alignment requirements and will do its best to salvage the alignment waste.
>> 
>> That is the core of the patch. The rest is fluff and tests.
>> 
>> ---
>> 
>> Notes:
>> 
>> Numbers are somewhat fluid: at the moment, we use a Klass alignment of 512 and a nKlass size of 21 bits. We will probably change nKlass width to 24 or 26 bits for Lilliputs first milestone.
>> 
>> And once this patch is in, the disadvantage of memory waste is eliminated, so we could increase the Klass alignment. Both 512 and 1K are good values: on average a Klass is between 400b...1K. A 1K alignment would spread out the nKlass value points more. Shift the nKlass-value-point-to-class ratio closer to 1:1.
>> 
>> The still unsolved problem is naive overalignment. We may change the encoding scheme of Klass*->nKlass to take that into account. But not in this patch. But this uncertainty is the reason why I opted for a new method `MetaspaceArena::allocate_for_klass` instead of just giving the existing `Metaspace::allocate` method an alignment parameter.
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix tests

I like it! I also like that you now preserve legacy behaviour when running with -UseCompactObjectHeaders :-) Change looks good, just a small nit.

src/hotspot/share/memory/metaspace/binList.hpp line 35:

> 33: #include "utilities/globalDefinitions.hpp"
> 34: 
> 35: 

stray newline?

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

Marked as reviewed by rkennke (Lead).

PR Review: https://git.openjdk.org/lilliput/pull/86#pullrequestreview-1414212042
PR Review Comment: https://git.openjdk.org/lilliput/pull/86#discussion_r1185724142

From stuefe at openjdk.org  Fri May  5 07:27:07 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 5 May 2023 07:27:07 GMT
Subject: [master] RFR: JDK-8307002: [Lilliput] [Metaspace] Make use of
 Klass alignment gaps [v6]
In-Reply-To: <5sLl4o4TcgXbG37aibf5ZDq0nJqQkRuyd3UXPXehLPQ=.a031f83d-f009-423b-8943-e2a2b7e0d2db@github.com>
References: <5sLl4o4TcgXbG37aibf5ZDq0nJqQkRuyd3UXPXehLPQ=.a031f83d-f009-423b-8943-e2a2b7e0d2db@github.com>
Message-ID: <lS-wOl7tjUbgSNxXMcT0oEyVcGNOqFlDWXx6w2L2R3A=.02d8c083-9fa2-4cbf-a8a5-b0eb414301ed@github.com>

> https://github.com/openjdk/lilliput/pull/13 changed nKlass encoding by increasing the Klass alignment gap to 512. Works fine and gives us a nKlass-value-point-to-class ratio of about 1.5:1, which means we get close to the goal of representing each class with a single value of nKlass without changing Klass to a fixed-sized Layout. It has two disadvantages, though. The most obvious one - the memory waste caused by alignment shadows - is addressed by this issue. 
> 
> (The second disadvantage that I don't address in this issue is what John Rose called "naive overalignment", but it has effects on the patch, see below)
> 
> That waste matters little for normal programs: the average waste is 256 bytes per class, and if Lilliput saves 4 bytes per object, we break even if we create more than 64 objects per class on average. We usually do that.
> 
> But class-generation scenarios are a different matter. There, we often only have a single or very few objects per class, and many many more classes, so the numbers don't add up anymore. So we need a way to eliminate the gaps.
> 
> The simple solution is to save non-class metadata from the same class loader into these gaps. This works fine since much of our non-class metadata is very fine granular. Like sand into cracks, they settle into the gaps and fill them nicely. And it is not even complicated since we already have the machinery (the descendant of Coleen's original dark-matter-prevention-structure that we use to manage prematurely deallocated metaspace). 
> 
> ----
> 
> Numbers:
> 
> Memory usage is almost back to baseline now. Volkers insane lambda generation test from JDK-8302154, loading 1 million lambdas, -Xshare:off, shows a reduction of 1.74GB->1.32GB, very close to the original 1.31GB baseline:
> 
> (interesting because scenarios like these will be the worst case from a metaspace perspective - metaspace usage of normal apps is unexciting with or without Lilliput):
> 
> 
> Lilliput unpatched:
> Virtual space:                                    
>   Non-class space:      832,00 MB reserved,     807,12 MB ( 97%) committed,  13 nodes.
>       Class space:        1,00 GB reserved,     977,31 MB ( 95%) committed,  1 nodes.                                                     
>              Both:        1,81 GB reserved,       1,74 GB ( 96%) committed. 
> 
> Lilliput patched:
> Virtual space:                                    
>   Non-class space:      384,00 MB reserved,     370,75 MB ( 97%) committed,  6 nodes.
>       Class space:        1,00 GB reserved,     977,31 MB ( 95%) committed,  1 nodes.                                                     
>              Both:        1,38 GB reserved,       1,32 GB ( 96%) committed. 
> 
> Stock VM:
> Virtual space:                                    
>   Non-class space:      832,00 MB reserved,     822,44 MB ( 99%) committed,  13 nodes.
>       Class space:        1,00 GB reserved,     521,31 MB ( 51%) committed,  1 nodes.
>              Both:        1,81 GB reserved,       1,31 GB ( 72%) committed. 
> 
> 
> ----
> 
> Patch:
> 
> https://github.com/openjdk/lilliput/pull/13 introduced the notion that every MetaspaceArena has an alignment - instead, as in the stock VM - working with one global alignment. This patch reverts much of this code (makes it easier to merge too). Instead, it treats alignment as an allocation option. An arena can satisfy allocations with different alignment requirements and will do its best to salvage the alignment waste.
> 
> That is the core of the patch. The rest is fluff and tests.
> 
> ---
> 
> Notes:
> 
> Numbers are somewhat fluid: at the moment, we use a Klass alignment of 512 and a nKlass size of 21 bits. We will probably change nKlass width to 24 or 26 bits for Lilliputs first milestone.
> 
> And once this patch is in, the disadvantage of memory waste is eliminated, so we could increase the Klass alignment. Both 512 and 1K are good values: on average a Klass is between 400b...1K. A 1K alignment would spread out the nKlass value points more. Shift the nKlass-value-point-to-class ratio closer to 1:1.
> 
> The still unsolved problem is naive overalignment. We may change the encoding scheme of Klass*->nKlass to take that into account. But not in this patch. But this uncertainty is the reason why I opted for a new method `MetaspaceArena::allocate_for_klass` instead of just giving the existing `Metaspace::allocate` method an alignment parameter.

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

  remove stray newline

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

Changes:
  - all: https://git.openjdk.org/lilliput/pull/86/files
  - new: https://git.openjdk.org/lilliput/pull/86/files/3338fb0e..4ab1e78d

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

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

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

From stuefe at openjdk.org  Fri May  5 07:27:08 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 5 May 2023 07:27:08 GMT
Subject: [master] RFR: JDK-8307002: [Lilliput] [Metaspace] Make use of
 Klass alignment gaps [v5]
In-Reply-To: <4qizbZpnXKW2DDQxxrk21bVhSPaQB-Wl8_NatsLBi8M=.a7508714-c94e-4502-9cd9-f7c4c8c0d024@github.com>
References: <5sLl4o4TcgXbG37aibf5ZDq0nJqQkRuyd3UXPXehLPQ=.a031f83d-f009-423b-8943-e2a2b7e0d2db@github.com>
 <RNEFvxkWlQjRS859eTriwUWHuqNxalgaK5e87gTYzX0=.4c251a5f-2e89-47e3-b990-f4947408f3af@github.com>
 <4qizbZpnXKW2DDQxxrk21bVhSPaQB-Wl8_NatsLBi8M=.a7508714-c94e-4502-9cd9-f7c4c8c0d024@github.com>
Message-ID: <CbwK8InnNl3K0evHBdMY11g6KVQ7zzLyTysyEdhZANE=.d9ad076b-ac35-4d27-9d9a-15f9a6b36edc@github.com>

On Fri, 5 May 2023 06:03:56 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> I like it! I also like that you now preserve legacy behaviour when running with -UseCompactObjectHeaders :-) Change looks good, just a small nit.

Thank you Roman!

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

PR Comment: https://git.openjdk.org/lilliput/pull/86#issuecomment-1535830178

From stuefe at openjdk.org  Fri May  5 07:27:10 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 5 May 2023 07:27:10 GMT
Subject: [master] Integrated: JDK-8307002: [Lilliput] [Metaspace] Make use of
 Klass alignment gaps
In-Reply-To: <5sLl4o4TcgXbG37aibf5ZDq0nJqQkRuyd3UXPXehLPQ=.a031f83d-f009-423b-8943-e2a2b7e0d2db@github.com>
References: <5sLl4o4TcgXbG37aibf5ZDq0nJqQkRuyd3UXPXehLPQ=.a031f83d-f009-423b-8943-e2a2b7e0d2db@github.com>
Message-ID: <J1qXL9-hxtlNpRG2wPX4tyzjkw3mbbbzj4akpHPjin0=.eccc3993-35e2-4529-b595-1243ea1b3cb5@github.com>

On Wed, 26 Apr 2023 15:59:34 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> https://github.com/openjdk/lilliput/pull/13 changed nKlass encoding by increasing the Klass alignment gap to 512. Works fine and gives us a nKlass-value-point-to-class ratio of about 1.5:1, which means we get close to the goal of representing each class with a single value of nKlass without changing Klass to a fixed-sized Layout. It has two disadvantages, though. The most obvious one - the memory waste caused by alignment shadows - is addressed by this issue. 
> 
> (The second disadvantage that I don't address in this issue is what John Rose called "naive overalignment", but it has effects on the patch, see below)
> 
> That waste matters little for normal programs: the average waste is 256 bytes per class, and if Lilliput saves 4 bytes per object, we break even if we create more than 64 objects per class on average. We usually do that.
> 
> But class-generation scenarios are a different matter. There, we often only have a single or very few objects per class, and many many more classes, so the numbers don't add up anymore. So we need a way to eliminate the gaps.
> 
> The simple solution is to save non-class metadata from the same class loader into these gaps. This works fine since much of our non-class metadata is very fine granular. Like sand into cracks, they settle into the gaps and fill them nicely. And it is not even complicated since we already have the machinery (the descendant of Coleen's original dark-matter-prevention-structure that we use to manage prematurely deallocated metaspace). 
> 
> ----
> 
> Numbers:
> 
> Memory usage is almost back to baseline now. Volkers insane lambda generation test from JDK-8302154, loading 1 million lambdas, -Xshare:off, shows a reduction of 1.74GB->1.32GB, very close to the original 1.31GB baseline:
> 
> (interesting because scenarios like these will be the worst case from a metaspace perspective - metaspace usage of normal apps is unexciting with or without Lilliput):
> 
> 
> Lilliput unpatched:
> Virtual space:                                    
>   Non-class space:      832,00 MB reserved,     807,12 MB ( 97%) committed,  13 nodes.
>       Class space:        1,00 GB reserved,     977,31 MB ( 95%) committed,  1 nodes.                                                     
>              Both:        1,81 GB reserved,       1,74 GB ( 96%) committed. 
> 
> Lilliput patched:
> Virtual space:                                    
>   Non-class space:      384,00 MB reserved,     370,75 MB ( 97%) committed,  6 nodes.
>       Class space:        1,00 GB reserved,     977,31 MB ( 95%) committed,  1 nodes.                                                     
>              Both:        1,38 GB reserved,       1,32 GB ( 96%) committed. 
> 
> Stock VM:
> Virtual space:                                    
>   Non-class space:      832,00 MB reserved,     822,44 MB ( 99%) committed,  13 nodes.
>       Class space:        1,00 GB reserved,     521,31 MB ( 51%) committed,  1 nodes.
>              Both:        1,81 GB reserved,       1,31 GB ( 72%) committed. 
> 
> 
> ----
> 
> Patch:
> 
> https://github.com/openjdk/lilliput/pull/13 introduced the notion that every MetaspaceArena has an alignment - instead, as in the stock VM - working with one global alignment. This patch reverts much of this code (makes it easier to merge too). Instead, it treats alignment as an allocation option. An arena can satisfy allocations with different alignment requirements and will do its best to salvage the alignment waste.
> 
> That is the core of the patch. The rest is fluff and tests.
> 
> ---
> 
> Notes:
> 
> Numbers are somewhat fluid: at the moment, we use a Klass alignment of 512 and a nKlass size of 21 bits. We will probably change nKlass width to 24 or 26 bits for Lilliputs first milestone.
> 
> And once this patch is in, the disadvantage of memory waste is eliminated, so we could increase the Klass alignment. Both 512 and 1K are good values: on average a Klass is between 400b...1K. A 1K alignment would spread out the nKlass value points more. Shift the nKlass-value-point-to-class ratio closer to 1:1.
> 
> The still unsolved problem is naive overalignment. We may change the encoding scheme of Klass*->nKlass to take that into account. But not in this patch. But this uncertainty is the reason why I opted for a new method `MetaspaceArena::allocate_for_klass` instead of just giving the existing `Metaspace::allocate` method an alignment parameter.

This pull request has now been integrated.

Changeset: 85e06bbf
Author:    Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.org/lilliput/commit/85e06bbf6505840fa3deb2fd279fad089b3439a2
Stats:     435 lines in 20 files changed: 329 ins; 42 del; 64 mod

8307002: [Lilliput] [Metaspace] Make use of Klass alignment gaps

Reviewed-by: rkennke

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

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

From stuefe at openjdk.org  Tue May  9 13:54:43 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 9 May 2023 13:54:43 GMT
Subject: [master] RFR: JDK-8307737: [Lilliput] Reduce number of loads used for
 Klass decoding in static code
Message-ID: <gAjaiNTP5lhOIvp3tojBFQjxE4t9XmttuqCPw5eTK8s=.83db8cb1-7e9d-4c32-9c73-17fb17af14dc@github.com>

Klass decode depends on several runtime parameters. In 64-bit header mode, these are:

- UseCompactObjectHeaders
- Encoding Base
- Encoding Shift

In Legacy header mode, these are:

- UseCompactObjectHeaders
- UseCompressedClassPointers
- Encoding Base
- Encoding Shift

These values are stored at distinct locations and require three resp. four loads (see disassmbly [1]). Unfortunately, Legacy mode is more expensive with Lilliput, since we now need to load two switches.

I want to minimize the number of loads. There are several ways to do this, but the most simple would be to use a denser representation in memory of these values. We always load them together anyway.

All four values (UseCompactObjectHeaders, UseCompressedClassPointers, Encoding Base+Shift) can be coded into a single 64-bit value. The encoding base will always be page-aligned. That leaves us an alignment shadow of 12 bits to hide all the rest of the information. UseCompactObjectHeaders and UseCompressedClassPointers can be represented by single bits. The encoding shift will not be larger than 31, so we can store the shift in 5 bits.

The result is that the three resp. four loads can be folded into a single 64-bit load without too much trouble.

Alternatives. 

- Generating a stub routine is not an option if one wants to keep decoding inlined
- We could generate different variants of the decoding routines via template, parametrized for each permutation of (shift, UseCompressedClassPointers, UseCompactObjectHeaders) and the most common encoding base. But: 
	- we would need a different solution for uncommon base addresses
	- we may want to make shift an adjustable runtime parameter
	- we would need to decide, at runtime, which code variant to use - again, introduces a runtime switch we need to load from memory - nothing gained compared to the proposed solution.

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

The patch changes the way the static helper class `CompressedKlassPointers` stores encoding base and shift to a denser format. The format also contains copies of UseCompressedClassPointers and UseCompactObjectHeaders:


Bit#
0:	UseCompactObjectHeaders
1:	UseCompressedClassPointers
2-6:	Encoding shift (5 bits)
7-11:   Unused
12-63:  Encoding Base address


Patch then changes some frequently used oop methods to use the dense representation of UseCompactObjectHeaders/UseCompressedClassPointers.

The result: we now only need one load for Klass decoding/encoding (see disassembly [2]).

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

[1] https://bugs.openjdk.org/secure/attachment/103772/KlassExtraction.txt
[2] https://bugs.openjdk.org/secure/attachment/103773/KlassExtraction-patched.txt

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

Commit messages:
 - remove whitespace changes
 - JDK-8307737-Reduce-number-of-loads-for-Klass-decoding-in-static-code

Changes: https://git.openjdk.org/lilliput/pull/92/files
 Webrev: https://webrevs.openjdk.org/?repo=lilliput&pr=92&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8307737
  Stats: 80 lines in 6 files changed: 45 ins; 3 del; 32 mod
  Patch: https://git.openjdk.org/lilliput/pull/92.diff
  Fetch: git fetch https://git.openjdk.org/lilliput.git pull/92/head:pull/92

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

From rkennke at openjdk.org  Tue May  9 16:15:41 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 9 May 2023 16:15:41 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8307764: [Lilliput/JDK17] Fix JVMTI
 GetObjectMonitorUsage()
Message-ID: <dTD466idXkL-5vAnpvJYzRgXq9pyguqnFyj8p-oKvY8=.6dcc5cf9-8bee-4739-805f-4783cb933eea@github.com>

This test:
make run-test TEST=vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage001/TestDescription.java

fails with:
(0) unexpected owner: Thread-1 (0x(nil))
(0) waiter_count expected: 1, actually: 0

Reason is that [JDK-8295849](https://bugs.openjdk.org/browse/JDK-8295849) (which is a pre-req for Lilliput) has not been backported properly.

A number of other JVMTI tests are failing because of the same issue, too:

vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage001/TestDescription.java
vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage003/TestDescription.java
vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage004/TestDescription.java
vmTestbase/nsk/jvmti/scenarios/contention/TC01/tc01t001/TestDescription.java
vmTestbase/nsk/jvmti/scenarios/contention/TC03/tc03t001/TestDescription.java
vmTestbase/nsk/jvmti/scenarios/contention/TC03/tc03t002/TestDescription.java

Testing:
 - [x] all failing tests (see above)
 - [x] all of vmTestbase/nsk/jvmti
 - [x] all of serviceability/jvmti

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

Commit messages:
 - 8307764: [Lilliput/JDK17] Fix JVMTI GetObjectMonitorUsage()

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

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

From shade at openjdk.org  Tue May  9 16:15:42 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 9 May 2023 16:15:42 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8307764: [Lilliput/JDK17] Fix
 JVMTI GetObjectMonitorUsage()
In-Reply-To: <dTD466idXkL-5vAnpvJYzRgXq9pyguqnFyj8p-oKvY8=.6dcc5cf9-8bee-4739-805f-4783cb933eea@github.com>
References: <dTD466idXkL-5vAnpvJYzRgXq9pyguqnFyj8p-oKvY8=.6dcc5cf9-8bee-4739-805f-4783cb933eea@github.com>
Message-ID: <5quu4p2pleub8TApKifb9otytKzB4xomKg6p3A877EI=.fa4811e1-6468-43fd-99c6-38fd9bbf08af@github.com>

On Tue, 9 May 2023 15:58:40 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> This test:
> make run-test TEST=vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage001/TestDescription.java
> 
> fails with:
> (0) unexpected owner: Thread-1 (0x(nil))
> (0) waiter_count expected: 1, actually: 0
> 
> Reason is that [JDK-8295849](https://bugs.openjdk.org/browse/JDK-8295849) (which is a pre-req for Lilliput) has not been backported properly.
> 
> A number of other JVMTI tests are failing because of the same issue, too:
> 
> vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage001/TestDescription.java
> vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage003/TestDescription.java
> vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage004/TestDescription.java
> vmTestbase/nsk/jvmti/scenarios/contention/TC01/tc01t001/TestDescription.java
> vmTestbase/nsk/jvmti/scenarios/contention/TC03/tc03t001/TestDescription.java
> vmTestbase/nsk/jvmti/scenarios/contention/TC03/tc03t002/TestDescription.java
> 
> Testing:
>  - [x] all failing tests (see above)
>  - [x] all of vmTestbase/nsk/jvmti
>  - [x] all of serviceability/jvmti

Looks fine.

(I think you would want to merge from master at some point to get GHA clean)

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/lilliput-jdk17u/pull/15#pullrequestreview-1418990393

From rkennke at openjdk.org  Tue May  9 16:55:34 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 9 May 2023 16:55:34 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8307764: [Lilliput/JDK17] Fix
 JVMTI GetObjectMonitorUsage()
In-Reply-To: <dTD466idXkL-5vAnpvJYzRgXq9pyguqnFyj8p-oKvY8=.6dcc5cf9-8bee-4739-805f-4783cb933eea@github.com>
References: <dTD466idXkL-5vAnpvJYzRgXq9pyguqnFyj8p-oKvY8=.6dcc5cf9-8bee-4739-805f-4783cb933eea@github.com>
Message-ID: <M8LuG22UcKPhnvsmcWbMqcM48YtP4WwfIZFNel5wZkg=.8ade2eda-8ec1-460f-863b-24dbe6170460@github.com>

On Tue, 9 May 2023 15:58:40 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> This test:
> make run-test TEST=vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage001/TestDescription.java
> 
> fails with:
> (0) unexpected owner: Thread-1 (0x(nil))
> (0) waiter_count expected: 1, actually: 0
> 
> Reason is that [JDK-8295849](https://bugs.openjdk.org/browse/JDK-8295849) (which is a pre-req for Lilliput) has not been backported properly.
> 
> A number of other JVMTI tests are failing because of the same issue, too:
> 
> vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage001/TestDescription.java
> vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage003/TestDescription.java
> vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage004/TestDescription.java
> vmTestbase/nsk/jvmti/scenarios/contention/TC01/tc01t001/TestDescription.java
> vmTestbase/nsk/jvmti/scenarios/contention/TC03/tc03t001/TestDescription.java
> vmTestbase/nsk/jvmti/scenarios/contention/TC03/tc03t002/TestDescription.java
> 
> Testing:
>  - [x] all failing tests (see above)
>  - [x] all of vmTestbase/nsk/jvmti
>  - [x] all of serviceability/jvmti

Thanks!

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

PR Comment: https://git.openjdk.org/lilliput-jdk17u/pull/15#issuecomment-1540531026

From rkennke at openjdk.org  Tue May  9 16:58:52 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 9 May 2023 16:58:52 GMT
Subject: [lilliput-jdk17u:lilliput] Integrated: 8307764: [Lilliput/JDK17] Fix
 JVMTI GetObjectMonitorUsage()
In-Reply-To: <dTD466idXkL-5vAnpvJYzRgXq9pyguqnFyj8p-oKvY8=.6dcc5cf9-8bee-4739-805f-4783cb933eea@github.com>
References: <dTD466idXkL-5vAnpvJYzRgXq9pyguqnFyj8p-oKvY8=.6dcc5cf9-8bee-4739-805f-4783cb933eea@github.com>
Message-ID: <CvN5YuuUa7tr2xFt3k5vVPL23oYMFnpI4o3Z1gd-jSU=.cccb78d5-bf4e-485e-873f-40a0b9af2e2e@github.com>

On Tue, 9 May 2023 15:58:40 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> This test:
> make run-test TEST=vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage001/TestDescription.java
> 
> fails with:
> (0) unexpected owner: Thread-1 (0x(nil))
> (0) waiter_count expected: 1, actually: 0
> 
> Reason is that [JDK-8295849](https://bugs.openjdk.org/browse/JDK-8295849) (which is a pre-req for Lilliput) has not been backported properly.
> 
> A number of other JVMTI tests are failing because of the same issue, too:
> 
> vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage001/TestDescription.java
> vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage003/TestDescription.java
> vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage004/TestDescription.java
> vmTestbase/nsk/jvmti/scenarios/contention/TC01/tc01t001/TestDescription.java
> vmTestbase/nsk/jvmti/scenarios/contention/TC03/tc03t001/TestDescription.java
> vmTestbase/nsk/jvmti/scenarios/contention/TC03/tc03t002/TestDescription.java
> 
> Testing:
>  - [x] all failing tests (see above)
>  - [x] all of vmTestbase/nsk/jvmti
>  - [x] all of serviceability/jvmti

This pull request has now been integrated.

Changeset: 6d64f2a8
Author:    Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.org/lilliput-jdk17u/commit/6d64f2a8810d8e6abf5cedf396d8a895ff64eef1
Stats:     16 lines in 1 file changed: 4 ins; 1 del; 11 mod

8307764: [Lilliput/JDK17] Fix JVMTI GetObjectMonitorUsage()

Reviewed-by: shade

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

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

From stuefe at openjdk.org  Wed May 10 08:29:47 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 10 May 2023 08:29:47 GMT
Subject: [master] RFR: JDK-8307737: [Lilliput] Reduce number of loads used
 for Klass decoding in static code [v2]
In-Reply-To: <gAjaiNTP5lhOIvp3tojBFQjxE4t9XmttuqCPw5eTK8s=.83db8cb1-7e9d-4c32-9c73-17fb17af14dc@github.com>
References: <gAjaiNTP5lhOIvp3tojBFQjxE4t9XmttuqCPw5eTK8s=.83db8cb1-7e9d-4c32-9c73-17fb17af14dc@github.com>
Message-ID: <zlaTVmQIqfqQyY72-wwmiK2ONqAUluh2aCx98ia3toA=.59caace5-80f7-44ec-aab1-2bc3e96dfd68@github.com>

> Klass decode depends on several runtime parameters. In 64-bit header mode, these are:
> 
> - UseCompactObjectHeaders
> - Encoding Base
> - Encoding Shift
> 
> In Legacy header mode, these are:
> 
> - UseCompactObjectHeaders
> - UseCompressedClassPointers
> - Encoding Base
> - Encoding Shift
> 
> These values are stored at distinct locations and require three resp. four loads (see disassmbly [1]). Unfortunately, Legacy mode is more expensive with Lilliput, since we now need to load two switches.
> 
> I want to minimize the number of loads. There are several ways to do this, but the most simple would be to use a denser representation in memory of these values. We always load them together anyway.
> 
> All four values (UseCompactObjectHeaders, UseCompressedClassPointers, Encoding Base+Shift) can be coded into a single 64-bit value. The encoding base will always be page-aligned. That leaves us an alignment shadow of 12 bits to hide all the rest of the information. UseCompactObjectHeaders and UseCompressedClassPointers can be represented by single bits. The encoding shift will not be larger than 31, so we can store the shift in 5 bits.
> 
> The result is that the three resp. four loads can be folded into a single 64-bit load without too much trouble.
> 
> Alternatives. 
> 
> - Generating a stub routine is not an option if one wants to keep decoding inlined
> - We could generate different variants of the decoding routines via template, parametrized for each permutation of (shift, UseCompressedClassPointers, UseCompactObjectHeaders) and the most common encoding base. But: 
> 	- we would need a different solution for uncommon base addresses
> 	- we may want to make shift an adjustable runtime parameter
> 	- we would need to decide, at runtime, which code variant to use - again, introduces a runtime switch we need to load from memory - nothing gained compared to the proposed solution.
> 
> ----------------
> 
> The patch changes the way the static helper class `CompressedKlassPointers` stores encoding base and shift to a denser format. The format also contains copies of UseCompressedClassPointers and UseCompactObjectHeaders:
> 
> 
> Bit#
> 0:	UseCompactObjectHeaders
> 1:	UseCompressedClassPointers
> 2-6:	Encoding shift (5 bits)
> 7-11:   Unused
> 12-63:  Encoding Base address
> 
> 
> Patch then changes some frequently used oop methods to use the dense representation of UseCompactObjectHeaders/UseCompressedClassPointers.
> 
> The result: we now only need one load for Klass decoding/encoding (see disassembly [2]).
> 
> -----------------------
> 
> [1] https://bugs.openjdk.org/secure/attachment/103772/KlassExtraction.txt
> [2] https://bugs.openjdk.org/secure/attachment/103773/KlassExtraction-patched.txt

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

  fix SA tests

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

Changes:
  - all: https://git.openjdk.org/lilliput/pull/92/files
  - new: https://git.openjdk.org/lilliput/pull/92/files/01804e52..a2f0fd99

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

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

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

From rkennke at openjdk.org  Wed May 10 10:36:44 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 10 May 2023 10:36:44 GMT
Subject: [master] RFR: JDK-8307737: [Lilliput] Reduce number of loads used
 for Klass decoding in static code [v2]
In-Reply-To: <zlaTVmQIqfqQyY72-wwmiK2ONqAUluh2aCx98ia3toA=.59caace5-80f7-44ec-aab1-2bc3e96dfd68@github.com>
References: <gAjaiNTP5lhOIvp3tojBFQjxE4t9XmttuqCPw5eTK8s=.83db8cb1-7e9d-4c32-9c73-17fb17af14dc@github.com>
 <zlaTVmQIqfqQyY72-wwmiK2ONqAUluh2aCx98ia3toA=.59caace5-80f7-44ec-aab1-2bc3e96dfd68@github.com>
Message-ID: <vf498Nqu0JwFiVN6ZLjCsuAOhwD2pAXWWQuRHEnDLEc=.7e9a6842-3f90-4f1a-9f0e-201e051527df@github.com>

On Wed, 10 May 2023 08:29:47 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Klass decode depends on several runtime parameters. In 64-bit header mode, these are:
>> 
>> - UseCompactObjectHeaders
>> - Encoding Base
>> - Encoding Shift
>> 
>> In Legacy header mode, these are:
>> 
>> - UseCompactObjectHeaders
>> - UseCompressedClassPointers
>> - Encoding Base
>> - Encoding Shift
>> 
>> These values are stored at distinct locations and require three resp. four loads (see disassmbly [1]). Unfortunately, Legacy mode is more expensive with Lilliput, since we now need to load two switches.
>> 
>> I want to minimize the number of loads. There are several ways to do this, but the most simple would be to use a denser representation in memory of these values. We always load them together anyway.
>> 
>> All four values (UseCompactObjectHeaders, UseCompressedClassPointers, Encoding Base+Shift) can be coded into a single 64-bit value. The encoding base will always be page-aligned. That leaves us an alignment shadow of 12 bits to hide all the rest of the information. UseCompactObjectHeaders and UseCompressedClassPointers can be represented by single bits. The encoding shift will not be larger than 31, so we can store the shift in 5 bits.
>> 
>> The result is that the three resp. four loads can be folded into a single 64-bit load without too much trouble.
>> 
>> Alternatives. 
>> 
>> - Generating a stub routine is not an option if one wants to keep decoding inlined
>> - We could generate different variants of the decoding routines via template, parametrized for each permutation of (shift, UseCompressedClassPointers, UseCompactObjectHeaders) and the most common encoding base. But: 
>> 	- we would need a different solution for uncommon base addresses
>> 	- we may want to make shift an adjustable runtime parameter
>> 	- we would need to decide, at runtime, which code variant to use - again, introduces a runtime switch we need to load from memory - nothing gained compared to the proposed solution.
>> 
>> ----------------
>> 
>> The patch changes the way the static helper class `CompressedKlassPointers` stores encoding base and shift to a denser format. The format also contains copies of UseCompressedClassPointers and UseCompactObjectHeaders:
>> 
>> 
>> Bit#
>> 0:	UseCompactObjectHeaders
>> 1:	UseCompressedClassPointers
>> 2-6:	Encoding shift (5 bits)
>> 7-11:   Unused
>> 12-63:  Encoding Base address
>> 
>> 
>> Patch then changes some frequently used oop methods to use the dense representation of UseCompactObjectHeaders/UseCompressedClassPointers.
>> 
>> The result: we now only need one load for Klass decoding/encoding (see disassembly [2]).
>> 
>> -----------------------
>> 
>> [1] https://bugs.openjdk.org/secure/attachment/103772/KlassExtraction.txt
>> [2] https://bugs.openjdk.org/secure/attachment/103773/KlassExtraction-patched.txt
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix SA tests

Looks good. Some relatively minor comments, up to you if you want to change anything.

src/hotspot/share/oops/compressedKlass.cpp line 101:

> 99:   assert((((uintptr_t)thebase) & ~baseAddressMask) == 0, "Base address " PTR_FORMAT " unaligned", p2i(thebase));
> 100: 
> 101:   _value = (UseCompactObjectHeaders ? ((uintptr_t)1 << useCompactObjectHeadersShift) : 0) |

I am not sure that _value is a good name. Maybe _config or so?

src/hotspot/share/oops/compressedKlass.hpp line 89:

> 87:   static void set_use_compressed_class_pointers(bool b);
> 88: 
> 89:   // These members hold copies of encoding base and shift and only exist for SA (see vmStructs.cpp and

I guess, SA could be changed to decode the config bits? Maybe not in this PR, though.

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

Marked as reviewed by rkennke (Lead).

PR Review: https://git.openjdk.org/lilliput/pull/92#pullrequestreview-1420320816
PR Review Comment: https://git.openjdk.org/lilliput/pull/92#discussion_r1189706769
PR Review Comment: https://git.openjdk.org/lilliput/pull/92#discussion_r1189708789

From stuefe at openjdk.org  Wed May 10 11:29:01 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 10 May 2023 11:29:01 GMT
Subject: [master] RFR: JDK-8307737: [Lilliput] Reduce number of loads used
 for Klass decoding in static code [v2]
In-Reply-To: <vf498Nqu0JwFiVN6ZLjCsuAOhwD2pAXWWQuRHEnDLEc=.7e9a6842-3f90-4f1a-9f0e-201e051527df@github.com>
References: <gAjaiNTP5lhOIvp3tojBFQjxE4t9XmttuqCPw5eTK8s=.83db8cb1-7e9d-4c32-9c73-17fb17af14dc@github.com>
 <zlaTVmQIqfqQyY72-wwmiK2ONqAUluh2aCx98ia3toA=.59caace5-80f7-44ec-aab1-2bc3e96dfd68@github.com>
 <vf498Nqu0JwFiVN6ZLjCsuAOhwD2pAXWWQuRHEnDLEc=.7e9a6842-3f90-4f1a-9f0e-201e051527df@github.com>
Message-ID: <Jrzx_F-jgK_NmsyUOqERPTVfAy-RP9h1t9lcsuORyZw=.fb76ad68-b352-4c72-a464-ec84565f7a16@github.com>

On Wed, 10 May 2023 10:30:47 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix SA tests
>
> src/hotspot/share/oops/compressedKlass.cpp line 101:
> 
>> 99:   assert((((uintptr_t)thebase) & ~baseAddressMask) == 0, "Base address " PTR_FORMAT " unaligned", p2i(thebase));
>> 100: 
>> 101:   _value = (UseCompactObjectHeaders ? ((uintptr_t)1 << useCompactObjectHeadersShift) : 0) |
> 
> I am not sure that _value is a good name. Maybe _config or so?

Okay, _config it is.

> src/hotspot/share/oops/compressedKlass.hpp line 89:
> 
>> 87:   static void set_use_compressed_class_pointers(bool b);
>> 88: 
>> 89:   // These members hold copies of encoding base and shift and only exist for SA (see vmStructs.cpp and
> 
> I guess, SA could be changed to decode the config bits? Maybe not in this PR, though.

Yes, we should fix that.

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

PR Review Comment: https://git.openjdk.org/lilliput/pull/92#discussion_r1189766737
PR Review Comment: https://git.openjdk.org/lilliput/pull/92#discussion_r1189766556

From stuefe at openjdk.org  Wed May 10 11:33:38 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 10 May 2023 11:33:38 GMT
Subject: [master] RFR: JDK-8307737: [Lilliput] Reduce number of loads used
 for Klass decoding in static code [v3]
In-Reply-To: <gAjaiNTP5lhOIvp3tojBFQjxE4t9XmttuqCPw5eTK8s=.83db8cb1-7e9d-4c32-9c73-17fb17af14dc@github.com>
References: <gAjaiNTP5lhOIvp3tojBFQjxE4t9XmttuqCPw5eTK8s=.83db8cb1-7e9d-4c32-9c73-17fb17af14dc@github.com>
Message-ID: <fL1B_ENaoUV5LQHmEKvT8sxwlPdG0CEQwI7-1wxBT_4=.512a2a0f-6585-4962-a3ea-e4e6ab8703ee@github.com>

> Klass decode depends on several runtime parameters. In 64-bit header mode, these are:
> 
> - UseCompactObjectHeaders
> - Encoding Base
> - Encoding Shift
> 
> In Legacy header mode, these are:
> 
> - UseCompactObjectHeaders
> - UseCompressedClassPointers
> - Encoding Base
> - Encoding Shift
> 
> These values are stored at distinct locations and require three resp. four loads (see disassmbly [1]). Unfortunately, Legacy mode is more expensive with Lilliput, since we now need to load two switches.
> 
> I want to minimize the number of loads. There are several ways to do this, but the most simple would be to use a denser representation in memory of these values. We always load them together anyway.
> 
> All four values (UseCompactObjectHeaders, UseCompressedClassPointers, Encoding Base+Shift) can be coded into a single 64-bit value. The encoding base will always be page-aligned. That leaves us an alignment shadow of 12 bits to hide all the rest of the information. UseCompactObjectHeaders and UseCompressedClassPointers can be represented by single bits. The encoding shift will not be larger than 31, so we can store the shift in 5 bits.
> 
> The result is that the three resp. four loads can be folded into a single 64-bit load without too much trouble.
> 
> Alternatives. 
> 
> - Generating a stub routine is not an option if one wants to keep decoding inlined
> - We could generate different variants of the decoding routines via template, parametrized for each permutation of (shift, UseCompressedClassPointers, UseCompactObjectHeaders) and the most common encoding base. But: 
> 	- we would need a different solution for uncommon base addresses
> 	- we may want to make shift an adjustable runtime parameter
> 	- we would need to decide, at runtime, which code variant to use - again, introduces a runtime switch we need to load from memory - nothing gained compared to the proposed solution.
> 
> ----------------
> 
> The patch changes the way the static helper class `CompressedKlassPointers` stores encoding base and shift to a denser format. The format also contains copies of UseCompressedClassPointers and UseCompactObjectHeaders:
> 
> 
> Bit#
> 0:	UseCompactObjectHeaders
> 1:	UseCompressedClassPointers
> 2-6:	Encoding shift (5 bits)
> 7-11:   Unused
> 12-63:  Encoding Base address
> 
> 
> Patch then changes some frequently used oop methods to use the dense representation of UseCompactObjectHeaders/UseCompressedClassPointers.
> 
> The result: we now only need one load for Klass decoding/encoding (see disassembly [2]).
> 
> -----------------------
> 
> [1] https://bugs.openjdk.org/secure/attachment/103772/KlassExtraction.txt
> [2] https://bugs.openjdk.org/secure/attachment/103773/KlassExtraction-patched.txt

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

  feedback roman

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

Changes:
  - all: https://git.openjdk.org/lilliput/pull/92/files
  - new: https://git.openjdk.org/lilliput/pull/92/files/a2f0fd99..59a2c191

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

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

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

From rkennke at openjdk.org  Wed May 10 12:13:48 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 10 May 2023 12:13:48 GMT
Subject: [master] RFR: JDK-8307737: [Lilliput] Reduce number of loads used
 for Klass decoding in static code [v3]
In-Reply-To: <fL1B_ENaoUV5LQHmEKvT8sxwlPdG0CEQwI7-1wxBT_4=.512a2a0f-6585-4962-a3ea-e4e6ab8703ee@github.com>
References: <gAjaiNTP5lhOIvp3tojBFQjxE4t9XmttuqCPw5eTK8s=.83db8cb1-7e9d-4c32-9c73-17fb17af14dc@github.com>
 <fL1B_ENaoUV5LQHmEKvT8sxwlPdG0CEQwI7-1wxBT_4=.512a2a0f-6585-4962-a3ea-e4e6ab8703ee@github.com>
Message-ID: <RZLFWUs4t_aRFo4Hefw7rSgx0ImLCcH9GlMdteuONCs=.ef9cc9ba-d28b-484b-a813-243652c95de2@github.com>

On Wed, 10 May 2023 11:33:38 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Klass decode depends on several runtime parameters. In 64-bit header mode, these are:
>> 
>> - UseCompactObjectHeaders
>> - Encoding Base
>> - Encoding Shift
>> 
>> In Legacy header mode, these are:
>> 
>> - UseCompactObjectHeaders
>> - UseCompressedClassPointers
>> - Encoding Base
>> - Encoding Shift
>> 
>> These values are stored at distinct locations and require three resp. four loads (see disassmbly [1]). Unfortunately, Legacy mode is more expensive with Lilliput, since we now need to load two switches.
>> 
>> I want to minimize the number of loads. There are several ways to do this, but the most simple would be to use a denser representation in memory of these values. We always load them together anyway.
>> 
>> All four values (UseCompactObjectHeaders, UseCompressedClassPointers, Encoding Base+Shift) can be coded into a single 64-bit value. The encoding base will always be page-aligned. That leaves us an alignment shadow of 12 bits to hide all the rest of the information. UseCompactObjectHeaders and UseCompressedClassPointers can be represented by single bits. The encoding shift will not be larger than 31, so we can store the shift in 5 bits.
>> 
>> The result is that the three resp. four loads can be folded into a single 64-bit load without too much trouble.
>> 
>> Alternatives. 
>> 
>> - Generating a stub routine is not an option if one wants to keep decoding inlined
>> - We could generate different variants of the decoding routines via template, parametrized for each permutation of (shift, UseCompressedClassPointers, UseCompactObjectHeaders) and the most common encoding base. But: 
>> 	- we would need a different solution for uncommon base addresses
>> 	- we may want to make shift an adjustable runtime parameter
>> 	- we would need to decide, at runtime, which code variant to use - again, introduces a runtime switch we need to load from memory - nothing gained compared to the proposed solution.
>> 
>> ----------------
>> 
>> The patch changes the way the static helper class `CompressedKlassPointers` stores encoding base and shift to a denser format. The format also contains copies of UseCompressedClassPointers and UseCompactObjectHeaders:
>> 
>> 
>> Bit#
>> 0:	UseCompactObjectHeaders
>> 1:	UseCompressedClassPointers
>> 2-6:	Encoding shift (5 bits)
>> 7-11:   Unused
>> 12-63:  Encoding Base address
>> 
>> 
>> Patch then changes some frequently used oop methods to use the dense representation of UseCompactObjectHeaders/UseCompressedClassPointers.
>> 
>> The result: we now only need one load for Klass decoding/encoding (see disassembly [2]).
>> 
>> -----------------------
>> 
>> [1] https://bugs.openjdk.org/secure/attachment/103772/KlassExtraction.txt
>> [2] https://bugs.openjdk.org/secure/attachment/103773/KlassExtraction-patched.txt
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback roman

Thanks, LGTM!

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

Marked as reviewed by rkennke (Lead).

PR Review: https://git.openjdk.org/lilliput/pull/92#pullrequestreview-1420496063

From stuefe at openjdk.org  Thu May 11 04:53:10 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 11 May 2023 04:53:10 GMT
Subject: [master] Integrated: JDK-8307737: [Lilliput] Reduce number of loads
 used for Klass decoding in static code
In-Reply-To: <gAjaiNTP5lhOIvp3tojBFQjxE4t9XmttuqCPw5eTK8s=.83db8cb1-7e9d-4c32-9c73-17fb17af14dc@github.com>
References: <gAjaiNTP5lhOIvp3tojBFQjxE4t9XmttuqCPw5eTK8s=.83db8cb1-7e9d-4c32-9c73-17fb17af14dc@github.com>
Message-ID: <Pineqj_sGXnRz7NNVXR68OCtGKgVrDaLm7gbEI68rN4=.8d1ad998-7585-47fc-86df-caa5068b6e8f@github.com>

On Tue, 9 May 2023 13:41:18 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Klass decode depends on several runtime parameters. In 64-bit header mode, these are:
> 
> - UseCompactObjectHeaders
> - Encoding Base
> - Encoding Shift
> 
> In Legacy header mode, these are:
> 
> - UseCompactObjectHeaders
> - UseCompressedClassPointers
> - Encoding Base
> - Encoding Shift
> 
> These values are stored at distinct locations and require three resp. four loads (see disassmbly [1]). Unfortunately, Legacy mode is more expensive with Lilliput, since we now need to load two switches.
> 
> I want to minimize the number of loads. There are several ways to do this, but the most simple would be to use a denser representation in memory of these values. We always load them together anyway.
> 
> All four values (UseCompactObjectHeaders, UseCompressedClassPointers, Encoding Base+Shift) can be coded into a single 64-bit value. The encoding base will always be page-aligned. That leaves us an alignment shadow of 12 bits to hide all the rest of the information. UseCompactObjectHeaders and UseCompressedClassPointers can be represented by single bits. The encoding shift will not be larger than 31, so we can store the shift in 5 bits.
> 
> The result is that the three resp. four loads can be folded into a single 64-bit load without too much trouble.
> 
> Alternatives. 
> 
> - Generating a stub routine is not an option if one wants to keep decoding inlined
> - We could generate different variants of the decoding routines via template, parametrized for each permutation of (shift, UseCompressedClassPointers, UseCompactObjectHeaders) and the most common encoding base. But: 
> 	- we would need a different solution for uncommon base addresses
> 	- we may want to make shift an adjustable runtime parameter
> 	- we would need to decide, at runtime, which code variant to use - again, introduces a runtime switch we need to load from memory - nothing gained compared to the proposed solution.
> 
> ----------------
> 
> The patch changes the way the static helper class `CompressedKlassPointers` stores encoding base and shift to a denser format. The format also contains copies of UseCompressedClassPointers and UseCompactObjectHeaders:
> 
> 
> Bit#
> 0:	UseCompactObjectHeaders
> 1:	UseCompressedClassPointers
> 2-6:	Encoding shift (5 bits)
> 7-11:   Unused
> 12-63:  Encoding Base address
> 
> 
> Patch then changes some frequently used oop methods to use the dense representation of UseCompactObjectHeaders/UseCompressedClassPointers.
> 
> The result: we now only need one load for Klass decoding/encoding (see disassembly [...

This pull request has now been integrated.

Changeset: f41625f0
Author:    Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.org/lilliput/commit/f41625f0b963151426499b1a7305cc47cae81c29
Stats:     81 lines in 7 files changed: 45 ins; 3 del; 33 mod

8307737: [Lilliput] Reduce number of loads used for Klass decoding in static code

Reviewed-by: rkennke

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

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

From john.r.rose at oracle.com  Thu May 11 18:28:23 2023
From: john.r.rose at oracle.com (John Rose)
Date: Thu, 11 May 2023 11:28:23 -0700
Subject: Fwd: Adding Valhalla bits to Lilliput headers
References: <71073C5F-E6FE-4A4F-BC5D-08EFA8AEA6F1@oracle.com>
Message-ID: <A01A6744-CB15-4A67-A424-D7F4483C8E0C@oracle.com>

FYI, here?s a discussion we are having in Valhalla about its requirements on the object header, and how we envision adjusting to Lilliput.

There is no immediate action required by Lilliput, but you can keep our requirements in mind for when the matter ripens.  It probably affects the way Lilliput thinks about further compression of class IDs.

https://mail.openjdk.org/pipermail/valhalla-dev/2023-May/011051.html

Forwarded message:

From: John Rose <john.r.rose at oracle.com>
To: valhalla-dev at openjdk.java.net
Subject: Adding Valhalla bits to Lilliput headers
Date: Thu, 11 May 2023 11:23:09 -0700

Since Lilliput is becoming very real (yay!) the question arises, how will Valhalla be impacted, if at all?

Since we use object header bits for special new state (4 at current count), we will need to rethink how those work with Lilliput?s reorganization of that same header.

Here are a few thoughts on this set of problems:

https://cr.openjdk.org/~jrose/values/valhalla-and-lilliput.html
https://cr.openjdk.org/~jrose/values/valhalla-and-lilliput.md

Comments?  Anything I should add or remove?

? John

From rkennke at openjdk.org  Fri May 12 14:16:20 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 12 May 2023 14:16:20 GMT
Subject: [master] RFR: 8307991: [Lilliput] Use narrow i-hash only when
 +UseCompactObjectHeaders
Message-ID: <wq6joNueSPMYotiUvONvl99AvT8PRe14qYgnn-qOoy4=.51ee55dc-57dc-4eb0-8dc2-f5a81cc3bd91@github.com>

Currently, we use a narrow 25bit identity-hash-code in Lilliput. That is even the case when running without compact object headers, even though we could just as well use the original 31bit identity hash-code then.

The fix is relatively simple. Also, this brings the code in line with what we're currently proposing in upstream https://github.com/openjdk/jdk/pull/13844.

Going forward we would trade Klass* bits to get the full 31 i-hash back, and we're going to do that soon, but let's first fix this issue at hand (also in preparation for a clean backport, where we don't currently have the metaspace improvements).

Testing:
 - [x] tier1 +UseCompactObjectHeaders
 - [ ] tier2 +UseCompactObjectHeaders
 - [x] tier1 -UseCompactObjectHeaders
 - [ ] tier2 -UseCompactObjectHeaders

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

Commit messages:
 - SA stuff, little fixes
 - 8307991: [Lilliput] Use narrow i-hash only when +UseCompactObjectHeaders

Changes: https://git.openjdk.org/lilliput/pull/93/files
 Webrev: https://webrevs.openjdk.org/?repo=lilliput&pr=93&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8307991
  Stats: 58 lines in 7 files changed: 42 ins; 0 del; 16 mod
  Patch: https://git.openjdk.org/lilliput/pull/93.diff
  Fetch: git fetch https://git.openjdk.org/lilliput.git pull/93/head:pull/93

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

From shade at openjdk.org  Fri May 12 15:40:11 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 12 May 2023 15:40:11 GMT
Subject: [master] RFR: 8307991: [Lilliput] Use narrow i-hash only when
 +UseCompactObjectHeaders
In-Reply-To: <wq6joNueSPMYotiUvONvl99AvT8PRe14qYgnn-qOoy4=.51ee55dc-57dc-4eb0-8dc2-f5a81cc3bd91@github.com>
References: <wq6joNueSPMYotiUvONvl99AvT8PRe14qYgnn-qOoy4=.51ee55dc-57dc-4eb0-8dc2-f5a81cc3bd91@github.com>
Message-ID: <968MvppK9vzpOp6Rkto5RUjf-ZFyK1q88kEofOXUc3Q=.d8f90654-19fb-466f-ab43-2ef1bc71fce9@github.com>

On Fri, 12 May 2023 10:33:45 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Currently, we use a narrow 25bit identity-hash-code in Lilliput. That is even the case when running without compact object headers, even though we could just as well use the original 31bit identity hash-code then.
> 
> The fix is relatively simple. Also, this brings the code in line with what we're currently proposing in upstream https://github.com/openjdk/jdk/pull/13844.
> 
> Going forward we would trade Klass* bits to get the full 31 i-hash back, and we're going to do that soon, but let's first fix this issue at hand (also in preparation for a clean backport, where we don't currently have the metaspace improvements).
> 
> Testing:
>  - [x] tier1 +UseCompactObjectHeaders
>  - [ ] tier2 +UseCompactObjectHeaders
>  - [x] tier1 -UseCompactObjectHeaders
>  - [ ] tier2 -UseCompactObjectHeaders

Looks good.

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

Marked as reviewed by shade (Committer).

PR Review: https://git.openjdk.org/lilliput/pull/93#pullrequestreview-1424749351

From rkennke at openjdk.org  Fri May 12 16:05:23 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 12 May 2023 16:05:23 GMT
Subject: [master] Integrated: 8307991: [Lilliput] Use narrow i-hash only when
 +UseCompactObjectHeaders
In-Reply-To: <wq6joNueSPMYotiUvONvl99AvT8PRe14qYgnn-qOoy4=.51ee55dc-57dc-4eb0-8dc2-f5a81cc3bd91@github.com>
References: <wq6joNueSPMYotiUvONvl99AvT8PRe14qYgnn-qOoy4=.51ee55dc-57dc-4eb0-8dc2-f5a81cc3bd91@github.com>
Message-ID: <fxFJziFyAubOhVG0TtIot5Au016Uh9zUfVScLX9rTOI=.d77d594d-a80a-4785-82fd-8e3211be1bfa@github.com>

On Fri, 12 May 2023 10:33:45 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Currently, we use a narrow 25bit identity-hash-code in Lilliput. That is even the case when running without compact object headers, even though we could just as well use the original 31bit identity hash-code then.
> 
> The fix is relatively simple. Also, this brings the code in line with what we're currently proposing in upstream https://github.com/openjdk/jdk/pull/13844.
> 
> Going forward we would trade Klass* bits to get the full 31 i-hash back, and we're going to do that soon, but let's first fix this issue at hand (also in preparation for a clean backport, where we don't currently have the metaspace improvements).
> 
> Testing:
>  - [x] tier1 +UseCompactObjectHeaders
>  - [x] tier2 +UseCompactObjectHeaders
>  - [x] tier1 -UseCompactObjectHeaders
>  - [x] tier2 -UseCompactObjectHeaders

This pull request has now been integrated.

Changeset: 646f6f5e
Author:    Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.org/lilliput/commit/646f6f5e2ba276bb510ea6460232026d46cede53
Stats:     58 lines in 7 files changed: 42 ins; 0 del; 16 mod

8307991: [Lilliput] Use narrow i-hash only when +UseCompactObjectHeaders

Reviewed-by: shade

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

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

From rkennke at openjdk.org  Fri May 12 16:08:25 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 12 May 2023 16:08:25 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8308011: [Lilliput/JDK17] Use narrow
 i-hash only when +UseCompactObjectHeaders
Message-ID: <9ft6_mQgnfb-jc4JUCy1J7trKYIfuHZtfsvrk5sVchA=.a5896ebd-301a-48b3-8170-b5eb597b0793@github.com>

Currently, we use a narrow 25bit identity-hash-code in Lilliput. That is even the case when running without compact object headers, even though we could just as well use the original 31bit identity hash-code then.

The fix is relatively simple. This is a backport of https://github.com/openjdk/lilliput/pull/93. Also, this brings the code in line with what we're currently proposing in upstream https://github.com/openjdk/jdk/pull/13844.

Testing:
 - [x] tier1 +UseCompactObjectHeaders
 - [ ] tier2 +UseCompactObjectHeaders
 - [x] tier1 -UseCompactObjectHeaders
 - [ ] tier2 -UseCompactObjectHeaders

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

Commit messages:
 - 8308011: [Lilliput/JDK17] Use narrow i-hash only when +UseCompactObjectHeaders

Changes: https://git.openjdk.org/lilliput-jdk17u/pull/16/files
 Webrev: https://webrevs.openjdk.org/?repo=lilliput-jdk17u&pr=16&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308011
  Stats: 61 lines in 7 files changed: 45 ins; 2 del; 14 mod
  Patch: https://git.openjdk.org/lilliput-jdk17u/pull/16.diff
  Fetch: git fetch https://git.openjdk.org/lilliput-jdk17u.git pull/16/head:pull/16

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

From shade at openjdk.org  Mon May 15 10:05:15 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 15 May 2023 10:05:15 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8308011: [Lilliput/JDK17] Use
 narrow i-hash only when +UseCompactObjectHeaders
In-Reply-To: <9ft6_mQgnfb-jc4JUCy1J7trKYIfuHZtfsvrk5sVchA=.a5896ebd-301a-48b3-8170-b5eb597b0793@github.com>
References: <9ft6_mQgnfb-jc4JUCy1J7trKYIfuHZtfsvrk5sVchA=.a5896ebd-301a-48b3-8170-b5eb597b0793@github.com>
Message-ID: <Hy0cjHnISdvqxTehfYvxW_p-kgG6Srr_RNXnHNo1Qr0=.a7b3df4c-81c2-484e-bf18-1a1fcdae5a8e@github.com>

On Fri, 12 May 2023 15:09:58 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Currently, we use a narrow 25bit identity-hash-code in Lilliput. That is even the case when running without compact object headers, even though we could just as well use the original 31bit identity hash-code then.
> 
> The fix is relatively simple. This is a backport of https://github.com/openjdk/lilliput/pull/93. Also, this brings the code in line with what we're currently proposing in upstream https://github.com/openjdk/jdk/pull/13844.
> 
> Testing:
>  - [x] tier1 +UseCompactObjectHeaders
>  - [ ] tier2 +UseCompactObjectHeaders
>  - [x] tier1 -UseCompactObjectHeaders
>  - [ ] tier2 -UseCompactObjectHeaders

Looks fine, with a comprehension question.

src/hotspot/share/oops/markWord.hpp line 155:

> 153:   static const int age_shift                      = self_forwarded_shift + self_forwarded_bits;
> 154:   static const int unused_gap_shift               = age_shift + age_bits;
> 155:   static const int hash_shift                     = unused_gap_shift + unused_gap_bits;

This moves `hash_shift` back to upstream state, right? Looks to me that way.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/lilliput-jdk17u/pull/16#pullrequestreview-1426209089
PR Review Comment: https://git.openjdk.org/lilliput-jdk17u/pull/16#discussion_r1193616252

From rkennke at openjdk.org  Mon May 15 13:50:19 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 15 May 2023 13:50:19 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8308011: [Lilliput/JDK17] Use
 narrow i-hash only when +UseCompactObjectHeaders
In-Reply-To: <Hy0cjHnISdvqxTehfYvxW_p-kgG6Srr_RNXnHNo1Qr0=.a7b3df4c-81c2-484e-bf18-1a1fcdae5a8e@github.com>
References: <9ft6_mQgnfb-jc4JUCy1J7trKYIfuHZtfsvrk5sVchA=.a5896ebd-301a-48b3-8170-b5eb597b0793@github.com>
 <Hy0cjHnISdvqxTehfYvxW_p-kgG6Srr_RNXnHNo1Qr0=.a7b3df4c-81c2-484e-bf18-1a1fcdae5a8e@github.com>
Message-ID: <ltVQixF7RNdByUZpNrggeRUNl5-M2dHNc1NJb-jqoGE=.05787406-8deb-4a2a-92db-7b97fef41b89@github.com>

On Mon, 15 May 2023 10:02:17 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Currently, we use a narrow 25bit identity-hash-code in Lilliput. That is even the case when running without compact object headers, even though we could just as well use the original 31bit identity hash-code then.
>> 
>> The fix is relatively simple. This is a backport of https://github.com/openjdk/lilliput/pull/93. Also, this brings the code in line with what we're currently proposing in upstream https://github.com/openjdk/jdk/pull/13844.
>> 
>> Testing:
>>  - [x] tier1 +UseCompactObjectHeaders
>>  - [ ] tier2 +UseCompactObjectHeaders
>>  - [x] tier1 -UseCompactObjectHeaders
>>  - [ ] tier2 -UseCompactObjectHeaders
>
> src/hotspot/share/oops/markWord.hpp line 155:
> 
>> 153:   static const int age_shift                      = self_forwarded_shift + self_forwarded_bits;
>> 154:   static const int unused_gap_shift               = age_shift + age_bits;
>> 155:   static const int hash_shift                     = unused_gap_shift + unused_gap_bits;
> 
> This moves `hash_shift` back to upstream state, right? Looks to me that way.

Yes, and the other constants, too. I'm adding *_constant variants of the relevant hash-related constants, and branch on UseCompactObjectHeaders in the relevant paths to get the legacy or new layout.

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

PR Review Comment: https://git.openjdk.org/lilliput-jdk17u/pull/16#discussion_r1193867917

From rkennke at openjdk.org  Mon May 15 15:43:55 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 15 May 2023 15:43:55 GMT
Subject: [master] RFR: Merge jdk:jdk-21+22
Message-ID: <7g9zJmTyX9owJr79tTOSUm2S-VNfe8gcg6k5olviEPQ=.da948cb4-6ba0-4a81-91bf-4b81341e91b1@github.com>

This merges upstream JDK at tag jdk-21+22.

Most notably this merges the upstreamed locking changes, and thus greatly reduces the upstream diff.

Testing:
 - [x] tier1 (x86_64)
 - [x] tier1 (aarch64)
 - [ ] tier2 (x86_64)
 - [ ] tier2 (aarch64)

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

Commit messages:
 - Merge tag 'jdk-21+22' into merge-jdk-21+22
 - 8307765: DynamicArchiveHeader contents are missing in CDS mapfile
 - 8307860: [BACKOUT] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries
 - 8307857: validate-source fails after JDK-8306758
 - 8306758: com/sun/jdi/ConnectedVMs.java fails with "Non-zero debuggee exitValue: 143"
 - 8307194: Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries
 - 8307244: Remove redundant class RMIIIOPServerImpl
 - 8151531: Add notes to BaseStream.spliterator/iterator docs regarding them being escape hatches
 - 8305748: Clarify reentrant behavior of close() in FileInputStream, FileOutputStream, and RandomAccessFile
 - 8307799: Newly added java/awt/dnd/MozillaDnDTest.java has invalid jtreg `@requires` clause
 - ... and 203 more: https://git.openjdk.org/lilliput/compare/f41625f0...27fd6000

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.org/?repo=lilliput&pr=94&range=00.0
 - jdk:jdk-21+22: https://webrevs.openjdk.org/?repo=lilliput&pr=94&range=00.1

Changes: https://git.openjdk.org/lilliput/pull/94/files
  Stats: 76532 lines in 1729 files changed: 49884 ins; 13686 del; 12962 mod
  Patch: https://git.openjdk.org/lilliput/pull/94.diff
  Fetch: git fetch https://git.openjdk.org/lilliput.git pull/94/head:pull/94

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

From stuefe at openjdk.org  Mon May 15 15:55:13 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 15 May 2023 15:55:13 GMT
Subject: [master] RFR: Merge jdk:jdk-21+22
In-Reply-To: <7g9zJmTyX9owJr79tTOSUm2S-VNfe8gcg6k5olviEPQ=.da948cb4-6ba0-4a81-91bf-4b81341e91b1@github.com>
References: <7g9zJmTyX9owJr79tTOSUm2S-VNfe8gcg6k5olviEPQ=.da948cb4-6ba0-4a81-91bf-4b81341e91b1@github.com>
Message-ID: <E9AbWG-fb5XvGfiEfKEq2ZH9T7g77D62U4gqz0mkyTw=.491c936d-68e8-47eb-b89a-54dd28957535@github.com>

On Mon, 15 May 2023 13:53:53 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> This merges upstream JDK at tag jdk-21+22.
> 
> Most notably this merges the upstreamed locking changes, and thus greatly reduces the upstream diff.
> 
> Testing:
>  - [x] tier1 (x86_64)
>  - [x] tier1 (aarch64)
>  - [ ] tier2 (x86_64)
>  - [ ] tier2 (aarch64)

Reviewed all 1725 files. Looks good.

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

Marked as reviewed by stuefe (Committer).

PR Review: https://git.openjdk.org/lilliput/pull/94#pullrequestreview-1426873115

From rkennke at openjdk.org  Mon May 15 16:48:17 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 15 May 2023 16:48:17 GMT
Subject: [lilliput-jdk17u:lilliput] Integrated: 8308011: [Lilliput/JDK17] Use
 narrow i-hash only when +UseCompactObjectHeaders
In-Reply-To: <9ft6_mQgnfb-jc4JUCy1J7trKYIfuHZtfsvrk5sVchA=.a5896ebd-301a-48b3-8170-b5eb597b0793@github.com>
References: <9ft6_mQgnfb-jc4JUCy1J7trKYIfuHZtfsvrk5sVchA=.a5896ebd-301a-48b3-8170-b5eb597b0793@github.com>
Message-ID: <yGAX-WS2K5PgFlMk_CZDU1q_aaoowIYbQrOck_0feaI=.caf2db45-d5e8-491f-a6b5-1353efe99d77@github.com>

On Fri, 12 May 2023 15:09:58 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Currently, we use a narrow 25bit identity-hash-code in Lilliput. That is even the case when running without compact object headers, even though we could just as well use the original 31bit identity hash-code then.
> 
> The fix is relatively simple. This is a backport of https://github.com/openjdk/lilliput/pull/93. Also, this brings the code in line with what we're currently proposing in upstream https://github.com/openjdk/jdk/pull/13844.
> 
> Testing:
>  - [x] tier1 +UseCompactObjectHeaders
>  - [ ] tier2 +UseCompactObjectHeaders
>  - [x] tier1 -UseCompactObjectHeaders
>  - [ ] tier2 -UseCompactObjectHeaders

This pull request has now been integrated.

Changeset: 2c69915a
Author:    Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.org/lilliput-jdk17u/commit/2c69915a57be39b1673962056717020ecd72520b
Stats:     61 lines in 7 files changed: 45 ins; 2 del; 14 mod

8308011: [Lilliput/JDK17] Use narrow i-hash only when +UseCompactObjectHeaders

Reviewed-by: shade

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

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

From rkennke at openjdk.org  Mon May 15 16:54:24 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 15 May 2023 16:54:24 GMT
Subject: [master] Integrated: Merge jdk:jdk-21+22
In-Reply-To: <7g9zJmTyX9owJr79tTOSUm2S-VNfe8gcg6k5olviEPQ=.da948cb4-6ba0-4a81-91bf-4b81341e91b1@github.com>
References: <7g9zJmTyX9owJr79tTOSUm2S-VNfe8gcg6k5olviEPQ=.da948cb4-6ba0-4a81-91bf-4b81341e91b1@github.com>
Message-ID: <sOWhkXIqkEHwrmmicfFOBV-A4JXPqD5ivzDsRdH8WU4=.2dd4e7a4-14c5-4eca-b9e2-8ca7c3af11c8@github.com>

On Mon, 15 May 2023 13:53:53 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> This merges upstream JDK at tag jdk-21+22.
> 
> Most notably this merges the upstreamed locking changes, and thus greatly reduces the upstream diff.
> 
> Testing:
>  - [x] tier1 (x86_64)
>  - [x] tier1 (aarch64)
>  - [ ] tier2 (x86_64)
>  - [ ] tier2 (aarch64)

This pull request has now been integrated.

Changeset: bb07378f
Author:    Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.org/lilliput/commit/bb07378f5b1ebb3a54ea88857e94501e5427113b
Stats:     76532 lines in 1729 files changed: 49884 ins; 13686 del; 12962 mod

Merge jdk:jdk-21+22

Reviewed-by: stuefe

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

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

From shade at openjdk.org  Mon May 15 17:23:39 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 15 May 2023 17:23:39 GMT
Subject: [lilliput-jdk17u:lilliput] Integrated: Merge jdk17u:jdk-17.0.8+2
In-Reply-To: <UKFAcuO796RTBio2fnQ6GYRPXG829jd5HPBr1cxCUpA=.f7b2f195-ddf1-44ef-ab53-839a13395622@github.com>
References: <UKFAcuO796RTBio2fnQ6GYRPXG829jd5HPBr1cxCUpA=.f7b2f195-ddf1-44ef-ab53-839a13395622@github.com>
Message-ID: <EUBOphLAjRx3f6fnmUyWjjXpB8ZnyIi2uNrAiQkFf70=.80eaef56-f80c-4961-904e-6b459f7b5ace@github.com>

On Fri, 12 May 2023 16:12:30 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Let's merge tag jdk-17.0.8+2. Merge was clean.
> 
> Testing:
>  - [ ] tier1
>  - [ ] tier2
>  - [ ] tier3

Looks fine, assuming tests are passing.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/lilliput-jdk17u/pull/17#pullrequestreview-1426192889

From rkennke at openjdk.org  Mon May 15 17:23:39 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 15 May 2023 17:23:39 GMT
Subject: [lilliput-jdk17u:lilliput] Integrated: Merge jdk17u:jdk-17.0.8+2
Message-ID: <UKFAcuO796RTBio2fnQ6GYRPXG829jd5HPBr1cxCUpA=.f7b2f195-ddf1-44ef-ab53-839a13395622@github.com>

Let's merge tag jdk-17.0.8+2. Merge was clean.

Testing:
 - [ ] tier1
 - [ ] tier2
 - [ ] tier3

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

Commit messages:
 - Merge tag 'jdk-17.0.8+2' into merge-jdk-17.0.8+2
 - 8305690: [X86] Do not emit two REX prefixes in Assembler::prefix
 - 8299570: [JVMCI] Insufficient error handling when CodeBuffer is exhausted
 - 8302508: Add timestamp to the output TraceCompilerThreads
 - 8297450: ScaledTextFieldBorderTest.java fails when run with -show parameter
 - 8289509: Improve test coverage for XPath Axes: descendant, descendant-or-self, following, following-sibling
 - 8296084: javax/swing/JSpinner/4788637/bug4788637.java fails intermittently on a VM
 - 8292990: Improve test coverage for XPath Axes: parent
 - 8244976: vmTestbase/nsk/jdi/Event/request/request001.java doesn' initialize eName
 - 8286398: Address possibly lossy conversions in jdk.internal.le
 - ... and 135 more: https://git.openjdk.org/lilliput-jdk17u/compare/6d64f2a8...0e56f934

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - lilliput: https://webrevs.openjdk.org/?repo=lilliput-jdk17u&pr=17&range=00.0
 - jdk17u:jdk-17.0.8+2: https://webrevs.openjdk.org/?repo=lilliput-jdk17u&pr=17&range=00.1

Changes: https://git.openjdk.org/lilliput-jdk17u/pull/17/files
  Stats: 53612 lines in 887 files changed: 34223 ins; 12287 del; 7102 mod
  Patch: https://git.openjdk.org/lilliput-jdk17u/pull/17.diff
  Fetch: git fetch https://git.openjdk.org/lilliput-jdk17u.git pull/17/head:pull/17

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

From rkennke at openjdk.org  Mon May 15 17:23:41 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 15 May 2023 17:23:41 GMT
Subject: [lilliput-jdk17u:lilliput] Integrated: Merge jdk17u:jdk-17.0.8+2
In-Reply-To: <UKFAcuO796RTBio2fnQ6GYRPXG829jd5HPBr1cxCUpA=.f7b2f195-ddf1-44ef-ab53-839a13395622@github.com>
References: <UKFAcuO796RTBio2fnQ6GYRPXG829jd5HPBr1cxCUpA=.f7b2f195-ddf1-44ef-ab53-839a13395622@github.com>
Message-ID: <ZGpT_8Bdi_YKi8pzrQQrarrBbipJT9A8Ovxduj7w4wg=.3f7b8f40-b296-45b8-b490-c0cb9bd3bb63@github.com>

On Fri, 12 May 2023 16:12:30 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Let's merge tag jdk-17.0.8+2. Merge was clean.
> 
> Testing:
>  - [ ] tier1
>  - [ ] tier2
>  - [ ] tier3

This pull request has now been integrated.

Changeset: ded5c311
Author:    Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.org/lilliput-jdk17u/commit/ded5c31174596a550458155609896607c17b6043
Stats:     53612 lines in 887 files changed: 34223 ins; 12287 del; 7102 mod

Merge

Reviewed-by: shade

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

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

From rkennke at openjdk.org  Tue May 16 11:04:24 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 16 May 2023 11:04:24 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8308172: [Lilliput/JDK17] Revert
 disabling vzeroupper
Message-ID: <rDUCbqfOT-lTIOOT30uiE2oPTTX3NZIXnGTAzXFsuQs=.43ca0433-c6b1-4049-897e-3b71d116abbb@github.com>

While looking through the diff between Lilliput/JDK17 and upstream JDK17, I noticed one change in library_call.cpp that should not be there, it probably slipped through from debugging.

        void clear_upper_avx() {
      #ifdef X86
    -     if (UseAVX >= 2) {
    +     if (false && UseAVX >= 2) {
            C->set_clear_upper_avx(true);
          }
      #endif
        }
 
This prevents emitting vzeroupper instructions on x86_64. I believe this will have performance impact when transitioning between AVX and SSE code. We should revert this.

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

Commit messages:
 - 8308172: [Lilliput/JDK17] Revert disabling vzeroupper

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

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

From shade at openjdk.org  Tue May 16 11:50:11 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 16 May 2023 11:50:11 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8308172: [Lilliput/JDK17] Revert
 disabling vzeroupper
In-Reply-To: <rDUCbqfOT-lTIOOT30uiE2oPTTX3NZIXnGTAzXFsuQs=.43ca0433-c6b1-4049-897e-3b71d116abbb@github.com>
References: <rDUCbqfOT-lTIOOT30uiE2oPTTX3NZIXnGTAzXFsuQs=.43ca0433-c6b1-4049-897e-3b71d116abbb@github.com>
Message-ID: <xS5f1sFyRQPKh4zk1bIzp7YFlpbmUuCK8yai3bUcDBU=.e574c82a-0660-4410-9ed6-1d2f4ba2be27@github.com>

On Tue, 16 May 2023 10:57:52 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> While looking through the diff between Lilliput/JDK17 and upstream JDK17, I noticed one change in library_call.cpp that should not be there, it probably slipped through from debugging.
> 
>         void clear_upper_avx() {
>       #ifdef X86
>     -     if (UseAVX >= 2) {
>     +     if (false && UseAVX >= 2) {
>             C->set_clear_upper_avx(true);
>           }
>       #endif
>         }
>  
> This prevents emitting vzeroupper instructions on x86_64. I believe this will have performance impact when transitioning between AVX and SSE code. We should revert this.

Looks fine

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/lilliput-jdk17u/pull/18#pullrequestreview-1428390413

From rkennke at openjdk.org  Tue May 16 12:00:15 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 16 May 2023 12:00:15 GMT
Subject: [lilliput-jdk17u:lilliput] Integrated: 8308172: [Lilliput/JDK17]
 Revert disabling vzeroupper
In-Reply-To: <rDUCbqfOT-lTIOOT30uiE2oPTTX3NZIXnGTAzXFsuQs=.43ca0433-c6b1-4049-897e-3b71d116abbb@github.com>
References: <rDUCbqfOT-lTIOOT30uiE2oPTTX3NZIXnGTAzXFsuQs=.43ca0433-c6b1-4049-897e-3b71d116abbb@github.com>
Message-ID: <yuk8EmlvohLX74O7KgZlqtL_b0PsduhW0iWrZdK8Ia8=.b0888d4a-24d5-44f7-a432-6f27ebb6bad4@github.com>

On Tue, 16 May 2023 10:57:52 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> While looking through the diff between Lilliput/JDK17 and upstream JDK17, I noticed one change in library_call.cpp that should not be there, it probably slipped through from debugging.
> 
>         void clear_upper_avx() {
>       #ifdef X86
>     -     if (UseAVX >= 2) {
>     +     if (false && UseAVX >= 2) {
>             C->set_clear_upper_avx(true);
>           }
>       #endif
>         }
>  
> This prevents emitting vzeroupper instructions on x86_64. I believe this will have performance impact when transitioning between AVX and SSE code. We should revert this.

This pull request has now been integrated.

Changeset: a7a8efbd
Author:    Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.org/lilliput-jdk17u/commit/a7a8efbdaa7daad48ae2a04eaf44fb70d27f8baf
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8308172: [Lilliput/JDK17] Revert disabling vzeroupper

Reviewed-by: shade

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

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

From rkennke at openjdk.org  Wed May 17 13:06:44 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 17 May 2023 13:06:44 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8308107: [Lilliput/JDK17] Cherry-pick:
 8291555: Implement alternative fast-locking scheme
Message-ID: <BPCHDR5ADzJPXOuUak9z5_7Pv25CRW4lhsoB7_gDUdg=.4c022b3d-b6f6-4879-be49-61c4e4aeb541@github.com>

This brings "8291555: Implement alternative fast-locking scheme" into lilliput/jdk17. Lots of small improvements, most importantly the fixed-size lock-stack, plus tons of testing and reviews that went into the upstream change that went into JDK21.

Testing:
 - [x] tier1 (x86, x86_64, aarch64)
 - [x] tier2 (x86, x86_64, aarch64)

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

Commit messages:
 - Some stray changes from the upstream PR
 - x86 parts
 - 8308107: [Lilliput/JDK17] Cherry-pick: 8291555: Implement alternative fast-locking scheme

Changes: https://git.openjdk.org/lilliput-jdk17u/pull/19/files
 Webrev: https://webrevs.openjdk.org/?repo=lilliput-jdk17u&pr=19&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308107
  Stats: 1318 lines in 67 files changed: 537 ins; 370 del; 411 mod
  Patch: https://git.openjdk.org/lilliput-jdk17u/pull/19.diff
  Fetch: git fetch https://git.openjdk.org/lilliput-jdk17u.git pull/19/head:pull/19

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

From rkennke at openjdk.org  Wed May 17 14:19:27 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 17 May 2023 14:19:27 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8308107: [Lilliput/JDK17]
 Cherry-pick: 8291555: Implement alternative fast-locking scheme [v2]
In-Reply-To: <BPCHDR5ADzJPXOuUak9z5_7Pv25CRW4lhsoB7_gDUdg=.4c022b3d-b6f6-4879-be49-61c4e4aeb541@github.com>
References: <BPCHDR5ADzJPXOuUak9z5_7Pv25CRW4lhsoB7_gDUdg=.4c022b3d-b6f6-4879-be49-61c4e4aeb541@github.com>
Message-ID: <Hr-XEAMo_VdpbGnf0ZmfIu9FSw6mA4_APzIE6o1TASU=.a0f718de-7d74-4e52-9e57-8c5730361e3d@github.com>

> This brings "8291555: Implement alternative fast-locking scheme" into lilliput/jdk17. Lots of small improvements, most importantly the fixed-size lock-stack, plus tons of testing and reviews that went into the upstream change that went into JDK21.
> 
> Testing:
>  - [x] tier1 (x86, x86_64, aarch64)
>  - [x] tier2 (x86, x86_64, aarch64)

Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:

 - 32bit build fix
 - Replace some nullptr with NULL

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

Changes:
  - all: https://git.openjdk.org/lilliput-jdk17u/pull/19/files
  - new: https://git.openjdk.org/lilliput-jdk17u/pull/19/files/e83f37f6..19c27f12

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

  Stats: 29 lines in 6 files changed: 0 ins; 17 del; 12 mod
  Patch: https://git.openjdk.org/lilliput-jdk17u/pull/19.diff
  Fetch: git fetch https://git.openjdk.org/lilliput-jdk17u.git pull/19/head:pull/19

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

From rkennke at openjdk.org  Wed May 17 16:35:50 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 17 May 2023 16:35:50 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8308296: [Lilliput/JDK17] Cherry-pick:
 8275415: Prepare Leak Profiler for Lilliput
Message-ID: <rsnJgEw0SqG-TFJQSozpqJ20q34mxQL_IaL6juCetVQ=.e18522b7-1c91-43cc-abc0-adbc7399129e@github.com>

We should cherry-pick [JDK-8275415](https://bugs.openjdk.org/browse/JDK-8275415) into Lilliput/JDK17, otherwise running leak-profiler with Lilliput would crash.

The original change applies cleanly on top of lilliput/jdk17u.

Testing:
 - [x] tier1
 - [x] jdk/jfr

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

Commit messages:
 - 8308296: [Lilliput/JDK17] Cherry-pick: 8275415: Prepare Leak Profiler for Lilliput

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

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

From rkennke at openjdk.org  Wed May 17 16:40:04 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 17 May 2023 16:40:04 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8308107: [Lilliput/JDK17]
 Cherry-pick: 8291555: Implement alternative fast-locking scheme [v3]
In-Reply-To: <BPCHDR5ADzJPXOuUak9z5_7Pv25CRW4lhsoB7_gDUdg=.4c022b3d-b6f6-4879-be49-61c4e4aeb541@github.com>
References: <BPCHDR5ADzJPXOuUak9z5_7Pv25CRW4lhsoB7_gDUdg=.4c022b3d-b6f6-4879-be49-61c4e4aeb541@github.com>
Message-ID: <64fld41PkvX5dmBsr1tEggnOzWGE1OTFKtcFe-e3MNs=.2db9af9a-b9a8-4e6e-9065-1c49f6f641f4@github.com>

> This brings "8291555: Implement alternative fast-locking scheme" into lilliput/jdk17. Lots of small improvements, most importantly the fixed-size lock-stack, plus tons of testing and reviews that went into the upstream change that went into JDK21.
> 
> Testing:
>  - [x] tier1 (x86, x86_64, aarch64)
>  - [x] tier2 (x86, x86_64, aarch64)

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

  Don't restrict Klass prototype headers to Lilliput, b/c biased-locking

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

Changes:
  - all: https://git.openjdk.org/lilliput-jdk17u/pull/19/files
  - new: https://git.openjdk.org/lilliput-jdk17u/pull/19/files/19c27f12..1ff93cdb

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

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

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

From rkennke at openjdk.org  Fri May 19 13:21:28 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 19 May 2023 13:21:28 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8308411: [Lilliput/JDK17] Cherry-pick:
 8283710: JVMTI: Use BitSet for object marking
Message-ID: <rwJFFALZc7kuYyIzybEZggPTcoXDJKhy5YG_eZUUxdU=.21553ab9-34f3-4534-aa3e-0051a8f98768@github.com>

This ports the original https://github.com/openjdk/jdk/pull/7964 to Lilliput/JDK17. It also includes the follow-up (cosmetic) fixes https://bugs.openjdk.org/browse/JDK-8284687 and https://bugs.openjdk.org/browse/JDK-8284725.

Testing:
 - [x] tier1
 - [x] serviceability/jvmti
 - [x] vmTestbase/nsk/jvmti

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

Commit messages:
 - Some follow-ups
 - 8283710: JVMTI: Use BitSet for object marking
 - 8283710: JVMTI: Use BitSet for object marking
 - Revert

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

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

From rkennke at openjdk.org  Fri May 19 21:05:45 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 19 May 2023 21:05:45 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8308423: [Lilliput/JDK17] Cherry-pick
 GC forwarding
Message-ID: <nq_qvvpMPZr-kzXZnQqYWc7atWLSePpUXsqpYAKnx-s=.31bd0210-cce8-4a7f-b7b3-1db657fca8c4@github.com>

I'd like to pick up the improvements that have been made in full-GC and self-forwarding in the upstream issues [JDK-8305896](https://bugs.openjdk.org/browse/JDK-8305896) and [JDK-8305898](https://bugs.openjdk.org/browse/JDK-8305898). Let's port them to Lilliput/JDK17.

The version in upstream PR uses resourceHash.hpp as fallback-table. Unfortunately, that doesn't cleanly work with the JDK17 version of resourceHash.hpp, so I used an earlier version with a self-implemented fallback-table.

Testing:
 - [x] hotspot_gc
 - [x] tier1
 - [ ] tier2

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

Commit messages:
 - 8308423: [Lilliput/JDK17] Cherry-pick GC forwarding

Changes: https://git.openjdk.org/lilliput-jdk17u/pull/22/files
 Webrev: https://webrevs.openjdk.org/?repo=lilliput-jdk17u&pr=22&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308423
  Stats: 847 lines in 40 files changed: 491 ins; 132 del; 224 mod
  Patch: https://git.openjdk.org/lilliput-jdk17u/pull/22.diff
  Fetch: git fetch https://git.openjdk.org/lilliput-jdk17u.git pull/22/head:pull/22

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

From shade at openjdk.org  Mon May 22 11:27:19 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 22 May 2023 11:27:19 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8308107: [Lilliput/JDK17]
 Cherry-pick: 8291555: Implement alternative fast-locking scheme [v3]
In-Reply-To: <64fld41PkvX5dmBsr1tEggnOzWGE1OTFKtcFe-e3MNs=.2db9af9a-b9a8-4e6e-9065-1c49f6f641f4@github.com>
References: <BPCHDR5ADzJPXOuUak9z5_7Pv25CRW4lhsoB7_gDUdg=.4c022b3d-b6f6-4879-be49-61c4e4aeb541@github.com>
 <64fld41PkvX5dmBsr1tEggnOzWGE1OTFKtcFe-e3MNs=.2db9af9a-b9a8-4e6e-9065-1c49f6f641f4@github.com>
Message-ID: <GmsZKZRJk0Kx3QTrCpb0tpQo_2h3csJXDBh7qbuNI1A=.adf5202e-a33e-44be-be46-40de38775f57@github.com>

On Wed, 17 May 2023 16:40:04 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This brings "8291555: Implement alternative fast-locking scheme" into lilliput/jdk17. Lots of small improvements, most importantly the fixed-size lock-stack, plus tons of testing and reviews that went into the upstream change that went into JDK21.
>> 
>> Testing:
>>  - [x] tier1 (x86, x86_64, aarch64)
>>  - [x] tier2 (x86, x86_64, aarch64)
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Don't restrict Klass prototype headers to Lilliput, b/c biased-locking

Looks okay, with minor nits. We also need to comb through the upstream diff after this integrates to catch anything we accidentally change in upstream.

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 518:

> 516:   movptr(tmpReg, Address(objReg, oopDesc::mark_offset_in_bytes()));          // [FETCH]
> 517:   testptr(tmpReg, markWord::monitor_value); // inflated vs stack-locked|neutral|biased
> 518:   jccb(Assembler::notZero, IsInflated);

Upstream patch does `jccb` -> `jcc` here:
https://github.com/openjdk/jdk/commit/7f6358a8b53a35a87c9413c68f8fe6c5fdec0caf#diff-318d0e76b9a97e8cf8936be1de34e52735c4d947a77cac38babbbf9a081d16fcR602

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 711:

> 709:   if (LockingMode == LM_LIGHTWEIGHT) {
> 710:     // If the owner is ANONYMOUS, we need to fix it.
> 711:     testb(Address(tmpReg, OM_OFFSET_NO_MONITOR_VALUE_TAG(owner)), (int) (intptr_t) ObjectMonitor::ANONYMOUS_OWNER);

Want to do `(int32_t) ObjectMonitor::ANONYMOUS_OWNER)` here, like in upstream? 
https://github.com/openjdk/jdk/commit/7f6358a8b53a35a87c9413c68f8fe6c5fdec0caf#diff-318d0e76b9a97e8cf8936be1de34e52735c4d947a77cac38babbbf9a081d16fcR788

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 724:

> 722:       // Call the slow-path instead.
> 723:       jcc(Assembler::notEqual, DONE_LABEL);
> 724:     }

(Cannot comment on unaffected code, commenting on the nearest hunk)

Upstream does `jmpb` -> `jmp`  in the RTM block below: https://github.com/openjdk/jdk/commit/7f6358a8b53a35a87c9413c68f8fe6c5fdec0caf#diff-318d0e76b9a97e8cf8936be1de34e52735c4d947a77cac38babbbf9a081d16fcR812

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 770:

> 768:   movptr(boxReg, Address(tmpReg, OM_OFFSET_NO_MONITOR_VALUE_TAG(EntryList)));
> 769:   orptr(boxReg, Address(tmpReg, OM_OFFSET_NO_MONITOR_VALUE_TAG(cxq)));
> 770:   jccb  (Assembler::notZero, DONE_LABEL);

Why this change?

src/hotspot/share/oops/klass.hpp line 655:

> 653:   // prototype markWord. If biased locking is enabled it may further be
> 654:   // biasable and have an epoch.
> 655:   markWord prototype_header() const      { return _prototype_header; }

Why this change? This does not relate to fast-locking scheme?

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

PR Review: https://git.openjdk.org/lilliput-jdk17u/pull/19#pullrequestreview-1436292822
PR Review Comment: https://git.openjdk.org/lilliput-jdk17u/pull/19#discussion_r1200305025
PR Review Comment: https://git.openjdk.org/lilliput-jdk17u/pull/19#discussion_r1200310451
PR Review Comment: https://git.openjdk.org/lilliput-jdk17u/pull/19#discussion_r1200312869
PR Review Comment: https://git.openjdk.org/lilliput-jdk17u/pull/19#discussion_r1200315155
PR Review Comment: https://git.openjdk.org/lilliput-jdk17u/pull/19#discussion_r1200328718

From shade at openjdk.org  Mon May 22 11:31:22 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 22 May 2023 11:31:22 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8308107: [Lilliput/JDK17]
 Cherry-pick: 8291555: Implement alternative fast-locking scheme [v3]
In-Reply-To: <64fld41PkvX5dmBsr1tEggnOzWGE1OTFKtcFe-e3MNs=.2db9af9a-b9a8-4e6e-9065-1c49f6f641f4@github.com>
References: <BPCHDR5ADzJPXOuUak9z5_7Pv25CRW4lhsoB7_gDUdg=.4c022b3d-b6f6-4879-be49-61c4e4aeb541@github.com>
 <64fld41PkvX5dmBsr1tEggnOzWGE1OTFKtcFe-e3MNs=.2db9af9a-b9a8-4e6e-9065-1c49f6f641f4@github.com>
Message-ID: <4afCeijpwAlHxsKIPwaBSOyRwJ7lqzcjnVH1H-Snmi4=.421f2485-c169-42ba-8901-8d8751cd6b6b@github.com>

On Wed, 17 May 2023 16:40:04 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This brings "8291555: Implement alternative fast-locking scheme" into lilliput/jdk17. Lots of small improvements, most importantly the fixed-size lock-stack, plus tons of testing and reviews that went into the upstream change that went into JDK21.
>> 
>> Testing:
>>  - [x] tier1 (x86, x86_64, aarch64)
>>  - [x] tier2 (x86, x86_64, aarch64)
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Don't restrict Klass prototype headers to Lilliput, b/c biased-locking

Also cross-compiled builds are failing -- I think some point to the actual problems.

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

PR Comment: https://git.openjdk.org/lilliput-jdk17u/pull/19#issuecomment-1557050438

From shade at openjdk.org  Mon May 22 11:48:17 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 22 May 2023 11:48:17 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8308423: [Lilliput/JDK17]
 Cherry-pick GC forwarding
In-Reply-To: <nq_qvvpMPZr-kzXZnQqYWc7atWLSePpUXsqpYAKnx-s=.31bd0210-cce8-4a7f-b7b3-1db657fca8c4@github.com>
References: <nq_qvvpMPZr-kzXZnQqYWc7atWLSePpUXsqpYAKnx-s=.31bd0210-cce8-4a7f-b7b3-1db657fca8c4@github.com>
Message-ID: <WEXY4FlwFggp0FyMl3jw5utdYhf_0i_20GANj7QwDxw=.43732c72-b9d8-40ab-9381-e647c7ad49f7@github.com>

On Fri, 19 May 2023 20:58:47 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> I'd like to pick up the improvements that have been made in full-GC and self-forwarding in the upstream issues [JDK-8305896](https://bugs.openjdk.org/browse/JDK-8305896) and [JDK-8305898](https://bugs.openjdk.org/browse/JDK-8305898). Let's port them to Lilliput/JDK17.
> 
> The version in upstream PR uses resourceHash.hpp as fallback-table. Unfortunately, that doesn't cleanly work with the JDK17 version of resourceHash.hpp, so I used an earlier version with a self-implemented fallback-table.
> 
> Testing:
>  - [x] hotspot_gc
>  - [x] tier1
>  - [ ] tier2

Apart from the trivial `fastHash.hpp` include that breaks lots of GHA builds, seems fine.
Are you sure you have tested this PR, given how it should not even compile?

Rescinding review until testing situation is clear.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/lilliput-jdk17u/pull/22#pullrequestreview-1436445335
PR Review: https://git.openjdk.org/lilliput-jdk17u/pull/22#pullrequestreview-1436447600

From rkennke at openjdk.org  Mon May 22 17:43:23 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 22 May 2023 17:43:23 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8308107: [Lilliput/JDK17]
 Cherry-pick: 8291555: Implement alternative fast-locking scheme [v3]
In-Reply-To: <GmsZKZRJk0Kx3QTrCpb0tpQo_2h3csJXDBh7qbuNI1A=.adf5202e-a33e-44be-be46-40de38775f57@github.com>
References: <BPCHDR5ADzJPXOuUak9z5_7Pv25CRW4lhsoB7_gDUdg=.4c022b3d-b6f6-4879-be49-61c4e4aeb541@github.com>
 <64fld41PkvX5dmBsr1tEggnOzWGE1OTFKtcFe-e3MNs=.2db9af9a-b9a8-4e6e-9065-1c49f6f641f4@github.com>
 <GmsZKZRJk0Kx3QTrCpb0tpQo_2h3csJXDBh7qbuNI1A=.adf5202e-a33e-44be-be46-40de38775f57@github.com>
Message-ID: <adIA_TKCBqbCdLERHNCDD3ol_IsHDgNoFa9vAoS1d2M=.3120b877-20d5-4fd3-beac-3883a51fc457@github.com>

On Mon, 22 May 2023 10:21:33 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Don't restrict Klass prototype headers to Lilliput, b/c biased-locking
>
> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 724:
> 
>> 722:       // Call the slow-path instead.
>> 723:       jcc(Assembler::notEqual, DONE_LABEL);
>> 724:     }
> 
> (Cannot comment on unaffected code, commenting on the nearest hunk)
> 
> Upstream does `jmpb` -> `jmp`  in the RTM block below: https://github.com/openjdk/jdk/commit/7f6358a8b53a35a87c9413c68f8fe6c5fdec0caf#diff-318d0e76b9a97e8cf8936be1de34e52735c4d947a77cac38babbbf9a081d16fcR812

Yes, but it already is jmp here? So no need to change anything?

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

PR Review Comment: https://git.openjdk.org/lilliput-jdk17u/pull/19#discussion_r1200833571

From rkennke at openjdk.org  Mon May 22 17:55:01 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 22 May 2023 17:55:01 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8308107: [Lilliput/JDK17]
 Cherry-pick: 8291555: Implement alternative fast-locking scheme [v4]
In-Reply-To: <BPCHDR5ADzJPXOuUak9z5_7Pv25CRW4lhsoB7_gDUdg=.4c022b3d-b6f6-4879-be49-61c4e4aeb541@github.com>
References: <BPCHDR5ADzJPXOuUak9z5_7Pv25CRW4lhsoB7_gDUdg=.4c022b3d-b6f6-4879-be49-61c4e4aeb541@github.com>
Message-ID: <gDtG3js5823Hp8d2lkGg49Ucpg4LPSVRHz-NJYOs5yI=.cd43365d-67ea-4cd9-9ed1-4c377a95f925@github.com>

> This brings "8291555: Implement alternative fast-locking scheme" into lilliput/jdk17. Lots of small improvements, most importantly the fixed-size lock-stack, plus tons of testing and reviews that went into the upstream change that went into JDK21.
> 
> Testing:
>  - [x] tier1 (x86, x86_64, aarch64)
>  - [x] tier2 (x86, x86_64, aarch64)

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

  Address @shipilev comments

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

Changes:
  - all: https://git.openjdk.org/lilliput-jdk17u/pull/19/files
  - new: https://git.openjdk.org/lilliput-jdk17u/pull/19/files/1ff93cdb..5edf8e70

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

  Stats: 6 lines in 2 files changed: 3 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/lilliput-jdk17u/pull/19.diff
  Fetch: git fetch https://git.openjdk.org/lilliput-jdk17u.git pull/19/head:pull/19

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

From rkennke at openjdk.org  Mon May 22 17:55:05 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 22 May 2023 17:55:05 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8308107: [Lilliput/JDK17]
 Cherry-pick: 8291555: Implement alternative fast-locking scheme [v3]
In-Reply-To: <4afCeijpwAlHxsKIPwaBSOyRwJ7lqzcjnVH1H-Snmi4=.421f2485-c169-42ba-8901-8d8751cd6b6b@github.com>
References: <BPCHDR5ADzJPXOuUak9z5_7Pv25CRW4lhsoB7_gDUdg=.4c022b3d-b6f6-4879-be49-61c4e4aeb541@github.com>
 <64fld41PkvX5dmBsr1tEggnOzWGE1OTFKtcFe-e3MNs=.2db9af9a-b9a8-4e6e-9065-1c49f6f641f4@github.com>
 <4afCeijpwAlHxsKIPwaBSOyRwJ7lqzcjnVH1H-Snmi4=.421f2485-c169-42ba-8901-8d8751cd6b6b@github.com>
Message-ID: <SDHPc0X3atMfeB1O5rXG7sUwjzaPm_SEdeusotHSbPU=.a34584b7-0488-4012-859e-f60fc756d99c@github.com>

On Mon, 22 May 2023 11:28:31 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Also cross-compiled builds are failing -- I think some point to the actual problems.

Yeah, but none of them relate to changes done in this PR. Should be fixed separately, IMO.

> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 770:
> 
>> 768:   movptr(boxReg, Address(tmpReg, OM_OFFSET_NO_MONITOR_VALUE_TAG(EntryList)));
>> 769:   orptr(boxReg, Address(tmpReg, OM_OFFSET_NO_MONITOR_VALUE_TAG(cxq)));
>> 770:   jccb  (Assembler::notZero, DONE_LABEL);
> 
> Why this change?

Because the code is arranged differently now. If we branched to CheckSucc, we would end up in the stack-locked path, which is incorrect. We really want to branch to DONE. That's also what we do in upstream JDK21 (I believe there has been some cleanup between 17 and 21 that fixed that).

> src/hotspot/share/oops/klass.hpp line 655:
> 
>> 653:   // prototype markWord. If biased locking is enabled it may further be
>> 654:   // biasable and have an epoch.
>> 655:   markWord prototype_header() const      { return _prototype_header; }
> 
> Why this change? This does not relate to fast-locking scheme?

Right. This is a change that should be done in a separate PR. Thing is that in 17 we could call this method if anybody enabled +UseBiasedLocking, and the assert would fail.

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

PR Comment: https://git.openjdk.org/lilliput-jdk17u/pull/19#issuecomment-1557646165
PR Review Comment: https://git.openjdk.org/lilliput-jdk17u/pull/19#discussion_r1200837325
PR Review Comment: https://git.openjdk.org/lilliput-jdk17u/pull/19#discussion_r1200839025

From shade at openjdk.org  Mon May 22 17:55:07 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 22 May 2023 17:55:07 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8308107: [Lilliput/JDK17]
 Cherry-pick: 8291555: Implement alternative fast-locking scheme [v3]
In-Reply-To: <adIA_TKCBqbCdLERHNCDD3ol_IsHDgNoFa9vAoS1d2M=.3120b877-20d5-4fd3-beac-3883a51fc457@github.com>
References: <BPCHDR5ADzJPXOuUak9z5_7Pv25CRW4lhsoB7_gDUdg=.4c022b3d-b6f6-4879-be49-61c4e4aeb541@github.com>
 <64fld41PkvX5dmBsr1tEggnOzWGE1OTFKtcFe-e3MNs=.2db9af9a-b9a8-4e6e-9065-1c49f6f641f4@github.com>
 <GmsZKZRJk0Kx3QTrCpb0tpQo_2h3csJXDBh7qbuNI1A=.adf5202e-a33e-44be-be46-40de38775f57@github.com>
 <adIA_TKCBqbCdLERHNCDD3ol_IsHDgNoFa9vAoS1d2M=.3120b877-20d5-4fd3-beac-3883a51fc457@github.com>
Message-ID: <bh0exikpUM83FxWrQOYRWAagnCyiVnQ3-xzf9aUwQFo=.48daaa59-2f57-449e-82b6-67a7ee08c3d9@github.com>

On Mon, 22 May 2023 17:40:56 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 724:
>> 
>>> 722:       // Call the slow-path instead.
>>> 723:       jcc(Assembler::notEqual, DONE_LABEL);
>>> 724:     }
>> 
>> (Cannot comment on unaffected code, commenting on the nearest hunk)
>> 
>> Upstream does `jmpb` -> `jmp`  in the RTM block below: https://github.com/openjdk/jdk/commit/7f6358a8b53a35a87c9413c68f8fe6c5fdec0caf#diff-318d0e76b9a97e8cf8936be1de34e52735c4d947a77cac38babbbf9a081d16fcR812
>
> Yes, but it already is jmp here? So no need to change anything?

Right, nevermind.

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

PR Review Comment: https://git.openjdk.org/lilliput-jdk17u/pull/19#discussion_r1200839400

From shade at openjdk.org  Mon May 22 17:58:18 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 22 May 2023 17:58:18 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8308107: [Lilliput/JDK17]
 Cherry-pick: 8291555: Implement alternative fast-locking scheme [v3]
In-Reply-To: <SDHPc0X3atMfeB1O5rXG7sUwjzaPm_SEdeusotHSbPU=.a34584b7-0488-4012-859e-f60fc756d99c@github.com>
References: <BPCHDR5ADzJPXOuUak9z5_7Pv25CRW4lhsoB7_gDUdg=.4c022b3d-b6f6-4879-be49-61c4e4aeb541@github.com>
 <64fld41PkvX5dmBsr1tEggnOzWGE1OTFKtcFe-e3MNs=.2db9af9a-b9a8-4e6e-9065-1c49f6f641f4@github.com>
 <4afCeijpwAlHxsKIPwaBSOyRwJ7lqzcjnVH1H-Snmi4=.421f2485-c169-42ba-8901-8d8751cd6b6b@github.com>
 <SDHPc0X3atMfeB1O5rXG7sUwjzaPm_SEdeusotHSbPU=.a34584b7-0488-4012-859e-f60fc756d99c@github.com>
Message-ID: <n4RAxdhcq5FNnH8xpd7aDlEBTw5Y_Z6VA_BsgE5xmE0=.9591e43d-1dff-4921-b727-1508429bd482@github.com>

On Mon, 22 May 2023 17:49:31 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Yeah, but none of them relate to changes done in this PR. Should be fixed separately, IMO.

Agreed.

>> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 770:
>> 
>>> 768:   movptr(boxReg, Address(tmpReg, OM_OFFSET_NO_MONITOR_VALUE_TAG(EntryList)));
>>> 769:   orptr(boxReg, Address(tmpReg, OM_OFFSET_NO_MONITOR_VALUE_TAG(cxq)));
>>> 770:   jccb  (Assembler::notZero, DONE_LABEL);
>> 
>> Why this change?
>
> Because the code is arranged differently now. If we branched to CheckSucc, we would end up in the stack-locked path, which is incorrect. We really want to branch to DONE. That's also what we do in upstream JDK21 (I believe there has been some cleanup between 17 and 21 that fixed that).

OK, so pessimistically if this is still a bug, we "just" enter the slow-path, right? If so, this looks acceptable.

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

PR Comment: https://git.openjdk.org/lilliput-jdk17u/pull/19#issuecomment-1557652183
PR Review Comment: https://git.openjdk.org/lilliput-jdk17u/pull/19#discussion_r1200844347

From shade at openjdk.org  Mon May 22 18:18:25 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 22 May 2023 18:18:25 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8308107: [Lilliput/JDK17]
 Cherry-pick: 8291555: Implement alternative fast-locking scheme [v4]
In-Reply-To: <gDtG3js5823Hp8d2lkGg49Ucpg4LPSVRHz-NJYOs5yI=.cd43365d-67ea-4cd9-9ed1-4c377a95f925@github.com>
References: <BPCHDR5ADzJPXOuUak9z5_7Pv25CRW4lhsoB7_gDUdg=.4c022b3d-b6f6-4879-be49-61c4e4aeb541@github.com>
 <gDtG3js5823Hp8d2lkGg49Ucpg4LPSVRHz-NJYOs5yI=.cd43365d-67ea-4cd9-9ed1-4c377a95f925@github.com>
Message-ID: <OQ4QhVKwfa3WKtDifi9joGQmwNqYn4gH89jPYj6kC08=.29bfb989-26c5-430d-a66e-602f03d86dd5@github.com>

On Mon, 22 May 2023 17:55:01 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This brings "8291555: Implement alternative fast-locking scheme" into lilliput/jdk17. Lots of small improvements, most importantly the fixed-size lock-stack, plus tons of testing and reviews that went into the upstream change that went into JDK21.
>> 
>> Testing:
>>  - [x] tier1 (x86, x86_64, aarch64)
>>  - [x] tier2 (x86, x86_64, aarch64)
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address @shipilev comments

Marked as reviewed by shade (Reviewer).

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

PR Review: https://git.openjdk.org/lilliput-jdk17u/pull/19#pullrequestreview-1437191901

From rkennke at openjdk.org  Tue May 23 15:26:42 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 23 May 2023 15:26:42 GMT
Subject: [lilliput-jdk17u:lilliput] Integrated: 8308107: [Lilliput/JDK17]
 Cherry-pick: 8291555: Implement alternative fast-locking scheme
In-Reply-To: <BPCHDR5ADzJPXOuUak9z5_7Pv25CRW4lhsoB7_gDUdg=.4c022b3d-b6f6-4879-be49-61c4e4aeb541@github.com>
References: <BPCHDR5ADzJPXOuUak9z5_7Pv25CRW4lhsoB7_gDUdg=.4c022b3d-b6f6-4879-be49-61c4e4aeb541@github.com>
Message-ID: <TGGhXFIMuOWs8Jyy57VvnutnHLky8zdyj4p36_yejko=.a63140e0-2ba6-4cb1-b0d2-185746980fa3@github.com>

On Tue, 16 May 2023 14:27:01 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> This brings "8291555: Implement alternative fast-locking scheme" into lilliput/jdk17. Lots of small improvements, most importantly the fixed-size lock-stack, plus tons of testing and reviews that went into the upstream change that went into JDK21.
> 
> Testing:
>  - [x] tier1 (x86, x86_64, aarch64)
>  - [x] tier2 (x86, x86_64, aarch64)

This pull request has now been integrated.

Changeset: dc437555
Author:    Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.org/lilliput-jdk17u/commit/dc437555b0568a91bb47c983ef1b35019b53a5b6
Stats:     1319 lines in 67 files changed: 535 ins; 385 del; 399 mod

8308107: [Lilliput/JDK17] Cherry-pick: 8291555: Implement alternative fast-locking scheme

Reviewed-by: shade

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

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

From rkennke at openjdk.org  Tue May 23 15:27:24 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 23 May 2023 15:27:24 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8308647: [Lilliput/JDK17] Fix
 cross-builds
Message-ID: <-9k0oxFmSMyBPpsfHtxH7jSRACf-6xarWiylxNiSs-8=.308ddab3-cf31-4b37-a0f7-61fa29bd66c2@github.com>

Some arches still require arrayOopDesc::header_size(BasicType) that we removed because it returns word-sized header-size, in favour of similar methods that return byte-sized header-size. Let's re-instate this old method to make cross-builds happy.

It also reduces the upstream diff. Let's see what the GHA of cross-builds say.

Testing:
 - [ ] GHA
 - [ ] build

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

Commit messages:
 - Add assert
 - 8308647: [Lilliput/JDK17] Fix cross-builds

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

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

From shade at openjdk.org  Tue May 23 15:27:41 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 23 May 2023 15:27:41 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8308647: [Lilliput/JDK17] Fix
 cross-builds
In-Reply-To: <-9k0oxFmSMyBPpsfHtxH7jSRACf-6xarWiylxNiSs-8=.308ddab3-cf31-4b37-a0f7-61fa29bd66c2@github.com>
References: <-9k0oxFmSMyBPpsfHtxH7jSRACf-6xarWiylxNiSs-8=.308ddab3-cf31-4b37-a0f7-61fa29bd66c2@github.com>
Message-ID: <IA74WuR8QMNfxODppAN89bo-O3Cvzb8Nd52kFODEzYs=.674fbde9-6f20-48c7-9e6a-1d44c44fae66@github.com>

On Tue, 23 May 2023 11:53:27 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Some arches still require arrayOopDesc::header_size(BasicType) that we removed because it returns word-sized header-size, in favour of similar methods that return byte-sized header-size. Let's re-instate this old method to make cross-builds happy.
> 
> It also reduces the upstream diff. Let's see what the GHA of cross-builds say.
> 
> Testing:
>  - [ ] GHA
>  - [ ] build

src/hotspot/share/oops/arrayOop.hpp line 136:

> 134:   // array object type.
> 135:   static int header_size(BasicType type) {
> 136:     size_t typesize_in_bytes = header_size_in_bytes();

`assert(!UseCompactObjectHeaders)` there, maybe?

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

PR Review Comment: https://git.openjdk.org/lilliput-jdk17u/pull/24#discussion_r1202170005

From rkennke at openjdk.org  Tue May 23 15:27:47 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 23 May 2023 15:27:47 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8308651: [Lilliput/JDK17] Cherry-pick
 PPC parts of 8297036: Generalize C2 stub mechanism
Message-ID: <ac0vQA3J6K2SKWzUAl0uzPvlT-gz6CqoBUfwacqGrPs=.a9a1be86-7818-447a-883f-55210443e05e@github.com>

We already have back-ported the majority of 8297036: Generalize C2 stub mechanism, but are missing the PPC parts. Backporting those parts will fix PPC builds.

Testing:
 - [ ] GHA PPC

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

Commit messages:
 - 8308651: [Lilliput/JDK17] Cherry-pick PPC parts of 8297036: Generalize C2 stub mechanism

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

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

From shade at openjdk.org  Tue May 23 15:27:45 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 23 May 2023 15:27:45 GMT
Subject: [lilliput-jdk17u:lilliput] Integrated: 8308641: [Lilliput/JDK17]
 Remove wrong assert in klass.hpp
In-Reply-To: <8g-N-L8aqF3Ztpri3nI95g-DexSN5l119-_j9qUb1uA=.95537e66-e427-422b-9ec1-8c008e7a7576@github.com>
References: <8g-N-L8aqF3Ztpri3nI95g-DexSN5l119-_j9qUb1uA=.95537e66-e427-422b-9ec1-8c008e7a7576@github.com>
Message-ID: <sL0J8nj6NTSTIUSjSQGOKx5vU4KrbdEpnhakQLknQFA=.a3bfbff0-d6b1-4663-8086-3e7d132a21f8@github.com>

On Tue, 23 May 2023 11:21:16 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> In klass.hpp, Klass::prototype_header() we have an assert(UseCompactObjectHeaders) which came from the similar upstream jdk21 change, but is wrong in jdk17, because the prototype_header() will also be used when biased locking is used. Biased locking is disabled by default, and the assert is harmless in release builds, but it makes a bunch of tests fail. Let's remove the assert and reduce upstream-jdk17u diff a little bit.
> 
> Testing:
>  - [x] tier1 on x86, where some tests failed before

Marked as reviewed by shade (Reviewer).

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

PR Review: https://git.openjdk.org/lilliput-jdk17u/pull/23#pullrequestreview-1439432486

From shade at openjdk.org  Tue May 23 15:27:52 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 23 May 2023 15:27:52 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8308651: [Lilliput/JDK17]
 Cherry-pick PPC parts of 8297036: Generalize C2 stub mechanism
In-Reply-To: <ac0vQA3J6K2SKWzUAl0uzPvlT-gz6CqoBUfwacqGrPs=.a9a1be86-7818-447a-883f-55210443e05e@github.com>
References: <ac0vQA3J6K2SKWzUAl0uzPvlT-gz6CqoBUfwacqGrPs=.a9a1be86-7818-447a-883f-55210443e05e@github.com>
Message-ID: <OAtk-QfLqzxWAOWrZupHipWdCrj6OWz7TbssALCTN18=.5e2e0267-cad9-419d-9c87-92e187dd8f62@github.com>

On Tue, 23 May 2023 12:16:10 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> We already have back-ported the majority of 8297036: Generalize C2 stub mechanism, but are missing the PPC parts. Backporting those parts will fix PPC builds.
> 
> Testing:
>  - [ ] GHA PPC

Looks okay.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/lilliput-jdk17u/pull/25#pullrequestreview-1439627226

From rkennke at openjdk.org  Tue May 23 15:27:39 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 23 May 2023 15:27:39 GMT
Subject: [lilliput-jdk17u:lilliput] Integrated: 8308641: [Lilliput/JDK17]
 Remove wrong assert in klass.hpp
Message-ID: <8g-N-L8aqF3Ztpri3nI95g-DexSN5l119-_j9qUb1uA=.95537e66-e427-422b-9ec1-8c008e7a7576@github.com>

In klass.hpp, Klass::prototype_header() we have an assert(UseCompactObjectHeaders) which came from the similar upstream jdk21 change, but is wrong in jdk17, because the prototype_header() will also be used when biased locking is used. Biased locking is disabled by default, and the assert is harmless in release builds, but it makes a bunch of tests fail. Let's remove the assert and reduce upstream-jdk17u diff a little bit.

Testing:
 - [x] tier1 on x86, where some tests failed before

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

Commit messages:
 - 8308641: [Lilliput/JDK17] Remove wrong assert in klass.hpp

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

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

From rkennke at openjdk.org  Tue May 23 15:27:50 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 23 May 2023 15:27:50 GMT
Subject: [lilliput-jdk17u:lilliput] Integrated: 8308641: [Lilliput/JDK17]
 Remove wrong assert in klass.hpp
In-Reply-To: <8g-N-L8aqF3Ztpri3nI95g-DexSN5l119-_j9qUb1uA=.95537e66-e427-422b-9ec1-8c008e7a7576@github.com>
References: <8g-N-L8aqF3Ztpri3nI95g-DexSN5l119-_j9qUb1uA=.95537e66-e427-422b-9ec1-8c008e7a7576@github.com>
Message-ID: <GqMSBerDFj-j2ktbtH5oCMbigblhzPq5LVEYPkbNqMg=.d778df78-f95b-42a3-9a89-8919b8eea794@github.com>

On Tue, 23 May 2023 11:21:16 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> In klass.hpp, Klass::prototype_header() we have an assert(UseCompactObjectHeaders) which came from the similar upstream jdk21 change, but is wrong in jdk17, because the prototype_header() will also be used when biased locking is used. Biased locking is disabled by default, and the assert is harmless in release builds, but it makes a bunch of tests fail. Let's remove the assert and reduce upstream-jdk17u diff a little bit.
> 
> Testing:
>  - [x] tier1 on x86, where some tests failed before

This pull request has now been integrated.

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

8308641: [Lilliput/JDK17] Remove wrong assert in klass.hpp

Reviewed-by: shade

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

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

From rkennke at openjdk.org  Tue May 23 15:29:11 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 23 May 2023 15:29:11 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8308423: [Lilliput/JDK17]
 Cherry-pick GC forwarding [v2]
In-Reply-To: <nq_qvvpMPZr-kzXZnQqYWc7atWLSePpUXsqpYAKnx-s=.31bd0210-cce8-4a7f-b7b3-1db657fca8c4@github.com>
References: <nq_qvvpMPZr-kzXZnQqYWc7atWLSePpUXsqpYAKnx-s=.31bd0210-cce8-4a7f-b7b3-1db657fca8c4@github.com>
Message-ID: <RfsYOiyk3hjloGUEopiw39II8jCkCe35SA3Z-7WJcnU=.85dfb4c9-2ce7-4fc5-b88f-6e89f8bca8bf@github.com>

> I'd like to pick up the improvements that have been made in full-GC and self-forwarding in the upstream issues [JDK-8305896](https://bugs.openjdk.org/browse/JDK-8305896) and [JDK-8305898](https://bugs.openjdk.org/browse/JDK-8305898). Let's port them to Lilliput/JDK17.
> 
> The version in upstream PR uses resourceHash.hpp as fallback-table. Unfortunately, that doesn't cleanly work with the JDK17 version of resourceHash.hpp, so I used an earlier version with a self-implemented fallback-table.
> 
> Testing:
>  - [x] hotspot_gc
>  - [x] tier1
>  - [ ] tier2

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

  Add missing fastHash.hpp

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

Changes:
  - all: https://git.openjdk.org/lilliput-jdk17u/pull/22/files
  - new: https://git.openjdk.org/lilliput-jdk17u/pull/22/files/07fb68f6..d9236ac5

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

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

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

From rkennke at openjdk.org  Tue May 23 16:31:07 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 23 May 2023 16:31:07 GMT
Subject: [lilliput-jdk17u:lilliput] Integrated: 8308651: [Lilliput/JDK17]
 Cherry-pick PPC parts of 8297036: Generalize C2 stub mechanism
In-Reply-To: <ac0vQA3J6K2SKWzUAl0uzPvlT-gz6CqoBUfwacqGrPs=.a9a1be86-7818-447a-883f-55210443e05e@github.com>
References: <ac0vQA3J6K2SKWzUAl0uzPvlT-gz6CqoBUfwacqGrPs=.a9a1be86-7818-447a-883f-55210443e05e@github.com>
Message-ID: <ITTXQ8LMfRW74hbbT8-wvyCbOMjt8f0PsyUKxLQXKtM=.853b16b1-4c08-470e-a3a6-d880b7a868ec@github.com>

On Tue, 23 May 2023 12:16:10 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> We already have back-ported the majority of 8297036: Generalize C2 stub mechanism, but are missing the PPC parts. Backporting those parts will fix PPC builds.
> 
> Testing:
>  - [x] GHA PPC

This pull request has now been integrated.

Changeset: 8777411f
Author:    Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.org/lilliput-jdk17u/commit/8777411f2bba855ba93e5a1aba555d2937c5c887
Stats:     121 lines in 3 files changed: 63 ins; 57 del; 1 mod

8308651: [Lilliput/JDK17] Cherry-pick PPC parts of 8297036: Generalize C2 stub mechanism

Reviewed-by: shade

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

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

From rkennke at openjdk.org  Wed May 24 15:49:52 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 24 May 2023 15:49:52 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8308647: [Lilliput/JDK17] Fix
 cross-builds [v2]
In-Reply-To: <-9k0oxFmSMyBPpsfHtxH7jSRACf-6xarWiylxNiSs-8=.308ddab3-cf31-4b37-a0f7-61fa29bd66c2@github.com>
References: <-9k0oxFmSMyBPpsfHtxH7jSRACf-6xarWiylxNiSs-8=.308ddab3-cf31-4b37-a0f7-61fa29bd66c2@github.com>
Message-ID: <pC3tVcw1Y6CYc1PmULelTKUY3nJzwtPqlyUbhkXGw_s=.5cd76b21-2fe4-4f49-93a4-e8bad545c2b3@github.com>

> Some arches still require arrayOopDesc::header_size(BasicType) that we removed because it returns word-sized header-size, in favour of similar methods that return byte-sized header-size. Let's re-instate this old method to make cross-builds happy.
> 
> It also reduces the upstream diff. Let's see what the GHA of cross-builds say.
> Update: GHA shows that the change fixes what it is supposed to fix. There's more stuff though, but that's handled in other PRs.
> 
> Testing:
>  - [x] GHA
>  - [x] build

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:

 - Merge branch 'lilliput' into JDK-8308647
 - Add assert
 - 8308647: [Lilliput/JDK17] Fix cross-builds

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

Changes:
  - all: https://git.openjdk.org/lilliput-jdk17u/pull/24/files
  - new: https://git.openjdk.org/lilliput-jdk17u/pull/24/files/a9e812d6..3d36724c

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

  Stats: 125 lines in 4 files changed: 63 ins; 60 del; 2 mod
  Patch: https://git.openjdk.org/lilliput-jdk17u/pull/24.diff
  Fetch: git fetch https://git.openjdk.org/lilliput-jdk17u.git pull/24/head:pull/24

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

From shade at openjdk.org  Wed May 24 15:49:52 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 24 May 2023 15:49:52 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8308647: [Lilliput/JDK17] Fix
 cross-builds [v2]
In-Reply-To: <pC3tVcw1Y6CYc1PmULelTKUY3nJzwtPqlyUbhkXGw_s=.5cd76b21-2fe4-4f49-93a4-e8bad545c2b3@github.com>
References: <-9k0oxFmSMyBPpsfHtxH7jSRACf-6xarWiylxNiSs-8=.308ddab3-cf31-4b37-a0f7-61fa29bd66c2@github.com>
 <pC3tVcw1Y6CYc1PmULelTKUY3nJzwtPqlyUbhkXGw_s=.5cd76b21-2fe4-4f49-93a4-e8bad545c2b3@github.com>
Message-ID: <4JF-L1fCSk5S3gstxMzLjrfd4HYKQbyecWJb5v8cGbM=.f0014028-89ce-49a1-90d1-56ef8bf2f42f@github.com>

On Wed, 24 May 2023 15:44:52 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Some arches still require arrayOopDesc::header_size(BasicType) that we removed because it returns word-sized header-size, in favour of similar methods that return byte-sized header-size. Let's re-instate this old method to make cross-builds happy.
>> 
>> It also reduces the upstream diff. Let's see what the GHA of cross-builds say.
>> Update: GHA shows that the change fixes what it is supposed to fix. There's more stuff though, but that's handled in other PRs.
>> 
>> Testing:
>>  - [x] GHA
>>  - [x] build
>
> 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:
> 
>  - Merge branch 'lilliput' into JDK-8308647
>  - Add assert
>  - 8308647: [Lilliput/JDK17] Fix cross-builds

Looks fine, but I think we need to re-merge from master to get clean GHA.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/lilliput-jdk17u/pull/24#pullrequestreview-1442231447

From rkennke at openjdk.org  Wed May 24 17:16:43 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 24 May 2023 17:16:43 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8308680: [Lilliput/JDK17] Add missing
 LoadKlassStub skeletons
Message-ID: <hgUrEvy1RzAKITKZQ6Xu--cPlmXhjf6gvK0PRXaZmGg=.c89bbbd6-9d5c-4bb7-96ed-5a0c937ba4ba@github.com>

Arm, PPC and s390 ports are missing the skeletons for LoadKlassStub::emit_code(), which breaks those builds.

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

Commit messages:
 - Merge branch 'lilliput' into JDK-8308680
 - Remove duplicate emit_load_klass() in s390; Add missing LoadKlassStub in arm, ppc and s390
 - 8308680: Cherry-pick s390 parts of 8277417: C1 LIR instruction for load-klass

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

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

From shade at openjdk.org  Wed May 24 17:16:44 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 24 May 2023 17:16:44 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8308680: [Lilliput/JDK17] Add
 missing LoadKlassStub skeletons
In-Reply-To: <hgUrEvy1RzAKITKZQ6Xu--cPlmXhjf6gvK0PRXaZmGg=.c89bbbd6-9d5c-4bb7-96ed-5a0c937ba4ba@github.com>
References: <hgUrEvy1RzAKITKZQ6Xu--cPlmXhjf6gvK0PRXaZmGg=.c89bbbd6-9d5c-4bb7-96ed-5a0c937ba4ba@github.com>
Message-ID: <AjCwx_NRzvg1VJU_JroBPzB4WItgPd8rJlYsbzTUVnw=.633900de-3586-4db8-97b8-511724af526f@github.com>

On Tue, 23 May 2023 15:56:01 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Arm, PPC and s390 ports are missing the skeletons for LoadKlassStub::emit_code(), which breaks those builds.

Looks fine.

Looks fine.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/lilliput-jdk17u/pull/26#pullrequestreview-1440159759
PR Review: https://git.openjdk.org/lilliput-jdk17u/pull/26#pullrequestreview-1442229169

From amitkumar at openjdk.org  Wed May 24 18:17:24 2023
From: amitkumar at openjdk.org (Amit Kumar)
Date: Wed, 24 May 2023 18:17:24 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8308680: [Lilliput/JDK17] Add
 missing LoadKlassStub skeletons
In-Reply-To: <hgUrEvy1RzAKITKZQ6Xu--cPlmXhjf6gvK0PRXaZmGg=.c89bbbd6-9d5c-4bb7-96ed-5a0c937ba4ba@github.com>
References: <hgUrEvy1RzAKITKZQ6Xu--cPlmXhjf6gvK0PRXaZmGg=.c89bbbd6-9d5c-4bb7-96ed-5a0c937ba4ba@github.com>
Message-ID: <9MPYYH20b0jEEeoyxeXqrpHOe7SfcG4Jf3a--mzqo6w=.93f1971e-5861-4bdf-bde6-d05afa5b2f4c@github.com>

On Tue, 23 May 2023 15:56:01 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Arm, PPC and s390 ports are missing the skeletons for LoadKlassStub::emit_code(), which breaks those builds.

Not sure If it's related or not, `JDK-17u` build is successful but when I tried build `lilliput` alongside this PR changes I got some failures. I'm attaching the log file: 
[build.log](https://github.com/openjdk/lilliput-jdk17u/files/11557736/build.log)

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

PR Comment: https://git.openjdk.org/lilliput-jdk17u/pull/26#issuecomment-1561724427

From rkennke at openjdk.org  Wed May 24 18:38:17 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 24 May 2023 18:38:17 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8308680: [Lilliput/JDK17] Add
 missing LoadKlassStub skeletons
In-Reply-To: <9MPYYH20b0jEEeoyxeXqrpHOe7SfcG4Jf3a--mzqo6w=.93f1971e-5861-4bdf-bde6-d05afa5b2f4c@github.com>
References: <hgUrEvy1RzAKITKZQ6Xu--cPlmXhjf6gvK0PRXaZmGg=.c89bbbd6-9d5c-4bb7-96ed-5a0c937ba4ba@github.com>
 <9MPYYH20b0jEEeoyxeXqrpHOe7SfcG4Jf3a--mzqo6w=.93f1971e-5861-4bdf-bde6-d05afa5b2f4c@github.com>
Message-ID: <pvKoS3nuCSMIs4nhuUhs_Yh_jawARuBS7p_c37XRKKs=.654c49fc-2490-4cae-a09b-3777f0fb434c@github.com>

On Wed, 24 May 2023 18:14:36 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

> Not sure If it's related or not, `JDK-17u` build is successful but when I tried build `lilliput` alongside this PR changes I got some failures. I'm attaching the log file: [build.log](https://github.com/openjdk/lilliput-jdk17u/files/11557736/build.log)

Yeah these are going to be addressed by #24 :-)
Thank you for testing! With both these PRs integrated, all the platforms should build, again.

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

PR Comment: https://git.openjdk.org/lilliput-jdk17u/pull/26#issuecomment-1561751666

From rkennke at openjdk.org  Wed May 24 18:42:32 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 24 May 2023 18:42:32 GMT
Subject: [lilliput-jdk17u:lilliput] Integrated: 8308647: [Lilliput/JDK17] Fix
 cross-builds
In-Reply-To: <-9k0oxFmSMyBPpsfHtxH7jSRACf-6xarWiylxNiSs-8=.308ddab3-cf31-4b37-a0f7-61fa29bd66c2@github.com>
References: <-9k0oxFmSMyBPpsfHtxH7jSRACf-6xarWiylxNiSs-8=.308ddab3-cf31-4b37-a0f7-61fa29bd66c2@github.com>
Message-ID: <uCXYAZ7c1gW8T2Fckc3LhhGM7wttZEHb9ful8hvOj1w=.a4ac52d9-e205-48ea-9dc2-de318a962423@github.com>

On Tue, 23 May 2023 11:53:27 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Some arches still require arrayOopDesc::header_size(BasicType) that we removed because it returns word-sized header-size, in favour of similar methods that return byte-sized header-size. Let's re-instate this old method to make cross-builds happy.
> 
> It also reduces the upstream diff. Let's see what the GHA of cross-builds say.
> Update: GHA shows that the change fixes what it is supposed to fix. There's more stuff though, but that's handled in other PRs.
> 
> Testing:
>  - [x] GHA
>  - [x] build

This pull request has now been integrated.

Changeset: 3a70c682
Author:    Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.org/lilliput-jdk17u/commit/3a70c682ba99839e4cf0e681f54361646e05c567
Stats:     12 lines in 1 file changed: 12 ins; 0 del; 0 mod

8308647: [Lilliput/JDK17] Fix cross-builds

Reviewed-by: shade

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

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

From rkennke at openjdk.org  Wed May 24 18:46:26 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 24 May 2023 18:46:26 GMT
Subject: [lilliput-jdk17u:lilliput] Integrated: 8308680: [Lilliput/JDK17] Add
 missing LoadKlassStub skeletons
In-Reply-To: <hgUrEvy1RzAKITKZQ6Xu--cPlmXhjf6gvK0PRXaZmGg=.c89bbbd6-9d5c-4bb7-96ed-5a0c937ba4ba@github.com>
References: <hgUrEvy1RzAKITKZQ6Xu--cPlmXhjf6gvK0PRXaZmGg=.c89bbbd6-9d5c-4bb7-96ed-5a0c937ba4ba@github.com>
Message-ID: <nmin7wE64ykaPKF0pgr6mhrI4F-NlLaXmhNxK8btE68=.e975c8e5-7d01-42f2-a24f-c9232d778942@github.com>

On Tue, 23 May 2023 15:56:01 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Arm, PPC and s390 ports are missing the skeletons for LoadKlassStub::emit_code(), which breaks those builds.

This pull request has now been integrated.

Changeset: e65f63bd
Author:    Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.org/lilliput-jdk17u/commit/e65f63bd2f153275397584aaf1c17b9287f57944
Stats:     10 lines in 3 files changed: 10 ins; 0 del; 0 mod

8308680: [Lilliput/JDK17] Add missing LoadKlassStub skeletons

Reviewed-by: shade

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

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

From rkennke at openjdk.org  Wed May 24 18:49:58 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 24 May 2023 18:49:58 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8308296: [Lilliput/JDK17]
 Cherry-pick: 8275415: Prepare Leak Profiler for Lilliput [v2]
In-Reply-To: <rsnJgEw0SqG-TFJQSozpqJ20q34mxQL_IaL6juCetVQ=.e18522b7-1c91-43cc-abc0-adbc7399129e@github.com>
References: <rsnJgEw0SqG-TFJQSozpqJ20q34mxQL_IaL6juCetVQ=.e18522b7-1c91-43cc-abc0-adbc7399129e@github.com>
Message-ID: <O1lB-fBDbA0LqfPrEFDsW7SqSheMVZYIKksdDXde2DE=.19f57f8c-dcc1-47af-b9df-3cde66f8f51a@github.com>

> We should cherry-pick [JDK-8275415](https://bugs.openjdk.org/browse/JDK-8275415) into Lilliput/JDK17, otherwise running leak-profiler with Lilliput would crash.
> 
> The original change applies cleanly on top of lilliput/jdk17u.
> 
> Testing:
>  - [x] tier1
>  - [x] jdk/jfr

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

 - Merge branch 'lilliput' into JDK-8308296
 - 8308296: [Lilliput/JDK17] Cherry-pick: 8275415: Prepare Leak Profiler for Lilliput

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

Changes:
  - all: https://git.openjdk.org/lilliput-jdk17u/pull/20/files
  - new: https://git.openjdk.org/lilliput-jdk17u/pull/20/files/fc13a3e8..9bb30dc3

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

  Stats: 1466 lines in 75 files changed: 620 ins; 445 del; 401 mod
  Patch: https://git.openjdk.org/lilliput-jdk17u/pull/20.diff
  Fetch: git fetch https://git.openjdk.org/lilliput-jdk17u.git pull/20/head:pull/20

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

From rkennke at openjdk.org  Wed May 24 18:50:57 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 24 May 2023 18:50:57 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8308411: [Lilliput/JDK17]
 Cherry-pick: 8283710: JVMTI: Use BitSet for object marking [v2]
In-Reply-To: <rwJFFALZc7kuYyIzybEZggPTcoXDJKhy5YG_eZUUxdU=.21553ab9-34f3-4534-aa3e-0051a8f98768@github.com>
References: <rwJFFALZc7kuYyIzybEZggPTcoXDJKhy5YG_eZUUxdU=.21553ab9-34f3-4534-aa3e-0051a8f98768@github.com>
Message-ID: <V6MKoQnhQ3idM76Cr48leqv0JPIUgM-GmngPtBHJ9Jw=.64d5cfca-21b8-469b-a3db-fb781c5f21fc@github.com>

> This ports the original https://github.com/openjdk/jdk/pull/7964 to Lilliput/JDK17. It also includes the follow-up (cosmetic) fixes https://bugs.openjdk.org/browse/JDK-8284687 and https://bugs.openjdk.org/browse/JDK-8284725.
> 
> Testing:
>  - [x] tier1
>  - [x] serviceability/jvmti
>  - [x] vmTestbase/nsk/jvmti

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

 - Merge branch 'lilliput' into JDK-8308411
 - Some follow-ups
 - 8283710: JVMTI: Use BitSet for object marking
   
   Reviewed-by: stuefe, coleenp
 - 8283710: JVMTI: Use BitSet for object marking
   
   Reviewed-by: stuefe, coleenp
 - Revert

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

Changes:
  - all: https://git.openjdk.org/lilliput-jdk17u/pull/21/files
  - new: https://git.openjdk.org/lilliput-jdk17u/pull/21/files/2f1793e4..d2d6123e

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

  Stats: 1466 lines in 75 files changed: 620 ins; 445 del; 401 mod
  Patch: https://git.openjdk.org/lilliput-jdk17u/pull/21.diff
  Fetch: git fetch https://git.openjdk.org/lilliput-jdk17u.git pull/21/head:pull/21

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

From rkennke at openjdk.org  Wed May 24 18:51:07 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 24 May 2023 18:51:07 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8308423: [Lilliput/JDK17]
 Cherry-pick GC forwarding [v3]
In-Reply-To: <nq_qvvpMPZr-kzXZnQqYWc7atWLSePpUXsqpYAKnx-s=.31bd0210-cce8-4a7f-b7b3-1db657fca8c4@github.com>
References: <nq_qvvpMPZr-kzXZnQqYWc7atWLSePpUXsqpYAKnx-s=.31bd0210-cce8-4a7f-b7b3-1db657fca8c4@github.com>
Message-ID: <fE0hf1P55P7r5Kt2CIUNf7et7Rb6yaK2ITFqRRi3hOg=.7920f5b1-86ab-4e43-a467-bd01aad963d5@github.com>

> I'd like to pick up the improvements that have been made in full-GC and self-forwarding in the upstream issues [JDK-8305896](https://bugs.openjdk.org/browse/JDK-8305896) and [JDK-8305898](https://bugs.openjdk.org/browse/JDK-8305898). Let's port them to Lilliput/JDK17.
> 
> The version in upstream PR uses resourceHash.hpp as fallback-table. Unfortunately, that doesn't cleanly work with the JDK17 version of resourceHash.hpp, so I used an earlier version with a self-implemented fallback-table.
> 
> Testing:
>  - [x] hotspot_gc
>  - [x] tier1
>  - [ ] tier2

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

 - Merge branch 'lilliput' into JDK-8308423
 - Add missing fastHash.hpp
 - 8308423: [Lilliput/JDK17] Cherry-pick GC forwarding

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

Changes:
  - all: https://git.openjdk.org/lilliput-jdk17u/pull/22/files
  - new: https://git.openjdk.org/lilliput-jdk17u/pull/22/files/d9236ac5..d26a8cc1

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

  Stats: 1466 lines in 75 files changed: 620 ins; 445 del; 401 mod
  Patch: https://git.openjdk.org/lilliput-jdk17u/pull/22.diff
  Fetch: git fetch https://git.openjdk.org/lilliput-jdk17u.git pull/22/head:pull/22

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

From shade at openjdk.org  Thu May 25 14:27:30 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 25 May 2023 14:27:30 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8308423: [Lilliput/JDK17]
 Cherry-pick GC forwarding [v3]
In-Reply-To: <fE0hf1P55P7r5Kt2CIUNf7et7Rb6yaK2ITFqRRi3hOg=.7920f5b1-86ab-4e43-a467-bd01aad963d5@github.com>
References: <nq_qvvpMPZr-kzXZnQqYWc7atWLSePpUXsqpYAKnx-s=.31bd0210-cce8-4a7f-b7b3-1db657fca8c4@github.com>
 <fE0hf1P55P7r5Kt2CIUNf7et7Rb6yaK2ITFqRRi3hOg=.7920f5b1-86ab-4e43-a467-bd01aad963d5@github.com>
Message-ID: <avNm7rf7JR4YLsrKaEGfIQCqphotyAk_iFlvrvbwvCE=.ec68d0a9-e9d7-4901-b549-327f38db9a2a@github.com>

On Wed, 24 May 2023 18:51:07 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> I'd like to pick up the improvements that have been made in full-GC and self-forwarding in the upstream issues [JDK-8305896](https://bugs.openjdk.org/browse/JDK-8305896) and [JDK-8305898](https://bugs.openjdk.org/browse/JDK-8305898). Let's port them to Lilliput/JDK17.
>> 
>> The version in upstream PR uses resourceHash.hpp as fallback-table. Unfortunately, that doesn't cleanly work with the JDK17 version of resourceHash.hpp, so I used an earlier version with a self-implemented fallback-table.
>> 
>> Testing:
>>  - [x] hotspot_gc
>>  - [x] tier1
>>  - [ ] tier2
>
> Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'lilliput' into JDK-8308423
>  - Add missing fastHash.hpp
>  - 8308423: [Lilliput/JDK17] Cherry-pick GC forwarding

Looks fine. This looks integrateable, if tests are clean?

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/lilliput-jdk17u/pull/22#pullrequestreview-1444021048

From rkennke at openjdk.org  Thu May 25 15:52:40 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 25 May 2023 15:52:40 GMT
Subject: [lilliput-jdk17u:lilliput] Integrated: 8308423: [Lilliput/JDK17]
 Cherry-pick GC forwarding
In-Reply-To: <nq_qvvpMPZr-kzXZnQqYWc7atWLSePpUXsqpYAKnx-s=.31bd0210-cce8-4a7f-b7b3-1db657fca8c4@github.com>
References: <nq_qvvpMPZr-kzXZnQqYWc7atWLSePpUXsqpYAKnx-s=.31bd0210-cce8-4a7f-b7b3-1db657fca8c4@github.com>
Message-ID: <WKL92xRBRQbgHUWOv8VzIffAwFISMbZWbZPjh24-XgU=.b2861a7e-521b-41ea-b027-6f2cc31c559a@github.com>

On Fri, 19 May 2023 20:58:47 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> I'd like to pick up the improvements that have been made in full-GC and self-forwarding in the upstream issues [JDK-8305896](https://bugs.openjdk.org/browse/JDK-8305896) and [JDK-8305898](https://bugs.openjdk.org/browse/JDK-8305898). Let's port them to Lilliput/JDK17.
> 
> The version in upstream PR uses resourceHash.hpp as fallback-table. Unfortunately, that doesn't cleanly work with the JDK17 version of resourceHash.hpp, so I used an earlier version with a self-implemented fallback-table.
> 
> Testing:
>  - [x] hotspot_gc
>  - [x] tier1
>  - [ ] tier2

This pull request has now been integrated.

Changeset: 5615bb95
Author:    Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.org/lilliput-jdk17u/commit/5615bb957b878c57f917294f93d3e153780e4bca
Stats:     944 lines in 41 files changed: 588 ins; 132 del; 224 mod

8308423: [Lilliput/JDK17] Cherry-pick GC forwarding

Reviewed-by: shade

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

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

From shade at openjdk.org  Thu May 25 20:02:48 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 25 May 2023 20:02:48 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8308901: [Lilliput/JDK17] Cherry-pick
 C2 prototype header improvements
Message-ID: <dAZy5V8ZHJZrk85xxsK4xmidOD6kudizaiWiSBDqm0g=.ab5eb6f5-54ad-48f3-91dd-33a1c2012855@github.com>

We need to pick up this improvement from upstream PR to Lilliput/JDK17:
  https://github.com/rkennke/jdk/commit/3a18945ce900e229331b1412002da4a6965e0764

The original hunk here: https://github.com/rkennke/jdk/commit/3a18945ce900e229331b1412002da4a6965e0764#diff-ec810a1df7150822244e55ee309c86d6cbffe108ae9c72b6d258ea5758677c28R2148 -- does not apply to JDK 17u.

Additional testing:
 - [ ] Linux x86_64 fastdebug `tier1`
 - [ ] Linux x86_64 fastdebug `tier1` + `+UseCompactObjectHeaders`

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

Commit messages:
 - C2 header improvements

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

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

From shade at openjdk.org  Thu May 25 20:03:59 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 25 May 2023 20:03:59 GMT
Subject: [master] RFR: 8308900: [Lilliput] Cherry-pick C2 prototype header
 improvements
Message-ID: <DFBEoY9cXxucKLpmx9jSTuImVeDqB96u4nuCsWroCuc=.abff72fd-1238-4a4b-98d5-a594c51e4e07@github.com>

This cherry-picks the commit from the upstream review: https://github.com/rkennke/jdk/commit/3a18945ce900e229331b1412002da4a6965e0764.

It also fixes the affected code with more `UseCompactObjectHeaders` guards, and partially reverts it to upstream state.

Additional testing:
 - [ ] Linux x86_64 fastdebug `tier1`
 - [ ] Linux x86_64 fastdebug `tier1` + `+UseCompactObjectHeaders`

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

Commit messages:
 - Cleaner upstream reversal
 - Cherry-pick C2 prototype header improvements

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

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

From shade at openjdk.org  Thu May 25 20:31:56 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 25 May 2023 20:31:56 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8308901: [Lilliput/JDK17]
 Cherry-pick C2 prototype header improvements [v2]
In-Reply-To: <dAZy5V8ZHJZrk85xxsK4xmidOD6kudizaiWiSBDqm0g=.ab5eb6f5-54ad-48f3-91dd-33a1c2012855@github.com>
References: <dAZy5V8ZHJZrk85xxsK4xmidOD6kudizaiWiSBDqm0g=.ab5eb6f5-54ad-48f3-91dd-33a1c2012855@github.com>
Message-ID: <MfimsfuW0TmdGripsvo8_IdHImq-HCDAT009LVQbhF8=.f9e75b07-89bd-4592-b4d0-09e38a973dcd@github.com>

> We need to pick up this improvement from upstream PR to Lilliput/JDK17:
>   https://github.com/rkennke/jdk/commit/3a18945ce900e229331b1412002da4a6965e0764
> 
> Additional testing:
>  - [ ] Linux x86_64 fastdebug `tier1`
>  - [ ] Linux x86_64 fastdebug `tier1` + `+UseCompactObjectHeaders`

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

  Missed LoadNode::Value hunk from the original patch

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

Changes:
  - all: https://git.openjdk.org/lilliput-jdk17u/pull/27/files
  - new: https://git.openjdk.org/lilliput-jdk17u/pull/27/files/ad200342..e37ba5a8

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

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

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

From shade at openjdk.org  Fri May 26 07:20:29 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 26 May 2023 07:20:29 GMT
Subject: [master] RFR: 8308900: [Lilliput] Cherry-pick C2 prototype header
 improvements
In-Reply-To: <DFBEoY9cXxucKLpmx9jSTuImVeDqB96u4nuCsWroCuc=.abff72fd-1238-4a4b-98d5-a594c51e4e07@github.com>
References: <DFBEoY9cXxucKLpmx9jSTuImVeDqB96u4nuCsWroCuc=.abff72fd-1238-4a4b-98d5-a594c51e4e07@github.com>
Message-ID: <H5_crXUyTgz0zOIhAFkElSfmujVAIU8X-_aWZLFeh6Q=.f9adede6-bba7-44d0-b86c-7b037df60ef8@github.com>

On Thu, 25 May 2023 19:21:47 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> This cherry-picks the commit from the upstream review: https://github.com/rkennke/jdk/commit/3a18945ce900e229331b1412002da4a6965e0764.
> 
> It also fixes the affected code with more `UseCompactObjectHeaders` guards, and partially reverts it to upstream state.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug `tier1`
>  - [x] Linux x86_64 fastdebug `tier1` + `+UseCompactObjectHeaders`

GHA shows the infrastructural problems on x86_32, and seemingly unrelated test failure on x86_64.

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

PR Comment: https://git.openjdk.org/lilliput/pull/95#issuecomment-1563919628

From rkennke at openjdk.org  Fri May 26 07:42:26 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 26 May 2023 07:42:26 GMT
Subject: [master] RFR: 8308900: [Lilliput] Cherry-pick C2 prototype header
 improvements
In-Reply-To: <H5_crXUyTgz0zOIhAFkElSfmujVAIU8X-_aWZLFeh6Q=.f9adede6-bba7-44d0-b86c-7b037df60ef8@github.com>
References: <DFBEoY9cXxucKLpmx9jSTuImVeDqB96u4nuCsWroCuc=.abff72fd-1238-4a4b-98d5-a594c51e4e07@github.com>
 <H5_crXUyTgz0zOIhAFkElSfmujVAIU8X-_aWZLFeh6Q=.f9adede6-bba7-44d0-b86c-7b037df60ef8@github.com>
Message-ID: <hDnJ-h6qxZ4Mvv3wmGs_9kJDKHJG1_N3Ts4rQ6n-1t8=.ca1e43c4-b385-4d68-9684-ce9f469b5b23@github.com>

On Fri, 26 May 2023 07:17:51 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> GHA shows the infrastructural problems on x86_32, and seemingly unrelated test failure on x86_64.

I have not seen those before, but yes, they look unrelated.

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

PR Comment: https://git.openjdk.org/lilliput/pull/95#issuecomment-1563947419

From rkennke at openjdk.org  Fri May 26 07:46:33 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 26 May 2023 07:46:33 GMT
Subject: [master] RFR: 8308900: [Lilliput] Cherry-pick C2 prototype header
 improvements
In-Reply-To: <DFBEoY9cXxucKLpmx9jSTuImVeDqB96u4nuCsWroCuc=.abff72fd-1238-4a4b-98d5-a594c51e4e07@github.com>
References: <DFBEoY9cXxucKLpmx9jSTuImVeDqB96u4nuCsWroCuc=.abff72fd-1238-4a4b-98d5-a594c51e4e07@github.com>
Message-ID: <MJuf5A0exFrwed18rGqOcyFxv1gdIxsLCCF2Pci-NPU=.5c8538cf-7e1c-433d-bbf1-64ed31b5e7ec@github.com>

On Thu, 25 May 2023 19:21:47 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> This cherry-picks the commit from the upstream review: https://github.com/rkennke/jdk/commit/3a18945ce900e229331b1412002da4a6965e0764.
> 
> It also fixes the affected code with more `UseCompactObjectHeaders` guards, and partially reverts it to upstream state.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug `tier1`
>  - [x] Linux x86_64 fastdebug `tier1` + `+UseCompactObjectHeaders`

Looks good to me! Thank you!

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

Marked as reviewed by rkennke (Lead).

PR Review: https://git.openjdk.org/lilliput/pull/95#pullrequestreview-1445461223

From rkennke at openjdk.org  Fri May 26 07:48:23 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 26 May 2023 07:48:23 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8308901: [Lilliput/JDK17]
 Cherry-pick C2 prototype header improvements [v2]
In-Reply-To: <MfimsfuW0TmdGripsvo8_IdHImq-HCDAT009LVQbhF8=.f9e75b07-89bd-4592-b4d0-09e38a973dcd@github.com>
References: <dAZy5V8ZHJZrk85xxsK4xmidOD6kudizaiWiSBDqm0g=.ab5eb6f5-54ad-48f3-91dd-33a1c2012855@github.com>
 <MfimsfuW0TmdGripsvo8_IdHImq-HCDAT009LVQbhF8=.f9e75b07-89bd-4592-b4d0-09e38a973dcd@github.com>
Message-ID: <5Dy2VpwcczhhP8u0X07GYcXP3EuPJ7Dmc8FNZkRmgiM=.c56b4c59-6654-4d9a-b6e5-fba30f44b2ba@github.com>

On Thu, 25 May 2023 20:31:56 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> We need to pick up this improvement from upstream PR to Lilliput/JDK17:
>>   https://github.com/rkennke/jdk/commit/3a18945ce900e229331b1412002da4a6965e0764
>> 
>> Additional testing:
>>  - [ ] Linux x86_64 fastdebug `tier1`
>>  - [ ] Linux x86_64 fastdebug `tier1` + `+UseCompactObjectHeaders`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missed LoadNode::Value hunk from the original patch

Looks good to me, thank you!

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

Marked as reviewed by rkennke (Reviewer).

PR Review: https://git.openjdk.org/lilliput-jdk17u/pull/27#pullrequestreview-1445470349

From shade at openjdk.org  Fri May 26 07:52:48 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 26 May 2023 07:52:48 GMT
Subject: [master] RFR: 8308900: [Lilliput] Cherry-pick C2 prototype header
 improvements
In-Reply-To: <DFBEoY9cXxucKLpmx9jSTuImVeDqB96u4nuCsWroCuc=.abff72fd-1238-4a4b-98d5-a594c51e4e07@github.com>
References: <DFBEoY9cXxucKLpmx9jSTuImVeDqB96u4nuCsWroCuc=.abff72fd-1238-4a4b-98d5-a594c51e4e07@github.com>
Message-ID: <JMUzUq9MV4D_eJ_aX-aGzn5YTPbOn-bJDSmhrcMWaWc=.28640eee-d863-4d3e-859e-d184be35b0ea@github.com>

On Thu, 25 May 2023 19:21:47 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> This cherry-picks the commit from the upstream review: https://github.com/rkennke/jdk/commit/3a18945ce900e229331b1412002da4a6965e0764.
> 
> It also fixes the affected code with more `UseCompactObjectHeaders` guards, and partially reverts it to upstream state.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug `tier1`
>  - [x] Linux x86_64 fastdebug `tier1` + `+UseCompactObjectHeaders`

Thanks!

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

PR Comment: https://git.openjdk.org/lilliput/pull/95#issuecomment-1563958327

From shade at openjdk.org  Fri May 26 07:55:30 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 26 May 2023 07:55:30 GMT
Subject: [master] Integrated: 8308900: [Lilliput] Cherry-pick C2 prototype
 header improvements
In-Reply-To: <DFBEoY9cXxucKLpmx9jSTuImVeDqB96u4nuCsWroCuc=.abff72fd-1238-4a4b-98d5-a594c51e4e07@github.com>
References: <DFBEoY9cXxucKLpmx9jSTuImVeDqB96u4nuCsWroCuc=.abff72fd-1238-4a4b-98d5-a594c51e4e07@github.com>
Message-ID: <8tSuK0-UcCAbA1r0wl8XJW5CQvdTiVN03p3dOjm05hM=.e901d520-6fd7-4eb5-9026-ffdab55472ea@github.com>

On Thu, 25 May 2023 19:21:47 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> This cherry-picks the commit from the upstream review: https://github.com/rkennke/jdk/commit/3a18945ce900e229331b1412002da4a6965e0764.
> 
> It also fixes the affected code with more `UseCompactObjectHeaders` guards, and partially reverts it to upstream state.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug `tier1`
>  - [x] Linux x86_64 fastdebug `tier1` + `+UseCompactObjectHeaders`

This pull request has now been integrated.

Changeset: 5e31caf7
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/lilliput/commit/5e31caf7245303acecdb85a25633ac649f970a79
Stats:     51 lines in 5 files changed: 47 ins; 0 del; 4 mod

8308900: [Lilliput] Cherry-pick C2 prototype header improvements

Reviewed-by: rkennke

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

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

From shade at openjdk.org  Fri May 26 09:49:17 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 26 May 2023 09:49:17 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8308901: [Lilliput/JDK17]
 Cherry-pick C2 prototype header improvements [v2]
In-Reply-To: <MfimsfuW0TmdGripsvo8_IdHImq-HCDAT009LVQbhF8=.f9e75b07-89bd-4592-b4d0-09e38a973dcd@github.com>
References: <dAZy5V8ZHJZrk85xxsK4xmidOD6kudizaiWiSBDqm0g=.ab5eb6f5-54ad-48f3-91dd-33a1c2012855@github.com>
 <MfimsfuW0TmdGripsvo8_IdHImq-HCDAT009LVQbhF8=.f9e75b07-89bd-4592-b4d0-09e38a973dcd@github.com>
Message-ID: <sjLoFd57CWY6s-tn7tuup6zsgTvYTJIcZAKINUfbO2E=.2f9a3b72-3ce8-47aa-b4ea-23d3f5aa73f6@github.com>

On Thu, 25 May 2023 20:31:56 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> We need to pick up this improvement from upstream PR to Lilliput/JDK17:
>>   https://github.com/rkennke/jdk/commit/3a18945ce900e229331b1412002da4a6965e0764
>> 
>> Additional testing:
>>  - [ ] Linux x86_64 fastdebug `tier1`
>>  - [x] Linux x86_64 fastdebug `tier1` + `+UseCompactObjectHeaders`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missed LoadNode::Value hunk from the original patch

Tests are passing, I am integrating.

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

PR Comment: https://git.openjdk.org/lilliput-jdk17u/pull/27#issuecomment-1564116688

From shade at openjdk.org  Fri May 26 09:49:18 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 26 May 2023 09:49:18 GMT
Subject: [lilliput-jdk17u:lilliput] Integrated: 8308901: [Lilliput/JDK17]
 Cherry-pick C2 prototype header improvements
In-Reply-To: <dAZy5V8ZHJZrk85xxsK4xmidOD6kudizaiWiSBDqm0g=.ab5eb6f5-54ad-48f3-91dd-33a1c2012855@github.com>
References: <dAZy5V8ZHJZrk85xxsK4xmidOD6kudizaiWiSBDqm0g=.ab5eb6f5-54ad-48f3-91dd-33a1c2012855@github.com>
Message-ID: <lVMHHE0jbjaE7GKv8Nhi7Eiv2AZ5NAe4deUBDMja_B0=.13ca8e6b-150b-4121-af56-0a24257d6c65@github.com>

On Thu, 25 May 2023 19:45:37 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> We need to pick up this improvement from upstream PR to Lilliput/JDK17:
>   https://github.com/rkennke/jdk/commit/3a18945ce900e229331b1412002da4a6965e0764
> 
> Additional testing:
>  - [ ] Linux x86_64 fastdebug `tier1`
>  - [x] Linux x86_64 fastdebug `tier1` + `+UseCompactObjectHeaders`

This pull request has now been integrated.

Changeset: 2d1a3cbf
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/lilliput-jdk17u/commit/2d1a3cbfe6eaa3e553a5696a785bf5dc5a7322a3
Stats:     51 lines in 5 files changed: 47 ins; 0 del; 4 mod

8308901: [Lilliput/JDK17] Cherry-pick C2 prototype header improvements

Reviewed-by: rkennke

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

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

From rkennke at openjdk.org  Sat May 27 10:06:45 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Sat, 27 May 2023 10:06:45 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8308956: [Lilliput/JDK17] Fix some
 object initialization paths
Message-ID: <aFlCWpCEDBigaA8uyssI9XfKjNxU7NJjUOp1YKXqswI=.a8769d7d-670a-4de5-b0e9-e55da5436ef3@github.com>

In some object initialization paths I got the conditions wrong, especial wrt to biased-locking. Let's fix them.

Testing:
 - [x] tier1
 - [x] tier2

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

Commit messages:
 - Fixes CDS and Zero
 - One more fixlet
 - Remove extra set_mark()
 - 8308956: [Lilliput/JDK17] Fix some object initialization paths

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

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

From shade at openjdk.org  Sat May 27 10:06:47 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Sat, 27 May 2023 10:06:47 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8308956: [Lilliput/JDK17] Fix some
 object initialization paths
In-Reply-To: <aFlCWpCEDBigaA8uyssI9XfKjNxU7NJjUOp1YKXqswI=.a8769d7d-670a-4de5-b0e9-e55da5436ef3@github.com>
References: <aFlCWpCEDBigaA8uyssI9XfKjNxU7NJjUOp1YKXqswI=.a8769d7d-670a-4de5-b0e9-e55da5436ef3@github.com>
Message-ID: <VMDZZdOYS_aePJTrb_YZPvZDRUtPMYyMO_SiHAb9iOg=.60d6ea5d-efaa-4229-ae78-0b6872a70592@github.com>

On Fri, 26 May 2023 12:35:33 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> In some object initialization paths I got the conditions wrong, especial wrt to biased-locking. Let's fix them.
> 
> Testing:
>  - [x] tier1
>  - [x] tier2

Changes requested by shade (Reviewer).

Changes requested by shade (Reviewer).

Looks fine.

Also in `bytecodeInterpreter.cpp`:


1958 #ifdef _LP64
1959               oopDesc::release_set_mark(result, ik->prototype_header());
1960 #else
1961               obj->set_mark(markWord::prototype());

1962               obj->set_klass(ik);
1963 #endif

src/hotspot/share/cds/heapShared.cpp line 429:

> 427:   {
> 428:     // This is copied from MemAllocator::finish
> 429:     if (UseBiasedLocking || UseCompactObjectHeaders) {

This misses klass store on `UseBiasedLocking` path.

src/hotspot/share/gc/shared/memAllocator.cpp line 388:

> 386:   assert(mem != NULL, "NULL object pointer");
> 387:   if (UseBiasedLocking) {
> 388:     oopDesc::set_mark(mem, _klass->prototype_header());

Not enough, I think, because there is a `oopDesc::set_mark` in the block below that would overwrite it.

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

PR Review: https://git.openjdk.org/lilliput-jdk17u/pull/28#pullrequestreview-1446180748
PR Review: https://git.openjdk.org/lilliput-jdk17u/pull/28#pullrequestreview-1446379853
Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/lilliput-jdk17u/pull/28#pullrequestreview-1447024723
PR Comment: https://git.openjdk.org/lilliput-jdk17u/pull/28#issuecomment-1564535169
PR Review Comment: https://git.openjdk.org/lilliput-jdk17u/pull/28#discussion_r1206887145
PR Review Comment: https://git.openjdk.org/lilliput-jdk17u/pull/28#discussion_r1206745051

From shade at openjdk.org  Sat May 27 10:06:49 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Sat, 27 May 2023 10:06:49 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8308956: [Lilliput/JDK17] Fix some
 object initialization paths
In-Reply-To: <VMDZZdOYS_aePJTrb_YZPvZDRUtPMYyMO_SiHAb9iOg=.60d6ea5d-efaa-4229-ae78-0b6872a70592@github.com>
References: <aFlCWpCEDBigaA8uyssI9XfKjNxU7NJjUOp1YKXqswI=.a8769d7d-670a-4de5-b0e9-e55da5436ef3@github.com>
 <VMDZZdOYS_aePJTrb_YZPvZDRUtPMYyMO_SiHAb9iOg=.60d6ea5d-efaa-4229-ae78-0b6872a70592@github.com>
Message-ID: <pARM-X4ryK9xlpnxCj_7yspwizDGUSUZmmUIwd_kaAA=.806752e3-b498-4422-b27d-23bcdf6c3481@github.com>

On Fri, 26 May 2023 14:37:46 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> In some object initialization paths I got the conditions wrong, especial wrt to biased-locking. Let's fix them.
>> 
>> Testing:
>>  - [x] tier1
>>  - [x] tier2
>
> src/hotspot/share/cds/heapShared.cpp line 429:
> 
>> 427:   {
>> 428:     // This is copied from MemAllocator::finish
>> 429:     if (UseBiasedLocking || UseCompactObjectHeaders) {
> 
> This misses klass store on `UseBiasedLocking` path.

Also, we should be doing `oopDesc::release_set_mark` if there is no klass-release on some path?

> src/hotspot/share/gc/shared/memAllocator.cpp line 388:
> 
>> 386:   assert(mem != NULL, "NULL object pointer");
>> 387:   if (UseBiasedLocking) {
>> 388:     oopDesc::set_mark(mem, _klass->prototype_header());
> 
> Not enough, I think, because there is a `oopDesc::set_mark` in the block below that would overwrite it.

I think this one would be cleaner:


if (UseCompactObjectHeaders) {
  oopDesc::release_set_mark(mem, _klass->prototype_header());
} else {
  if (UseBiasedLocking) {
    oopDesc::set_mark(mem, _klass->prototype_header());
  } else {
    // May be bootstrapping
    oopDesc::set_mark(mem, markWord::prototype());
  }
  // Need a release store to ensure array/class length, mark word, and
  // object zeroing are visible before setting the klass non-NULL, for
  // concurrent collectors.
  if (!UseCompactObjectHeaders) {
    oopDesc::release_set_klass(mem, _klass);
  }
}

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

PR Review Comment: https://git.openjdk.org/lilliput-jdk17u/pull/28#discussion_r1206888142
PR Review Comment: https://git.openjdk.org/lilliput-jdk17u/pull/28#discussion_r1206895479

From shade at openjdk.org  Sat May 27 10:06:51 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Sat, 27 May 2023 10:06:51 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8308956: [Lilliput/JDK17] Fix some
 object initialization paths
In-Reply-To: <pARM-X4ryK9xlpnxCj_7yspwizDGUSUZmmUIwd_kaAA=.806752e3-b498-4422-b27d-23bcdf6c3481@github.com>
References: <aFlCWpCEDBigaA8uyssI9XfKjNxU7NJjUOp1YKXqswI=.a8769d7d-670a-4de5-b0e9-e55da5436ef3@github.com>
 <VMDZZdOYS_aePJTrb_YZPvZDRUtPMYyMO_SiHAb9iOg=.60d6ea5d-efaa-4229-ae78-0b6872a70592@github.com>
 <pARM-X4ryK9xlpnxCj_7yspwizDGUSUZmmUIwd_kaAA=.806752e3-b498-4422-b27d-23bcdf6c3481@github.com>
Message-ID: <LadZk0ffX1ohOQXWB0SrFRCGP0ezeEIJ7b9NoBiE_EA=.24779e9c-1e4a-44ad-b0f9-3142927a7eea@github.com>

On Fri, 26 May 2023 14:43:24 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> src/hotspot/share/gc/shared/memAllocator.cpp line 388:
>> 
>>> 386:   assert(mem != NULL, "NULL object pointer");
>>> 387:   if (UseBiasedLocking) {
>>> 388:     oopDesc::set_mark(mem, _klass->prototype_header());
>> 
>> Not enough, I think, because there is a `oopDesc::set_mark` in the block below that would overwrite it.
>
> I think this one would be cleaner:
> 
> 
> if (UseCompactObjectHeaders) {
>   oopDesc::release_set_mark(mem, _klass->prototype_header());
> } else {
>   if (UseBiasedLocking) {
>     oopDesc::set_mark(mem, _klass->prototype_header());
>   } else {
>     // May be bootstrapping
>     oopDesc::set_mark(mem, markWord::prototype());
>   }
>   // Need a release store to ensure array/class length, mark word, and
>   // object zeroing are visible before setting the klass non-NULL, for
>   // concurrent collectors.
>   if (!UseCompactObjectHeaders) {
>     oopDesc::release_set_klass(mem, _klass);
>   }
> }

Copy this to `HeapShared::copy_roots` too.

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

PR Review Comment: https://git.openjdk.org/lilliput-jdk17u/pull/28#discussion_r1206897247

From rkennke at openjdk.org  Sat May 27 10:12:23 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Sat, 27 May 2023 10:12:23 GMT
Subject: [lilliput-jdk17u:lilliput] Integrated: 8308956: [Lilliput/JDK17] Fix
 some object initialization paths
In-Reply-To: <aFlCWpCEDBigaA8uyssI9XfKjNxU7NJjUOp1YKXqswI=.a8769d7d-670a-4de5-b0e9-e55da5436ef3@github.com>
References: <aFlCWpCEDBigaA8uyssI9XfKjNxU7NJjUOp1YKXqswI=.a8769d7d-670a-4de5-b0e9-e55da5436ef3@github.com>
Message-ID: <zkYpZMmO_GuvYkj31WwTF90jbt_uZuJNWRYE2dGp1Sk=.348bd141-2d44-435e-bf9d-16dd1688acd0@github.com>

On Fri, 26 May 2023 12:35:33 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> In some object initialization paths I got the conditions wrong, especial wrt to biased-locking. Let's fix them.
> 
> Testing:
>  - [x] tier1
>  - [x] tier2

This pull request has now been integrated.

Changeset: 2a6b3cdf
Author:    Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.org/lilliput-jdk17u/commit/2a6b3cdf5103bc0ff585d3b4bc80a498f874942f
Stats:     37 lines in 5 files changed: 12 ins; 1 del; 24 mod

8308956: [Lilliput/JDK17] Fix some object initialization paths

Reviewed-by: shade

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

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

From shade at openjdk.org  Wed May 31 11:17:30 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 31 May 2023 11:17:30 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8309192: [Lilliput/JDK17] Disable
 Lilliput by default, and turn off CDS when Lilliput is enabled
Message-ID: <f2j-5AGSB0a914hHdzWx7jWybog68Xkk-P9Qcqc9Q4k=.7df04991-63d8-4b8f-8fe0-0459b90c45d3@github.com>

See the discussion in the bug.

There is a problem that disabling Lilliput effectively disables CDS. I think for 17u we should disable UCOH by default, and disable CDS when UCOH is on. That is, keep the legacy configuration untouched, and let Lilliput pay the price, if any.

Additional testing:
 - [x] macos-aarch64-server-fastdebug, `runtime/cds`

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

Commit messages:
 - Disable Lilliput by default, and turn off CDS when Lilliput is enabled

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

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

From shade at openjdk.org  Wed May 31 11:50:50 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 31 May 2023 11:50:50 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8309197: [Lilliput/JDK17] Fix
 ObjectSampleMarker without Lilliput
Message-ID: <kleqC5-Gd9y_kw116WZqaqH6jNiTFJGux33iWoZ3bfw=.2df4891a-383a-4749-9c28-ff684935051d@github.com>

The change in ObjectSampleMarker, a part of JFR, is incorrect when Lilliput is off. It would reach to `set_narrow_klass` and `narrow_klass` unconditionally, but that is only safe to do when `UseCompactObjectHeader` is on.

This would be caught by assert in `set_narrow_klass` and `narrow_klass` with `-UCOH`. AFAICS, this has a chance to corrupt the header in release bits, as it would copy only the parts of the mark word, and we might be just lucky those are the same bits. 

Additional testing:
 - [x] macos-aarch64-server-fastdebug, `jdk/jfr/event/oldobject` with `-XX:-UseCompactObjectHeaders` (passes now)
 - [x] macos-aarch64-server-fastdebug, `jdk/jfr/event/oldobject` with `-XX:+UseCompactObjectHeaders` (still fails, with unrelated problems)

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

Commit messages:
 - Fix

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

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

From stuefe at openjdk.org  Wed May 31 12:07:22 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 31 May 2023 12:07:22 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8309192: [Lilliput/JDK17] Disable
 Lilliput by default, and turn off CDS when Lilliput is enabled
In-Reply-To: <f2j-5AGSB0a914hHdzWx7jWybog68Xkk-P9Qcqc9Q4k=.7df04991-63d8-4b8f-8fe0-0459b90c45d3@github.com>
References: <f2j-5AGSB0a914hHdzWx7jWybog68Xkk-P9Qcqc9Q4k=.7df04991-63d8-4b8f-8fe0-0459b90c45d3@github.com>
Message-ID: <f1truEZlUO2msCXDFKe9rKM54nEK2wsxkjsjbDWNgLc=.11eff80c-e6a0-4a87-9b1d-401661647f22@github.com>

On Wed, 31 May 2023 11:10:03 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See the discussion in the bug.
> 
> There is a problem that disabling Lilliput effectively disables CDS. I think for 17u we should disable UCOH by default, and disable CDS when UCOH is on. That is, keep the legacy configuration untouched, and let Lilliput pay the price, if any.
> 
> Additional testing:
>  - [x] macos-aarch64-server-fastdebug, `runtime/cds`

Okay as in it does what you write it does. Not much discussion found in the bug though. In Lilliput master, CDS works with compact headers. Are the necessary parts just missing?

Note that I currently work on the upstream patch for https://github.com/tstuefe/jdk/tree/metaspace-for-lilliput (still very much wip), which will also touch CDS.

Cheers, Thomas

p.s. you may run into CDS tests that assume CDS is enabled by default, or that test that.

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

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/lilliput-jdk17u/pull/29#pullrequestreview-1453025556

From rkennke at openjdk.org  Wed May 31 14:58:28 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 31 May 2023 14:58:28 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8309192: [Lilliput/JDK17] Disable
 Lilliput by default, and turn off CDS when Lilliput is enabled
In-Reply-To: <f2j-5AGSB0a914hHdzWx7jWybog68Xkk-P9Qcqc9Q4k=.7df04991-63d8-4b8f-8fe0-0459b90c45d3@github.com>
References: <f2j-5AGSB0a914hHdzWx7jWybog68Xkk-P9Qcqc9Q4k=.7df04991-63d8-4b8f-8fe0-0459b90c45d3@github.com>
Message-ID: <0gH1BnWrNe2Ws5hsgGxUu2i_t6gHivc2P84zFeuQaoI=.3c5fb70f-f7e5-41e4-ab66-61e879d5c19f@github.com>

On Wed, 31 May 2023 11:10:03 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See the discussion in the bug.
> 
> There is a problem that disabling Lilliput effectively disables CDS. I think for 17u we should disable UCOH by default, and disable CDS when UCOH is on. That is, keep the legacy configuration untouched, and let Lilliput pay the price, if any.
> 
> Additional testing:
>  - [x] macos-aarch64-server-fastdebug, `runtime/cds`

The upstream PR has a better fix that eliminated the flag mess and makes CDS more resilient: https://github.com/openjdk/jdk/commit/69d469adf0e6dcec943929836e0a0620f63b46f0

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

PR Comment: https://git.openjdk.org/lilliput-jdk17u/pull/29#issuecomment-1570396486

From rkennke at openjdk.org  Wed May 31 15:01:26 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 31 May 2023 15:01:26 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8309197: [Lilliput/JDK17] Fix
 ObjectSampleMarker without Lilliput
In-Reply-To: <kleqC5-Gd9y_kw116WZqaqH6jNiTFJGux33iWoZ3bfw=.2df4891a-383a-4749-9c28-ff684935051d@github.com>
References: <kleqC5-Gd9y_kw116WZqaqH6jNiTFJGux33iWoZ3bfw=.2df4891a-383a-4749-9c28-ff684935051d@github.com>
Message-ID: <d2YUSDelcGGt8_4Z0W8Jo62T2YNQl8BMtGuMGA0LnaY=.ec41b943-bf0c-47c9-bfa0-21730b2acf2a@github.com>

On Wed, 31 May 2023 11:43:31 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> The change in ObjectSampleMarker, a part of JFR, is incorrect when Lilliput is off. It would reach to `set_narrow_klass` and `narrow_klass` unconditionally, but that is only safe to do when `UseCompactObjectHeader` is on.
> 
> This would be caught by assert in `set_narrow_klass` and `narrow_klass` with `-UCOH`. AFAICS, this has a chance to corrupt the header in release bits, as it would copy only the parts of the mark word, and we might be just lucky those are the same bits. 
> 
> Additional testing:
>  - [x] macos-aarch64-server-fastdebug, `jdk/jfr/event/oldobject` with `-XX:-UseCompactObjectHeaders` (passes now)
>  - [x] macos-aarch64-server-fastdebug, `jdk/jfr/event/oldobject` with `-XX:+UseCompactObjectHeaders` (still fails, with unrelated problems)

Is this better than #20? (Sorry can't review, I am currently on smartphone)

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

PR Comment: https://git.openjdk.org/lilliput-jdk17u/pull/30#issuecomment-1570400849

From iklam at openjdk.org  Wed May 31 15:02:28 2023
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 31 May 2023 15:02:28 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8309192: [Lilliput/JDK17] Disable
 Lilliput by default, and turn off CDS when Lilliput is enabled
In-Reply-To: <f1truEZlUO2msCXDFKe9rKM54nEK2wsxkjsjbDWNgLc=.11eff80c-e6a0-4a87-9b1d-401661647f22@github.com>
References: <f2j-5AGSB0a914hHdzWx7jWybog68Xkk-P9Qcqc9Q4k=.7df04991-63d8-4b8f-8fe0-0459b90c45d3@github.com>
 <f1truEZlUO2msCXDFKe9rKM54nEK2wsxkjsjbDWNgLc=.11eff80c-e6a0-4a87-9b1d-401661647f22@github.com>
Message-ID: <gmMYaVoQo33Baaciy6ayNeDXdh-2xsHyCQPctMWpvZU=.af46ecbd-6dfc-40d1-863d-77f201a8f255@github.com>

On Wed, 31 May 2023 12:04:30 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Okay as in it does what you write it does. Not much discussion found in the bug though. In Lilliput master, CDS works with compact headers. Are the necessary parts just missing?
> 
> Note that I currently work on the upstream patch for https://github.com/tstuefe/jdk/tree/metaspace-for-lilliput (still very much wip), which will also touch CDS.
> 
> Cheers, Thomas
> 
> p.s. you may run into CDS tests that assume CDS is enabled by default, or that test that.

We already fixed such tests in the mainline. See https://bugs.openjdk.org/browse/JDK-8308034

If you find any other CDS tests failing for liliput due to the same reason, please file a new bug.

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

PR Comment: https://git.openjdk.org/lilliput-jdk17u/pull/29#issuecomment-1570402804

From shade at openjdk.org  Wed May 31 15:08:26 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 31 May 2023 15:08:26 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8309192: [Lilliput/JDK17] Disable
 Lilliput by default, and turn off CDS when Lilliput is enabled
In-Reply-To: <f2j-5AGSB0a914hHdzWx7jWybog68Xkk-P9Qcqc9Q4k=.7df04991-63d8-4b8f-8fe0-0459b90c45d3@github.com>
References: <f2j-5AGSB0a914hHdzWx7jWybog68Xkk-P9Qcqc9Q4k=.7df04991-63d8-4b8f-8fe0-0459b90c45d3@github.com>
Message-ID: <9WOKmQZ07nndKMSNKobCgizEiqHifch1dBQjJzbEwcw=.84aff92a-7583-4f04-9190-7940d00454b9@github.com>

On Wed, 31 May 2023 11:10:03 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See the discussion in the bug.
> 
> There is a problem that disabling Lilliput effectively disables CDS. I think for 17u we should disable UCOH by default, and disable CDS when UCOH is on. That is, keep the legacy configuration untouched, and let Lilliput pay the price, if any.
> 
> Additional testing:
>  - [x] macos-aarch64-server-fastdebug, `runtime/cds`

> The upstream PR has a better fix that eliminated the flag mess and makes CDS more resilient: [openjdk/jdk at 69d469a](https://github.com/openjdk/jdk/commit/69d469adf0e6dcec943929836e0a0620f63b46f0)

Does it change the format of CDS archive? I.e. if we generate the CDS archive with Lilliput-enabled JDK (even when Lilliput is off), would that archive be properly readable with non-Lilliput JDK from the same release version? That is my concern about porting that fix into JDK 17 version.

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

PR Comment: https://git.openjdk.org/lilliput-jdk17u/pull/29#issuecomment-1570415027

From shade at openjdk.org  Wed May 31 15:26:19 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 31 May 2023 15:26:19 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8309192: [Lilliput/JDK17] Disable
 Lilliput by default, and turn off CDS when Lilliput is enabled
In-Reply-To: <9WOKmQZ07nndKMSNKobCgizEiqHifch1dBQjJzbEwcw=.84aff92a-7583-4f04-9190-7940d00454b9@github.com>
References: <f2j-5AGSB0a914hHdzWx7jWybog68Xkk-P9Qcqc9Q4k=.7df04991-63d8-4b8f-8fe0-0459b90c45d3@github.com>
 <9WOKmQZ07nndKMSNKobCgizEiqHifch1dBQjJzbEwcw=.84aff92a-7583-4f04-9190-7940d00454b9@github.com>
Message-ID: <TPLNrrvRqHM2bNkZFQKEQSQoZGpHX3ZOrlrI8gITDdw=.3aed6050-c65e-491f-9224-877ab08c142c@github.com>

On Wed, 31 May 2023 15:05:36 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> > The upstream PR has a better fix that eliminated the flag mess and makes CDS more resilient: [openjdk/jdk at 69d469a](https://github.com/openjdk/jdk/commit/69d469adf0e6dcec943929836e0a0620f63b46f0)
> 
> Does it change the format of CDS archive? I.e. if we generate the CDS archive with Lilliput-enabled JDK (even when Lilliput is off), would that archive be properly readable with non-Lilliput JDK from the same release version? That is my concern about porting that fix into JDK 17 version.

Answering myself: it seems CDS archive is fingerprinted with JVM ident string, so this is not a concern. Let me backport that upstream change instead then.

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

PR Comment: https://git.openjdk.org/lilliput-jdk17u/pull/29#issuecomment-1570444549

From shade at openjdk.org  Wed May 31 15:50:20 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 31 May 2023 15:50:20 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8309197: [Lilliput/JDK17] Fix
 ObjectSampleMarker without Lilliput
In-Reply-To: <d2YUSDelcGGt8_4Z0W8Jo62T2YNQl8BMtGuMGA0LnaY=.ec41b943-bf0c-47c9-bfa0-21730b2acf2a@github.com>
References: <kleqC5-Gd9y_kw116WZqaqH6jNiTFJGux33iWoZ3bfw=.2df4891a-383a-4749-9c28-ff684935051d@github.com>
 <d2YUSDelcGGt8_4Z0W8Jo62T2YNQl8BMtGuMGA0LnaY=.ec41b943-bf0c-47c9-bfa0-21730b2acf2a@github.com>
Message-ID: <WKBJNiiPhUbs-RVI0npJRRAbPUwUw7GhsLS4zOyOnxc=.55e0db51-acda-42e9-ac2f-eb540c789e6b@github.com>

On Wed, 31 May 2023 14:58:24 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Is this better than #20? (Sorry can't review, I am currently on smartphone)

It is different, not even the same code, I think.

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

PR Comment: https://git.openjdk.org/lilliput-jdk17u/pull/30#issuecomment-1570485267

From shade at openjdk.org  Wed May 31 16:11:53 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 31 May 2023 16:11:53 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8309192: [Lilliput/JDK17] Properly
 deal with flag mismatch in CDS [v2]
In-Reply-To: <f2j-5AGSB0a914hHdzWx7jWybog68Xkk-P9Qcqc9Q4k=.7df04991-63d8-4b8f-8fe0-0459b90c45d3@github.com>
References: <f2j-5AGSB0a914hHdzWx7jWybog68Xkk-P9Qcqc9Q4k=.7df04991-63d8-4b8f-8fe0-0459b90c45d3@github.com>
Message-ID: <XgD6Ztx8vbnlLZ8GQ0yFLp2kB9zf3RFOiNQMhtsaB90=.aca1b428-ca94-4a57-8ef0-09547c0cdfc5@github.com>

> See the discussion in the bug.
> 
> There is a problem that disabling Lilliput effectively disables CDS. I think for 17u we should disable UCOH by default, and disable CDS when UCOH is on. That is, keep the legacy configuration untouched, and let Lilliput pay the price, if any.
> 
> Additional testing:
>  - [x] macos-aarch64-server-fastdebug, `runtime/cds`

Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision:

 - Cherry-pick
 - Revert old patch

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

Changes:
  - all: https://git.openjdk.org/lilliput-jdk17u/pull/29/files
  - new: https://git.openjdk.org/lilliput-jdk17u/pull/29/files/123213b7..8abfae53

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

  Stats: 83 lines in 5 files changed: 78 ins; 4 del; 1 mod
  Patch: https://git.openjdk.org/lilliput-jdk17u/pull/29.diff
  Fetch: git fetch https://git.openjdk.org/lilliput-jdk17u.git pull/29/head:pull/29

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

From shade at openjdk.org  Wed May 31 16:11:56 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 31 May 2023 16:11:56 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8309192: [Lilliput/JDK17] Properly
 deal with flag mismatch in CDS
In-Reply-To: <f2j-5AGSB0a914hHdzWx7jWybog68Xkk-P9Qcqc9Q4k=.7df04991-63d8-4b8f-8fe0-0459b90c45d3@github.com>
References: <f2j-5AGSB0a914hHdzWx7jWybog68Xkk-P9Qcqc9Q4k=.7df04991-63d8-4b8f-8fe0-0459b90c45d3@github.com>
Message-ID: <14OCeszs6AO6F0E6kIFab1EIroPCF5rEwC9tjAAq8T8=.a96ce868-0dd7-4f79-bdfc-b1f27c337550@github.com>

On Wed, 31 May 2023 11:10:03 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See the discussion in the bug.
> 
> There is a problem that disabling Lilliput effectively disables CDS. I think for 17u we should disable UCOH by default, and disable CDS when UCOH is on. That is, keep the legacy configuration untouched, and let Lilliput pay the price, if any.
> 
> Additional testing:
>  - [x] macos-aarch64-server-fastdebug, `runtime/cds`

Please see new commit. `runtime/cds` tests are passing with both +UCOH and -UCOH.

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

PR Comment: https://git.openjdk.org/lilliput-jdk17u/pull/29#issuecomment-1570513751