From rkennke at openjdk.org Mon Apr 7 11:12:40 2025 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 7 Apr 2025 11:12:40 GMT Subject: [master] RFR: 8347711: [Lilliput] Parallel GC support for compact identity hashcode [v4] In-Reply-To: References: Message-ID: > The Parallel GC does not yet support Lilliput 2 until now. The big problem has been that the Parallel Full GC is too rigid with respect to object sizes, and we could not make it work with compact identity hashcode, which requires that objects can grow during GC. > > The PR implements an alternative full GC for Parallel GC, which is more flexible. The algorithm mostly follows G1 and Shenandoah, with the difference that it creates temporary 'regions' (because Parallel GC does not use heap regions), with boundaries such that no object crosses region boundaries, and then after GC fill any gaps at end of regions with dummy objects. > > The implementation has a special 'serial' mode, which sets up only 4 regions which exactly match the 4 heap spaces (old, eden, from, to), and performs the forwarding and compaction phases serially to achieve perfect compaction at the expense of performance. (The marking and adjust-refs phases will still be done with parallel workers). > > I've run the micro benchmarks for systemgc, there seem to be only minor differences, and looks mostly like a few milliseconds offset in the new implementation: > > Baseline Full GC: > > AllDead.gc ss 25 31.120 ? 0.447 ms/op > AllLive.gc ss 25 83.655 ? 2.238 ms/op > DifferentObjectSizesArray.gc ss 25 179.725 ? 1.171 ms/op > DifferentObjectSizesHashMap.gc ss 25 186.011 ? 1.409 ms/op > DifferentObjectSizesTreeMap.gc ss 25 65.668 ? 3.333 ms/op > HalfDeadFirstPart.gc ss 25 64.862 ? 0.696 ms/op > HalfDeadInterleaved.gc ss 25 67.764 ? 3.139 ms/op > HalfDeadInterleavedChunks.gc ss 25 59.160 ? 1.667 ms/op > HalfDeadSecondPart.gc ss 25 66.210 ? 1.167 ms/op > HalfHashedHalfDead.gc ss 25 69.584 ? 2.276 ms/op > NoObjects.gc ss 25 18.462 ? 0.270 ms/op > OneBigObject.gc ss 25 587.425 ? 27.493 ms/op > > > New Parallel Full GC: > > > AllDead.gc ss 25 39.891 ? 0.461 ms/op > AllLive.gc ss 25 87.898 ? 1.940 ms/op > DifferentObjectSizesArray.gc ss 25 184.109 ? 0.795 ms/op > DifferentObjectSizesHashMap.gc ss 25 189.620 ? 2.236 ms/op > DifferentObjectSizesTreeMap.gc ss 25 69.915 ? 3.308 ms/op > HalfDeadFirstPart.gc ss 25 70.664 ? 0.804 ms/op > HalfDeadInterleaved.gc ss 25 71.318 ? 1.583 ms/op > HalfDeadInterleavedChunks.gc ss 25 65.050... Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Avoid racy update in Klass::expand_for_hash() ------------- Changes: - all: https://git.openjdk.org/lilliput/pull/195/files - new: https://git.openjdk.org/lilliput/pull/195/files/738c3093..95728b46 Webrevs: - full: https://webrevs.openjdk.org/?repo=lilliput&pr=195&range=03 - incr: https://webrevs.openjdk.org/?repo=lilliput&pr=195&range=02-03 Stats: 9 lines in 4 files changed: 0 ins; 0 del; 9 mod Patch: https://git.openjdk.org/lilliput/pull/195.diff Fetch: git fetch https://git.openjdk.org/lilliput.git pull/195/head:pull/195 PR: https://git.openjdk.org/lilliput/pull/195 From rkennke at openjdk.org Mon Apr 7 12:52:25 2025 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 7 Apr 2025 12:52:25 GMT Subject: [master] RFR: 8353849: [Lilliput] Avoid race in compact identity hashcode Message-ID: Multiple GC threads can concurrently update an object's mark-word (Parallel, G1 and Shenandoah). We need to be careful when doing object-size calculations and pass-through the pre-loaded, safe mark-word, instead of re-loading the mark-word from the object. In the latter case, we might read a forwarding pointer and interpret the bits as hash-bits which would lead to wrong size-calculation and crash. Testing: - hotspot_gc (+UCOH) ------------- Commit messages: - 8353849: [Lilliput] Avoid race in compact identity hashcode Changes: https://git.openjdk.org/lilliput/pull/196/files Webrev: https://webrevs.openjdk.org/?repo=lilliput&pr=196&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8353849 Stats: 9 lines in 4 files changed: 0 ins; 0 del; 9 mod Patch: https://git.openjdk.org/lilliput/pull/196.diff Fetch: git fetch https://git.openjdk.org/lilliput.git pull/196/head:pull/196 PR: https://git.openjdk.org/lilliput/pull/196 From zgu at openjdk.org Mon Apr 7 12:58:16 2025 From: zgu at openjdk.org (Zhengyu Gu) Date: Mon, 7 Apr 2025 12:58:16 GMT Subject: [master] RFR: 8353849: [Lilliput] Avoid race in compact identity hashcode In-Reply-To: References: Message-ID: On Mon, 7 Apr 2025 12:48:02 GMT, Roman Kennke wrote: > Multiple GC threads can concurrently update an object's mark-word (Parallel, G1 and Shenandoah). We need to be careful when doing object-size calculations and pass-through the pre-loaded, safe mark-word, instead of re-loading the mark-word from the object. In the latter case, we might read a forwarding pointer and interpret the bits as hash-bits which would lead to wrong size-calculation and crash. > > Testing: > - hotspot_gc (+UCOH) Seem reasonable. ------------- Marked as reviewed by zgu (Reviewer). PR Review: https://git.openjdk.org/lilliput/pull/196#pullrequestreview-2746720818 From stuefe at openjdk.org Mon Apr 7 13:18:20 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 7 Apr 2025 13:18:20 GMT Subject: [master] RFR: 8347711: [Lilliput] Parallel GC support for compact identity hashcode [v4] In-Reply-To: References: Message-ID: <4ymgfJEnBDmDE7onL28bOgn5qh1Mvk8uKOqYFU71Ftw=.46a21291-92b3-4a39-8c19-a4e4b8e86725@github.com> On Mon, 7 Apr 2025 11:12:40 GMT, Roman Kennke wrote: >> The Parallel GC does not yet support Lilliput 2 until now. The big problem has been that the Parallel Full GC is too rigid with respect to object sizes, and we could not make it work with compact identity hashcode, which requires that objects can grow during GC. >> >> The PR implements an alternative full GC for Parallel GC, which is more flexible. The algorithm mostly follows G1 and Shenandoah, with the difference that it creates temporary 'regions' (because Parallel GC does not use heap regions), with boundaries such that no object crosses region boundaries, and then after GC fill any gaps at end of regions with dummy objects. >> >> The implementation has a special 'serial' mode, which sets up only 4 regions which exactly match the 4 heap spaces (old, eden, from, to), and performs the forwarding and compaction phases serially to achieve perfect compaction at the expense of performance. (The marking and adjust-refs phases will still be done with parallel workers). >> >> I've run the micro benchmarks for systemgc, there seem to be only minor differences, and looks mostly like a few milliseconds offset in the new implementation: >> >> Baseline Full GC: >> >> AllDead.gc ss 25 31.120 ? 0.447 ms/op >> AllLive.gc ss 25 83.655 ? 2.238 ms/op >> DifferentObjectSizesArray.gc ss 25 179.725 ? 1.171 ms/op >> DifferentObjectSizesHashMap.gc ss 25 186.011 ? 1.409 ms/op >> DifferentObjectSizesTreeMap.gc ss 25 65.668 ? 3.333 ms/op >> HalfDeadFirstPart.gc ss 25 64.862 ? 0.696 ms/op >> HalfDeadInterleaved.gc ss 25 67.764 ? 3.139 ms/op >> HalfDeadInterleavedChunks.gc ss 25 59.160 ? 1.667 ms/op >> HalfDeadSecondPart.gc ss 25 66.210 ? 1.167 ms/op >> HalfHashedHalfDead.gc ss 25 69.584 ? 2.276 ms/op >> NoObjects.gc ss 25 18.462 ? 0.270 ms/op >> OneBigObject.gc ss 25 587.425 ? 27.493 ms/op >> >> >> New Parallel Full GC: >> >> >> AllDead.gc ss 25 39.891 ? 0.461 ms/op >> AllLive.gc ss 25 87.898 ? 1.940 ms/op >> DifferentObjectSizesArray.gc ss 25 184.109 ? 0.795 ms/op >> DifferentObjectSizesHashMap.gc ss 25 189.620 ? 2.236 ms/op >> DifferentObjectSizesTreeMap.gc ss 25 69.915 ? 3.308 ms/op >> HalfDeadFirstPart.gc ss 25 70.664 ? 0.804 ms/op >> HalfDeadInterleaved.gc ss 25 71.31... > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Avoid racy update in Klass::expand_for_hash() How does this algorithm deal with objects larger than region size? ------------- PR Comment: https://git.openjdk.org/lilliput/pull/195#issuecomment-2783303710 From rkennke at openjdk.org Mon Apr 7 13:24:03 2025 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 7 Apr 2025 13:24:03 GMT Subject: [master] RFR: 8347711: [Lilliput] Parallel GC support for compact identity hashcode [v4] In-Reply-To: <4ymgfJEnBDmDE7onL28bOgn5qh1Mvk8uKOqYFU71Ftw=.46a21291-92b3-4a39-8c19-a4e4b8e86725@github.com> References: <4ymgfJEnBDmDE7onL28bOgn5qh1Mvk8uKOqYFU71Ftw=.46a21291-92b3-4a39-8c19-a4e4b8e86725@github.com> Message-ID: On Mon, 7 Apr 2025 13:15:27 GMT, Thomas Stuefe wrote: > How does this algorithm deal with objects larger than region size? Currently not particularily well: it doesn't move them at all (because they don't fit), and it *also* doesn't move other objects past them. There's a TODO to make it possible to move objects around large objects (don't have to be > region-sized, also something like 1/2 region sized objects may have difficulty to move). I'll address that in a follow-up PR. ------------- PR Comment: https://git.openjdk.org/lilliput/pull/195#issuecomment-2783321874 From zgu at openjdk.org Mon Apr 7 13:51:18 2025 From: zgu at openjdk.org (Zhengyu Gu) Date: Mon, 7 Apr 2025 13:51:18 GMT Subject: [master] RFR: 8347711: [Lilliput] Parallel GC support for compact identity hashcode [v4] In-Reply-To: References: Message-ID: On Mon, 7 Apr 2025 11:12:40 GMT, Roman Kennke wrote: >> The Parallel GC does not yet support Lilliput 2 until now. The big problem has been that the Parallel Full GC is too rigid with respect to object sizes, and we could not make it work with compact identity hashcode, which requires that objects can grow during GC. >> >> The PR implements an alternative full GC for Parallel GC, which is more flexible. The algorithm mostly follows G1 and Shenandoah, with the difference that it creates temporary 'regions' (because Parallel GC does not use heap regions), with boundaries such that no object crosses region boundaries, and then after GC fill any gaps at end of regions with dummy objects. >> >> The implementation has a special 'serial' mode, which sets up only 4 regions which exactly match the 4 heap spaces (old, eden, from, to), and performs the forwarding and compaction phases serially to achieve perfect compaction at the expense of performance. (The marking and adjust-refs phases will still be done with parallel workers). >> >> I've run the micro benchmarks for systemgc, there seem to be only minor differences, and looks mostly like a few milliseconds offset in the new implementation: >> >> Baseline Full GC: >> >> AllDead.gc ss 25 31.120 ? 0.447 ms/op >> AllLive.gc ss 25 83.655 ? 2.238 ms/op >> DifferentObjectSizesArray.gc ss 25 179.725 ? 1.171 ms/op >> DifferentObjectSizesHashMap.gc ss 25 186.011 ? 1.409 ms/op >> DifferentObjectSizesTreeMap.gc ss 25 65.668 ? 3.333 ms/op >> HalfDeadFirstPart.gc ss 25 64.862 ? 0.696 ms/op >> HalfDeadInterleaved.gc ss 25 67.764 ? 3.139 ms/op >> HalfDeadInterleavedChunks.gc ss 25 59.160 ? 1.667 ms/op >> HalfDeadSecondPart.gc ss 25 66.210 ? 1.167 ms/op >> HalfHashedHalfDead.gc ss 25 69.584 ? 2.276 ms/op >> NoObjects.gc ss 25 18.462 ? 0.270 ms/op >> OneBigObject.gc ss 25 587.425 ? 27.493 ms/op >> >> >> New Parallel Full GC: >> >> >> AllDead.gc ss 25 39.891 ? 0.461 ms/op >> AllLive.gc ss 25 87.898 ? 1.940 ms/op >> DifferentObjectSizesArray.gc ss 25 184.109 ? 0.795 ms/op >> DifferentObjectSizesHashMap.gc ss 25 189.620 ? 2.236 ms/op >> DifferentObjectSizesTreeMap.gc ss 25 69.915 ? 3.308 ms/op >> HalfDeadFirstPart.gc ss 25 70.664 ? 0.804 ms/op >> HalfDeadInterleaved.gc ss 25 71.31... > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Avoid racy update in Klass::expand_for_hash() > > How does this algorithm deal with objects larger than region size? > > Currently not particularily well: it doesn't move them at all (because they don't fit), and it _also_ doesn't move other objects past them. There's a TODO to make it possible to move objects around large objects (don't have to be > region-sized, also something like 1/2 region sized objects may have difficulty to move). I'll address that in a follow-up PR. Are you talking about parallel specific? Thanks. ------------- PR Comment: https://git.openjdk.org/lilliput/pull/195#issuecomment-2783405252 From rkennke at openjdk.org Mon Apr 7 15:31:21 2025 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 7 Apr 2025 15:31:21 GMT Subject: [master] RFR: 8347711: [Lilliput] Parallel GC support for compact identity hashcode [v4] In-Reply-To: References: Message-ID: On Mon, 7 Apr 2025 13:47:18 GMT, Zhengyu Gu wrote: > > > How does this algorithm deal with objects larger than region size? > > > > > > Currently not particularily well: it doesn't move them at all (because they don't fit), and it _also_ doesn't move other objects past them. There's a TODO to make it possible to move objects around large objects (don't have to be > region-sized, also something like 1/2 region sized objects may have difficulty to move). I'll address that in a follow-up PR. > > Are you talking about parallel specific? Can you explain why region size > object size > 1/2 region size scenario? Thanks. I only used 1/2 region size as an example. It can affect any object: if there is not enough space in the target region, and there is no other preceding target region in the queue, we might not be able to move the object, or only move the object within its region. It's only that the problem becomes worse the larger the object is, and for objects > region-size it's currently guaranteed that we can not move it. Being able to move objects around large/un-movable objects would help a lot to reduce gaps. ------------- PR Comment: https://git.openjdk.org/lilliput/pull/195#issuecomment-2783733550 From wkemper at openjdk.org Mon Apr 7 16:28:14 2025 From: wkemper at openjdk.org (William Kemper) Date: Mon, 7 Apr 2025 16:28:14 GMT Subject: [master] RFR: 8353849: [Lilliput] Avoid race in compact identity hashcode In-Reply-To: References: Message-ID: <_MWs6M0adnHnppG_bazQ973qd8L7NqYyV7ki8yLrQGQ=.591bb9a6-7a27-4a8e-95de-52bde04bdf26@github.com> On Mon, 7 Apr 2025 12:48:02 GMT, Roman Kennke wrote: > Multiple GC threads can concurrently update an object's mark-word (Parallel, G1 and Shenandoah). We need to be careful when doing object-size calculations and pass-through the pre-loaded, safe mark-word, instead of re-loading the mark-word from the object. In the latter case, we might read a forwarding pointer and interpret the bits as hash-bits which would lead to wrong size-calculation and crash. > > Testing: > - hotspot_gc (+UCOH) LGTM ------------- Marked as reviewed by wkemper (Reviewer). PR Review: https://git.openjdk.org/lilliput/pull/196#pullrequestreview-2747423621 From rkennke at openjdk.org Mon Apr 7 17:48:14 2025 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 7 Apr 2025 17:48:14 GMT Subject: [master] RFR: 8347711: [Lilliput] Parallel GC support for compact identity hashcode [v5] In-Reply-To: References: Message-ID: > The Parallel GC does not yet support Lilliput 2 until now. The big problem has been that the Parallel Full GC is too rigid with respect to object sizes, and we could not make it work with compact identity hashcode, which requires that objects can grow during GC. > > The PR implements an alternative full GC for Parallel GC, which is more flexible. The algorithm mostly follows G1 and Shenandoah, with the difference that it creates temporary 'regions' (because Parallel GC does not use heap regions), with boundaries such that no object crosses region boundaries, and then after GC fill any gaps at end of regions with dummy objects. > > The implementation has a special 'serial' mode, which sets up only 4 regions which exactly match the 4 heap spaces (old, eden, from, to), and performs the forwarding and compaction phases serially to achieve perfect compaction at the expense of performance. (The marking and adjust-refs phases will still be done with parallel workers). > > I've run the micro benchmarks for systemgc, there seem to be only minor differences, and looks mostly like a few milliseconds offset in the new implementation: > > Baseline Full GC: > > AllDead.gc ss 25 31.120 ? 0.447 ms/op > AllLive.gc ss 25 83.655 ? 2.238 ms/op > DifferentObjectSizesArray.gc ss 25 179.725 ? 1.171 ms/op > DifferentObjectSizesHashMap.gc ss 25 186.011 ? 1.409 ms/op > DifferentObjectSizesTreeMap.gc ss 25 65.668 ? 3.333 ms/op > HalfDeadFirstPart.gc ss 25 64.862 ? 0.696 ms/op > HalfDeadInterleaved.gc ss 25 67.764 ? 3.139 ms/op > HalfDeadInterleavedChunks.gc ss 25 59.160 ? 1.667 ms/op > HalfDeadSecondPart.gc ss 25 66.210 ? 1.167 ms/op > HalfHashedHalfDead.gc ss 25 69.584 ? 2.276 ms/op > NoObjects.gc ss 25 18.462 ? 0.270 ms/op > OneBigObject.gc ss 25 587.425 ? 27.493 ms/op > > > New Parallel Full GC: > > > AllDead.gc ss 25 39.891 ? 0.461 ms/op > AllLive.gc ss 25 87.898 ? 1.940 ms/op > DifferentObjectSizesArray.gc ss 25 184.109 ? 0.795 ms/op > DifferentObjectSizesHashMap.gc ss 25 189.620 ? 2.236 ms/op > DifferentObjectSizesTreeMap.gc ss 25 69.915 ? 3.308 ms/op > HalfDeadFirstPart.gc ss 25 70.664 ? 0.804 ms/op > HalfDeadInterleaved.gc ss 25 71.318 ? 1.583 ms/op > HalfDeadInterleavedChunks.gc ss 25 65.050... Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Avoid more races ------------- Changes: - all: https://git.openjdk.org/lilliput/pull/195/files - new: https://git.openjdk.org/lilliput/pull/195/files/95728b46..40512654 Webrevs: - full: https://webrevs.openjdk.org/?repo=lilliput&pr=195&range=04 - incr: https://webrevs.openjdk.org/?repo=lilliput&pr=195&range=03-04 Stats: 19 lines in 13 files changed: 3 ins; 0 del; 16 mod Patch: https://git.openjdk.org/lilliput/pull/195.diff Fetch: git fetch https://git.openjdk.org/lilliput.git pull/195/head:pull/195 PR: https://git.openjdk.org/lilliput/pull/195 From rkennke at openjdk.org Mon Apr 7 19:52:46 2025 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 7 Apr 2025 19:52:46 GMT Subject: [master] RFR: 8353849: [Lilliput] Avoid race in compact identity hashcode [v2] In-Reply-To: References: Message-ID: > Multiple GC threads can concurrently update an object's mark-word (Parallel, G1 and Shenandoah). We need to be careful when doing object-size calculations and pass-through the pre-loaded, safe mark-word, instead of re-loading the mark-word from the object. In the latter case, we might read a forwarding pointer and interpret the bits as hash-bits which would lead to wrong size-calculation and crash. > > Testing: > - hotspot_gc (+UCOH) Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Avoid more races ------------- Changes: - all: https://git.openjdk.org/lilliput/pull/196/files - new: https://git.openjdk.org/lilliput/pull/196/files/12804a55..08ce0ac7 Webrevs: - full: https://webrevs.openjdk.org/?repo=lilliput&pr=196&range=01 - incr: https://webrevs.openjdk.org/?repo=lilliput&pr=196&range=00-01 Stats: 19 lines in 13 files changed: 3 ins; 0 del; 16 mod Patch: https://git.openjdk.org/lilliput/pull/196.diff Fetch: git fetch https://git.openjdk.org/lilliput.git pull/196/head:pull/196 PR: https://git.openjdk.org/lilliput/pull/196 From rkennke at openjdk.org Mon Apr 7 20:23:32 2025 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 7 Apr 2025 20:23:32 GMT Subject: [master] RFR: 8353849: [Lilliput] Avoid race in compact identity hashcode [v2] In-Reply-To: References: Message-ID: <5J-012tBKpz1iIzke2Y1OogOnHamR6k7qpet5d3eX7E=.806c3d12-7128-4b17-9c7e-14134d8ee6ac@github.com> On Mon, 7 Apr 2025 12:55:11 GMT, Zhengyu Gu wrote: >> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: >> >> Avoid more races > > Seem reasonable. Thanks @zhengyu123 and @earthling-amzn! I found more races in that code path and would need a re-review! ------------- PR Comment: https://git.openjdk.org/lilliput/pull/196#issuecomment-2784532118 From rkennke at openjdk.org Tue Apr 8 10:39:58 2025 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 8 Apr 2025 10:39:58 GMT Subject: [master] RFR: 8353849: [Lilliput] Avoid race in compact identity hashcode [v3] In-Reply-To: References: Message-ID: > Multiple GC threads can concurrently update an object's mark-word (Parallel, G1 and Shenandoah). We need to be careful when doing object-size calculations and pass-through the pre-loaded, safe mark-word, instead of re-loading the mark-word from the object. In the latter case, we might read a forwarding pointer and interpret the bits as hash-bits which would lead to wrong size-calculation and crash. > > Testing: > - hotspot_gc (+UCOH) Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Fix 32 bit build ------------- Changes: - all: https://git.openjdk.org/lilliput/pull/196/files - new: https://git.openjdk.org/lilliput/pull/196/files/08ce0ac7..47e1ea05 Webrevs: - full: https://webrevs.openjdk.org/?repo=lilliput&pr=196&range=02 - incr: https://webrevs.openjdk.org/?repo=lilliput&pr=196&range=01-02 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/lilliput/pull/196.diff Fetch: git fetch https://git.openjdk.org/lilliput.git pull/196/head:pull/196 PR: https://git.openjdk.org/lilliput/pull/196 From rkennke at openjdk.org Tue Apr 8 11:19:36 2025 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 8 Apr 2025 11:19:36 GMT Subject: [master] RFR: 8353849: [Lilliput] Avoid race in compact identity hashcode [v4] In-Reply-To: References: Message-ID: > Multiple GC threads can concurrently update an object's mark-word (Parallel, G1 and Shenandoah). We need to be careful when doing object-size calculations and pass-through the pre-loaded, safe mark-word, instead of re-loading the mark-word from the object. In the latter case, we might read a forwarding pointer and interpret the bits as hash-bits which would lead to wrong size-calculation and crash. > > Testing: > - hotspot_gc (+UCOH) Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Fix 32 bit build, again ------------- Changes: - all: https://git.openjdk.org/lilliput/pull/196/files - new: https://git.openjdk.org/lilliput/pull/196/files/47e1ea05..c76ba87e Webrevs: - full: https://webrevs.openjdk.org/?repo=lilliput&pr=196&range=03 - incr: https://webrevs.openjdk.org/?repo=lilliput&pr=196&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/lilliput/pull/196.diff Fetch: git fetch https://git.openjdk.org/lilliput.git pull/196/head:pull/196 PR: https://git.openjdk.org/lilliput/pull/196 From rkennke at openjdk.org Tue Apr 8 11:25:53 2025 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 8 Apr 2025 11:25:53 GMT Subject: [master] RFR: 8347711: [Lilliput] Parallel GC support for compact identity hashcode [v6] In-Reply-To: References: Message-ID: > The Parallel GC does not yet support Lilliput 2 until now. The big problem has been that the Parallel Full GC is too rigid with respect to object sizes, and we could not make it work with compact identity hashcode, which requires that objects can grow during GC. > > The PR implements an alternative full GC for Parallel GC, which is more flexible. The algorithm mostly follows G1 and Shenandoah, with the difference that it creates temporary 'regions' (because Parallel GC does not use heap regions), with boundaries such that no object crosses region boundaries, and then after GC fill any gaps at end of regions with dummy objects. > > The implementation has a special 'serial' mode, which sets up only 4 regions which exactly match the 4 heap spaces (old, eden, from, to), and performs the forwarding and compaction phases serially to achieve perfect compaction at the expense of performance. (The marking and adjust-refs phases will still be done with parallel workers). > > I've run the micro benchmarks for systemgc, there seem to be only minor differences, and looks mostly like a few milliseconds offset in the new implementation: > > Baseline Full GC: > > AllDead.gc ss 25 31.120 ? 0.447 ms/op > AllLive.gc ss 25 83.655 ? 2.238 ms/op > DifferentObjectSizesArray.gc ss 25 179.725 ? 1.171 ms/op > DifferentObjectSizesHashMap.gc ss 25 186.011 ? 1.409 ms/op > DifferentObjectSizesTreeMap.gc ss 25 65.668 ? 3.333 ms/op > HalfDeadFirstPart.gc ss 25 64.862 ? 0.696 ms/op > HalfDeadInterleaved.gc ss 25 67.764 ? 3.139 ms/op > HalfDeadInterleavedChunks.gc ss 25 59.160 ? 1.667 ms/op > HalfDeadSecondPart.gc ss 25 66.210 ? 1.167 ms/op > HalfHashedHalfDead.gc ss 25 69.584 ? 2.276 ms/op > NoObjects.gc ss 25 18.462 ? 0.270 ms/op > OneBigObject.gc ss 25 587.425 ? 27.493 ms/op > > > New Parallel Full GC: > > > AllDead.gc ss 25 39.891 ? 0.461 ms/op > AllLive.gc ss 25 87.898 ? 1.940 ms/op > DifferentObjectSizesArray.gc ss 25 184.109 ? 0.795 ms/op > DifferentObjectSizesHashMap.gc ss 25 189.620 ? 2.236 ms/op > DifferentObjectSizesTreeMap.gc ss 25 69.915 ? 3.308 ms/op > HalfDeadFirstPart.gc ss 25 70.664 ? 0.804 ms/op > HalfDeadInterleaved.gc ss 25 71.318 ? 1.583 ms/op > HalfDeadInterleavedChunks.gc ss 25 65.050... Roman Kennke has updated the pull request incrementally with two additional commits since the last revision: - Revert "Avoid racy update in Klass::expand_for_hash()" This reverts commit 95728b46ce8be9610988ab61ebe35235bb1f23ff. - Revert "Avoid more races" This reverts commit 4051265403db82450cb1624149dbacc85724ff03. ------------- Changes: - all: https://git.openjdk.org/lilliput/pull/195/files - new: https://git.openjdk.org/lilliput/pull/195/files/40512654..163798bb Webrevs: - full: https://webrevs.openjdk.org/?repo=lilliput&pr=195&range=05 - incr: https://webrevs.openjdk.org/?repo=lilliput&pr=195&range=04-05 Stats: 26 lines in 14 files changed: 0 ins; 3 del; 23 mod Patch: https://git.openjdk.org/lilliput/pull/195.diff Fetch: git fetch https://git.openjdk.org/lilliput.git pull/195/head:pull/195 PR: https://git.openjdk.org/lilliput/pull/195 From stuefe at openjdk.org Tue Apr 8 13:29:41 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 8 Apr 2025 13:29:41 GMT Subject: [master] RFR: 8347711: [Lilliput] Parallel GC support for compact identity hashcode [v6] In-Reply-To: References: Message-ID: On Tue, 8 Apr 2025 11:25:53 GMT, Roman Kennke wrote: >> The Parallel GC does not yet support Lilliput 2 until now. The big problem has been that the Parallel Full GC is too rigid with respect to object sizes, and we could not make it work with compact identity hashcode, which requires that objects can grow during GC. >> >> The PR implements an alternative full GC for Parallel GC, which is more flexible. The algorithm mostly follows G1 and Shenandoah, with the difference that it creates temporary 'regions' (because Parallel GC does not use heap regions), with boundaries such that no object crosses region boundaries, and then after GC fill any gaps at end of regions with dummy objects. >> >> The implementation has a special 'serial' mode, which sets up only 4 regions which exactly match the 4 heap spaces (old, eden, from, to), and performs the forwarding and compaction phases serially to achieve perfect compaction at the expense of performance. (The marking and adjust-refs phases will still be done with parallel workers). >> >> I've run the micro benchmarks for systemgc, there seem to be only minor differences, and looks mostly like a few milliseconds offset in the new implementation: >> >> Baseline Full GC: >> >> AllDead.gc ss 25 31.120 ? 0.447 ms/op >> AllLive.gc ss 25 83.655 ? 2.238 ms/op >> DifferentObjectSizesArray.gc ss 25 179.725 ? 1.171 ms/op >> DifferentObjectSizesHashMap.gc ss 25 186.011 ? 1.409 ms/op >> DifferentObjectSizesTreeMap.gc ss 25 65.668 ? 3.333 ms/op >> HalfDeadFirstPart.gc ss 25 64.862 ? 0.696 ms/op >> HalfDeadInterleaved.gc ss 25 67.764 ? 3.139 ms/op >> HalfDeadInterleavedChunks.gc ss 25 59.160 ? 1.667 ms/op >> HalfDeadSecondPart.gc ss 25 66.210 ? 1.167 ms/op >> HalfHashedHalfDead.gc ss 25 69.584 ? 2.276 ms/op >> NoObjects.gc ss 25 18.462 ? 0.270 ms/op >> OneBigObject.gc ss 25 587.425 ? 27.493 ms/op >> >> >> New Parallel Full GC: >> >> >> AllDead.gc ss 25 39.891 ? 0.461 ms/op >> AllLive.gc ss 25 87.898 ? 1.940 ms/op >> DifferentObjectSizesArray.gc ss 25 184.109 ? 0.795 ms/op >> DifferentObjectSizesHashMap.gc ss 25 189.620 ? 2.236 ms/op >> DifferentObjectSizesTreeMap.gc ss 25 69.915 ? 3.308 ms/op >> HalfDeadFirstPart.gc ss 25 70.664 ? 0.804 ms/op >> HalfDeadInterleaved.gc ss 25 71.31... > > Roman Kennke has updated the pull request incrementally with two additional commits since the last revision: > > - Revert "Avoid racy update in Klass::expand_for_hash()" > > This reverts commit 95728b46ce8be9610988ab61ebe35235bb1f23ff. > - Revert "Avoid more races" > > This reverts commit 4051265403db82450cb1624149dbacc85724ff03. Okay ------------- Marked as reviewed by stuefe (Reviewer). PR Review: https://git.openjdk.org/lilliput/pull/195#pullrequestreview-2749984515 From wkemper at openjdk.org Tue Apr 8 16:51:53 2025 From: wkemper at openjdk.org (William Kemper) Date: Tue, 8 Apr 2025 16:51:53 GMT Subject: [master] RFR: 8353849: [Lilliput] Avoid race in compact identity hashcode [v4] In-Reply-To: References: Message-ID: On Tue, 8 Apr 2025 11:19:36 GMT, Roman Kennke wrote: >> Multiple GC threads can concurrently update an object's mark-word (Parallel, G1 and Shenandoah). We need to be careful when doing object-size calculations and pass-through the pre-loaded, safe mark-word, instead of re-loading the mark-word from the object. In the latter case, we might read a forwarding pointer and interpret the bits as hash-bits which would lead to wrong size-calculation and crash. >> >> Testing: >> - hotspot_gc (+UCOH) > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Fix 32 bit build, again Latest revision passes internal testing pipelines on x86 and aarch64. Looks better to me! ------------- Marked as reviewed by wkemper (Reviewer). PR Review: https://git.openjdk.org/lilliput/pull/196#pullrequestreview-2750725621 From rkennke at openjdk.org Tue Apr 8 18:46:47 2025 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 8 Apr 2025 18:46:47 GMT Subject: [master] RFR: 8353849: [Lilliput] Avoid race in compact identity hashcode [v4] In-Reply-To: References: Message-ID: <6ojTSsrEmSeuQjWL-Lhw2Xnf8_Acgqx8UR3b_TWc4YY=.b59aaed0-c6e2-4393-9e5f-df80ef196988@github.com> On Tue, 8 Apr 2025 11:19:36 GMT, Roman Kennke wrote: >> Multiple GC threads can concurrently update an object's mark-word (Parallel, G1 and Shenandoah). We need to be careful when doing object-size calculations and pass-through the pre-loaded, safe mark-word, instead of re-loading the mark-word from the object. In the latter case, we might read a forwarding pointer and interpret the bits as hash-bits which would lead to wrong size-calculation and crash. >> >> Testing: >> - hotspot_gc (+UCOH) > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Fix 32 bit build, again Thanks! ------------- PR Comment: https://git.openjdk.org/lilliput/pull/196#issuecomment-2787364588 From rkennke at openjdk.org Tue Apr 8 18:46:48 2025 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 8 Apr 2025 18:46:48 GMT Subject: [master] Integrated: 8353849: [Lilliput] Avoid race in compact identity hashcode In-Reply-To: References: Message-ID: On Mon, 7 Apr 2025 12:48:02 GMT, Roman Kennke wrote: > Multiple GC threads can concurrently update an object's mark-word (Parallel, G1 and Shenandoah). We need to be careful when doing object-size calculations and pass-through the pre-loaded, safe mark-word, instead of re-loading the mark-word from the object. In the latter case, we might read a forwarding pointer and interpret the bits as hash-bits which would lead to wrong size-calculation and crash. > > Testing: > - hotspot_gc (+UCOH) This pull request has now been integrated. Changeset: e20e6c84 Author: Roman Kennke URL: https://git.openjdk.org/lilliput/commit/e20e6c8450d355478a564f9b6147ab5bc0ffdf7d Stats: 27 lines in 14 files changed: 4 ins; 0 del; 23 mod 8353849: [Lilliput] Avoid race in compact identity hashcode Reviewed-by: zgu, wkemper ------------- PR: https://git.openjdk.org/lilliput/pull/196 From zjx001202 at gmail.com Wed Apr 9 17:01:19 2025 From: zjx001202 at gmail.com (Glavo) Date: Thu, 10 Apr 2025 01:01:19 +0800 Subject: Is it possible to reimplement 64-bit object header based on improved i-hash? Message-ID: Just a whim: Is it possible to reimplement 64-bit object header based on improved i-hash? Compared to JEP 450, I feel like this seems more suitable as the default behavior of the JVM. This will not limit the number of classes and will reserve enough bits in the mark word for new GC or other things. It will also be easier to expand to 64-bit/128-bit i-hash in the future. I think it's a perfect evolution of the current 96-bit object header. As for Lilliput 2, although it is very good, it reserves too few bits for mark words. Therefore, even if it is delivered, a 64-bit object header implementation may be retained for a long time in the future to cope with possible future needs. Glavo -------------- next part -------------- An HTML attachment was scrubbed... URL: From rkennke at openjdk.org Thu Apr 10 11:47:59 2025 From: rkennke at openjdk.org (Roman Kennke) Date: Thu, 10 Apr 2025 11:47:59 GMT Subject: [master] RFR: 8347711: [Lilliput] Parallel GC support for compact identity hashcode [v6] In-Reply-To: References: Message-ID: On Tue, 8 Apr 2025 11:25:53 GMT, Roman Kennke wrote: >> The Parallel GC does not yet support Lilliput 2 until now. The big problem has been that the Parallel Full GC is too rigid with respect to object sizes, and we could not make it work with compact identity hashcode, which requires that objects can grow during GC. >> >> The PR implements an alternative full GC for Parallel GC, which is more flexible. The algorithm mostly follows G1 and Shenandoah, with the difference that it creates temporary 'regions' (because Parallel GC does not use heap regions), with boundaries such that no object crosses region boundaries, and then after GC fill any gaps at end of regions with dummy objects. >> >> The implementation has a special 'serial' mode, which sets up only 4 regions which exactly match the 4 heap spaces (old, eden, from, to), and performs the forwarding and compaction phases serially to achieve perfect compaction at the expense of performance. (The marking and adjust-refs phases will still be done with parallel workers). >> >> I've run the micro benchmarks for systemgc, there seem to be only minor differences, and looks mostly like a few milliseconds offset in the new implementation: >> >> Baseline Full GC: >> >> AllDead.gc ss 25 31.120 ? 0.447 ms/op >> AllLive.gc ss 25 83.655 ? 2.238 ms/op >> DifferentObjectSizesArray.gc ss 25 179.725 ? 1.171 ms/op >> DifferentObjectSizesHashMap.gc ss 25 186.011 ? 1.409 ms/op >> DifferentObjectSizesTreeMap.gc ss 25 65.668 ? 3.333 ms/op >> HalfDeadFirstPart.gc ss 25 64.862 ? 0.696 ms/op >> HalfDeadInterleaved.gc ss 25 67.764 ? 3.139 ms/op >> HalfDeadInterleavedChunks.gc ss 25 59.160 ? 1.667 ms/op >> HalfDeadSecondPart.gc ss 25 66.210 ? 1.167 ms/op >> HalfHashedHalfDead.gc ss 25 69.584 ? 2.276 ms/op >> NoObjects.gc ss 25 18.462 ? 0.270 ms/op >> OneBigObject.gc ss 25 587.425 ? 27.493 ms/op >> >> >> New Parallel Full GC: >> >> >> AllDead.gc ss 25 39.891 ? 0.461 ms/op >> AllLive.gc ss 25 87.898 ? 1.940 ms/op >> DifferentObjectSizesArray.gc ss 25 184.109 ? 0.795 ms/op >> DifferentObjectSizesHashMap.gc ss 25 189.620 ? 2.236 ms/op >> DifferentObjectSizesTreeMap.gc ss 25 69.915 ? 3.308 ms/op >> HalfDeadFirstPart.gc ss 25 70.664 ? 0.804 ms/op >> HalfDeadInterleaved.gc ss 25 71.31... > > Roman Kennke has updated the pull request incrementally with two additional commits since the last revision: > > - Revert "Avoid racy update in Klass::expand_for_hash()" > > This reverts commit 95728b46ce8be9610988ab61ebe35235bb1f23ff. > - Revert "Avoid more races" > > This reverts commit 4051265403db82450cb1624149dbacc85724ff03. Thanks! ------------- PR Comment: https://git.openjdk.org/lilliput/pull/195#issuecomment-2792467378 From rkennke at openjdk.org Thu Apr 10 11:48:01 2025 From: rkennke at openjdk.org (Roman Kennke) Date: Thu, 10 Apr 2025 11:48:01 GMT Subject: [master] Integrated: 8347711: [Lilliput] Parallel GC support for compact identity hashcode In-Reply-To: References: Message-ID: <6YM1QMoqRWOOvasvytPtOPE8yRM01RqOKhDhCJ6dONc=.6c12581f-46a0-4955-ba58-9af208c9aa84@github.com> On Fri, 14 Mar 2025 11:25:23 GMT, Roman Kennke wrote: > The Parallel GC does not yet support Lilliput 2 until now. The big problem has been that the Parallel Full GC is too rigid with respect to object sizes, and we could not make it work with compact identity hashcode, which requires that objects can grow during GC. > > The PR implements an alternative full GC for Parallel GC, which is more flexible. The algorithm mostly follows G1 and Shenandoah, with the difference that it creates temporary 'regions' (because Parallel GC does not use heap regions), with boundaries such that no object crosses region boundaries, and then after GC fill any gaps at end of regions with dummy objects. > > The implementation has a special 'serial' mode, which sets up only 4 regions which exactly match the 4 heap spaces (old, eden, from, to), and performs the forwarding and compaction phases serially to achieve perfect compaction at the expense of performance. (The marking and adjust-refs phases will still be done with parallel workers). > > I've run the micro benchmarks for systemgc, there seem to be only minor differences, and looks mostly like a few milliseconds offset in the new implementation: > > Baseline Full GC: > > AllDead.gc ss 25 31.120 ? 0.447 ms/op > AllLive.gc ss 25 83.655 ? 2.238 ms/op > DifferentObjectSizesArray.gc ss 25 179.725 ? 1.171 ms/op > DifferentObjectSizesHashMap.gc ss 25 186.011 ? 1.409 ms/op > DifferentObjectSizesTreeMap.gc ss 25 65.668 ? 3.333 ms/op > HalfDeadFirstPart.gc ss 25 64.862 ? 0.696 ms/op > HalfDeadInterleaved.gc ss 25 67.764 ? 3.139 ms/op > HalfDeadInterleavedChunks.gc ss 25 59.160 ? 1.667 ms/op > HalfDeadSecondPart.gc ss 25 66.210 ? 1.167 ms/op > HalfHashedHalfDead.gc ss 25 69.584 ? 2.276 ms/op > NoObjects.gc ss 25 18.462 ? 0.270 ms/op > OneBigObject.gc ss 25 587.425 ? 27.493 ms/op > > > New Parallel Full GC: > > > AllDead.gc ss 25 39.891 ? 0.461 ms/op > AllLive.gc ss 25 87.898 ? 1.940 ms/op > DifferentObjectSizesArray.gc ss 25 184.109 ? 0.795 ms/op > DifferentObjectSizesHashMap.gc ss 25 189.620 ? 2.236 ms/op > DifferentObjectSizesTreeMap.gc ss 25 69.915 ? 3.308 ms/op > HalfDeadFirstPart.gc ss 25 70.664 ? 0.804 ms/op > HalfDeadInterleaved.gc ss 25 71.318 ? 1.583 ms/op > HalfDeadInterleavedChunks.gc ss 25 65.050... This pull request has now been integrated. Changeset: 4b6094a0 Author: Roman Kennke URL: https://git.openjdk.org/lilliput/commit/4b6094a023e6d9f3c74a0afc65192d7e81c7e3a0 Stats: 2081 lines in 12 files changed: 2065 ins; 4 del; 12 mod 8347711: [Lilliput] Parallel GC support for compact identity hashcode Reviewed-by: stuefe ------------- PR: https://git.openjdk.org/lilliput/pull/195 From rkennke at openjdk.org Thu Apr 10 13:31:31 2025 From: rkennke at openjdk.org (Roman Kennke) Date: Thu, 10 Apr 2025 13:31:31 GMT Subject: [master] RFR: Merge jdk:jdk-25+17 Message-ID: As title says. As always, made merge to clean tag, then cherry-picked our own changes on top. ------------- Commit messages: - 8347711: [Lilliput] Parallel GC support for compact identity hashcode - 8347710: [Lilliput] Implement 4 byte headers - 8320761: [Lilliput] Implement compact identity hashcode - 8346011: [Lilliput] Compact Full-GC Forwarding - Merge branch 'master' into merge-jdk-25+17 - 8338675: javac shouldn't silently change .jar files on the classpath - 8353058: [PPC64] Some IR framework tests are failing after JDK-8352595 - 8353325: Rewrite appcds/methodHandles test cases to use CDSAppTester - 8353584: [BACKOUT] DaCapo xalan performance with -XX:+UseObjectMonitorTable - 8352645: Add tool support to check order of includes - ... and 705 more: https://git.openjdk.org/lilliput/compare/4b6094a0...e4526b07 The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.org/?repo=lilliput&pr=197&range=00.0 - jdk:jdk-25+17: https://webrevs.openjdk.org/?repo=lilliput&pr=197&range=00.1 Changes: https://git.openjdk.org/lilliput/pull/197/files Stats: 198263 lines in 4794 files changed: 89847 ins; 82364 del; 26052 mod Patch: https://git.openjdk.org/lilliput/pull/197.diff Fetch: git fetch https://git.openjdk.org/lilliput.git pull/197/head:pull/197 PR: https://git.openjdk.org/lilliput/pull/197 From rkennke at amazon.de Thu Apr 10 14:27:41 2025 From: rkennke at amazon.de (Kennke, Roman) Date: Thu, 10 Apr 2025 14:27:41 +0000 Subject: Is it possible to reimplement 64-bit object header based on improved i-hash? In-Reply-To: References: Message-ID: <723BBFF4-9220-475C-9DED-91381BE5BF72@amazon.de> Hi Glavo, > Just a whim: Is it possible to reimplement 64-bit object header based on improved i-hash? > Compared to JEP 450, I feel like this seems more suitable as the default behavior of the JVM. > This will not limit the number of classes and will reserve enough bits in the mark word for new GC or other things. > It will also be easier to expand to 64-bit/128-bit i-hash in the future. > I think it's a perfect evolution of the current 96-bit object header. > Only very few applications, if any, would benefit from having more classes (>500.000 currently). However, *almost all* applications would benefit from smaller 4-byte headers. It seems an obvious trade-off to choose 4-byte headers. We do have a plan how to support more classes, if that?s necessary, but to be honest, I currently doubt that any application reaches that limit. > As for Lilliput 2, although it is very good, it reserves too few bits for mark words. No, I don?t think so. We currently even reserve 4 bits for future work coming from Valhalla, and Valhalla may not even need them all. And I would not keep around spare bits just in case that we ever need them. We did have spare bits in the header ever since 64 bit JVMs became a thing (pre-dating OpenJDK), and they have never been used. What?s not available can?t be used, period, and we need to find ways to deal with such situations when they arise. It doesn?t make sense to punish ourselves now, just in case we need something later, which may well never happen at all. > Therefore, even if it is delivered, a 64-bit object header implementation may be retained for a long time in the future to cope with possible future needs. Nope. If and when 4-byte headers are delivered, we will get rid of any old implementation eventually. Cheers, Roman From rkennke at openjdk.org Mon Apr 14 13:16:52 2025 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 14 Apr 2025 13:16:52 GMT Subject: [master] RFR: Merge jdk:jdk-25+17 [v2] In-Reply-To: References: Message-ID: > As title says. > As always, made merge to clean tag, then cherry-picked our own changes on top. 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. ------------- Changes: - all: https://git.openjdk.org/lilliput/pull/197/files - new: https://git.openjdk.org/lilliput/pull/197/files/e4526b07..e4526b07 Webrevs: - full: https://webrevs.openjdk.org/?repo=lilliput&pr=197&range=01 - incr: https://webrevs.openjdk.org/?repo=lilliput&pr=197&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/lilliput/pull/197.diff Fetch: git fetch https://git.openjdk.org/lilliput.git pull/197/head:pull/197 PR: https://git.openjdk.org/lilliput/pull/197 From rkennke at openjdk.org Mon Apr 14 13:16:54 2025 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 14 Apr 2025 13:16:54 GMT Subject: [master] Withdrawn: Merge jdk:jdk-25+17 In-Reply-To: References: Message-ID: On Thu, 10 Apr 2025 13:25:37 GMT, Roman Kennke wrote: > As title says. > As always, made merge to clean tag, then cherry-picked our own changes on top. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/lilliput/pull/197