From duke at openjdk.org Tue Jan 2 04:04:02 2024 From: duke at openjdk.org (duke) Date: Tue, 2 Jan 2024 04:04:02 GMT Subject: [master] Withdrawn: 8304710: [Lilliput] Use forwarding table for sliding GCs In-Reply-To: References: Message-ID: On Thu, 23 Mar 2023 19:25:40 GMT, Roman Kennke wrote: > This changes the full-GC forwarding of Serial, Parallel, G1 and Shenandoah to use a forwarding table instead of the fancy SlidingForwarding that we had until now. SlidingForwarding has been problematic because it did not work universally, in particular we needed to disable the G1 serial full GC (the last last ditch GC, after parallel full GC failed). Also, sliding forwarding would not work when we start working towards 32bit headers. > > The implementation of the forwarding table is a dense array of forwardings, with sorted entries and binary search. For details, have a look at the comments at the top of class ForwardingTable. > > The change also greatly reduces the upstream diff. > > In G1 I added a little code to count the marked objects in each region by counting bits in the mark-bitmap. > > In Serial GC I likewise added some code to count new vs old objects during full-GC marking. Here there would be the alternative to treat the heap as a single region, and count marked objects without distinguishing old vs young. The problem is that old is allocated in higher memory than young, and the full-GC compacts old-gen first, and then young-gen, which breaks the assumption in ForwardingTable, which leads to very slow forwarding insertions. I also tried to simply swap the old and young reserved memory, and that is possible, but triggers all sorts of related changes where the memory order is implicitely used for stuff like is_in_young() etc. > > Testing: > - [x] tier1 > - [x] tier2 This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/lilliput/pull/83 From rkennke at openjdk.org Fri Jan 12 13:45:21 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Fri, 12 Jan 2024 13:45:21 GMT Subject: [master] RFR: 8323192: [Lilliput] Implement new Serial Full GC Message-ID: This implements a compressor-style compacting full-GC for the Serial GC, which does not require storing any forwarding pointers in object headers. For a description of the algorithm, see the text block at the beginning of serialCompressor.hpp. Notice that the algorithm uses extra memory: 1/64th of the heap-size is allocated for the marking bitmap and another 1/64th of the heap-size is allocated for the block-offset-table. On the other hand, it does not use storage for preserved-marks table, which is very unpredictable (often it is quite small, but if a workload churns locks or mass-i-hashes objects, it can become pretty large). Performance: I tested performance using the following program, which exxagerates the performance impact of the algorithm. Real-world workloads would be more dominated by the copying. public class Retain { static final int RETAINED = Integer.getInteger("retained", 10_000_000); static final int GCS = Integer.getInteger("gcs", 100); static Object[] OBJECTS = new Object[RETAINED]; public static void main(String... args) { for (int t = 0; t < GCS; t++) { for (int c = 0; c < RETAINED; c++) { OBJECTS[c] = new Object(); } System.gc(); } } } The new algorithm can be tested by: `java -XX:+UseSerialGC -XX:+UnlockExperimentalVMOptions -XX:+UseCompressorFullGC -Xlog:gc*:file=compressor.txt Retain ` Average time for full-GCs on by machine: - baseline: 394.61ms - compressor: 411.61ms (+4.3%) Testing: - [x] tier1 +UseSerialGC +UseFullGCCompressor x86_64 - [x] tier1 +UseSerialGC +UseFullGCCompressor x86 - [ ] tier1 +UseSerialGC +UseFullGCCompressor aarch64 - [x] tier1 +UseSerialGC +UseCompactObjectHeaders x86_64 - [x] tier1 +UseSerialGC +UseCompactObjectHeaders x86 - [ ] tier1 +UseSerialGC +UseCompactObjectHeaders aarch64 ------------- Commit messages: - Add missing include - More cleanups and docs - Better space iteration, some docs, etc - Array chunking - Various stuff - Add missing fwd declaration - No tabs - Initial prototype Changes: https://git.openjdk.org/lilliput/pull/122/files Webrev: https://webrevs.openjdk.org/?repo=lilliput&pr=122&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8323192 Stats: 871 lines in 11 files changed: 853 ins; 15 del; 3 mod Patch: https://git.openjdk.org/lilliput/pull/122.diff Fetch: git fetch https://git.openjdk.org/lilliput.git pull/122/head:pull/122 PR: https://git.openjdk.org/lilliput/pull/122 From rkennke at openjdk.org Fri Jan 12 21:25:09 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Fri, 12 Jan 2024 21:25:09 GMT Subject: [master] RFR: 8323192: [Lilliput] Implement new Serial Full GC [v2] In-Reply-To: References: Message-ID: <72okn4lfTqtpQHwooltBlDxcfAqf4Rb_tn4PZCpIJtM=.4a618b9e-f215-4a8c-8d16-47edbf462333@github.com> > This implements a compressor-style compacting full-GC for the Serial GC, which does not require storing any forwarding pointers in object headers. > > For a description of the algorithm, see the text block at the beginning of serialCompressor.hpp. > > Notice that the algorithm uses extra memory: 1/64th of the heap-size is allocated for the marking bitmap and another 1/64th of the heap-size is allocated for the block-offset-table. On the other hand, it does not use storage for preserved-marks table, which is very unpredictable (often it is quite small, but if a workload churns locks or mass-i-hashes objects, it can become pretty large). > > Performance: > I tested performance using the following program, which exxagerates the performance impact of the algorithm. Real-world workloads would be more dominated by the copying. > > > public class Retain { > static final int RETAINED = Integer.getInteger("retained", 10_000_000); > static final int GCS = Integer.getInteger("gcs", 100); > static Object[] OBJECTS = new Object[RETAINED]; > > public static void main(String... args) { > for (int t = 0; t < GCS; t++) { > for (int c = 0; c < RETAINED; c++) { > OBJECTS[c] = new Object(); > } > System.gc(); > } > } > } > > > > The new algorithm can be tested by: > `java -XX:+UseSerialGC -XX:+UnlockExperimentalVMOptions -XX:+UseCompressorFullGC -Xlog:gc*:file=compressor.txt Retain > ` > > Average time for full-GCs on by machine: > - baseline: 394.61ms > - compressor: 411.61ms (+4.3%) > > Testing: > - [x] tier1 +UseSerialGC +UseFullGCCompressor x86_64 > - [x] tier1 +UseSerialGC +UseFullGCCompressor x86 > - [ ] tier1 +UseSerialGC +UseFullGCCompressor aarch64 > - [x] tier1 +UseSerialGC +UseCompactObjectHeaders x86_64 > - [x] tier1 +UseSerialGC +UseCompactObjectHeaders x86 > - [ ] tier1 +UseSerialGC +UseCompactObjectHeaders aarch64 Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Don't use __builtin_popcount() ------------- Changes: - all: https://git.openjdk.org/lilliput/pull/122/files - new: https://git.openjdk.org/lilliput/pull/122/files/f781c147..c2c4a011 Webrevs: - full: https://webrevs.openjdk.org/?repo=lilliput&pr=122&range=01 - incr: https://webrevs.openjdk.org/?repo=lilliput&pr=122&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/lilliput/pull/122.diff Fetch: git fetch https://git.openjdk.org/lilliput.git pull/122/head:pull/122 PR: https://git.openjdk.org/lilliput/pull/122 From duke at openjdk.org Wed Jan 17 01:02:17 2024 From: duke at openjdk.org (duke) Date: Wed, 17 Jan 2024 01:02:17 GMT Subject: [master] Withdrawn: 8319185: [Lilliput] Enable and fix vectorization tests In-Reply-To: References: Message-ID: On Tue, 21 Nov 2023 10:54:01 GMT, Roman Kennke wrote: > The change does two (related) things: > - It white-lists the UseCompactObjectHeaders flag in the IR testing framework. Without this, the flag would not be passed through to any IR framework test. > - That first change makes 3 tests fail. Those are all vectorization tests, and they are failing because 'small' array types (4-byte-elements and smaller) no longer have their elements aligned at 8-byte-boundaries. This throws off vectorization because this only kicks in on aligned accesses. The fix is to allocate those arrays a little larger and align-up the test data to the next 8-byte-boundary. (And no, Lilliput does not break vectorization in general, but it can change the characteristics in particular cases.) > > Testing: > - [x] compiler/c2/irTests/TestVectorizationMismatchedAccess.java +UCOH > - [x] compiler/c2/irTests/TestVectorizationNotRun.java +UCOH > - [x] compiler/loopopts/superword/TestIndependentPacksWithCyclicDependency.java +UCOH > - [x] compiler/c2/irTests/TestVectorizationMismatchedAccess.java -UCOH > - [x] compiler/c2/irTests/TestVectorizationNotRun.java -UCOH > - [x] compiler/loopopts/superword/TestIndependentPacksWithCyclicDependency.java -UCOH > - [x] tier1 +UCOH > - [x] tier1 -UCOH This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/lilliput/pull/118 From stuefe at openjdk.org Fri Jan 19 14:01:12 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 19 Jan 2024 14:01:12 GMT Subject: [master] RFR: 8319185: [Lilliput] Enable and fix vectorization tests In-Reply-To: References: Message-ID: On Tue, 21 Nov 2023 10:54:01 GMT, Roman Kennke wrote: > The change does two (related) things: > - It white-lists the UseCompactObjectHeaders flag in the IR testing framework. Without this, the flag would not be passed through to any IR framework test. > - That first change makes 3 tests fail. Those are all vectorization tests, and they are failing because 'small' array types (4-byte-elements and smaller) no longer have their elements aligned at 8-byte-boundaries. This throws off vectorization because this only kicks in on aligned accesses. The fix is to allocate those arrays a little larger and align-up the test data to the next 8-byte-boundary. (And no, Lilliput does not break vectorization in general, but it can change the characteristics in particular cases.) > > Testing: > - [x] compiler/c2/irTests/TestVectorizationMismatchedAccess.java +UCOH > - [x] compiler/c2/irTests/TestVectorizationNotRun.java +UCOH > - [x] compiler/loopopts/superword/TestIndependentPacksWithCyclicDependency.java +UCOH > - [x] compiler/c2/irTests/TestVectorizationMismatchedAccess.java -UCOH > - [x] compiler/c2/irTests/TestVectorizationNotRun.java -UCOH > - [x] compiler/loopopts/superword/TestIndependentPacksWithCyclicDependency.java -UCOH > - [x] tier1 +UCOH > - [x] tier1 -UCOH Hi Roman, was there a reason you did not follow up on this? Or just lack of time? PR looks fine to me. ------------- PR Comment: https://git.openjdk.org/lilliput/pull/118#issuecomment-1900472296 From rkennke at openjdk.org Fri Jan 19 15:30:10 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Fri, 19 Jan 2024 15:30:10 GMT Subject: [master] RFR: 8319185: [Lilliput] Enable and fix vectorization tests In-Reply-To: References:

Message-ID: On Fri, 19 Jan 2024 13:58:28 GMT, Thomas Stuefe wrote: > Hi Roman, was there a reason you did not follow up on this? Or just lack of time? PR looks fine to me. I had some discussions with Oracle engineers and they had concerns. I'm currently thinking that it might be reasonable to move straight to 4-byte-headers and avoid any array alignment surprises to begin with. ------------- PR Comment: https://git.openjdk.org/lilliput/pull/118#issuecomment-1900623773 From stuefe at openjdk.org Mon Jan 22 15:12:00 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 22 Jan 2024 15:12:00 GMT Subject: [master] RFR: 8319185: [Lilliput] Enable and fix vectorization tests In-Reply-To: References:

Message-ID: On Fri, 19 Jan 2024 15:26:57 GMT, Roman Kennke wrote: > > Hi Roman, was there a reason you did not follow up on this? Or just lack of time? PR looks fine to me. > > I had some discussions with Oracle engineers and they had concerns. I'm currently thinking that it might be reasonable to move straight to 4-byte-headers and avoid any array alignment surprises to begin with. Sure, but in the meantime, fix this bug or problemlist the tests? To reduce test noise? ------------- PR Comment: https://git.openjdk.org/lilliput/pull/118#issuecomment-1904205622 From stuefe at openjdk.org Tue Jan 23 15:24:31 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 23 Jan 2024 15:24:31 GMT Subject: [master] RFR: JDK-8324523: Lilliput: if +UseCOH, always use the archive's encoding base and shift Message-ID: We have two ways to initialize narrow Klass encoding: either we let the JVM choose base and shift freely, or we dictate base and shift. The former gives the JVM more leeway, e.g. to go with unscaled encoding. The latter, however, is required if we load a CDS archive and that archive contains precomputed narrow Klass IDs. In the Legacy VM, this can only happen if the archive contains heap objects. In Lilliput, the markword carries the nKlass, and therefore the prototype baked into archived Klass structures carries it also. Therefore, we must always choose the strict initialization when +UseCOH. ------------- Commit messages: - JDK-8324523-Lilliput-if-UseCOH-always-use-the-archives-encoding-base-and-shift Changes: https://git.openjdk.org/lilliput/pull/124/files Webrev: https://webrevs.openjdk.org/?repo=lilliput&pr=124&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8324523 Stats: 18 lines in 1 file changed: 6 ins; 0 del; 12 mod Patch: https://git.openjdk.org/lilliput/pull/124.diff Fetch: git fetch https://git.openjdk.org/lilliput.git pull/124/head:pull/124 PR: https://git.openjdk.org/lilliput/pull/124 From stuefe at openjdk.org Tue Jan 23 15:24:33 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 23 Jan 2024 15:24:33 GMT Subject: [master] RFR: JDK-8324523: Lilliput: if +UseCOH, always use the archive's encoding base and shift In-Reply-To: References: Message-ID: On Tue, 23 Jan 2024 13:21:11 GMT, Thomas Stuefe wrote: > We have two ways to initialize narrow Klass encoding: either we let the JVM choose base and shift freely, or we dictate base and shift. The former gives the JVM more leeway, e.g. to go with unscaled encoding. The latter, however, is required if we load a CDS archive and that archive contains precomputed narrow Klass IDs. > > In the Legacy VM, this can only happen if the archive contains heap objects. In Lilliput, the markword carries the nKlass, and therefore the prototype baked into archived Klass structures carries it also. Therefore, we must always choose the strict initialization when +UseCOH. x86 problem unrelated. ------------- PR Comment: https://git.openjdk.org/lilliput/pull/124#issuecomment-1906270949 From rkennke at openjdk.org Tue Jan 23 15:41:08 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 23 Jan 2024 15:41:08 GMT Subject: [master] RFR: JDK-8324523: Lilliput: if +UseCOH, always use the archive's encoding base and shift In-Reply-To: References: Message-ID: On Tue, 23 Jan 2024 13:21:11 GMT, Thomas Stuefe wrote: > We have two ways to initialize narrow Klass encoding: either we let the JVM choose base and shift freely, or we dictate base and shift. The former gives the JVM more leeway, e.g. to go with unscaled encoding. The latter, however, is required if we load a CDS archive and that archive contains precomputed narrow Klass IDs. > > In the Legacy VM, this can only happen if the archive contains heap objects. In Lilliput, the markword carries the nKlass, and therefore the prototype baked into archived Klass structures carries it also. Therefore, we must always choose the strict initialization when +UseCOH. Change looks ok. Questions, though: what is the impact of this? Is it a bug? Does it improve or regress performance? Should it be backported? ------------- Marked as reviewed by rkennke (Lead). PR Review: https://git.openjdk.org/lilliput/pull/124#pullrequestreview-1839123144 From rkennke at openjdk.org Tue Jan 23 15:59:01 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 23 Jan 2024 15:59:01 GMT Subject: [master] RFR: 8319185: [Lilliput] Enable and fix vectorization tests In-Reply-To: References: Message-ID: <4y1GduWSxGGMFM64hLXcwZj-oJImZI7NaOsIhkG0I7M=.2659e187-efa5-4c85-a1d2-70b57455a77a@github.com> On Tue, 21 Nov 2023 10:54:01 GMT, Roman Kennke wrote: > The change does two (related) things: > - It white-lists the UseCompactObjectHeaders flag in the IR testing framework. Without this, the flag would not be passed through to any IR framework test. > - That first change makes 3 tests fail. Those are all vectorization tests, and they are failing because 'small' array types (4-byte-elements and smaller) no longer have their elements aligned at 8-byte-boundaries. This throws off vectorization because this only kicks in on aligned accesses. The fix is to allocate those arrays a little larger and align-up the test data to the next 8-byte-boundary. (And no, Lilliput does not break vectorization in general, but it can change the characteristics in particular cases.) > > Testing: > - [x] compiler/c2/irTests/TestVectorizationMismatchedAccess.java +UCOH > - [x] compiler/c2/irTests/TestVectorizationNotRun.java +UCOH > - [x] compiler/loopopts/superword/TestIndependentPacksWithCyclicDependency.java +UCOH > - [x] compiler/c2/irTests/TestVectorizationMismatchedAccess.java -UCOH > - [x] compiler/c2/irTests/TestVectorizationNotRun.java -UCOH > - [x] compiler/loopopts/superword/TestIndependentPacksWithCyclicDependency.java -UCOH > - [x] tier1 +UCOH > - [x] tier1 -UCOH Closing in favour of #125. ------------- PR Comment: https://git.openjdk.org/lilliput/pull/118#issuecomment-1906370067 From rkennke at openjdk.org Tue Jan 23 16:01:23 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 23 Jan 2024 16:01:23 GMT Subject: [master] RFR: 8319185: [Lilliput] Enable and fix vectorization tests Message-ID: The change does two (related) things: It white-lists the UseCompactObjectHeaders flag in the IR testing framework. Without this, the flag would not be passed through to any IR framework test. That first change makes 3 tests fail. Those are all vectorization tests, and they are failing because 'small' array types (4-byte-elements and smaller) no longer have their elements aligned at 8-byte-boundaries. This throws off vectorization because this only kicks in on aligned accesses. The mitigation is to disable the failing tests for now. #118 offered a more comprehensive solution, but it was also more intrusive. After some discussion with Emmanuel Peter and Maurizio Cimadamore, we came to the conclusion that disabling the tests for now might be a better approach, especially considering that we may soon no longer need special 4-byte-array-alignment anymore. Testing: - [x] compiler/c2/irTests/TestVectorizationMismatchedAccess.java +UCOH - [x] compiler/c2/irTests/TestVectorizationNotRun.java +UCOH - [x] compiler/loopopts/superword/TestIndependentPacksWithCyclicDependency.java +UCOH - [x] compiler/c2/irTests/TestVectorizationMismatchedAccess.java -UCOH - [x] compiler/c2/irTests/TestVectorizationNotRun.java -UCOH - [x] compiler/loopopts/superword/TestIndependentPacksWithCyclicDependency.java -UCOH - [x] tier1 +UCOH - [x] tier1 -UCOH ------------- Commit messages: - 8319185: [Lilliput] Enable and fix vectorization tests Changes: https://git.openjdk.org/lilliput/pull/125/files Webrev: https://webrevs.openjdk.org/?repo=lilliput&pr=125&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8319185 Stats: 11 lines in 4 files changed: 2 ins; 0 del; 9 mod Patch: https://git.openjdk.org/lilliput/pull/125.diff Fetch: git fetch https://git.openjdk.org/lilliput.git pull/125/head:pull/125 PR: https://git.openjdk.org/lilliput/pull/125 From stuefe at openjdk.org Tue Jan 23 20:44:05 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 23 Jan 2024 20:44:05 GMT Subject: [master] RFR: JDK-8324523: Lilliput: if +UseCOH, always use the archive's encoding base and shift In-Reply-To: References:

Message-ID: On Tue, 23 Jan 2024 15:38:16 GMT, Roman Kennke wrote: > Change looks ok. > > Questions, though: what is the impact of this? Is it a bug? Does it improve or regress performance? Should it be backported? It is a bug, but I saw it only on Windows with my new class pointer patch. I could not reproduce it with the standard JVM, but I did not try very hard. Bug could lead to crashes. Performance impact is nil, since if we do actually run with an encoding scheme mismatch, we won't live very long. If we don't, it does not matter. ------------- PR Comment: https://git.openjdk.org/lilliput/pull/124#issuecomment-1906883687 From stuefe at openjdk.org Wed Jan 24 08:06:14 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 24 Jan 2024 08:06:14 GMT Subject: [master] RFR: JDK-8324523: Lilliput: if +UseCOH, always use the archive's encoding base and shift In-Reply-To: References:

Message-ID: On Tue, 23 Jan 2024 15:38:16 GMT, Roman Kennke wrote: >> We have two ways to initialize narrow Klass encoding: either we let the JVM choose base and shift freely, or we dictate base and shift. The former gives the JVM more leeway, e.g. to go with unscaled encoding. The latter, however, is required if we load a CDS archive and that archive contains precomputed narrow Klass IDs. >> >> In the Legacy VM, this can only happen if the archive contains heap objects. In Lilliput, the markword carries the nKlass, and therefore the prototype baked into archived Klass structures carries it also. Therefore, we must always choose the strict initialization when +UseCOH. > > Change looks ok. > > Questions, though: what is the impact of this? Is it a bug? Does it improve or regress performance? Should it be backported? > @rkennke : > > > Questions, though: what is the impact of this? Is it a bug? > > Okay, this bugged me, and I just had to know for sure. This bug is confirmed. In the traditional Lilliput VM this leads to early crashes in rare cases if a couple of conditions hold: > > * we generate and run with an archive that had been created using +UseCOH (my Smaller Classpointers patch generates such archives) > * we don't use CDS heap archiving (Windows, or did not build with G1 support) > * when reserving the class space, we optimize for zero- or unscaled encoding even though we run with CDS. This is highly CPU-specific; on some platforms, we do that today (eg PPC). On x64, it will be the case once [JDK-8323497: On x64, use 32-bit immediate moves for narrow klass base if possible?jdk#17340](https://github.com/openjdk/jdk/pull/17340) is merged. > > If all these conditions hold, we will generate the archive using precomputed narrow Klass IDs in prototype headers based on the assumption that the later encoding base is the Klass range start. But at runtime, we set the encoding base to zero, and now the narrow Klass IDs don't match up, and we get a crash right away: > > ``` > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (/shared/projects/openjdk/lilliput/source/src/hotspot/share/classfile/javaClasses.cpp:1274), pid=192787, tid=192788 > # assert(is_instance(java_class)) failed: must be a Class object > ``` > > > Does it improve or regress performance? > > Neither. If the bug hits, we crash. If it does not, we already do the right thing today, nothing changes with this patch. > > Another answer is that it can improve performance, since it makes +UseCOH able to run with CDS archive, so it improves startup. > > > Should it be backported? > > Yes, but this is based upon the big classspace rework patch from last summer (JDK-8312018) and a bunch of other patches. If they had been backported too, this should be backported as well. Ok, thank you very much for the clarification, this is very useful! Patch is good to go! ------------- PR Comment: https://git.openjdk.org/lilliput/pull/124#issuecomment-1907769184 From stuefe at openjdk.org Wed Jan 24 10:10:50 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 24 Jan 2024 10:10:50 GMT Subject: [master] RFR: JDK-8324523: Lilliput: if +UseCOH, always use the archive's encoding base and shift In-Reply-To: References: Message-ID: <2stoknNeJhcej0ZIEEwJWCgTbMW7R4Ss0xY-CeClhXE=.22759132-e41e-4547-81a2-c2e6a211fbb5@github.com> On Tue, 23 Jan 2024 13:21:11 GMT, Thomas Stuefe wrote: > We have two ways to initialize narrow Klass encoding: either we let the JVM choose base and shift freely, or we dictate base and shift. The former gives the JVM more leeway, e.g. to go with unscaled encoding. The latter, however, is required if we load a CDS archive and that archive contains precomputed narrow Klass IDs. > > In the Legacy VM, this can only happen if the archive contains heap objects. In Lilliput, the markword carries the nKlass, and therefore the prototype baked into archived Klass structures carries it also. Therefore, we must always choose the strict initialization when +UseCOH. x86 error unrelated (and I think already fixed upstream). Thanks @rkennke ------------- PR Comment: https://git.openjdk.org/lilliput/pull/124#issuecomment-1907806770 From stuefe at openjdk.org Wed Jan 24 10:10:51 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 24 Jan 2024 10:10:51 GMT Subject: [master] Integrated: JDK-8324523: Lilliput: if +UseCOH, always use the archive's encoding base and shift In-Reply-To: References: Message-ID: <2aZ9ouFhjTLWZQdBlyYNaUbEgpotdHMy0j7ilZ3yLZQ=.2a732e45-b279-43d8-83f7-76001eb57fca@github.com> On Tue, 23 Jan 2024 13:21:11 GMT, Thomas Stuefe wrote: > We have two ways to initialize narrow Klass encoding: either we let the JVM choose base and shift freely, or we dictate base and shift. The former gives the JVM more leeway, e.g. to go with unscaled encoding. The latter, however, is required if we load a CDS archive and that archive contains precomputed narrow Klass IDs. > > In the Legacy VM, this can only happen if the archive contains heap objects. In Lilliput, the markword carries the nKlass, and therefore the prototype baked into archived Klass structures carries it also. Therefore, we must always choose the strict initialization when +UseCOH. This pull request has now been integrated. Changeset: e7353767 Author: Thomas Stuefe URL: https://git.openjdk.org/lilliput/commit/e7353767eb9f31c5de4cbd7cc638fef47222efa3 Stats: 18 lines in 1 file changed: 6 ins; 0 del; 12 mod 8324523: Lilliput: if +UseCOH, always use the archive's encoding base and shift Reviewed-by: rkennke ------------- PR: https://git.openjdk.org/lilliput/pull/124 From rkennke at openjdk.org Thu Jan 25 18:12:39 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Thu, 25 Jan 2024 18:12:39 GMT Subject: [master] RFR: Merge jdk:jdk-23+6 Message-ID: Let's merge latest tag jdk-23+6. ------------- Commit messages: - Merge tag 'jdk-23+6' into merge-jdk-23+6 - 8323694: RISC-V: Unnecessary ResourceMark in NativeCall::set_destination_mt_safe - 8316497: ColorConvertOp - typo for non-ICC conversions needs one-line fix - 8323554: The typos in Javadoc: "@return if " - 8322100: Fix GCMIncrementByte4 & GCMIncrementDirect4, and increase overlap testing - 8317771: [macos14] Expand/collapse a JTree using keyboard freezes the application in macOS 14 Sonoma - 8323710: (fc) FileChannel.lock creates a FileKey with a poor hashCode after JDK-8321429 (win) - 8321561: (fs) Clarify non-atomic behavior of Files.move - 8323794: Remove unused jimage compressor plugin configuration - 8321137: Reconsider ICStub alignment - ... and 388 more: https://git.openjdk.org/lilliput/compare/e7353767...2ebe7140 The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.org/?repo=lilliput&pr=126&range=00.0 - jdk:jdk-23+6: https://webrevs.openjdk.org/?repo=lilliput&pr=126&range=00.1 Changes: https://git.openjdk.org/lilliput/pull/126/files Stats: 55131 lines in 1420 files changed: 35585 ins; 13302 del; 6244 mod Patch: https://git.openjdk.org/lilliput/pull/126.diff Fetch: git fetch https://git.openjdk.org/lilliput.git pull/126/head:pull/126 PR: https://git.openjdk.org/lilliput/pull/126 From rkennke at openjdk.org Thu Jan 25 19:17:50 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Thu, 25 Jan 2024 19:17:50 GMT Subject: [master] RFR: Merge jdk:jdk-23+7 [v2] In-Reply-To: References: Message-ID: > Let's merge latest tag jdk-23+7. Roman Kennke has updated the pull request incrementally with 78 additional commits since the last revision: - Merge tag 'jdk-23+7' into merge-jdk-23+6 Added tag jdk-23+7 for changeset 6d36eb78 - 8322768: Optimize non-subword vector compress and expand APIs for AVX2 target. Reviewed-by: epeter, sviswanathan - 8323645: Remove unused internal sun.net.www.protocol.jar.URLJarFileCallBack interface Reviewed-by: alanb, dfuchs - 8324242: Avoid null check for OopHandle::ptr_raw() Reviewed-by: shade, jsjolen, coleenp - 8307788: vmTestbase/gc/gctests/LargeObjects/large003/TestDescription.java timed out Reviewed-by: lmesnik, shade - 8324280: RISC-V: Incorrect implementation in VM_Version::parse_satp_mode Reviewed-by: rehn, fyang - 6503196: API doc for DecimalFormat::getMaximumIntegerDigits is unclear Reviewed-by: naoto, iris - 8324647: Invalid test group of lib-test after JDK-8323515 Reviewed-by: shade - 8320692: Null icon returned for .exe without custom icon Co-authored-by: Alexey Ivanov Reviewed-by: aivanov - 8324553: Shenandoah: Move periodic tasks closer to their collaborators Reviewed-by: kdnilsen, shade - ... and 68 more: https://git.openjdk.org/lilliput/compare/2ebe7140...c15847a2 ------------- Changes: - all: https://git.openjdk.org/lilliput/pull/126/files - new: https://git.openjdk.org/lilliput/pull/126/files/2ebe7140..c15847a2 Webrevs: - full: https://webrevs.openjdk.org/?repo=lilliput&pr=126&range=01 - incr: https://webrevs.openjdk.org/?repo=lilliput&pr=126&range=00-01 Stats: 7800 lines in 287 files changed: 4839 ins; 1864 del; 1097 mod Patch: https://git.openjdk.org/lilliput/pull/126.diff Fetch: git fetch https://git.openjdk.org/lilliput.git pull/126/head:pull/126 PR: https://git.openjdk.org/lilliput/pull/126 From rkennke at openjdk.org Fri Jan 26 13:01:00 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Fri, 26 Jan 2024 13:01:00 GMT Subject: [master] Integrated: Merge jdk:jdk-23+7 In-Reply-To: References: Message-ID: On Thu, 25 Jan 2024 18:02:20 GMT, Roman Kennke wrote: > Let's merge latest tag jdk-23+7. This pull request has now been integrated. Changeset: 96b3ad6d Author: Roman Kennke URL: https://git.openjdk.org/lilliput/commit/96b3ad6d5ad84d64d104b822645ddd6e9b9c3d97 Stats: 63187 lines in 1643 files changed: 40567 ins; 15309 del; 7311 mod Merge jdk:jdk-23+7 ------------- PR: https://git.openjdk.org/lilliput/pull/126 From duke at openjdk.org Tue Jan 30 04:20:49 2024 From: duke at openjdk.org (duke) Date: Tue, 30 Jan 2024 04:20:49 GMT Subject: [master] Withdrawn: Only include Mark Word when required In-Reply-To: References: Message-ID: On Mon, 25 Apr 2022 04:57:19 GMT, Julian Waters wrote: > WIP, some code here is meant as a placeholder > > Discussion: https://bugs.openjdk.java.net/browse/JDK-8198331 > > Current goals and dependencies (To help keep track) > - [x] 2 bit identity Hash Code > - [ ] Elimination of locking from the Mark Word entirely (Hopefully) > - [ ] 5 bit GC section (4 bit object age, 1 bit forwarding state) > - [ ] No Mark Word in header until required > - [ ] Support and optimizations for objects guaranteed to not have a Mark Word (May depend on Valhalla for the GC section) This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/lilliput/pull/47 From shade at openjdk.org Tue Jan 30 16:19:09 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 30 Jan 2024 16:19:09 GMT Subject: [master] RFR: 8319185: [Lilliput] Enable and fix vectorization tests [v2] In-Reply-To: References:

Message-ID: <7Wu24BnnajNoPT1DnhvxM950XOaV2OJYcScKMgCHs-8=.16e18290-5628-4f1a-9f02-dec9d2479440@github.com> On Tue, 30 Jan 2024 16:16:16 GMT, Roman Kennke wrote: >> The change does two (related) things: >> >> It white-lists the UseCompactObjectHeaders flag in the IR testing framework. Without this, the flag would not be passed through to any IR framework test. >> That first change makes 3 tests fail. Those are all vectorization tests, and they are failing because 'small' array types (4-byte-elements and smaller) no longer have their elements aligned at 8-byte-boundaries. This throws off vectorization because this only kicks in on aligned accesses. The mitigation is to disable the failing tests for now. #118 offered a more comprehensive solution, but it was also more intrusive. After some discussion with Emmanuel Peter and Maurizio Cimadamore, we came to the conclusion that disabling the tests for now might be a better approach, especially considering that we may soon no longer need special 4-byte-array-alignment anymore. >> >> >> Testing: >> - [x] compiler/c2/irTests/TestVectorizationMismatchedAccess.java +UCOH >> - [x] compiler/c2/irTests/TestVectorizationNotRun.java +UCOH >> - [x] compiler/loopopts/superword/TestIndependentPacksWithCyclicDependency.java +UCOH >> - [x] compiler/c2/irTests/TestVectorizationMismatchedAccess.java -UCOH >> - [x] compiler/c2/irTests/TestVectorizationNotRun.java -UCOH >> - [x] compiler/loopopts/superword/TestIndependentPacksWithCyclicDependency.java -UCOH >> - [x] tier1 +UCOH >> - [x] tier1 -UCOH > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Formatting improvement Looks fine, but consider a stylistic nit. Marked as reviewed by shade (Committer). test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationMismatchedAccess.java line 153: > 151: > 152: @Test > 153: @IR(applyIf = {"UseCompactObjectHeaders", "false"}, counts = { IRNode.LOAD_VECTOR_L, ">=1", IRNode.STORE_VECTOR, ">=1" }) Putting `applyIf` and `counts` on different lines looks cleaner; like in the case way below. ------------- Marked as reviewed by shade (Committer). PR Review: https://git.openjdk.org/lilliput/pull/125#pullrequestreview-1851628907 PR Review: https://git.openjdk.org/lilliput/pull/125#pullrequestreview-1851745737 PR Review Comment: https://git.openjdk.org/lilliput/pull/125#discussion_r1471453995 From rkennke at openjdk.org Tue Jan 30 16:19:08 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 30 Jan 2024 16:19:08 GMT Subject: [master] RFR: 8319185: [Lilliput] Enable and fix vectorization tests [v2] In-Reply-To: References: Message-ID: > The change does two (related) things: > > It white-lists the UseCompactObjectHeaders flag in the IR testing framework. Without this, the flag would not be passed through to any IR framework test. > That first change makes 3 tests fail. Those are all vectorization tests, and they are failing because 'small' array types (4-byte-elements and smaller) no longer have their elements aligned at 8-byte-boundaries. This throws off vectorization because this only kicks in on aligned accesses. The mitigation is to disable the failing tests for now. #118 offered a more comprehensive solution, but it was also more intrusive. After some discussion with Emmanuel Peter and Maurizio Cimadamore, we came to the conclusion that disabling the tests for now might be a better approach, especially considering that we may soon no longer need special 4-byte-array-alignment anymore. > > > Testing: > - [x] compiler/c2/irTests/TestVectorizationMismatchedAccess.java +UCOH > - [x] compiler/c2/irTests/TestVectorizationNotRun.java +UCOH > - [x] compiler/loopopts/superword/TestIndependentPacksWithCyclicDependency.java +UCOH > - [x] compiler/c2/irTests/TestVectorizationMismatchedAccess.java -UCOH > - [x] compiler/c2/irTests/TestVectorizationNotRun.java -UCOH > - [x] compiler/loopopts/superword/TestIndependentPacksWithCyclicDependency.java -UCOH > - [x] tier1 +UCOH > - [x] tier1 -UCOH Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Formatting improvement ------------- Changes: - all: https://git.openjdk.org/lilliput/pull/125/files - new: https://git.openjdk.org/lilliput/pull/125/files/08460a63..341cef3e Webrevs: - full: https://webrevs.openjdk.org/?repo=lilliput&pr=125&range=01 - incr: https://webrevs.openjdk.org/?repo=lilliput&pr=125&range=00-01 Stats: 14 lines in 2 files changed: 7 ins; 0 del; 7 mod Patch: https://git.openjdk.org/lilliput/pull/125.diff Fetch: git fetch https://git.openjdk.org/lilliput.git pull/125/head:pull/125 PR: https://git.openjdk.org/lilliput/pull/125 From rkennke at openjdk.org Tue Jan 30 18:25:58 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 30 Jan 2024 18:25:58 GMT Subject: [master] RFR: 8319185: [Lilliput] Enable and fix vectorization tests [v2] In-Reply-To: References:

Message-ID: On Tue, 30 Jan 2024 16:19:08 GMT, Roman Kennke wrote: >> The change does two (related) things: >> >> It white-lists the UseCompactObjectHeaders flag in the IR testing framework. Without this, the flag would not be passed through to any IR framework test. >> That first change makes 3 tests fail. Those are all vectorization tests, and they are failing because 'small' array types (4-byte-elements and smaller) no longer have their elements aligned at 8-byte-boundaries. This throws off vectorization because this only kicks in on aligned accesses. The mitigation is to disable the failing tests for now. #118 offered a more comprehensive solution, but it was also more intrusive. After some discussion with Emmanuel Peter and Maurizio Cimadamore, we came to the conclusion that disabling the tests for now might be a better approach, especially considering that we may soon no longer need special 4-byte-array-alignment anymore. >> >> >> Testing: >> - [x] compiler/c2/irTests/TestVectorizationMismatchedAccess.java +UCOH >> - [x] compiler/c2/irTests/TestVectorizationNotRun.java +UCOH >> - [x] compiler/loopopts/superword/TestIndependentPacksWithCyclicDependency.java +UCOH >> - [x] compiler/c2/irTests/TestVectorizationMismatchedAccess.java -UCOH >> - [x] compiler/c2/irTests/TestVectorizationNotRun.java -UCOH >> - [x] compiler/loopopts/superword/TestIndependentPacksWithCyclicDependency.java -UCOH >> - [x] tier1 +UCOH >> - [x] tier1 -UCOH > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Formatting improvement linux-x86 GHA failure looks unrelated. ------------- PR Comment: https://git.openjdk.org/lilliput/pull/125#issuecomment-1917636857 From rkennke at openjdk.org Tue Jan 30 18:25:58 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 30 Jan 2024 18:25:58 GMT Subject: [master] Integrated: 8319185: [Lilliput] Enable and fix vectorization tests In-Reply-To: References: Message-ID: On Tue, 23 Jan 2024 15:56:08 GMT, Roman Kennke wrote: > The change does two (related) things: > > It white-lists the UseCompactObjectHeaders flag in the IR testing framework. Without this, the flag would not be passed through to any IR framework test. > That first change makes 3 tests fail. Those are all vectorization tests, and they are failing because 'small' array types (4-byte-elements and smaller) no longer have their elements aligned at 8-byte-boundaries. This throws off vectorization because this only kicks in on aligned accesses. The mitigation is to disable the failing tests for now. #118 offered a more comprehensive solution, but it was also more intrusive. After some discussion with Emmanuel Peter and Maurizio Cimadamore, we came to the conclusion that disabling the tests for now might be a better approach, especially considering that we may soon no longer need special 4-byte-array-alignment anymore. > > > Testing: > - [x] compiler/c2/irTests/TestVectorizationMismatchedAccess.java +UCOH > - [x] compiler/c2/irTests/TestVectorizationNotRun.java +UCOH > - [x] compiler/loopopts/superword/TestIndependentPacksWithCyclicDependency.java +UCOH > - [x] compiler/c2/irTests/TestVectorizationMismatchedAccess.java -UCOH > - [x] compiler/c2/irTests/TestVectorizationNotRun.java -UCOH > - [x] compiler/loopopts/superword/TestIndependentPacksWithCyclicDependency.java -UCOH > - [x] tier1 +UCOH > - [x] tier1 -UCOH This pull request has now been integrated. Changeset: c0496069 Author: Roman Kennke URL: https://git.openjdk.org/lilliput/commit/c04960696376dd226c5efa7eb7b822dbdefc6bd1 Stats: 18 lines in 4 files changed: 9 ins; 0 del; 9 mod 8319185: [Lilliput] Enable and fix vectorization tests Reviewed-by: shade ------------- PR: https://git.openjdk.org/lilliput/pull/125 From axel.boldt-christmas at oracle.com Wed Jan 31 15:41:57 2024 From: axel.boldt-christmas at oracle.com (Axel Boldt-Christmas) Date: Wed, 31 Jan 2024 15:41:57 +0000 Subject: Object to ObjectMonitor mapping using a HashTable to avoid displaced headers Message-ID: <08E8A4A4-39FB-47C5-8138-CF7B12E56207@oracle.com> Hello, We at Oracle have been working on an effort to make the Klass* stable (and avoid displaced headers) with Lilliput?s 64-bit headers. Some background to the issue. With the introduction of Lilliput and 64-bit headers it creates a scenario where both the narrowKlass* and the ObjectMonitor* cannot fit inside the markWord at the same time. The current solution is to place the Klass* in a displaced header. LM_LIGHTWEIGHT was introduced to the JDK project partially because the same issue existed with LM_LEGACY and the BasicLock*. Having the Klass* not be displaced is something we see it as a pre-requisite for integrating Lilliput in the JDK. As mentioned we have been working on a solution which uses an external hash table to map objects to their respective ObjectMonitor. With per thread caches to speed up retrieval in compiled code. The work has been done under the name OMWorld (ObjectMonitor World). The solution was initially based on LM_LIGHTWEIGHT but has been separated into a fourth locking mode. It is time to open up the work to the broader community, and make it part of the Lilliput project. Creating a central base to work from inside the Lilliput project and repository. Here are the latest rebased branches both on the OpenJDK/JDK master and the OpenJDK/Lilliput master. Latest OMWorld on Mainline: https://github.com/xmas92/jdk/tree/omworld-as-new-lm Latest OMWorld on Lilliput: https://github.com/xmas92/lilliput/tree/omworld-as-new-lm-on-lilliput Hopefully Roman can coordinate the creation of branches in the Lilliput repo which we all can work against. Sincerely // Axel Boldt-Christmas -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Wed Jan 31 17:05:24 2024 From: duke at openjdk.org (duke) Date: Wed, 31 Jan 2024 17:05:24 GMT Subject: git: openjdk/lilliput: created branch omworld based on the branch master containing 3 unique commits Message-ID: The following commits are unique to the omworld branch: ======================================================== 97a7754d: Initial Split 91be2ea9: Minor cleanups 279dfedf: LM_PLACEHOLDER Lilliput fix From rkennke at amazon.de Wed Jan 31 17:19:50 2024 From: rkennke at amazon.de (Kennke, Roman) Date: Wed, 31 Jan 2024 17:19:50 +0000 Subject: Object to ObjectMonitor mapping using a HashTable to avoid displaced headers In-Reply-To: <08E8A4A4-39FB-47C5-8138-CF7B12E56207@oracle.com> References: <08E8A4A4-39FB-47C5-8138-CF7B12E56207@oracle.com> Message-ID: <345DFDF4-1FF6-4A06-BC8E-D877F90C434D@amazon.de> Hi Axel, > We at Oracle have been working on an effort to make the Klass* stable (and avoid displaced headers) with Lilliput?s 64-bit headers. > This is great stuff! > Some background to the issue. > With the introduction of Lilliput and 64-bit headers it creates a scenario where both the narrowKlass* and the ObjectMonitor* cannot fit inside the markWord at the same time. The current solution is to place the Klass* in a displaced header. LM_LIGHTWEIGHT was introduced to the JDK project partially because the same issue existed with LM_LEGACY and the BasicLock*. > > Having the Klass* not be displaced is something we see it as a pre-requisite for integrating Lilliput in the JDK. > > As mentioned we have been working on a solution which uses an external hash table to map objects to their respective ObjectMonitor. With per thread caches to speed up retrieval in compiled code. The work has been done under the name OMWorld (ObjectMonitor World). The solution was initially based on LM_LIGHTWEIGHT but has been separated into a fourth locking mode. This sounds nice! It will simplify and 'unlock' a number of things in Lilliput: - Currently, we require a branch on the fast-path of any code that accesses the Klass*, e.g. for any runtime type-checking, etc. This has caused some (minor, but still) regressions in some workloads. With your work, this will no longer be necessary. - ZGC support, because I could never get ZGC to properly coordinate with the monitor-deflation protocol, which has been necessary to safely access the Klass*. I guess this is why you consider this a must-have (and I agree). - Looking forward, towards 4-byte headers (aka Lilliput 2), compact-identity-hashcode will also be much simpler because when headers can be displaced, and we are in the process of copying/extending an object, which object does the displaced header refer to - the old or the new? - And of course get rid of all things that have to do with displaced headers. I am curious: have you made any performance studies, yet? How does it look? (I will certainly do some of my own later, but will not get to it this week. Traveling to FOSDEM/OCW the rest of the week.) > It is time to open up the work to the broader community, and make it part of the Lilliput project. Creating a central base to work from inside the Lilliput project and repository. > > Here are the latest rebased branches both on the OpenJDK/JDK master and the OpenJDK/Lilliput master. > >> Latest OMWorld on Mainline: https://github.com/xmas92/jdk/tree/omworld-as-new-lm >> Latest OMWorld on Lilliput: https://github.com/xmas92/lilliput/tree/omworld-as-new-lm-on-lilliput > > Hopefully Roman can coordinate the creation of branches in the Lilliput repo which we all can work against. I have created the branch: https://github.com/openjdk/lilliput/tree/omworld And the PR to track it (and easily see the diff vs mainline Lilliput): https://github.com/openjdk/lilliput/pull/127/files I noticed that you, Axel, have no role in Lilliput, yet. I will propose you for Lilliput Committer ASAP, then you can work directly on that branch. I don?t think we want reviews/PRs for changes going to that branch. (Except, I am not sure if committers can push directly to repos, or if only the maintainer can do that? We need to see.) I?ve got a whole lot of follow-up stuff (see above) that I would like to do on top of OMWorld - I would suggest to do that in another branch to keep the OMWorld changes and the other experimental stuff separate. Thank you, Axel! This looks like very useful work! Cheers, Roman Amazon Development Center Germany GmbH Krausenstr. 38 10117 Berlin Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B Sitz: Berlin Ust-ID: DE 289 237 879 From aph-open at littlepinkcloud.com Wed Jan 31 17:32:15 2024 From: aph-open at littlepinkcloud.com (Andrew Haley) Date: Wed, 31 Jan 2024 17:32:15 +0000 Subject: Object to ObjectMonitor mapping using a HashTable to avoid displaced headers In-Reply-To: <345DFDF4-1FF6-4A06-BC8E-D877F90C434D@amazon.de> References: <08E8A4A4-39FB-47C5-8138-CF7B12E56207@oracle.com> <345DFDF4-1FF6-4A06-BC8E-D877F90C434D@amazon.de> Message-ID: <12d922d9-e1ef-43ce-8485-0d64307af7bc@littlepinkcloud.com> On 1/31/24 17:19, Kennke, Roman wrote: > As mentioned we have been working on a solution which uses an external hash table to map objects to their respective ObjectMonitor. That's great news. Historical note: we did that in GCJ, long before OpenJDK was a thing. When OpenJDK began I had to learn about HotSpot. I remember being in the audience in a talk about the layout of an object. When I learned about the lock word, I was very surprised. Why would you want to waste a whole word of every object? ;-) -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671