From forax at univ-mlv.fr Sat Mar 2 10:25:28 2024 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 2 Mar 2024 11:25:28 +0100 (CET) Subject: 32 bits header and alignment slack Message-ID: <77699604.19300095.1709375128835.JavaMail.zimbra@univ-eiffel.fr> Hello, I was try to read the code corresponding to the compact identity hashcode https://wiki.openjdk.org/display/lilliput/Compact+Identity+Hashcode But I did not see any mention of the fact that due to object alignment, there is maybe already an empty 32 bits space at the end of the object. By example, with a java.lang.Integer and a 64 bits header, due to alignment to 64 bits, there is 32 bits of space which is not used after the value of the Integer j.l.Integer layout mark word / 64 bits value / 32 bits empty / 32 bits In that case, when System.identityHashCode() is called, it could use that space directly instead of waiting the GC to move the object to another location of the mostly same size. Obviously, there is a good chance that this is exactly what the VM currently does and I've just missed that part :) R?mi From rkennke at amazon.de Mon Mar 4 11:59:48 2024 From: rkennke at amazon.de (Kennke, Roman) Date: Mon, 4 Mar 2024 11:59:48 +0000 Subject: 32 bits header and alignment slack In-Reply-To: <77699604.19300095.1709375128835.JavaMail.zimbra@univ-eiffel.fr> References: <77699604.19300095.1709375128835.JavaMail.zimbra@univ-eiffel.fr> Message-ID: <17C905C3-649E-488C-A478-863C1C7F7E52@amazon.de> Hello Remi, > Hello, > I was try to read the code corresponding to the compact identity hashcode > https://wiki.openjdk.org/display/lilliput/Compact+Identity+Hashcode > > But I did not see any mention of the fact that due to object alignment, there is maybe already an empty 32 bits space at the end of the object. > By example, with a java.lang.Integer and a 64 bits header, due to alignment to 64 bits, there is 32 bits of space which is not used after the value of the Integer > > j.l.Integer layout > mark word / 64 bits > value / 32 bits > empty / 32 bits > > In that case, when System.identityHashCode() is called, it could use that space directly instead of waiting the GC to move the object to another location of the mostly same size. > > Obviously, there is a good chance that this is exactly what the VM currently does and I've just missed that part :) I have not called it out separately, but it?s mentioned in side-sentences, like: "The first call to System.identityHashCode() transitions the hash-bits from the 00 state to the 01 state, *if there is no sufficient alignment gap at the end of the object,* and return the computed i-hash.? The current prototype does it that way. https://github.com/openjdk/lilliput/pull/137 I?ll write it down more specifically. Thanks for pointing out! 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 rkennke at openjdk.org Mon Mar 4 12:52:25 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 4 Mar 2024 12:52:25 GMT Subject: [master] RFR: Merge jdk:jdk-23+12 Message-ID: <_VvsmUFT6j1VEb5TGkob_r-ug9lrWn68OBzhCc_9zJc=.1dafe5d0-b425-4e0d-94f3-bd0c2663e53a@github.com> Let's merge jdk-23+12, in particular, this brings in: [8139457: Relax alignment of array elements](https://bugs.openjdk.org/browse/JDK-8139457). After this merge, I'll check the remaining diff vs upstream and see if I find any leftovers. Testing: - [x] tier1 (-UCOH) - [x] tier1 (+UCOH) ------------- Commit messages: - Merge tag 'jdk-23+12' into merge-jdk-23+12 - 8324799: Use correct extension for C++ test headers - 8318302: ThreadCountLimit.java failed with "Native memory allocation (mprotect) failed to protect 16384 bytes for memory to guard stack pages" - 8326953: Race in creation of win-exports.def with static-libs - 8326694: Defer setting of autocapitalize attribute - 8326687: Inconsistent use of "ZIP", "Zip" and "zip" in java.util.zip/jar zipfs javadoc - 8324969: C2: prevent elimination of unbalanced coarsened locking regions - 8326763: Consolidate print methods in ContiguousSpace - 8325762: Use PassFailJFrame.Builder.splitUI() in PrintLatinCJKTest.java - 8326892: Remove unused PSAdaptiveSizePolicyResizeVirtualSpaceAlot develop flag - ... and 71 more: https://git.openjdk.org/lilliput/compare/763dcced...00694eb1 The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.org/?repo=lilliput&pr=142&range=00.0 - jdk:jdk-23+12: https://webrevs.openjdk.org/?repo=lilliput&pr=142&range=00.1 Changes: https://git.openjdk.org/lilliput/pull/142/files Stats: 12692 lines in 1121 files changed: 6866 ins; 2387 del; 3439 mod Patch: https://git.openjdk.org/lilliput/pull/142.diff Fetch: git fetch https://git.openjdk.org/lilliput.git pull/142/head:pull/142 PR: https://git.openjdk.org/lilliput/pull/142 From forax at univ-mlv.fr Mon Mar 4 12:52:41 2024 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Mon, 4 Mar 2024 13:52:41 +0100 (CET) Subject: 32 bits header and alignment slack In-Reply-To: <17C905C3-649E-488C-A478-863C1C7F7E52@amazon.de> References: <77699604.19300095.1709375128835.JavaMail.zimbra@univ-eiffel.fr> <17C905C3-649E-488C-A478-863C1C7F7E52@amazon.de> Message-ID: <1249027529.20510860.1709556761626.JavaMail.zimbra@univ-eiffel.fr> ----- Original Message ----- > From: "Roman Kennke" > To: "Remi Forax" > Cc: "lilliput-dev" > Sent: Monday, March 4, 2024 12:59:48 PM > Subject: Re: 32 bits header and alignment slack > Hello Remi, > >> Hello, >> I was try to read the code corresponding to the compact identity hashcode >> https://wiki.openjdk.org/display/lilliput/Compact+Identity+Hashcode >> >> But I did not see any mention of the fact that due to object alignment, there is >> maybe already an empty 32 bits space at the end of the object. >> By example, with a java.lang.Integer and a 64 bits header, due to alignment to >> 64 bits, there is 32 bits of space which is not used after the value of the >> Integer >> >> j.l.Integer layout >> mark word / 64 bits >> value / 32 bits >> empty / 32 bits >> >> In that case, when System.identityHashCode() is called, it could use that space >> directly instead of waiting the GC to move the object to another location of >> the mostly same size. >> >> Obviously, there is a good chance that this is exactly what the VM currently >> does and I've just missed that part :) > > I have not called it out separately, but it?s mentioned in side-sentences, like: > > "The first call to System.identityHashCode() transitions the hash-bits from the > 00 state to the 01 state, *if there is no sufficient alignment gap at the end > of the object,* and return the computed i-hash.? > > The current prototype does it that way. > https://github.com/openjdk/lilliput/pull/137 > > I?ll write it down more specifically. > > Thanks for pointing out! Thinking a little more about it. The aligment gap is not necessary at the end of the object, a j.l.Long with a 32 bits header has a 32 bits gap in between the mark/class word and the field containing the value. > > Roman R?mi > > > > 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 rkennke at amazon.de Mon Mar 4 13:10:08 2024 From: rkennke at amazon.de (Kennke, Roman) Date: Mon, 4 Mar 2024 13:10:08 +0000 Subject: 32 bits header and alignment slack In-Reply-To: <1249027529.20510860.1709556761626.JavaMail.zimbra@univ-eiffel.fr> References: <77699604.19300095.1709375128835.JavaMail.zimbra@univ-eiffel.fr> <17C905C3-649E-488C-A478-863C1C7F7E52@amazon.de> <1249027529.20510860.1709556761626.JavaMail.zimbra@univ-eiffel.fr> Message-ID: Hello Remi, >>> Hello, >>> I was try to read the code corresponding to the compact identity hashcode >>> https://wiki.openjdk.org/display/lilliput/Compact+Identity+Hashcode >>> >>> But I did not see any mention of the fact that due to object alignment, there is >>> maybe already an empty 32 bits space at the end of the object. >>> By example, with a java.lang.Integer and a 64 bits header, due to alignment to >>> 64 bits, there is 32 bits of space which is not used after the value of the >>> Integer >>> >>> j.l.Integer layout >>> mark word / 64 bits >>> value / 32 bits >>> empty / 32 bits >>> >>> In that case, when System.identityHashCode() is called, it could use that space >>> directly instead of waiting the GC to move the object to another location of >>> the mostly same size. >>> >>> Obviously, there is a good chance that this is exactly what the VM currently >>> does and I've just missed that part :) >> >> I have not called it out separately, but it?s mentioned in side-sentences, like: >> >> "The first call to System.identityHashCode() transitions the hash-bits from the >> 00 state to the 01 state, *if there is no sufficient alignment gap at the end >> of the object,* and return the computed i-hash.? >> >> The current prototype does it that way. >> https://github.com/openjdk/lilliput/pull/137 >> >> I?ll write it down more specifically. >> >> Thanks for pointing out! > > Thinking a little more about it. > The aligment gap is not necessary at the end of the object, a j.l.Long with a 32 bits header has a 32 bits gap in between the mark/class word and the field containing the value. This is a very good point, and a nice improvement! And should not be very difficult to implement, either. Thanks for suggesting that! 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 rkennke at openjdk.org Mon Mar 4 13:15:51 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 4 Mar 2024 13:15:51 GMT Subject: [master] RFR: Merge jdk:jdk-23+12 [v2] In-Reply-To: <_VvsmUFT6j1VEb5TGkob_r-ug9lrWn68OBzhCc_9zJc=.1dafe5d0-b425-4e0d-94f3-bd0c2663e53a@github.com> References: <_VvsmUFT6j1VEb5TGkob_r-ug9lrWn68OBzhCc_9zJc=.1dafe5d0-b425-4e0d-94f3-bd0c2663e53a@github.com> Message-ID: > Let's merge jdk-23+12, in particular, this brings in: [8139457: Relax alignment of array elements](https://bugs.openjdk.org/browse/JDK-8139457). After this merge, I'll check the remaining diff vs upstream and see if I find any leftovers. > > Testing: > - [x] tier1 (-UCOH) > - [x] tier1 (+UCOH) Roman Kennke has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: Merge tag 'jdk-23+12' into merge-jdk-23+12 Added tag jdk-23+12 for changeset 998d0baa ------------- Changes: - all: https://git.openjdk.org/lilliput/pull/142/files - new: https://git.openjdk.org/lilliput/pull/142/files/00694eb1..75d9e46c Webrevs: - full: https://webrevs.openjdk.org/?repo=lilliput&pr=142&range=01 - incr: https://webrevs.openjdk.org/?repo=lilliput&pr=142&range=00-01 Stats: 100 lines in 1 file changed: 55 ins; 11 del; 34 mod Patch: https://git.openjdk.org/lilliput/pull/142.diff Fetch: git fetch https://git.openjdk.org/lilliput.git pull/142/head:pull/142 PR: https://git.openjdk.org/lilliput/pull/142 From rkennke at openjdk.org Mon Mar 4 13:36:45 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 4 Mar 2024 13:36:45 GMT Subject: [master] RFR: Merge jdk:jdk-23+12 [v3] In-Reply-To: <_VvsmUFT6j1VEb5TGkob_r-ug9lrWn68OBzhCc_9zJc=.1dafe5d0-b425-4e0d-94f3-bd0c2663e53a@github.com> References: <_VvsmUFT6j1VEb5TGkob_r-ug9lrWn68OBzhCc_9zJc=.1dafe5d0-b425-4e0d-94f3-bd0c2663e53a@github.com> Message-ID: > Let's merge jdk-23+12, in particular, this brings in: [8139457: Relax alignment of array elements](https://bugs.openjdk.org/browse/JDK-8139457). After this merge, I'll check the remaining diff vs upstream and see if I find any leftovers. > > Testing: > - [x] tier1 (-UCOH) > - [x] tier1 (+UCOH) Roman Kennke has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: Merge tag 'jdk-23+12' into merge-jdk-23+12 Added tag jdk-23+12 for changeset 998d0baa ------------- Changes: - all: https://git.openjdk.org/lilliput/pull/142/files - new: https://git.openjdk.org/lilliput/pull/142/files/75d9e46c..26ab639f Webrevs: - full: https://webrevs.openjdk.org/?repo=lilliput&pr=142&range=02 - incr: https://webrevs.openjdk.org/?repo=lilliput&pr=142&range=01-02 Stats: 13 lines in 1 file changed: 0 ins; 13 del; 0 mod Patch: https://git.openjdk.org/lilliput/pull/142.diff Fetch: git fetch https://git.openjdk.org/lilliput.git pull/142/head:pull/142 PR: https://git.openjdk.org/lilliput/pull/142 From rkennke at openjdk.org Mon Mar 4 16:44:05 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 4 Mar 2024 16:44:05 GMT Subject: [master] RFR: Merge jdk:jdk-23+12 [v3] In-Reply-To: References: <_VvsmUFT6j1VEb5TGkob_r-ug9lrWn68OBzhCc_9zJc=.1dafe5d0-b425-4e0d-94f3-bd0c2663e53a@github.com> Message-ID: On Mon, 4 Mar 2024 13:36:45 GMT, Roman Kennke wrote: >> Let's merge jdk-23+12, in particular, this brings in: [8139457: Relax alignment of array elements](https://bugs.openjdk.org/browse/JDK-8139457). After this merge, I'll check the remaining diff vs upstream and see if I find any leftovers. >> >> Testing: >> - [x] tier1 (-UCOH) >> - [x] tier1 (+UCOH) > > Roman Kennke has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > Merge tag 'jdk-23+12' into merge-jdk-23+12 > > Added tag jdk-23+12 for changeset 998d0baa I see 3 failures with +UCOH, but all of them are preexisting. No failures with -UCOH. Going to push the merge. ------------- PR Comment: https://git.openjdk.org/lilliput/pull/142#issuecomment-1977011535 From rkennke at openjdk.org Mon Mar 4 16:44:06 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 4 Mar 2024 16:44:06 GMT Subject: [master] Integrated: Merge jdk:jdk-23+12 In-Reply-To: <_VvsmUFT6j1VEb5TGkob_r-ug9lrWn68OBzhCc_9zJc=.1dafe5d0-b425-4e0d-94f3-bd0c2663e53a@github.com> References: <_VvsmUFT6j1VEb5TGkob_r-ug9lrWn68OBzhCc_9zJc=.1dafe5d0-b425-4e0d-94f3-bd0c2663e53a@github.com> Message-ID: On Mon, 4 Mar 2024 12:46:14 GMT, Roman Kennke wrote: > Let's merge jdk-23+12, in particular, this brings in: [8139457: Relax alignment of array elements](https://bugs.openjdk.org/browse/JDK-8139457). After this merge, I'll check the remaining diff vs upstream and see if I find any leftovers. > > Testing: > - [x] tier1 (-UCOH) > - [x] tier1 (+UCOH) This pull request has now been integrated. Changeset: b2fcfb73 Author: Roman Kennke URL: https://git.openjdk.org/lilliput/commit/b2fcfb737fb18491d31fa1fd32b7c9a513e7ee73 Stats: 12749 lines in 1121 files changed: 6910 ins; 2400 del; 3439 mod Merge jdk:jdk-23+12 ------------- PR: https://git.openjdk.org/lilliput/pull/142 From kbarrett at openjdk.org Mon Mar 4 19:04:23 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 4 Mar 2024 19:04:23 GMT Subject: git: openjdk/lilliput: jdk: 172 new changesets Message-ID: <0eeda776-a034-4674-8cb7-987238237f9d@openjdk.org> Changeset: 0e2fdc95 Author: Erik ?sterlund Date: 2024-02-15 09:26:48 +0000 URL: https://git.openjdk.org/lilliput/commit/0e2fdc95ae47c11e6a1e47cdc6190268e29a9d9c 8324933: ConcurrentHashTable::statistics_calculate synchronization is expensive Reviewed-by: tschatzl, coleenp ! src/hotspot/share/utilities/concurrentHashTable.inline.hpp Changeset: b718ae35 Author: Albert Mingkun Yang Date: 2024-02-15 09:36:07 +0000 URL: https://git.openjdk.org/lilliput/commit/b718ae35a87e5696cd6d26952ab1f7d3fda27691 8325882: Serial: Move is_maximal_no_gc to TenuredGeneration Reviewed-by: stefank ! src/hotspot/share/gc/serial/defNewGeneration.hpp ! src/hotspot/share/gc/serial/generation.hpp ! src/hotspot/share/gc/serial/serialHeap.cpp ! src/hotspot/share/gc/serial/tenuredGeneration.hpp Changeset: 2b1a8400 Author: Albert Mingkun Yang Date: 2024-02-15 10:20:12 +0000 URL: https://git.openjdk.org/lilliput/commit/2b1a8400023d4fdbe253c44d68db630864ae5e55 8325860: Serial: Move Generation.java to serial folder Reviewed-by: cjplummer, tschatzl ! src/hotspot/share/gc/serial/vmStructs_serial.hpp ! src/hotspot/share/gc/shared/vmStructs_gc.hpp ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/HSDB.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/serial/DefNewGeneration.java + src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/serial/Generation.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/serial/SerialHeap.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/serial/TenuredGeneration.java - src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/shared/Generation.java - src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/shared/GenerationIsInClosure.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/HeapSummary.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/PointerFinder.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/PointerLocation.java ! test/hotspot/jtreg/serviceability/sa/TestUniverse.java Changeset: 0d51b769 Author: Magnus Ihse Bursie Date: 2024-02-15 10:38:30 +0000 URL: https://git.openjdk.org/lilliput/commit/0d51b76947324643166cdaf9ca703431bd83bc0e 8325877: Split up NativeCompilation.gmk Reviewed-by: erikj, jwaters ! make/common/NativeCompilation.gmk + make/common/native/CompileFile.gmk + make/common/native/DebugSymbols.gmk + make/common/native/Flags.gmk + make/common/native/Link.gmk + make/common/native/Paths.gmk + make/common/native/ToolchainDefinitions.gmk Changeset: a0e5e16a Author: Daniel Jeli?ski Date: 2024-02-15 11:27:00 +0000 URL: https://git.openjdk.org/lilliput/commit/a0e5e16afbd19f6396f0af2cba954225a357eca8 8325162: Remove duplicate GCMParameters class Reviewed-by: weijun, valeriep - src/java.base/share/classes/com/sun/crypto/provider/GCMParameters.java ! src/java.base/share/classes/com/sun/crypto/provider/SunJCE.java Changeset: 9a1b843f Author: Matias Saavedra Silva Date: 2024-02-15 14:48:39 +0000 URL: https://git.openjdk.org/lilliput/commit/9a1b843ff6ef72e17ec6096733408c5e265ee429 8324584: Optimize Symbol and char* handling in ClassLoader Reviewed-by: dholmes, coleenp ! src/hotspot/share/classfile/classLoader.cpp ! src/hotspot/share/classfile/classLoader.hpp ! src/hotspot/share/classfile/systemDictionary.cpp Changeset: 2564f0f9 Author: Leonid Mesnik Date: 2024-02-15 15:06:12 +0000 URL: https://git.openjdk.org/lilliput/commit/2564f0f99866c33d14947609c276a421ce8cc0a2 8325906: Problemlist vmTestbase/vm/mlvm/meth/stress/compiler/deoptimize/Test.java#id1 until JDK-8320865 is fixed Reviewed-by: thartmann ! test/hotspot/jtreg/ProblemList.txt Changeset: a231706a Author: Zdenek Zambersky Committer: Thomas Stuefe Date: 2024-02-15 16:01:18 +0000 URL: https://git.openjdk.org/lilliput/commit/a231706a06a86abb16d0040e8ca1b76a9741a0b2 8324580: SIGFPE on THP initialization on kernels < 4.10 Reviewed-by: stuefe, sjohanss ! src/hotspot/os/linux/hugepages.cpp ! src/hotspot/os/linux/hugepages.hpp ! src/hotspot/os/linux/os_linux.cpp ! test/hotspot/jtreg/runtime/os/HugePageConfiguration.java ! test/hotspot/jtreg/runtime/os/TestHugePageDecisionsAtVMStartup.java Changeset: 5a988a50 Author: Alexander Zvegintsev Date: 2024-02-15 17:52:48 +0000 URL: https://git.openjdk.org/lilliput/commit/5a988a5087d0afbb577c6715fd5e1e44564888cb 8322750: Test "api/java_awt/interactive/SystemTrayTests.html" failed because A blue ball icon is added outside of the system tray Reviewed-by: jdv, kizune, psadhukhan, prr ! src/java.desktop/unix/classes/sun/awt/UNIXToolkit.java ! src/java.desktop/unix/classes/sun/awt/X11/XSystemTrayPeer.java Changeset: 3b1062d4 Author: Alexander Zuev Date: 2024-02-15 18:18:29 +0000 URL: https://git.openjdk.org/lilliput/commit/3b1062d45df69d4cf8479c6a65602bd2453ab885 8322239: [macos] a11y : java.lang.NullPointerException is thrown when focus is moved on the JTabbedPane Reviewed-by: asemenov, abhiscxk, aivanov ! src/java.desktop/share/classes/javax/swing/JTabbedPane.java + test/jdk/javax/swing/JTabbedPane/TabbedPaneNPECheck.java Changeset: 0fdfdf71 Author: Zdenek Zambersky Committer: Daniel D. Daugherty Date: 2024-02-15 21:10:56 +0000 URL: https://git.openjdk.org/lilliput/commit/0fdfdf71f242b39f2e758fcff99bd61060fa2870 8325983: Build failure after JDK-8324580 Reviewed-by: stuefe, dcubed ! src/hotspot/os/linux/hugepages.cpp ! test/hotspot/jtreg/runtime/os/HugePageConfiguration.java Changeset: 99c9ae12 Author: Christoph Langer Date: 2024-02-15 22:36:54 +0000 URL: https://git.openjdk.org/lilliput/commit/99c9ae127c0a3b8c4fc6ede87079ff7c693a2905 8323664: java/awt/font/JNICheck/FreeTypeScalerJNICheck.java still fails with JNI warning on some Windows configurations Reviewed-by: prr, mbaesken, aivanov ! src/java.desktop/windows/native/libawt/windows/awt_Debug.cpp ! test/jdk/java/awt/font/JNICheck/FreeTypeScalerJNICheck.java Changeset: 9029bf64 Author: Leonid Mesnik Date: 2024-02-15 22:50:14 +0000 URL: https://git.openjdk.org/lilliput/commit/9029bf644e238a504e1f114a73edf5760d19980b 8316451: 6 java/lang/instrument/PremainClass tests ignore VM flags Reviewed-by: cjplummer, sspitsyn ! test/jdk/java/lang/instrument/NegativeAgentRunner.java ! test/jdk/java/lang/instrument/PremainClass/PremainClassTest.java Changeset: 18cea823 Author: Axel Boldt-Christmas Date: 2024-02-16 07:18:31 +0000 URL: https://git.openjdk.org/lilliput/commit/18cea823a173e1b8b48d276daeca67b2a5cf3584 8319801: Recursive lightweight locking: aarch64 implementation Co-authored-by: Stefan Karlsson Co-authored-by: Erik ?sterlund Reviewed-by: rkennke, coleenp, dcubed, aph ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/aarch64/c1_MacroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.hpp ! src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp ! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp ! src/hotspot/cpu/aarch64/vm_version_aarch64.hpp Changeset: ba8db1f6 Author: Matthias Baesken Date: 2024-02-16 08:21:02 +0000 URL: https://git.openjdk.org/lilliput/commit/ba8db1f6d737bf369f1795d03327217186c0cf64 8325876: crashes in docker container tests on Linuxppc64le Power8 machines Reviewed-by: mdoerr, clanger ! test/lib/jdk/test/lib/containers/docker/DockerfileConfig.java Changeset: 3d851033 Author: Afshin Zafari Date: 2024-02-16 08:27:19 +0000 URL: https://git.openjdk.org/lilliput/commit/3d851033e9319b2e579b1e52e4c0af3ce153d1f6 8316813: NMT: Using WhiteBox API, virtual memory tracking should also be stressed in JMH tests Reviewed-by: jsjolen, gziemski, stuefe + test/micro/org/openjdk/bench/vm/runtime/NMTBenchmark_wb.java Changeset: 2705ed0a Author: Axel Boldt-Christmas Date: 2024-02-16 08:34:58 +0000 URL: https://git.openjdk.org/lilliput/commit/2705ed0a71e606a517518569d60051c85ad3c516 8325074: ZGC fails assert(index == 0 || is_power_of_2(index)) failed: Incorrect load shift: 11 Reviewed-by: eosterlund, stefank, rcastanedalo ! src/hotspot/share/gc/z/zBarrierSet.cpp ! src/hotspot/share/gc/z/zBarrierSet.hpp ! src/hotspot/share/gc/z/zBarrierSet.inline.hpp Changeset: 4018b2b1 Author: Richard Reingruber Date: 2024-02-16 08:40:13 +0000 URL: https://git.openjdk.org/lilliput/commit/4018b2b19629ddb8cd7a56e064dfef371f23e5fa 8323782: Race: Thread::interrupt vs. AbstractInterruptibleChannel.begin Co-authored-by: Alan Bateman Reviewed-by: alanb, dholmes ! src/java.base/share/classes/java/lang/Thread.java + test/jdk/java/nio/channels/Selector/LotsOfInterrupts.java Changeset: 0aaec975 Author: Leo Korinth Date: 2024-02-16 09:23:42 +0000 URL: https://git.openjdk.org/lilliput/commit/0aaec97527ddf2b229a9dd6beaa7ff55c635dee5 8325763: Revert properties: vm.opt.x.* Reviewed-by: ayang, stefank ! test/hotspot/jtreg/gc/arguments/TestG1HeapSizeFlags.java ! test/hotspot/jtreg/gc/arguments/TestHeapFreeRatio.java ! test/hotspot/jtreg/gc/arguments/TestMaxNewSize.java ! test/hotspot/jtreg/gc/arguments/TestParallelHeapSizeFlags.java ! test/hotspot/jtreg/gc/arguments/TestSerialHeapSizeFlags.java ! test/jtreg-ext/requires/VMProps.java Changeset: 9f4ec21f Author: Matthias Baesken Date: 2024-02-16 13:13:11 +0000 URL: https://git.openjdk.org/lilliput/commit/9f4ec21f4793d4c5fc10f93a32140c26ec0eec00 8325862: set -XX:+ErrorFileToStderr when executing java in containers for some container related jtreg tests Reviewed-by: sgehwolf, stuefe, mdoerr ! test/lib/jdk/test/lib/containers/docker/DockerRunOptions.java Changeset: 80b63b67 Author: Alexey Ivanov Date: 2024-02-16 14:10:44 +0000 URL: https://git.openjdk.org/lilliput/commit/80b63b67293970936d57ae4375ad76cd2b11a333 8323801: tag doesn't strikethrough the text Reviewed-by: honkar, dnguyen, psadhukhan ! src/java.desktop/share/classes/javax/swing/text/html/HTMLDocument.java + test/jdk/javax/swing/text/html/HTMLDocument/HTMLUnderlineStrike.java Changeset: 244573e7 Author: Ben Perez Committer: Weijun Wang Date: 2024-02-16 14:51:31 +0000 URL: https://git.openjdk.org/lilliput/commit/244573e719ddb387cb1739d3cab26b72df1e1f0a 8265372: Simplify PKCS9Attribute Reviewed-by: weijun ! src/java.base/share/classes/sun/security/pkcs/PKCS9Attribute.java ! src/java.base/share/classes/sun/security/pkcs/PKCS9Attributes.java + test/jdk/sun/security/pkcs/pkcs9/EncodeDecode.java ! test/jdk/sun/security/x509/AlgorithmId/NonStandardNames.java Changeset: 4388095c Author: Martin Doerr Date: 2024-02-16 15:58:37 +0000 URL: https://git.openjdk.org/lilliput/commit/4388095cde20dec602ada9fe2977f1a359ceab91 8325326: [PPC64] Don't relocate in case of allocation failure Reviewed-by: goetz, rrich ! src/hotspot/cpu/ppc/ppc.ad Changeset: 00b5c707 Author: Daniel D. Daugherty Date: 2024-02-16 16:03:12 +0000 URL: https://git.openjdk.org/lilliput/commit/00b5c70750737855b29b125de6a0c806677c118c 8326062: ProblemList jcstress tests that are failing due to JDK-8325984 Reviewed-by: azvegint, jvernee ! test/hotspot/jtreg/ProblemList.txt Changeset: 7a762520 Author: Brian Burkhalter Date: 2024-02-16 16:06:56 +0000 URL: https://git.openjdk.org/lilliput/commit/7a76252007b603b4346fad61818d488999644f80 8325990: Remove use of snippet @replace annotation in java.base Reviewed-by: jlu, naoto ! src/java.base/share/classes/java/io/Console.java ! src/java.base/share/classes/java/util/ResourceBundle.java Changeset: 53102502 Author: Albert Mingkun Yang Date: 2024-02-16 16:39:28 +0000 URL: https://git.openjdk.org/lilliput/commit/53102502c3f08bef8251a0a2bb361a2f09099576 8325941: Remove unused Space::block_size Reviewed-by: tschatzl ! src/hotspot/share/gc/shared/space.cpp ! src/hotspot/share/gc/shared/space.hpp Changeset: 4c7b313e Author: Justin Lu Date: 2024-02-16 17:14:46 +0000 URL: https://git.openjdk.org/lilliput/commit/4c7b313e0dc917cdaffbb2ecc86d1347683acad0 8325908: Finish removal of IntlTest and CollatorTest Reviewed-by: naoto ! test/jdk/java/text/BreakIterator/Bug4533872.java ! test/jdk/java/text/Collator/APITest.java ! test/jdk/java/text/Format/DateFormat/DateFormatRoundTripTest.java ! test/jdk/java/text/Format/NumberFormat/BigDecimalFormat.java ! test/jdk/java/text/Format/NumberFormat/DFSExponential.java ! test/jdk/java/text/Format/NumberFormat/DFSSerialization.java ! test/jdk/java/util/TimeZone/Bug4322313.java Changeset: f3073db4 Author: Rajan Halade Date: 2024-02-16 18:07:53 +0000 URL: https://git.openjdk.org/lilliput/commit/f3073db42aa80b3ced47edea8d2e8add874fb70f 8321408: Add Certainly roots R1 and E1 Reviewed-by: ascarpino, hchao + src/java.base/share/data/cacerts/certainlyroote1 + src/java.base/share/data/cacerts/certainlyrootr1 ! test/jdk/security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java ! test/jdk/sun/security/lib/cacerts/VerifyCACerts.java Changeset: 267780bf Author: Serguei Spitsyn Date: 2024-02-16 21:21:42 +0000 URL: https://git.openjdk.org/lilliput/commit/267780bf0adf4bfd831fbc04347e297fa8f3bb01 8324680: Replace NULL with nullptr in JVMTI generated code Reviewed-by: amenkov, coleenp ! src/hotspot/share/prims/jvmti.xml ! src/hotspot/share/prims/jvmti.xsl ! src/hotspot/share/prims/jvmtiEnter.xsl ! src/hotspot/share/prims/jvmtiEnv.xsl ! src/hotspot/share/prims/jvmtiLib.xsl Changeset: b5df2f43 Author: Ji?? Van?k Committer: Phil Race Date: 2024-02-16 22:16:58 +0000 URL: https://git.openjdk.org/lilliput/commit/b5df2f43147535b4d22c6451e3a65170159f76b7 8323170: j2dbench is using outdated javac source/target to be able to build by itself Reviewed-by: serb ! src/demo/share/java2d/J2DBench/Makefile ! src/demo/share/java2d/J2DBench/README ! src/demo/share/java2d/J2DBench/build.xml Changeset: 3b763722 Author: Joe Darcy Date: 2024-02-16 22:56:16 +0000 URL: https://git.openjdk.org/lilliput/commit/3b76372254aa638f5dcae1d54b963cd43bca7102 8325687: SimpleJavaFileObject specification would benefit from implSpec Reviewed-by: jlahoda, iris ! src/java.compiler/share/classes/javax/tools/JavaFileManager.java ! src/java.compiler/share/classes/javax/tools/SimpleJavaFileObject.java Changeset: cf13086e Author: Jan Kratochvil Committer: Vladimir Kozlov Date: 2024-02-17 16:37:56 +0000 URL: https://git.openjdk.org/lilliput/commit/cf13086efe0a145d3fc84896473a39a863530629 8317697: refactor-encapsulate x86 VM_Version::CpuidInfo Reviewed-by: dholmes, kvn ! src/hotspot/cpu/x86/vm_version_x86.cpp ! src/hotspot/cpu/x86/vm_version_x86.hpp Changeset: f50df105 Author: Leonid Mesnik Date: 2024-02-17 19:19:47 +0000 URL: https://git.openjdk.org/lilliput/commit/f50df105912858198809b50432ef5a4ab184528d 8299023: TestPLABResize.java and TestPLABPromotion.java are failing intermittently Reviewed-by: tschatzl, ayang ! test/hotspot/jtreg/gc/g1/plab/TestPLABPromotion.java ! test/hotspot/jtreg/gc/g1/plab/TestPLABResize.java Changeset: c2d9fa26 Author: Christoph Langer Date: 2024-02-18 06:58:22 +0000 URL: https://git.openjdk.org/lilliput/commit/c2d9fa26ce903be7c86a47db5ff289cdb9de3a62 8326000: Remove obsolete comments for class sun.security.ssl.SunJSSE Reviewed-by: mbaesken, ascarpino ! src/java.base/share/classes/sun/security/ssl/SunJSSE.java Changeset: 7004c272 Author: Eirik Bj?rsn?s Date: 2024-02-18 15:25:58 +0000 URL: https://git.openjdk.org/lilliput/commit/7004c2724d9b150112c66febb7f24b781ff379dd 8303972: (zipfs) Make test/jdk/jdk/nio/zipfs/TestLocOffsetFromZip64EF.java independent of the zip command line 8301183: (zipfs) jdk/jdk/nio/zipfs/TestLocOffsetFromZip64EF.java failing with ZipException:R0 on OL9 Reviewed-by: lancea ! test/jdk/ProblemList.txt ! test/jdk/jdk/nio/zipfs/TestLocOffsetFromZip64EF.java Changeset: 39627bc4 Author: Prasanta Sadhukhan Date: 2024-02-18 16:14:33 +0000 URL: https://git.openjdk.org/lilliput/commit/39627bc4296dc1cde83c7ef2f2ece1719015df64 6510914: JScrollBar.getMinimumSize() breaks the contract of JComponent.setMinimumSize() Reviewed-by: abhiscxk, prr ! src/java.desktop/share/classes/javax/swing/JComponent.java ! src/java.desktop/share/classes/javax/swing/JScrollBar.java Changeset: 099b7442 Author: Daniel D. Daugherty Date: 2024-02-18 18:10:32 +0000 URL: https://git.openjdk.org/lilliput/commit/099b744235a28331b99f7b429cf1e8abcb367c41 8326117: ProblemList serviceability/jvmti/vthread/SuspendWithInterruptLock/SuspendWithInterruptLock.java#default in Xcomp mode 8326120: ProblemList sun/java2d/X11SurfaceData/SharedMemoryPixmapsTest/SharedMemoryPixmapsTest.sh on macosx-aarch64 Reviewed-by: alanb ! test/hotspot/jtreg/ProblemList-Xcomp.txt ! test/jdk/ProblemList.txt Changeset: 3742bc62 Author: Yi Yang Committer: Tobias Hartmann Date: 2024-02-19 07:38:55 +0000 URL: https://git.openjdk.org/lilliput/commit/3742bc626e80f597373913f02e79c5231e1b7dbc 8323795: jcmd Compiler.codecache should print total size of code cache Reviewed-by: thartmann, kvn ! src/hotspot/share/code/codeCache.cpp ! test/hotspot/jtreg/serviceability/dcmd/compiler/CodeCacheTest.java ! test/hotspot/jtreg/vmTestbase/vm/compiler/CodeCacheInfo/Test.java Changeset: d422811b Author: Denghui Dong Date: 2024-02-19 08:34:40 +0000 URL: https://git.openjdk.org/lilliput/commit/d422811bb7d96d61f7d795ffd4ba84f569a09422 8324630: C1: Canonicalizer::do_LookupSwitch doesn't break the loop when the successor is found Reviewed-by: dlong, thartmann ! src/hotspot/share/c1/c1_Canonicalizer.cpp Changeset: 9451677d Author: Eirik Bj?rsn?s Date: 2024-02-19 09:15:14 +0000 URL: https://git.openjdk.org/lilliput/commit/9451677daaf1184f67759c87114af3f81fa74f23 8326100: DeflaterDictionaryTests should use Deflater.getBytesWritten instead of Deflater.getTotalOut Reviewed-by: alanb, jpai ! test/jdk/java/util/zip/DeflaterDictionaryTests.java Changeset: b3664927 Author: Jaikiran Pai Date: 2024-02-19 09:56:45 +0000 URL: https://git.openjdk.org/lilliput/commit/b3664927616d898ce099808b34e91cc226c8f8ad 8326152: Bad copyright header in test/jdk/java/util/zip/DeflaterDictionaryTests.java Reviewed-by: tschatzl ! test/jdk/java/util/zip/DeflaterDictionaryTests.java Changeset: dc17c268 Author: Matthias Baesken Date: 2024-02-19 12:52:35 +0000 URL: https://git.openjdk.org/lilliput/commit/dc17c268e8e73a36a9914924ee5d0c99fb998f0f 8325116: Amend jdk.ContainerConfiguration by swap related value Reviewed-by: sgehwolf, lucy, egahlin ! src/hotspot/share/jfr/jni/jfrJniMethod.cpp ! src/hotspot/share/jfr/jni/jfrJniMethod.hpp ! src/hotspot/share/jfr/jni/jfrJniMethodRegistration.cpp ! src/jdk.jfr/share/classes/jdk/jfr/events/ContainerConfigurationEvent.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/JVM.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JDKEvents.java ! test/hotspot/jtreg/containers/docker/TestJFREvents.java Changeset: aeb6d8c4 Author: Albert Mingkun Yang Date: 2024-02-19 13:09:22 +0000 URL: https://git.openjdk.org/lilliput/commit/aeb6d8c4594f87ea06d04b52550f83d53b8953b6 8326170: Parallel: Remove unused enum CollectionType in ParallelScavengeHeap Reviewed-by: stefank ! src/hotspot/share/gc/parallel/parallelScavengeHeap.hpp Changeset: 56c50841 Author: vtstydev Committer: Alexey Ivanov Date: 2024-02-19 13:15:13 +0000 URL: https://git.openjdk.org/lilliput/commit/56c50841ee1d4382203e200e9b9c803ee6021097 8307246: Printing: banded raster path doesn't account for device offset values Reviewed-by: prr, psadhukhan, aivanov ! src/java.desktop/share/classes/sun/print/RasterPrinterJob.java + test/jdk/java/awt/print/PrinterJob/ImagePrinting/AlphaPrintingOffsets.java Changeset: a776104e Author: Markus Gr?nlund Date: 2024-02-19 13:19:12 +0000 URL: https://git.openjdk.org/lilliput/commit/a776104e210db212c4e32894844d3c0cbaac53c3 8326106: Write and clear stack trace table outside of safepoint Reviewed-by: egahlin ! src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp ! src/hotspot/share/jfr/recorder/service/jfrRecorderService.cpp ! src/hotspot/share/jfr/recorder/stacktrace/jfrStackTraceRepository.cpp Changeset: 82609b1e Author: Per Minborg Date: 2024-02-19 13:33:09 +0000 URL: https://git.openjdk.org/lilliput/commit/82609b1ebceb658c612c7ed58959cb159a77d4df 8326112: Javadoc snippet for Linker.Option.captureCallState is wrong Reviewed-by: jvernee ! src/java.base/share/classes/java/lang/foreign/Linker.java Changeset: f6d7e30b Author: Chen Liang Committer: Jaikiran Pai Date: 2024-02-19 14:07:46 +0000 URL: https://git.openjdk.org/lilliput/commit/f6d7e30b84fedbf42077526610ba7a5bcfaece4c 8294977: Convert test/jdk/java tests from ASM library to Classfile API Reviewed-by: asotona ! test/jdk/java/io/Serializable/records/BadCanonicalCtrTest.java ! test/jdk/java/io/Serializable/records/ProhibitedMethods.java ! test/jdk/java/io/Serializable/records/SerialPersistentFieldsTest.java ! test/jdk/java/lang/Class/getSimpleName/GetSimpleNameTest.java ! test/jdk/java/lang/ModuleTests/AnnotationsTest.java ! test/jdk/java/lang/annotation/AnnotationTypeMismatchException/AnnotationTypeMismatchTest.java ! test/jdk/java/lang/annotation/AnnotationTypeMismatchException/ArityTypeMismatchTest.java ! test/jdk/java/lang/annotation/AnnotationTypeMismatchException/ArrayTypeMismatchTest.java ! test/jdk/java/lang/annotation/AnnotationTypeMismatchException/EnumTypeMismatchTest.java ! test/jdk/java/lang/annotation/AnnotationVerifier.java ! test/jdk/java/lang/annotation/ClassFileGenerator.java ! test/jdk/java/lang/instrument/MakeJAR2.sh ! test/jdk/java/lang/instrument/NativeMethodPrefixAgent.java ! test/jdk/java/lang/instrument/RetransformAgent.java ! test/jdk/java/lang/instrument/asmlib/Instrumentor.java ! test/jdk/java/lang/invoke/8022701/BogoLoader.java ! test/jdk/java/lang/invoke/8022701/MHIllegalAccess.java ! test/jdk/java/lang/invoke/DefineClassTest.java ! test/jdk/java/lang/invoke/MethodHandles/classData/ClassDataTest.java ! test/jdk/java/lang/invoke/accessProtectedSuper/BogoLoader.java ! test/jdk/java/lang/invoke/accessProtectedSuper/Test.java ! test/jdk/java/lang/invoke/defineHiddenClass/BasicTest.java ! test/jdk/java/lang/invoke/defineHiddenClass/HiddenNestmateTest.java ! test/jdk/java/lang/invoke/defineHiddenClass/PreviewHiddenClass.java ! test/jdk/java/lang/invoke/defineHiddenClass/StaticInvocableTest.java ! test/jdk/java/lang/invoke/lambda/LambdaAsm.java ! test/jdk/java/lang/invoke/lambda/LambdaStackTrace.java ! test/jdk/java/lang/invoke/lookup/SpecialStatic.java ! test/jdk/java/lang/reflect/Method/invoke/TestPrivateInterfaceMethodReflect.java ! test/jdk/java/lang/reflect/records/IsRecordTest.java ! test/jdk/java/util/ServiceLoader/BadProvidersTest.java Changeset: a19314b0 Author: Martin Doerr Date: 2024-02-19 15:20:23 +0000 URL: https://git.openjdk.org/lilliput/commit/a19314b08789afb28e14651868f91d54ed6a9c30 8326101: [PPC64] Need to bailout cleanly if creation of stubs fails when code cache is out of space Reviewed-by: rrich, mbaesken ! src/hotspot/cpu/ppc/c1_CodeStubs_ppc.cpp ! src/hotspot/cpu/ppc/ppc.ad Changeset: 8668198c Author: Magnus Ihse Bursie Date: 2024-02-19 16:11:02 +0000 URL: https://git.openjdk.org/lilliput/commit/8668198c26bdac412f0a9d1255ca74da860761c5 8325972: Add -x to bash for building with LOG=debug Reviewed-by: erikj ! make/common/MakeBase.gmk Changeset: 5c5a282f Author: Magnus Ihse Bursie Date: 2024-02-19 16:13:34 +0000 URL: https://git.openjdk.org/lilliput/commit/5c5a282f91dd28b306673ca2bcc30dec451e7a7d 8325950: Make sure all files in the JDK pass jcheck Reviewed-by: prr, wetmore, erikj, naoto ! make/autoconf/build-aux/pkg.m4 ! src/hotspot/cpu/aarch64/ad_encode.m4 ! src/java.desktop/share/classes/sun/awt/resources/cursors/cursors.properties ! src/java.desktop/share/conf/psfontj2d.properties ! src/java.desktop/share/legal/freetype.md ! src/java.logging/share/conf/logging.properties ! src/java.naming/share/classes/com/sun/jndi/ldap/jndiprovider.properties ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/resources/jdkinternals.properties ! src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent.properties ! src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_de.properties ! src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_es.properties ! src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_fr.properties ! src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_it.properties ! src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_ja.properties ! src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_ko.properties ! src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_pt_BR.properties ! src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_sv.properties ! src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_zh_CN.properties ! src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_zh_TW.properties ! src/jdk.management.agent/share/conf/management.properties ! test/hotspot/jtreg/containers/docker/JfrReporter.java ! test/jdk/java/io/Serializable/serialFilter/logging.properties ! test/jdk/java/lang/ProcessBuilder/ProcessLogging-FINE.properties ! test/jdk/java/lang/ProcessBuilder/ProcessLogging-FINER.properties ! test/jdk/java/lang/ProcessBuilder/ProcessLogging-INFO.properties ! test/jdk/java/lang/RuntimeTests/ExitLogging-FINE.properties ! test/jdk/java/lang/RuntimeTests/ExitLogging-INFO.properties ! test/jdk/java/lang/System/LoggerFinder/SignedLoggerFinderTest/logging.properties ! test/jdk/java/util/Currency/currency.properties ! test/jdk/java/util/jar/JarFile/jarVerification/logging.properties ! test/jdk/java/util/logging/LogManager/Configuration/rootLoggerHandlers/badglobal.properties ! test/jdk/java/util/logging/LogManager/Configuration/rootLoggerHandlers/badlogging.properties ! test/jdk/java/util/logging/LogManager/Configuration/rootLoggerHandlers/logging.properties ! test/jdk/java/util/logging/modules/LogManagerInModule/logging.properties ! test/jdk/jdk/security/logging/logging.properties ! test/jdk/sun/management/LoggingTest/logging.properties ! test/jdk/sun/management/jmxremote/bootstrap/rmiregistry.properties ! test/jdk/sun/management/jmxremote/bootstrap/rmiregistryssl.properties Changeset: 20a25f60 Author: Thomas Stuefe Date: 2024-02-19 19:33:07 +0000 URL: https://git.openjdk.org/lilliput/commit/20a25f60ea56ecd28da1ab377f8f2ca8b2098a3b 8326067: Remove os::remap_memory and simplify os::map_memory Reviewed-by: eosterlund, iklam ! src/hotspot/os/aix/os_aix.cpp ! src/hotspot/os/bsd/os_bsd.cpp ! src/hotspot/os/linux/os_linux.cpp ! src/hotspot/os/posix/os_posix.cpp ! src/hotspot/os/windows/os_windows.cpp ! src/hotspot/share/cds/filemap.cpp ! src/hotspot/share/runtime/os.cpp ! src/hotspot/share/runtime/os.hpp Changeset: a3d7f9f2 Author: David Holmes Date: 2024-02-19 22:00:48 +0000 URL: https://git.openjdk.org/lilliput/commit/a3d7f9f2422cb4b65de7a086dc27dadc0858bf82 8326126: Update the java manpage with the changes from JDK-8322478 Reviewed-by: alanb, cstein ! src/java.base/share/man/java.1 Changeset: 7d32a1a8 Author: Denghui Dong Date: 2024-02-20 00:39:21 +0000 URL: https://git.openjdk.org/lilliput/commit/7d32a1a8293f6d82f4d5959a4c929f96244cc057 8326111: JFR: Cleanup for JFR_ONLY Reviewed-by: egahlin ! src/hotspot/share/classfile/moduleEntry.cpp ! src/hotspot/share/classfile/packageEntry.cpp ! src/hotspot/share/gc/g1/g1Trace.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/x/xTracer.cpp ! src/hotspot/share/gc/z/zTracer.cpp ! src/hotspot/share/runtime/objectMonitor.cpp Changeset: 9fbcc008 Author: Denghui Dong Date: 2024-02-20 00:41:15 +0000 URL: https://git.openjdk.org/lilliput/commit/9fbcc008cbf933aac97b50b7d9f387b19239857f 8326127: JFR: Add SafepointCleanupTask to hardToTestEvents of TestLookForUntestedEvents Reviewed-by: mgronlun ! test/jdk/jdk/jfr/event/metadata/TestLookForUntestedEvents.java ! test/jdk/jdk/jfr/event/runtime/TestSafepointEvents.java Changeset: 69a11c7f Author: David Holmes Date: 2024-02-20 01:25:57 +0000 URL: https://git.openjdk.org/lilliput/commit/69a11c7f7ea7c4195a8ee56391bdf04c75bd8156 8326222: Fix copyright year in src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp Reviewed-by: jiefu, mikael ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp Changeset: 0d285312 Author: Christian Stein Date: 2024-02-20 07:01:45 +0000 URL: https://git.openjdk.org/lilliput/commit/0d285312a958c159d2efb8bd00fc29dd6a5a4d16 8318812: LauncherHelper.checkAndLoadMain closes jar file that's about to be re-opened Reviewed-by: alanb, jpai, coffeys ! src/java.base/share/classes/sun/launcher/LauncherHelper.java ! src/java.base/share/classes/sun/launcher/resources/launcher.properties Changeset: 5bf859c8 Author: Joshua Cao Committer: Aleksey Shipilev Date: 2024-02-20 08:54:36 +0000 URL: https://git.openjdk.org/lilliput/commit/5bf859c8e9bd54cfd254a1485509a7dfa12d02af 8325610: CTW: Add StressIncrementalInlining to stress options Reviewed-by: shade, xliu ! test/hotspot/jtreg/testlibrary/ctw/src/sun/hotspot/tools/ctw/CtwRunner.java Changeset: bb675afa Author: Joshua Cao Committer: Aleksey Shipilev Date: 2024-02-20 08:54:48 +0000 URL: https://git.openjdk.org/lilliput/commit/bb675afae6876fb99aaf0160298463008a9c5efa 8325542: CTW: Runner can produce negative StressSeed Reviewed-by: shade, xliu ! test/hotspot/jtreg/testlibrary/ctw/src/sun/hotspot/tools/ctw/CtwRunner.java Changeset: 56073cd1 Author: Albert Mingkun Yang Date: 2024-02-20 09:19:14 +0000 URL: https://git.openjdk.org/lilliput/commit/56073cd1eadca41f4712299f9647cd43f20d2dd8 8326171: Serial: Remove VerifyGCLevel Reviewed-by: stefank, tschatzl ! src/hotspot/share/gc/serial/serialHeap.cpp ! src/hotspot/share/gc/shared/gc_globals.hpp Changeset: beed4145 Author: Albert Mingkun Yang Date: 2024-02-20 09:38:13 +0000 URL: https://git.openjdk.org/lilliput/commit/beed4145ec014addc7fe6ca82652740c247da496 8326209: G1: Remove G1ConcurrentMark::_total_cleanup_time Reviewed-by: kbarrett, tschatzl ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp ! src/hotspot/share/gc/g1/g1ConcurrentMark.hpp Changeset: d60331a2 Author: Albert Mingkun Yang Date: 2024-02-20 09:38:23 +0000 URL: https://git.openjdk.org/lilliput/commit/d60331a21c30271340f7d6d58f3122f0e6431a04 8326196: Serial: Remove SerialHeap::generation_iterate Reviewed-by: tschatzl, kbarrett ! src/hotspot/share/gc/serial/serialHeap.cpp ! src/hotspot/share/gc/serial/serialHeap.hpp Changeset: 4957d6a6 Author: Tobias Holenstein Date: 2024-02-20 15:49:48 +0000 URL: https://git.openjdk.org/lilliput/commit/4957d6a61e520f61884b16a37db5daf330c69ac0 8325441: IGV: update pom.xml such that IntelliJ can import as maven project Reviewed-by: rcastanedalo, chagedorn ! src/utils/IdealGraphVisualizer/.java-version ! src/utils/IdealGraphVisualizer/Bytecodes/pom.xml ! src/utils/IdealGraphVisualizer/ControlFlow/pom.xml ! src/utils/IdealGraphVisualizer/Coordinator/pom.xml ! src/utils/IdealGraphVisualizer/Data/pom.xml ! src/utils/IdealGraphVisualizer/Difference/pom.xml ! src/utils/IdealGraphVisualizer/Filter/pom.xml ! src/utils/IdealGraphVisualizer/FilterWindow/pom.xml ! src/utils/IdealGraphVisualizer/Graph/pom.xml ! src/utils/IdealGraphVisualizer/HierarchicalLayout/pom.xml ! src/utils/IdealGraphVisualizer/Layout/pom.xml ! src/utils/IdealGraphVisualizer/NetworkConnection/pom.xml ! src/utils/IdealGraphVisualizer/SelectionCoordinator/pom.xml ! src/utils/IdealGraphVisualizer/ServerCompiler/pom.xml ! src/utils/IdealGraphVisualizer/Settings/pom.xml ! src/utils/IdealGraphVisualizer/Util/pom.xml ! src/utils/IdealGraphVisualizer/View/pom.xml ! src/utils/IdealGraphVisualizer/View/src/main/java/com/sun/hotspot/igv/view/ExportGraph.java ! src/utils/IdealGraphVisualizer/application/pom.xml ! src/utils/IdealGraphVisualizer/branding/pom.xml ! src/utils/IdealGraphVisualizer/pom.xml Changeset: 9538f5d3 Author: Darragh Clarke Date: 2024-02-20 16:00:09 +0000 URL: https://git.openjdk.org/lilliput/commit/9538f5d317972bbb82f7f2575819d35d2a5f8b91 8319651: Several network tests ignore vm flags when start java process Reviewed-by: dfuchs, jpai ! test/jdk/java/net/InetAddress/ptr/Lookup.java ! test/jdk/java/net/ServerSocket/AcceptCauseFileDescriptorLeak.java ! test/jdk/java/net/ServerSocket/AcceptInheritHandle.java ! test/jdk/java/net/URLClassLoader/getresourceasstream/TestDriver.java ! test/jdk/java/net/URLClassLoader/sealing/CheckSealedTest.java ! test/jdk/java/net/URLConnection/6212146/TestDriver.java ! test/jdk/java/net/URLConnection/ContentHandlers/ContentHandlersTest.java ! test/jdk/java/net/httpclient/security/Driver.java ! test/jdk/java/net/spi/URLStreamHandlerProvider/Basic.java ! test/jdk/javax/net/ssl/DTLS/DTLSWontNegotiateV10.java ! test/jdk/javax/net/ssl/ciphersuites/TLSWontNegotiateDisabledCipherAlgos.java ! test/jdk/sun/net/www/protocol/jar/GetContentTypeTest.java ! test/jdk/sun/net/www/protocol/jar/jarbug/TestDriver.java ! test/jdk/sun/net/www/protocol/jrt/OtherResourcesTest.java Changeset: b419e951 Author: Alexey Ivanov Date: 2024-02-20 16:30:32 +0000 URL: https://git.openjdk.org/lilliput/commit/b419e9517361ed9d28f8ab2f5beacf5adfe3db91 8294148: Support JSplitPane for instructions and test UI Reviewed-by: honkar, dmarkov ! test/jdk/java/awt/regtesthelpers/PassFailJFrame.java Changeset: a2d027ea Author: Hannes Walln?fer Date: 2024-02-20 19:22:59 +0000 URL: https://git.openjdk.org/lilliput/commit/a2d027eaa0b11b6bca39bc88a66304ba149721bf 8326089: Text incorrectly placed in breadcrumbs list in generated docs Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Navigation.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/stylesheet.css ! test/langtools/jdk/javadoc/doclet/testModules/TestModulePackages.java ! test/langtools/jdk/javadoc/doclet/testNavigation/TestNavigation.java ! test/langtools/jdk/javadoc/doclet/testPreview/TestPreview.java Changeset: aa792eab Author: Hannes Walln?fer Date: 2024-02-20 19:56:15 +0000 URL: https://git.openjdk.org/lilliput/commit/aa792eababda966c1195dc5701906c66f1628f49 8164094: javadoc allows to create a @link to a non-existent method Reviewed-by: prappo, jjg ! src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTrees.java ! test/langtools/tools/javac/doctree/ReferenceTest.java Changeset: d2590c69 Author: Claes Redestad Date: 2024-02-20 20:28:55 +0000 URL: https://git.openjdk.org/lilliput/commit/d2590c69b4efe5aa2b48b08070e0dbafb04ef202 8325730: StringBuilder.toString allocation for the empty String Reviewed-by: jlaskey, shade ! src/java.base/share/classes/java/lang/StringBuffer.java ! src/java.base/share/classes/java/lang/StringBuilder.java ! test/micro/org/openjdk/bench/java/lang/StringBuffers.java ! test/micro/org/openjdk/bench/java/lang/StringBuilders.java Changeset: 221fbfb4 Author: Calvin Cheung Date: 2024-02-20 21:10:09 +0000 URL: https://git.openjdk.org/lilliput/commit/221fbfb4360102a6661bfb05a336bd9461a9fa2a 8320002: Remove obsolete CDS check in Reflection::verify_class_access() Reviewed-by: iklam, matsaave, dholmes ! src/hotspot/share/runtime/reflection.cpp Changeset: 4d50ee63 Author: Magnus Ihse Bursie Date: 2024-02-20 22:24:25 +0000 URL: https://git.openjdk.org/lilliput/commit/4d50ee63d6eebe73579f05214e6a0fc1b8ebad99 8326368: compare.sh -2bins prints ugly errors on Windows Reviewed-by: erikj ! make/scripts/compare.sh Changeset: 1bd91cde Author: Magnus Ihse Bursie Date: 2024-02-20 22:25:29 +0000 URL: https://git.openjdk.org/lilliput/commit/1bd91cdebee1e9ec78ecf185529923eef40ff89c 8325963: Clean up NativeCompilation.gmk and its newly created parts Reviewed-by: jwaters, erikj ! make/common/NativeCompilation.gmk ! make/common/native/CompileFile.gmk ! make/common/native/DebugSymbols.gmk ! make/common/native/Flags.gmk ! make/common/native/Link.gmk ! make/common/native/Paths.gmk Changeset: 14f9aba9 Author: David Holmes Date: 2024-02-21 01:15:25 +0000 URL: https://git.openjdk.org/lilliput/commit/14f9aba921c811eebc78d871aa24915412a19e14 8326371: [BACKOUT] Clean up NativeCompilation.gmk and its newly created parts Reviewed-by: mikael ! make/common/NativeCompilation.gmk ! make/common/native/CompileFile.gmk ! make/common/native/DebugSymbols.gmk ! make/common/native/Flags.gmk ! make/common/native/Link.gmk ! make/common/native/Paths.gmk Changeset: 36246c97 Author: Jaikiran Pai Date: 2024-02-21 01:26:21 +0000 URL: https://git.openjdk.org/lilliput/commit/36246c975bd62845367fe67274d67bcffcff7c80 8326233: Utils#copySSLParameters loses needClientAuth Setting Reviewed-by: djelinski, jjiang, dfuchs ! src/java.net.http/share/classes/jdk/internal/net/http/common/Utils.java ! test/jdk/java/net/httpclient/HttpClientBuilderTest.java Changeset: 27003b53 Author: Kim Barrett Date: 2024-02-21 03:09:29 +0000 URL: https://git.openjdk.org/lilliput/commit/27003b53bbb565123678a7feca74628b29991a5c 8326090: Rename jvmti_aod.h Reviewed-by: coleenp, sspitsyn ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach002/attach002Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach002a/attach002aAgent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach008/attach008Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach009/attach009Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach012/attach012Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach014/attach014Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach015/attach015Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach015/attach015Agent01.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach015/attach015Target.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach020/attach020Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach021/attach021Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach022/attach022Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach037/attach037Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach038/attach038Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach039/attach039Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach040/attach040Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach041/attach041Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach042/attach042Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach045/attach045Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach045/attach045Agent01.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach045/attach045Agent02.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach045/attach045Agent03.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach046/attach046Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach050/attach050Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/sharedAgents/simpleAgent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/aod/jvmti_aod.cpp = test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/aod/jvmti_aod.hpp Changeset: d31fd78d Author: Thomas Stuefe Date: 2024-02-21 04:39:09 +0000 URL: https://git.openjdk.org/lilliput/commit/d31fd78d963d5d103b1b1bf66ae0bdbe4be2b790 8325496: Make TrimNativeHeapInterval a product switch Reviewed-by: dholmes, mbaesken ! src/hotspot/share/runtime/globals.hpp ! src/java.base/share/man/java.1 ! test/hotspot/jtreg/gtest/NativeHeapTrimmerGtest.java ! test/hotspot/jtreg/runtime/os/TestTrimNative.java Changeset: d5f3d5c8 Author: Amit Kumar Date: 2024-02-21 05:37:21 +0000 URL: https://git.openjdk.org/lilliput/commit/d5f3d5c8cc347ae384dea25b1a55ed57204d1af3 8326201: [S390] Need to bailout cleanly if creation of stubs fails when code cache is out of space Reviewed-by: lucy, mdoerr ! src/hotspot/cpu/s390/c1_CodeStubs_s390.cpp ! src/hotspot/cpu/s390/s390.ad Changeset: 04d43c43 Author: Tejesh R Date: 2024-02-21 05:54:30 +0000 URL: https://git.openjdk.org/lilliput/commit/04d43c435d3ede519df169053dd9d724aa2312eb 8187759: Background not refreshed when painting over a transparent JFrame Reviewed-by: azvegint, abhiscxk, serb ! src/java.desktop/share/classes/javax/swing/BufferStrategyPaintManager.java + test/jdk/javax/swing/JFrame/JFrameBackgroundRefreshTest.java Changeset: 68eb5a1d Author: Robbin Ehn Date: 2024-02-21 08:58:19 +0000 URL: https://git.openjdk.org/lilliput/commit/68eb5a1df5afdc011aa467f1c723a8792532dd3f 8321075: RISC-V: UseSystemMemoryBarrier lacking proper OS support Reviewed-by: fyang, yadongwang, luhenry ! src/hotspot/os/linux/os_linux.cpp ! src/hotspot/os/linux/os_linux.hpp ! src/hotspot/os/linux/systemMemoryBarrier_linux.cpp Changeset: 921507c5 Author: Albert Mingkun Yang Date: 2024-02-21 10:27:55 +0000 URL: https://git.openjdk.org/lilliput/commit/921507c51062e82e55ade43262e7eb8036ea4bd6 8326319: G1: Remove unused G1ConcurrentMark::_init_times Reviewed-by: tschatzl, kbarrett ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp ! src/hotspot/share/gc/g1/g1ConcurrentMark.hpp Changeset: 5f16f342 Author: Claes Redestad Date: 2024-02-21 11:19:37 +0000 URL: https://git.openjdk.org/lilliput/commit/5f16f342d9be955b87054bf4b6369ed47cca964d 8326370: Remove redundant and misplaced micros from StringBuffers Reviewed-by: shade ! test/micro/org/openjdk/bench/java/lang/StringBuffers.java Changeset: 492e8bf5 Author: Aleksey Shipilev Date: 2024-02-21 11:48:59 +0000 URL: https://git.openjdk.org/lilliput/commit/492e8bf563135d27b46fde198880e62d5f1940e8 8325587: Shenandoah: ShenandoahLock should allow blocking in VM Reviewed-by: rehn, rkennke ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahLock.cpp ! src/hotspot/share/gc/shenandoah/shenandoahLock.hpp Changeset: 23522682 Author: Markus Gr?nlund Date: 2024-02-21 13:38:36 +0000 URL: https://git.openjdk.org/lilliput/commit/23522682d4bcf9592682007909a74c5cf0b067c3 8326334: JFR failed assert(used(klass)) failed: invariant Reviewed-by: egahlin ! src/hotspot/share/jfr/support/jfrKlassUnloading.cpp Changeset: 33834b7d Author: Magnus Ihse Bursie Date: 2024-02-21 13:44:12 +0000 URL: https://git.openjdk.org/lilliput/commit/33834b7d14de8cca1587d8405d13aec669b6cc23 8326375: [REDO] Clean up NativeCompilation.gmk and its newly created parts Reviewed-by: jwaters, erikj ! make/common/NativeCompilation.gmk ! make/common/native/CompileFile.gmk ! make/common/native/DebugSymbols.gmk ! make/common/native/Flags.gmk ! make/common/native/Link.gmk ! make/common/native/Paths.gmk Changeset: c022431a Author: Magnus Ihse Bursie Date: 2024-02-21 14:10:38 +0000 URL: https://git.openjdk.org/lilliput/commit/c022431a00a1d84594779315dd1159a7cf03142e 8326412: debuginfo files should not have executable bit set Reviewed-by: erikj ! make/common/native/DebugSymbols.gmk Changeset: 51e2dde0 Author: Robbin Ehn Date: 2024-02-21 14:33:29 +0000 URL: https://git.openjdk.org/lilliput/commit/51e2dde018746f419922ae40cd039cd6f27f1b75 8326235: RISC-V: Size CodeCache for short calls encoding Reviewed-by: fyang, tonyp ! src/hotspot/cpu/riscv/globalDefinitions_riscv.hpp ! src/hotspot/share/utilities/globalDefinitions.hpp Changeset: f0f4d63f Author: Lance Andersen Date: 2024-02-21 14:51:35 +0000 URL: https://git.openjdk.org/lilliput/commit/f0f4d63fa9c9f487198b2a2b7b410b590e1437bc 8326351: Update the Zlib version in open/src/java.base/share/legal/zlib.md to 1.3.1 Reviewed-by: iris, naoto, jpai ! src/java.base/share/legal/zlib.md Changeset: 64f7972a Author: Naoto Sato Date: 2024-02-21 16:53:57 +0000 URL: https://git.openjdk.org/lilliput/commit/64f7972a3d0c82ad7047f73f0b57c3d88f62935f 8326158: Javadoc for java.time.DayOfWeek#minus(long) Reviewed-by: iris, lancea ! src/java.base/share/classes/java/time/DayOfWeek.java Changeset: 0bcece99 Author: Magnus Ihse Bursie Date: 2024-02-21 22:34:58 +0000 URL: https://git.openjdk.org/lilliput/commit/0bcece995840777db660811e4b20bb018e90439b 8325342: Remove unneeded exceptions in compare.sh Reviewed-by: erikj ! make/scripts/compare.sh ! make/scripts/compare_exceptions.sh.incl Changeset: 8e5f6ddb Author: Sam James Committer: Julian Waters Date: 2024-02-22 06:27:25 +0000 URL: https://git.openjdk.org/lilliput/commit/8e5f6ddb68572c0cc8b6e256e423706f6f7cec94 8324243: Compilation failures in java.desktop module with gcc 14 Reviewed-by: jwaters, ihse, kbarrett, prr ! make/modules/java.desktop/lib/Awt2dLibraries.gmk ! src/java.desktop/linux/native/libjsound/PLATFORM_API_LinuxOS_ALSA_MidiIn.c ! src/java.desktop/linux/native/libjsound/PLATFORM_API_LinuxOS_ALSA_MidiUtils.c ! src/java.desktop/share/native/libfontmanager/sunFont.c Changeset: 8b305033 Author: Laurent Bourg?s Date: 2024-02-22 07:57:21 +0000 URL: https://git.openjdk.org/lilliput/commit/8b3050338768ea7f378fbc39dedb51be9846137d 8323695: RenderPerf (2D) enhancements (23.12) Reviewed-by: avu, prr ! test/jdk/performance/client/RenderPerfTest/src/renderperf/RenderPerfTest.java Changeset: 0f4cd8f1 Author: Albert Mingkun Yang Date: 2024-02-22 07:57:31 +0000 URL: https://git.openjdk.org/lilliput/commit/0f4cd8f1c06a78cce8eea241034bcb33154f769e 8326414: Serial: Inline SerialHeap::create_rem_set Reviewed-by: kbarrett ! src/hotspot/share/gc/serial/serialHeap.cpp ! src/hotspot/share/gc/serial/serialHeap.hpp Changeset: 10eafdc6 Author: Axel Boldt-Christmas Date: 2024-02-22 09:14:20 +0000 URL: https://git.openjdk.org/lilliput/commit/10eafdc62e8216e6ef69773fe491a21346c8682d 8325870: Zap end padding bits for ArrayOops in non-release builds Reviewed-by: stefank, ayang ! src/hotspot/share/gc/shared/memAllocator.cpp ! src/hotspot/share/gc/shared/memAllocator.hpp ! src/hotspot/share/gc/z/zObjArrayAllocator.cpp ! src/hotspot/share/utilities/globalDefinitions.hpp Changeset: cc1e216e Author: SendaoYan Committer: Alan Bateman Date: 2024-02-22 09:59:37 +0000 URL: https://git.openjdk.org/lilliput/commit/cc1e216eb9e4c817f6744ec76d62f21f4bd14489 8326461: tools/jlink/CheckExecutable.java fails as .debuginfo files are not executable Reviewed-by: shade, alanb ! test/jdk/tools/jlink/CheckExecutable.java Changeset: 4406915e Author: Roland Westrelin Date: 2024-02-22 11:07:13 +0000 URL: https://git.openjdk.org/lilliput/commit/4406915ebce4266b3eb4a238382fff3c2c1d1739 8323274: C2: array load may float above range check Reviewed-by: epeter, thartmann ! src/hotspot/share/opto/arraycopynode.cpp ! src/hotspot/share/opto/loopnode.hpp ! src/hotspot/share/opto/loopopts.cpp ! src/hotspot/share/opto/split_if.cpp + test/hotspot/jtreg/compiler/rangechecks/TestArrayAccessAboveRCAfterPartialPeeling.java + test/hotspot/jtreg/compiler/rangechecks/TestArrayAccessAboveRCAfterSinking.java + test/hotspot/jtreg/compiler/rangechecks/TestArrayAccessAboveRCAfterSplitIf.java + test/hotspot/jtreg/compiler/rangechecks/TestArrayAccessAboveRCAfterUnswitching.java + test/hotspot/jtreg/compiler/rangechecks/TestArrayAccessAboveRCForArrayCopyLoad.java Changeset: f365d807 Author: Fredrik Bredberg Committer: Coleen Phillimore Date: 2024-02-22 13:07:32 +0000 URL: https://git.openjdk.org/lilliput/commit/f365d807e5552a6ad9a36afd82db8f0881d62cc3 8325153: SEGV in stackChunkOopDesc::derelativize_address(int) Reviewed-by: stefank, coleenp ! src/hotspot/share/prims/stackwalk.cpp Changeset: 724a2a2c Author: Renjith Kannath Pariyangad Committer: Alexey Ivanov Date: 2024-02-22 14:05:02 +0000 URL: https://git.openjdk.org/lilliput/commit/724a2a2c4a6020188b7907509cd48aa126b79b0f 8321192: j.a.PrintJob/ImageTest/ImageTest.java: Fail or skip the test if there's no printer Reviewed-by: aivanov, tr + test/jdk/java/awt/PrintJob/ImageTest/ImageTest.java Changeset: 8e5c0ee4 Author: Erik Gahlin Date: 2024-02-22 15:29:05 +0000 URL: https://git.openjdk.org/lilliput/commit/8e5c0ee402be597f6354ea870d3d5d1f43051e65 8324832: JFR: Improve sorting of 'jfr summary' Reviewed-by: mgronlun ! src/jdk.jfr/share/classes/jdk/jfr/internal/tool/Summary.java Changeset: 864cf222 Author: Stefan Karlsson Date: 2024-02-22 15:58:41 +0000 URL: https://git.openjdk.org/lilliput/commit/864cf22241281721a0f0ddbe96cd43b4e3c5520c 8325742: Remove MetaWord usage from MemRegion Reviewed-by: coleenp, tschatzl ! src/hotspot/share/memory/memRegion.hpp Changeset: 9f9a732c Author: Stefan Karlsson Date: 2024-02-22 16:02:26 +0000 URL: https://git.openjdk.org/lilliput/commit/9f9a732c38072b8168b3c0caee9069f34f6655a8 8325752: Remove badMetaWordVal Reviewed-by: coleenp, tschatzl ! src/hotspot/share/oops/oop.cpp ! src/hotspot/share/oops/stackChunkOop.cpp ! src/hotspot/share/utilities/globalDefinitions.hpp Changeset: d695af89 Author: Thomas Stuefe Date: 2024-02-22 17:45:34 +0000 URL: https://git.openjdk.org/lilliput/commit/d695af89f6463591e870f631dc816c7729e33567 8326376: java -version failed with CONF=fastdebug -XX:InitialCodeCacheSize=1024K -XX:ReservedCodeCacheSize=1200k Reviewed-by: kvn, jwaters ! src/hotspot/share/compiler/compilationFailureInfo.cpp ! src/hotspot/share/compiler/compilationFailureInfo.hpp ! test/hotspot/jtreg/compiler/startup/StartupOutput.java Changeset: 00ffc42c Author: Justin Lu Date: 2024-02-22 22:27:12 +0000 URL: https://git.openjdk.org/lilliput/commit/00ffc42cef79d82b2f417c133a48bffec4c7e6b9 8318761: MessageFormat pattern support for CompactNumberFormat, ListFormat, and DateTimeFormatter Reviewed-by: naoto, rriggs ! src/java.base/share/classes/java/text/DateFormat.java ! src/java.base/share/classes/java/text/MessageFormat.java ! src/java.base/share/classes/java/text/NumberFormat.java + test/jdk/java/text/Format/MessageFormat/CompactSubFormats.java + test/jdk/java/text/Format/MessageFormat/ListSubFormats.java ! test/jdk/java/text/Format/MessageFormat/MessageFormatExceptions.java + test/jdk/java/text/Format/MessageFormat/TemporalSubFormats.java Changeset: 54f09d73 Author: Jaikiran Pai Date: 2024-02-23 00:53:19 +0000 URL: https://git.openjdk.org/lilliput/commit/54f09d734584a71c648520664447f8395050adbe 8278527: java/util/concurrent/tck/JSR166TestCase.java fails nanoTime test Reviewed-by: martin, lancea ! test/jdk/java/util/concurrent/tck/JSR166TestCase.java - test/jdk/java/util/concurrent/tck/SystemTest.java Changeset: c4409eaf Author: Erik Gahlin Date: 2024-02-23 02:02:35 +0000 URL: https://git.openjdk.org/lilliput/commit/c4409eafc418c1e7a4ca2a2a522b6855c70c0f8c 8325994: JFR: Examples in JFR.start help use incorrect separator Reviewed-by: mikael ! src/jdk.jfr/share/classes/jdk/jfr/internal/dcmd/DCmdStart.java Changeset: cb809f8e Author: Jan Lahoda Date: 2024-02-23 08:56:14 +0000 URL: https://git.openjdk.org/lilliput/commit/cb809f8e04c12f0d06237c9c3fd05f6c585098a6 8325215: Incorrect not exhaustive switch error Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java ! test/langtools/tools/javac/patterns/Exhaustiveness.java Changeset: 336bbbe3 Author: Roman Kennke Date: 2024-02-23 10:05:25 +0000 URL: https://git.openjdk.org/lilliput/commit/336bbbe3895214a772e0f3aafb36277c46645ded 8139457: Relax alignment of array elements Co-authored-by: Fei Yang Co-authored-by: Thomas Stuefe Reviewed-by: stuefe, stefank, shade, coleenp, kdnilsen, aboldtch ! src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/c1_MacroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/c1_MacroAssembler_aarch64.hpp ! src/hotspot/cpu/arm/c1_LIRAssembler_arm.cpp ! src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cpp ! src/hotspot/cpu/ppc/c1_MacroAssembler_ppc.cpp ! src/hotspot/cpu/ppc/c1_MacroAssembler_ppc.hpp ! src/hotspot/cpu/riscv/c1_LIRAssembler_riscv.cpp ! src/hotspot/cpu/riscv/c1_MacroAssembler_riscv.cpp ! src/hotspot/cpu/riscv/c1_MacroAssembler_riscv.hpp ! src/hotspot/cpu/s390/c1_LIRAssembler_s390.cpp ! src/hotspot/cpu/s390/c1_MacroAssembler_s390.cpp ! src/hotspot/cpu/s390/c1_MacroAssembler_s390.hpp ! src/hotspot/cpu/x86/c1_LIRAssembler_x86.cpp ! src/hotspot/cpu/x86/c1_MacroAssembler_x86.cpp ! src/hotspot/cpu/x86/c1_MacroAssembler_x86.hpp ! src/hotspot/share/gc/shared/collectedHeap.cpp ! src/hotspot/share/gc/x/xObjArrayAllocator.cpp ! src/hotspot/share/gc/z/zObjArrayAllocator.cpp ! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp ! src/hotspot/share/oops/arrayOop.hpp ! src/hotspot/share/oops/objArrayOop.hpp ! src/hotspot/share/opto/runtime.cpp ! src/hotspot/share/opto/type.cpp ! src/hotspot/share/prims/unsafe.cpp ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/memory/Universe.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/Array.java ! test/hotspot/gtest/oops/test_arrayOop.cpp + test/hotspot/gtest/oops/test_objArrayOop.cpp + test/hotspot/jtreg/gtest/ArrayTests.java + test/hotspot/jtreg/gtest/ObjArrayTests.java + test/hotspot/jtreg/runtime/FieldLayout/ArrayBaseOffsets.java ! test/jdk/java/lang/instrument/GetObjectSizeIntrinsicsTest.java Changeset: 93a2e773 Author: Jan Lahoda Date: 2024-02-23 10:08:56 +0000 URL: https://git.openjdk.org/lilliput/commit/93a2e773a508ef7960214e20c2df5e8456f2e8c2 8326129: Java Record Pattern Match leads to infinite loop Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java ! test/langtools/tools/javac/patterns/TranslationTest.java Changeset: 5d414da5 Author: Roland Westrelin Date: 2024-02-23 10:09:06 +0000 URL: https://git.openjdk.org/lilliput/commit/5d414da50459b7a1e6f0f537ff3b318854b2c427 8325372: Shenandoah: SIGSEGV crash in unnecessary_acquire due to LoadStore split through phi Reviewed-by: shade, rkennke, thartmann ! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp ! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.hpp ! src/hotspot/share/opto/memnode.cpp + test/hotspot/jtreg/gc/shenandoah/compiler/TestUnsafeLoadStoreMergedHeapStableTests.java Changeset: 11fdca06 Author: Ivan Walulya Date: 2024-02-23 10:48:50 +0000 URL: https://git.openjdk.org/lilliput/commit/11fdca06345542b8d5e54feb1d16f17c2bcb1a82 8325202: gc/g1/TestMarkStackOverflow.java intermittently crash: G1CMMarkStack::ChunkAllocator::allocate_new_chunk Reviewed-by: tschatzl, ayang ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp ! src/hotspot/share/gc/g1/g1ConcurrentMark.hpp Changeset: ef2d5c40 Author: Albert Mingkun Yang Date: 2024-02-23 11:47:29 +0000 URL: https://git.openjdk.org/lilliput/commit/ef2d5c40c0d997ba1c5c7eaa50040e8757f06f36 8326065: Merge Space into ContiguousSpace Reviewed-by: cjplummer, sjohanss ! src/hotspot/share/gc/shared/space.cpp ! src/hotspot/share/gc/shared/space.hpp ! src/hotspot/share/gc/shared/vmStructs_gc.hpp ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/serial/SerialHeap.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/shared/ContiguousSpace.java - src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/shared/GenerationFactory.java - src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/shared/Space.java - src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/shared/SpaceClosure.java Changeset: 09a78b5d Author: Martin Doerr Date: 2024-02-23 13:52:10 +0000 URL: https://git.openjdk.org/lilliput/commit/09a78b5da961f3575cf20c9b56bff86ddbd6545d 8326378: [PPC64] CodeEntryAlignment too large Reviewed-by: shade, lucy ! src/hotspot/cpu/ppc/globals_ppc.hpp Changeset: c26c5833 Author: Weijun Wang Date: 2024-02-23 16:10:44 +0000 URL: https://git.openjdk.org/lilliput/commit/c26c5833ccd7bdfd3f8ed9da76334d5b4e6e55ca 8311003: missing @since info in jdk.security.jgss Reviewed-by: mullan ! src/jdk.security.jgss/share/classes/com/sun/security/jgss/AuthorizationDataEntry.java ! src/jdk.security.jgss/share/classes/com/sun/security/jgss/ExtendedGSSContext.java ! src/jdk.security.jgss/share/classes/com/sun/security/jgss/GSSUtil.java ! src/jdk.security.jgss/share/classes/com/sun/security/jgss/InquireSecContextPermission.java ! src/jdk.security.jgss/share/classes/com/sun/security/jgss/InquireType.java ! src/jdk.security.jgss/share/classes/com/sun/security/jgss/package-info.java Changeset: 27574b38 Author: Magnus Ihse Bursie Date: 2024-02-23 17:31:13 +0000 URL: https://git.openjdk.org/lilliput/commit/27574b384cb5c46358a8bba1bffa8d57d85f6670 8326585: COMPARE_BUILD=PATCH fails if patch -R fails Reviewed-by: erikj ! make/InitSupport.gmk Changeset: 63f6a563 Author: Joe Darcy Date: 2024-02-23 18:03:02 +0000 URL: https://git.openjdk.org/lilliput/commit/63f6a563a3987d74ef673718d5209cc7c469751c 8326530: Widen allowable error bound of Math.tan Reviewed-by: bpb, rgiulietti ! src/java.base/share/classes/java/lang/Math.java Changeset: d10f277b Author: Leonid Mesnik Date: 2024-02-23 19:58:38 +0000 URL: https://git.openjdk.org/lilliput/commit/d10f277bd39bb5ac9bd48939c916de607fef8ace 8326006: Allow TEST_VM_FLAGLESS to set flagless mode Reviewed-by: tschatzl, ayang ! test/jtreg-ext/requires/VMProps.java Changeset: 1799ffea Author: Korov Committer: Jaikiran Pai Date: 2024-02-25 11:52:19 +0000 URL: https://git.openjdk.org/lilliput/commit/1799ffeaa9baa7d703c7acc8d8738211694f946e 8310351: Typo in ImmutableCollections Reviewed-by: jlaskey, jpai ! src/java.base/share/classes/java/util/ImmutableCollections.java Changeset: 09f755a6 Author: Thomas Schatzl Date: 2024-02-26 07:28:37 +0000 URL: https://git.openjdk.org/lilliput/commit/09f755a64db2e38d59c89e6b14d6e409f51126e4 8325857: G1 Full GC flushes mark stats cache too early Reviewed-by: iwalulya, ayang ! src/hotspot/share/gc/g1/g1FullCollector.cpp ! src/hotspot/share/gc/g1/g1FullGCMarkTask.cpp Changeset: f32f5740 Author: Albert Mingkun Yang Date: 2024-02-26 09:36:48 +0000 URL: https://git.openjdk.org/lilliput/commit/f32f5740046e11868a3eec69495056c75e1237a9 8326575: Remove unused ContiguousSpace::set_top_for_allocations Reviewed-by: tschatzl, sjohanss ! src/hotspot/share/gc/shared/space.cpp ! src/hotspot/share/gc/shared/space.hpp Changeset: 3a00fc73 Author: Chen Liang Committer: Pavel Rappo Date: 2024-02-26 12:10:58 +0000 URL: https://git.openjdk.org/lilliput/commit/3a00fc732a959300a558d5062e5486220ea75192 8323698: Class use page does not include extends/implements type arguments Reviewed-by: prappo, hannesw ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassUseWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/ClassUseMapper.java ! test/langtools/jdk/javadoc/doclet/testUseOption/TestUseOption.java Changeset: 490825fb Author: Emanuel Peter Date: 2024-02-26 13:02:04 +0000 URL: https://git.openjdk.org/lilliput/commit/490825fb915c9a63459f87ffea4a9b7c1f0448ef 8325589: C2 SuperWord refactoring: create VLoopAnalyzer with Submodules Reviewed-by: kvn, chagedorn ! src/hotspot/cpu/x86/x86_64.ad ! src/hotspot/share/opto/loopopts.cpp ! src/hotspot/share/opto/superword.cpp ! src/hotspot/share/opto/superword.hpp ! src/hotspot/share/opto/traceAutoVectorizationTag.hpp ! src/hotspot/share/opto/vectorization.cpp ! src/hotspot/share/opto/vectorization.hpp Changeset: bb6b0489 Author: Eirik Bj?rsn?s Date: 2024-02-26 14:15:24 +0000 URL: https://git.openjdk.org/lilliput/commit/bb6b04897b5d83dd89fc11074dd66af024f9c6fc 8326099: GZIPOutputStream should use Deflater.getBytesRead() instead of Deflater.getTotalIn() Reviewed-by: jpai ! src/java.base/share/classes/java/util/zip/GZIPOutputStream.java Changeset: c042f086 Author: Claes Redestad Date: 2024-02-26 15:30:21 +0000 URL: https://git.openjdk.org/lilliput/commit/c042f0863247633e98ace9757fb8531145286e66 8326653: Remove jdk.internal.reflect.UTF8 Reviewed-by: rriggs, alanb ! src/java.base/share/classes/jdk/internal/reflect/ClassFileAssembler.java - src/java.base/share/classes/jdk/internal/reflect/UTF8.java Changeset: 20c71cea Author: Lance Andersen Date: 2024-02-26 15:31:55 +0000 URL: https://git.openjdk.org/lilliput/commit/20c71ceacdcb791f5b70cda456bdc47bdd9acf6c 8321156: Improve the handling of invalid UTF-8 byte sequences for ZipInputStream::getNextEntry and ZipFile::getComment Reviewed-by: jpai, alanb ! src/java.base/share/classes/java/util/zip/ZipFile.java ! src/java.base/share/classes/java/util/zip/ZipInputStream.java ! test/jdk/java/util/zip/ZipFile/InvalidBytesInEntryNameOrComment.java Changeset: 2d3c9c5e Author: Albert Mingkun Yang Date: 2024-02-26 15:34:10 +0000 URL: https://git.openjdk.org/lilliput/commit/2d3c9c5e673cf72fd4873fb5139e7d7a3d65a097 8325553: Parallel: Use per-marker cache for marking stats during Full GC Reviewed-by: sjohanss, tschatzl ! src/hotspot/share/gc/parallel/psCompactionManager.cpp ! src/hotspot/share/gc/parallel/psCompactionManager.hpp ! src/hotspot/share/gc/parallel/psCompactionManager.inline.hpp ! src/hotspot/share/gc/parallel/psParallelCompact.cpp ! src/hotspot/share/gc/parallel/psParallelCompact.inline.hpp Changeset: 3780ad31 Author: Magnus Ihse Bursie Date: 2024-02-26 15:43:47 +0000 URL: https://git.openjdk.org/lilliput/commit/3780ad3133302a91e082dd4e8526425799e88e1f 8326587: Separate out Microsoft toolchain linking Reviewed-by: erikj ! make/Hsdis.gmk ! make/autoconf/buildjdk-spec.gmk.template ! make/autoconf/flags-ldflags.m4 ! make/autoconf/flags-other.m4 ! make/autoconf/flags.m4 ! make/autoconf/spec.gmk.template ! make/autoconf/toolchain.m4 ! make/common/NativeCompilation.gmk ! make/common/native/Link.gmk + make/common/native/LinkMicrosoft.gmk ! make/common/native/ToolchainDefinitions.gmk ! make/hotspot/gensrc/GensrcAdlc.gmk Changeset: 9a9cfbe0 Author: Claes Redestad Date: 2024-02-26 16:05:18 +0000 URL: https://git.openjdk.org/lilliput/commit/9a9cfbe0ba18084bbeae212c9e0da2715a3086e7 8325340: Add ASCII fast-path to Data-/ObjectInputStream.readUTF Reviewed-by: rgiulietti, bpb, rriggs ! src/java.base/share/classes/java/io/DataInputStream.java ! src/java.base/share/classes/java/io/ObjectInputStream.java ! test/micro/org/openjdk/bench/java/io/DataInputStreamTest.java + test/micro/org/openjdk/bench/java/io/ObjectInputStreamTest.java Changeset: f62b5789 Author: Anthony Scarpino Date: 2024-02-26 16:49:01 +0000 URL: https://git.openjdk.org/lilliput/commit/f62b5789add23adda2634a1cfb80f48b4387be74 8311644: Server should not send bad_certificate alert when the client does not send any certificates Reviewed-by: djelinski, jjiang, ssahoo ! src/java.base/share/classes/sun/security/ssl/Alert.java ! src/java.base/share/classes/sun/security/ssl/CertificateMessage.java + test/jdk/javax/net/ssl/SSLSession/CertMsgCheck.java ! test/jdk/javax/net/ssl/SSLSession/CheckSessionContext.java ! test/jdk/javax/net/ssl/templates/TLSBase.java ! test/jdk/sun/security/ssl/DHKeyExchange/LegacyDHEKeyExchange.java ! test/jdk/sun/security/ssl/SignatureScheme/SigAlgosExtTestWithTLS12.java ! test/jdk/sun/security/ssl/SignatureScheme/SigAlgosExtTestWithTLS13.java Changeset: bf13a4e2 Author: sunyaqi Committer: Brian Burkhalter Date: 2024-02-26 20:47:59 +0000 URL: https://git.openjdk.org/lilliput/commit/bf13a4e2819fa5bcb3e4f2281121d4e0b5535403 8322881: java/nio/file/Files/CopyMoveVariations.java fails with AccessDeniedException due to permissions of files in /tmp Reviewed-by: bpb ! test/jdk/java/nio/file/Files/CopyMoveVariations.java Changeset: 0963a4e9 Author: Anthony Scarpino Date: 2024-02-26 21:00:07 +0000 URL: https://git.openjdk.org/lilliput/commit/0963a4e9a11c189791a6e9238d162cd0c12b998d 8326699: Problemlist CertMsgCheck.java Reviewed-by: rhalade ! test/jdk/ProblemList.txt Changeset: b87d9cf2 Author: Weijun Wang Date: 2024-02-26 21:52:40 +0000 URL: https://git.openjdk.org/lilliput/commit/b87d9cf2c9d905c15f4c957d42361b1a72974edf 8325506: Ensure randomness is only read from provided SecureRandom object Reviewed-by: kdriver, valeriep ! src/java.base/share/classes/sun/security/util/SignatureUtil.java + test/jdk/sun/security/provider/all/Deterministic.java ! test/lib-test/jdk/test/lib/AssertsTest.java + test/lib-test/jdk/test/lib/security/SeededSecureRandomTest.java ! test/lib/jdk/test/lib/Asserts.java + test/lib/jdk/test/lib/security/SeededSecureRandom.java Changeset: fc67c2b4 Author: Alex Menkov Date: 2024-02-26 23:18:49 +0000 URL: https://git.openjdk.org/lilliput/commit/fc67c2b4f17216d4adcc0825d0f378ae4f150025 8325530: Vague error message when com.sun.tools.attach.VirtualMachine fails to load agent library Reviewed-by: sspitsyn, cjplummer ! src/hotspot/share/prims/jvmtiAgentList.cpp ! src/hotspot/share/prims/jvmtiAgentList.hpp ! src/hotspot/share/services/attachListener.cpp ! src/hotspot/share/services/diagnosticCommand.cpp ! src/jdk.attach/share/classes/sun/tools/attach/HotSpotVirtualMachine.java + test/jdk/com/sun/tools/attach/FailedLoadAgentTest.java Changeset: 93feda3d Author: Patricio Chilano Mateo Date: 2024-02-26 23:29:18 +0000 URL: https://git.openjdk.org/lilliput/commit/93feda3d9a1807422c7f47703358aabd2e8639b8 8322962: Upcall stub might go undetected when freezing frames Reviewed-by: jvernee, alanb, mdoerr, fyang, dlong ! src/hotspot/cpu/aarch64/upcallLinker_aarch64.cpp ! src/hotspot/cpu/ppc/upcallLinker_ppc.cpp ! src/hotspot/cpu/riscv/upcallLinker_riscv.cpp ! src/hotspot/cpu/x86/upcallLinker_x86_64.cpp ! src/hotspot/share/runtime/continuationFreezeThaw.cpp ! test/jdk/java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java Changeset: d22d890c Author: Justin Lu Date: 2024-02-26 23:43:52 +0000 URL: https://git.openjdk.org/lilliput/commit/d22d890cac3c2c27f89445c65a91909c9cb8f9ad 8325898: ChoiceFormat returns erroneous result when formatting bad pattern Reviewed-by: naoto ! src/java.base/share/classes/java/text/ChoiceFormat.java ! test/jdk/java/text/Format/ChoiceFormat/PatternsTest.java Changeset: 0901dede Author: Jiangli Zhou Date: 2024-02-27 01:34:19 +0000 URL: https://git.openjdk.org/lilliput/commit/0901dedefe16afa3f7222723b3fec7a22d9df675 8326433: Make file-local functions static in src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c Reviewed-by: cjplummer, sspitsyn ! src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c Changeset: ec9437db Author: Daniel Jeli?ski Date: 2024-02-27 07:06:35 +0000 URL: https://git.openjdk.org/lilliput/commit/ec9437dbcc242b62e3b099dd05b129760419f025 8325247: Memory leak in SessionKeyRef class def when using PKCS11 security provider Reviewed-by: valeriep ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java Changeset: 97aca09e Author: Dan Lutker Committer: Aleksey Shipilev Date: 2024-02-27 07:34:10 +0000 URL: https://git.openjdk.org/lilliput/commit/97aca09e586c086f8130b394682f45724f08b3a4 8326717: Disable stringop-overflow in shenandoahLock.cpp Reviewed-by: erikj, shade ! make/hotspot/lib/CompileJvm.gmk Changeset: 5daf63b7 Author: SendaoYan Committer: Tobias Hartmann Date: 2024-02-27 08:14:38 +0000 URL: https://git.openjdk.org/lilliput/commit/5daf63b7177b8c30b6375bdb394186c03a624ea3 8326636: Problem list StartupOutput.java due to 8326615 Reviewed-by: kvn, thartmann ! test/hotspot/jtreg/ProblemList.txt Changeset: a48f5966 Author: Hamlin Li Date: 2024-02-27 08:17:33 +0000 URL: https://git.openjdk.org/lilliput/commit/a48f5966be17dea1c69e1c66719e43828768dbc1 8322179: RISC-V: Implement SHA-1 intrinsic Reviewed-by: tonyp, fyang ! src/hotspot/cpu/riscv/stubGenerator_riscv.cpp ! src/hotspot/cpu/riscv/stubRoutines_riscv.hpp ! src/hotspot/cpu/riscv/vm_version_riscv.cpp ! test/hotspot/jtreg/compiler/testlibrary/sha/predicate/IntrinsicPredicates.java Changeset: 4d82ea10 Author: Denghui Dong Date: 2024-02-27 08:28:49 +0000 URL: https://git.openjdk.org/lilliput/commit/4d82ea102a347b12f33104917ae790156ed524a1 8325144: C1: Optimize CriticalEdgeFinder Reviewed-by: dlong, chagedorn ! src/hotspot/share/c1/c1_IR.cpp ! src/hotspot/share/c1/c1_Instruction.cpp ! src/hotspot/share/c1/c1_Instruction.hpp Changeset: c5f1dccc Author: Lei Zaakjyu Committer: Thomas Schatzl Date: 2024-02-27 08:58:52 +0000 URL: https://git.openjdk.org/lilliput/commit/c5f1dcccfce7b943c1a91aa65709576038098e91 8325082: Rename headers named 'heapRegion*' of G1 Reviewed-by: stefank, tschatzl ! src/hotspot/cpu/aarch64/gc/g1/g1BarrierSetAssembler_aarch64.cpp ! src/hotspot/cpu/arm/gc/g1/g1BarrierSetAssembler_arm.cpp ! src/hotspot/cpu/ppc/gc/g1/g1BarrierSetAssembler_ppc.cpp ! src/hotspot/cpu/riscv/gc/g1/g1BarrierSetAssembler_riscv.cpp ! src/hotspot/cpu/s390/gc/g1/g1BarrierSetAssembler_s390.cpp ! src/hotspot/cpu/x86/gc/g1/g1BarrierSetAssembler_x86.cpp ! src/hotspot/share/cds/archiveHeapWriter.cpp ! src/hotspot/share/cds/filemap.cpp ! src/hotspot/share/gc/g1/c1/g1BarrierSetC1.cpp ! src/hotspot/share/gc/g1/c2/g1BarrierSetC2.cpp ! src/hotspot/share/gc/g1/g1AllocRegion.hpp ! src/hotspot/share/gc/g1/g1AllocRegion.inline.hpp ! src/hotspot/share/gc/g1/g1Allocator.cpp ! src/hotspot/share/gc/g1/g1Arguments.cpp ! src/hotspot/share/gc/g1/g1BarrierSet.cpp ! src/hotspot/share/gc/g1/g1BlockOffsetTable.cpp ! src/hotspot/share/gc/g1/g1BlockOffsetTable.inline.hpp ! src/hotspot/share/gc/g1/g1CardSet.cpp ! src/hotspot/share/gc/g1/g1CardTable.inline.hpp ! src/hotspot/share/gc/g1/g1CodeBlobClosure.cpp ! src/hotspot/share/gc/g1/g1CodeRootSet.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp ! src/hotspot/share/gc/g1/g1CollectedHeap.inline.hpp ! src/hotspot/share/gc/g1/g1CollectionSet.cpp ! src/hotspot/share/gc/g1/g1CollectionSetCandidates.cpp ! src/hotspot/share/gc/g1/g1CollectionSetChooser.cpp ! src/hotspot/share/gc/g1/g1CollectionSetChooser.hpp ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp ! src/hotspot/share/gc/g1/g1ConcurrentMark.hpp ! src/hotspot/share/gc/g1/g1ConcurrentMark.inline.hpp ! src/hotspot/share/gc/g1/g1ConcurrentMarkBitMap.cpp ! src/hotspot/share/gc/g1/g1ConcurrentMarkObjArrayProcessor.cpp ! src/hotspot/share/gc/g1/g1ConcurrentRebuildAndScrub.cpp ! src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp ! src/hotspot/share/gc/g1/g1ConcurrentRefineThreadsNeeded.cpp ! src/hotspot/share/gc/g1/g1DirtyCardQueue.cpp ! src/hotspot/share/gc/g1/g1EdenRegions.hpp ! src/hotspot/share/gc/g1/g1EvacFailureRegions.cpp ! src/hotspot/share/gc/g1/g1FullCollector.inline.hpp ! src/hotspot/share/gc/g1/g1FullGCAdjustTask.cpp ! src/hotspot/share/gc/g1/g1FullGCAdjustTask.hpp ! src/hotspot/share/gc/g1/g1FullGCCompactTask.cpp ! src/hotspot/share/gc/g1/g1FullGCCompactTask.hpp ! src/hotspot/share/gc/g1/g1FullGCCompactionPoint.cpp ! src/hotspot/share/gc/g1/g1FullGCMarkTask.hpp ! src/hotspot/share/gc/g1/g1FullGCOopClosures.inline.hpp ! src/hotspot/share/gc/g1/g1FullGCPrepareTask.cpp ! src/hotspot/share/gc/g1/g1FullGCPrepareTask.hpp ! src/hotspot/share/gc/g1/g1FullGCPrepareTask.inline.hpp ! src/hotspot/share/gc/g1/g1FullGCResetMetadataTask.hpp ! src/hotspot/share/gc/g1/g1HRPrinter.cpp ! src/hotspot/share/gc/g1/g1HRPrinter.hpp = src/hotspot/share/gc/g1/g1HeapRegion.cpp = src/hotspot/share/gc/g1/g1HeapRegion.hpp = src/hotspot/share/gc/g1/g1HeapRegion.inline.hpp ! src/hotspot/share/gc/g1/g1HeapRegionAttr.hpp = src/hotspot/share/gc/g1/g1HeapRegionBounds.hpp + src/hotspot/share/gc/g1/g1HeapRegionBounds.inline.hpp ! src/hotspot/share/gc/g1/g1HeapRegionEventSender.cpp = src/hotspot/share/gc/g1/g1HeapRegionManager.cpp = src/hotspot/share/gc/g1/g1HeapRegionManager.hpp = src/hotspot/share/gc/g1/g1HeapRegionManager.inline.hpp = src/hotspot/share/gc/g1/g1HeapRegionRemSet.cpp = src/hotspot/share/gc/g1/g1HeapRegionRemSet.hpp = src/hotspot/share/gc/g1/g1HeapRegionRemSet.inline.hpp = src/hotspot/share/gc/g1/g1HeapRegionSet.cpp = src/hotspot/share/gc/g1/g1HeapRegionSet.hpp = src/hotspot/share/gc/g1/g1HeapRegionSet.inline.hpp = src/hotspot/share/gc/g1/g1HeapRegionTracer.cpp = src/hotspot/share/gc/g1/g1HeapRegionTracer.hpp = src/hotspot/share/gc/g1/g1HeapRegionType.cpp = src/hotspot/share/gc/g1/g1HeapRegionType.hpp ! src/hotspot/share/gc/g1/g1HeapVerifier.cpp ! src/hotspot/share/gc/g1/g1HeapVerifier.hpp ! src/hotspot/share/gc/g1/g1MemoryPool.cpp ! src/hotspot/share/gc/g1/g1MonotonicArenaFreeMemoryTask.cpp ! src/hotspot/share/gc/g1/g1MonotonicArenaFreeMemoryTask.hpp ! src/hotspot/share/gc/g1/g1NUMA.hpp ! src/hotspot/share/gc/g1/g1OldGenAllocationTracker.hpp ! src/hotspot/share/gc/g1/g1OopClosures.inline.hpp ! src/hotspot/share/gc/g1/g1Policy.cpp ! src/hotspot/share/gc/g1/g1RegionPinCache.hpp ! src/hotspot/share/gc/g1/g1RegionsOnNodes.cpp ! src/hotspot/share/gc/g1/g1RemSet.cpp ! src/hotspot/share/gc/g1/g1RemSet.hpp ! src/hotspot/share/gc/g1/g1RemSetSummary.cpp ! src/hotspot/share/gc/g1/g1RemSetTrackingPolicy.cpp ! src/hotspot/share/gc/g1/g1RemSetTrackingPolicy.hpp ! src/hotspot/share/gc/g1/g1RootProcessor.cpp ! src/hotspot/share/gc/g1/g1SATBMarkQueueSet.cpp ! src/hotspot/share/gc/g1/g1SurvRateGroup.cpp ! src/hotspot/share/gc/g1/g1SurvivorRegions.cpp ! src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp ! src/hotspot/share/gc/g1/g1YoungGenSizer.cpp - src/hotspot/share/gc/g1/heapRegionBounds.inline.hpp ! src/hotspot/share/gc/g1/jvmFlagConstraintsG1.cpp ! src/hotspot/share/gc/g1/vmStructs_g1.hpp ! src/hotspot/share/jvmci/vmStructs_jvmci.cpp ! src/hotspot/share/opto/runtime.cpp ! src/hotspot/share/prims/whitebox.cpp ! test/hotspot/gtest/gc/g1/test_freeRegionList.cpp ! test/hotspot/gtest/gc/g1/test_g1CardSet.cpp ! test/hotspot/gtest/gc/g1/test_g1CardSetContainers.cpp ! test/hotspot/gtest/gc/g1/test_heapRegion.cpp Changeset: 7583419d Author: Afshin Zafari Date: 2024-02-27 08:59:10 +0000 URL: https://git.openjdk.org/lilliput/commit/7583419d88d7a61007951d5abdff4ac8e620c7d8 8324828: Avoid multiple search of reserved regions during splitting Reviewed-by: stuefe, jsjolen ! src/hotspot/share/cds/metaspaceShared.cpp ! src/hotspot/share/nmt/memTracker.hpp ! src/hotspot/share/nmt/virtualMemoryTracker.cpp ! src/hotspot/share/nmt/virtualMemoryTracker.hpp Changeset: 5d3d40d9 Author: Albert Mingkun Yang Date: 2024-02-27 09:12:20 +0000 URL: https://git.openjdk.org/lilliput/commit/5d3d40d962ece0395d1da233e1f8db3de826cb93 8326659: Serial: Remove redundant TenuredSpace::print_on Reviewed-by: tschatzl ! src/hotspot/share/gc/shared/space.cpp ! src/hotspot/share/gc/shared/space.hpp Changeset: e85355ad Author: Suchismith Roy Committer: Martin Doerr Date: 2024-02-27 09:15:40 +0000 URL: https://git.openjdk.org/lilliput/commit/e85355ada4ac1061c49ee9f1247d37a437c7b5ab 8320005: Allow loading of shared objects with .a extension on AIX Reviewed-by: amitkumar, stuefe, jkern, mdoerr ! src/hotspot/os/aix/os_aix.cpp Changeset: d482c1af Author: Kim Barrett Date: 2024-02-27 10:26:42 +0000 URL: https://git.openjdk.org/lilliput/commit/d482c1af28cacd60cc05fe3f975a00a0c68c72b7 8326524: Rename agent_common.h Reviewed-by: coleenp, sspitsyn, jwaters, dlong, lmesnik ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AddCapabilities/addcaps001/addcaps001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AddCapabilities/addcaps002/addcaps002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AddCapabilities/addcaps003/addcaps003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/Agent_OnLoad/agentonload001/agentonload001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/Agent_OnLoad/agentonload002/agentonload002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/Agent_OnLoad/agentonload003/agentonload003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/Agent_OnUnload/agentonunload001/agentonunload001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/Allocate/alloc001/alloc001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClassFileLoadHook/classfloadhk001/classfloadhk001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClassFileLoadHook/classfloadhk002/classfloadhk002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClassFileLoadHook/classfloadhk003/classfloadhk003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClassFileLoadHook/classfloadhk004/classfloadhk004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClassFileLoadHook/classfloadhk005/classfloadhk005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClassFileLoadHook/classfloadhk006/classfloadhk006.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClassFileLoadHook/classfloadhk007/classfloadhk007.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClassFileLoadHook/classfloadhk008/classfloadhk008.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClassFileLoadHook/classfloadhk009/classfloadhk009.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClearBreakpoint/clrbrk001/clrbrk001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClearBreakpoint/clrbrk002/clrbrk002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClearBreakpoint/clrbrk005/clrbrk005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClearFieldAccessWatch/clrfldw001/clrfldw001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClearFieldAccessWatch/clrfldw002/clrfldw002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClearFieldModificationWatch/clrfmodw001/clrfmodw001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClearFieldModificationWatch/clrfmodw002/clrfmodw002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/CompiledMethodLoad/compmethload001/compmethload001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001/compmethunload001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/CreateRawMonitor/crrawmon001/crrawmon001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/CreateRawMonitor/crrawmon002/crrawmon002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/DataDumpRequest/datadumpreq001/datadumpreq001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/Deallocate/dealloc001/dealloc001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/DestroyRawMonitor/drrawmon001/drrawmon001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/DestroyRawMonitor/drrawmon003/drrawmon003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/DestroyRawMonitor/drrawmon004/drrawmon004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/DisposeEnvironment/disposeenv001/disposeenv001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/DisposeEnvironment/disposeenv002/disposeenv002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/DynamicCodeGenerated/dyncodgen001/dyncodgen001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ForceEarlyReturn/ForceEarlyReturn001/ForceEarlyReturn001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ForceGarbageCollection/forcegc001/forcegc001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ForceGarbageCollection/forcegc002/forcegc002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GarbageCollectionFinish/gcfinish001/gcfinish001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GarbageCollectionStart/gcstart001/gcstart001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GarbageCollectionStart/gcstart002/gcstart002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GenerateEvents/genevents001/genevents001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetArgumentsSize/argsize001/argsize001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetArgumentsSize/argsize002/argsize002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetAvailableProcessors/getavailproc001/getavailproc001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetBytecodes/bytecodes001/bytecodes001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetBytecodes/bytecodes002/bytecodes002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetBytecodes/bytecodes003/bytecodes003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetCapabilities/getcaps001/getcaps001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetCapabilities/getcaps002/getcaps002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassFields/getclfld005/getclfld005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassFields/getclfld006/getclfld006.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassFields/getclfld007/getclfld007.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassLoader/getclsldr001/getclsldr001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassLoader/getclsldr002/getclsldr002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassLoader/getclsldr003/getclsldr003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassLoaderClasses/clsldrclss001/clsldrclss001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassLoaderClasses/clsldrclss002/clsldrclss002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassMethods/getclmthd005/getclmthd005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassMethods/getclmthd006/getclmthd006.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassMethods/getclmthd007/getclmthd007.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassModifiers/getclmdf004/getclmdf004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassModifiers/getclmdf005/getclmdf005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassModifiers/getclmdf006/getclmdf006.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassModifiers/getclmdf007/getclmdf007.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassSignature/getclsig004/getclsig004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassSignature/getclsig005/getclsig005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassSignature/getclsig006/getclsig006.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassStatus/getclstat005/getclstat005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassStatus/getclstat006/getclstat006.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassStatus/getclstat007/getclstat007.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetCurrentThreadCpuTime/curthrcputime001/curthrcputime001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetCurrentThreadCpuTimerInfo/curthrtimerinfo001/curthrtimerinfo001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetEnv/GetEnv001/GetEnv001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetEnvironmentLocalStorage/getenvstor001/getenvstor001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetErrorName/geterrname001/geterrname001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetErrorName/geterrname002/geterrname002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetExtensionEvents/extevents001/extevents001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetExtensionFunctions/extfuncs001/extfuncs001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetFieldDeclaringClass/getfldecl001/getfldecl001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetFieldDeclaringClass/getfldecl002/getfldecl002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetFieldDeclaringClass/getfldecl004/getfldecl004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetFieldModifiers/getfldmdf003/getfldmdf003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetFieldModifiers/getfldmdf004/getfldmdf004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetFieldName/getfldnm003/getfldnm003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetFieldName/getfldnm004/getfldnm004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetFieldName/getfldnm005/getfldnm005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetImplementedInterfaces/getintrf005/getintrf005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetImplementedInterfaces/getintrf006/getintrf006.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetImplementedInterfaces/getintrf007/getintrf007.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetJLocationFormat/getjlocfmt001/getjlocfmt001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetJLocationFormat/getjlocfmt002/getjlocfmt002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetJNIFunctionTable/getjniftab001/getjniftab001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetJNIFunctionTable/getjniftab002/getjniftab002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetLineNumberTable/linetab001/linetab001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetLineNumberTable/linetab002/linetab002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetLineNumberTable/linetab003/linetab003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetLoadedClasses/loadedclss001/loadedclss001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetLoadedClasses/loadedclss002/loadedclss002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetLocalVariable/getlocal001/getlocal001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetLocalVariable/getlocal002/getlocal002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetLocalVariableTable/localtab001/localtab001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetLocalVariableTable/localtab002/localtab002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetLocalVariableTable/localtab003/localtab003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetLocalVariableTable/localtab004/localtab004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetLocalVariableTable/localtab005/localtab005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetMaxLocals/maxloc001/maxloc001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetMaxLocals/maxloc002/maxloc002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetMethodDeclaringClass/declcls001/declcls001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetMethodDeclaringClass/declcls002/declcls002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetMethodDeclaringClass/declcls003/declcls003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetMethodLocation/methloc001/methloc001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetMethodLocation/methloc002/methloc002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetMethodModifiers/methmod001/methmod001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetMethodModifiers/methmod002/methmod002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetMethodName/methname001/methname001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetMethodName/methname002/methname002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetMethodName/methname003/methname003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectHashCode/objhashcode001/objhashcode001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage001/objmonusage001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage002/objmonusage002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage003/objmonusage003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage004/objmonusage004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage005/objmonusage005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage006/objmonusage006.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectSize/objsize001/objsize001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectsWithTags/objwithtags001/objwithtags001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetOwnedMonitorInfo/ownmoninf001/ownmoninf001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetOwnedMonitorInfo/ownmoninf002/ownmoninf002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetOwnedMonitorInfo/ownmoninf003/ownmoninf003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetPhase/getphase001/getphase001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetPhase/getphase002/getphase002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetPotentialCapabilities/getpotcaps001/getpotcaps001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetSourceDebugExtension/srcdebugex001/srcdebugex001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetSourceDebugExtension/srcdebugex002/srcdebugex002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetSourceDebugExtension/srcdebugex003/srcdebugex003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetSourceFileName/getsrcfn004/getsrcfn004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetSourceFileName/getsrcfn005/getsrcfn005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetSourceFileName/getsrcfn006/getsrcfn006.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetSystemProperties/getsysprops001/getsysprops001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetSystemProperties/getsysprops002/getsysprops002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetSystemProperty/getsysprop001/getsysprop001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetSystemProperty/getsysprop002/getsysprop002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetTag/gettag001/gettag001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetThreadCpuTime/thrcputime001/thrcputime001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetThreadCpuTime/thrcputime002/thrcputime002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetThreadCpuTimerInfo/thrtimerinfo001/thrtimerinfo001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetThreadGroupChildren/getthrdgrpchld001/getthrdgrpchld001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetThreadGroupInfo/thrgrpinfo001/thrgrpinfo001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetThreadGroupInfo/thrgrpinfo002/thrgrpinfo002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetThreadLocalStorage/getthrdstor001/getthrdstor001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetTime/gettime001/gettime001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetTimerInfo/timerinfo001/timerinfo001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetTopThreadGroups/topthrgrp001/topthrgrp001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetTopThreadGroups/topthrgrp002/topthrgrp002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetVersionNumber/getvern001/getvern001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/InterruptThread/intrpthrd001/intrpthrd001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/InterruptThread/intrpthrd002/intrpthrd002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/InterruptThread/intrpthrd003/intrpthrd003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IsArrayClass/isarray004/isarray004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IsArrayClass/isarray005/isarray005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IsFieldSynthetic/isfldsin002/isfldsin002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IsFieldSynthetic/isfldsin003/isfldsin003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IsInterface/isintrf004/isintrf004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IsInterface/isintrf005/isintrf005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IsMethodNative/isnative001/isnative001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IsMethodNative/isnative002/isnative002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IsMethodObsolete/isobsolete001/isobsolete001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IsMethodSynthetic/issynth001/issynth001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IsMethodSynthetic/issynth002/issynth002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverHeap/iterheap001/iterheap001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverHeap/iterheap002/iterheap002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverHeap/iterheap003/iterheap003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverHeap/iterheap004/iterheap004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverHeap/iterheap005/iterheap005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverHeap/iterheap006/iterheap006.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverHeap/iterheap007/iterheap007.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverInstancesOfClass/iterinstcls001/iterinstcls001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverInstancesOfClass/iterinstcls002/iterinstcls002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverInstancesOfClass/iterinstcls003/iterinstcls003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverInstancesOfClass/iterinstcls004/iterinstcls004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverInstancesOfClass/iterinstcls005/iterinstcls005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverInstancesOfClass/iterinstcls006/iterinstcls006.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverInstancesOfClass/iterinstcls007/iterinstcls007.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverObjectsReachableFromObject/iterobjreachobj001/iterobjreachobj001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverObjectsReachableFromObject/iterobjreachobj002/iterobjreachobj002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverObjectsReachableFromObject/iterobjreachobj003/iterobjreachobj003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverObjectsReachableFromObject/iterobjreachobj004/iterobjreachobj004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverObjectsReachableFromObject/iterobjreachobj005/iterobjreachobj005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverReachableObjects/iterreachobj001/iterreachobj001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverReachableObjects/iterreachobj002/iterreachobj002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverReachableObjects/iterreachobj003/iterreachobj003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverReachableObjects/iterreachobj004/iterreachobj004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverReachableObjects/iterreachobj005/iterreachobj005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateThroughHeap/abort/Abort.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateThroughHeap/callbacks/Callbacks.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateThroughHeap/concrete-klass-filter/ConcreteKlassFilter.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateThroughHeap/filter-tagged/HeapFilter.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateThroughHeap/non-concrete-klass-filter/NonConcreteKlassFilter.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/NotifyFramePop/nframepop001/nframepop001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/NotifyFramePop/nframepop002/nframepop002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/NotifyFramePop/nframepop003/nframepop003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ObjectFree/objfree001/objfree001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ObjectFree/objfree002/objfree002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/PopFrame/popframe001/popframe001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/PopFrame/popframe002/popframe002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/PopFrame/popframe003/popframe003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/PopFrame/popframe004/popframe004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/PopFrame/popframe005/popframe005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/PopFrame/popframe006/popframe006.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/PopFrame/popframe007/popframe007.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/PopFrame/popframe008/popframe008.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/PopFrame/popframe009/popframe009.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/PopFrame/popframe010/popframe010.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/PopFrame/popframe011/popframe011.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorEnter/rawmonenter001/rawmonenter001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorEnter/rawmonenter002/rawmonenter002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorEnter/rawmonenter003/rawmonenter003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorEnter/rawmonenter004/rawmonenter004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorExit/rawmonexit001/rawmonexit001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorExit/rawmonexit002/rawmonexit002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorExit/rawmonexit003/rawmonexit003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorExit/rawmonexit005/rawmonexit005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorNotify/rawmnntfy001/rawmnntfy001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorNotify/rawmnntfy002/rawmnntfy002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorNotify/rawmnntfy003/rawmnntfy003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorNotify/rawmnntfy004/rawmnntfy004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorNotifyAll/rawmnntfyall001/rawmnntfyall001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorNotifyAll/rawmnntfyall002/rawmnntfyall002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorNotifyAll/rawmnntfyall003/rawmnntfyall003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorNotifyAll/rawmnntfyall004/rawmnntfyall004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorWait/rawmnwait001/rawmnwait001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorWait/rawmnwait002/rawmnwait002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorWait/rawmnwait003/rawmnwait003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorWait/rawmnwait004/rawmnwait004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorWait/rawmnwait005/rawmnwait005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine/stressRedefine.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass001/redefclass001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass002/redefclass002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass003/redefclass003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass004/redefclass004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass005/redefclass005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass006/redefclass006.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass008/redefclass008.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass009/redefclass009.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass010/redefclass010.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass011/redefclass011.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass012/redefclass012.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass013/redefclass013.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass014/redefclass014.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass015/redefclass015.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass016/redefclass016.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass017/redefclass017.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass018/redefclass018.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass019/redefclass019.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass020/redefclass020.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass021/redefclass021.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass022/redefclass022.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass023/redefclass023.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass024/redefclass024.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass025/redefclass025.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass026/redefclass026.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass027/redefclass027.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass028/redefclass028.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass029/redefclass029.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass030/redefclass030.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass031/redefclass031.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RelinquishCapabilities/relcaps001/relcaps001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RelinquishCapabilities/relcaps002/relcaps002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ResourceExhausted/resexhausted.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ResumeThread/resumethrd001/resumethrd001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ResumeThread/resumethrd002/resumethrd002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ResumeThreadList/resumethrdlst001/resumethrdlst001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ResumeThreadList/resumethrdlst002/resumethrdlst002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RetransformClasses/retransform002/retransform002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RetransformClasses/retransform003/retransform003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RetransformClasses/retransform004/retransform004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RunAgentThread/agentthr001/agentthr001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RunAgentThread/agentthr002/agentthr002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RunAgentThread/agentthr003/agentthr003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetBreakpoint/setbrk002/setbrk002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetBreakpoint/setbrk003/setbrk003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetBreakpoint/setbrk005/setbrk005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetBreakpoint/setbrk007/setbrk007.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetBreakpoint/setbrk008/setbrk008.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetEnvironmentLocalStorage/setenvstor001/setenvstor001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetEnvironmentLocalStorage/setenvstor002/setenvstor002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetEnvironmentLocalStorage/setenvstor003/setenvstor003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetEventCallbacks/setevntcallb001/setevntcallb001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetEventCallbacks/setevntcallb002/setevntcallb002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetEventCallbacks/setevntcallb003/setevntcallb003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetEventNotificationMode/setnotif001/setnotif001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetExtensionEventCallback/setextevent001/setextevent001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetFieldAccessWatch/setfldw001/setfldw001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetFieldAccessWatch/setfldw002/setfldw002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetFieldAccessWatch/setfldw003/setfldw003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetFieldAccessWatch/setfldw004/setfldw004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetFieldAccessWatch/setfldw005/setfldw005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetFieldAccessWatch/setfldw006/setfldw006.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetFieldModificationWatch/setfmodw001/setfmodw001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetFieldModificationWatch/setfmodw002/setfmodw002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetFieldModificationWatch/setfmodw003/setfmodw003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetFieldModificationWatch/setfmodw004/setfmodw004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetFieldModificationWatch/setfmodw005/setfmodw005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetFieldModificationWatch/setfmodw006/setfmodw006.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetJNIFunctionTable/setjniftab001/setjniftab001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetJNIFunctionTable/setjniftab002/setjniftab002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetLocalVariable/setlocal001/setlocal001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetLocalVariable/setlocal002/setlocal002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetLocalVariable/setlocal003/setlocal003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetLocalVariable/setlocal004/setlocal004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetNativeMethodPrefix/SetNativeMethodPrefix001/SetNativeMethodPrefix001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetNativeMethodPrefix/SetNativeMethodPrefix002/SetNativeMethodPrefix002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetSystemProperty/setsysprop002/setsysprop002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetSystemProperty/setsysprop003/setsysprop003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetTag/settag001/settag001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetThreadLocalStorage/setthrdstor001/setthrdstor001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetThreadLocalStorage/setthrdstor002/setthrdstor002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetThreadLocalStorage/setthrdstor003/setthrdstor003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetVerboseFlag/setvrbflag001/setvrbflag001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetVerboseFlag/setvrbflag002/setvrbflag002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/StopThread/stopthrd006/stopthrd006.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/StopThread/stopthrd007/stopthrd007.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SuspendThread/suspendthrd001/suspendthrd001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SuspendThread/suspendthrd002/suspendthrd002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SuspendThread/suspendthrd003/suspendthrd003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SuspendThreadList/suspendthrdlst001/suspendthrdlst001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SuspendThreadList/suspendthrdlst002/suspendthrdlst002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/VMDeath/vmdeath001/vmdeath001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/VMInit/vminit001/vminit001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP01/ap01t001/ap01t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP02/ap02t001/ap02t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP03/ap03t001/ap03t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP04/ap04t001/ap04t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP04/ap04t002/ap04t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP04/ap04t003/ap04t003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP05/ap05t001/ap05t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP05/ap05t002/ap05t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP06/ap06t001/ap06t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP07/ap07t001/ap07t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP07/ap07t002/ap07t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP09/ap09t001/ap09t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP10/ap10t001/ap10t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP11/ap11t001/ap11t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP12/ap12t001/ap12t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI01/bi01t001/bi01t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI01/bi01t002/bi01t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI02/bi02t001/bi02t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI02/bi02t002/bi02t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI03/bi03t001/bi03t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI03/bi03t002/bi03t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI04/bi04t002/bi04t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t001/cm01t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t002/cm01t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t003/cm01t003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t004/cm01t004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t005/cm01t005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t006/cm01t006.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t007/cm01t007.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t008/cm01t008.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t009/cm01t009.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t010/cm01t010.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t011/cm01t011.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t012/cm01t012.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t013/cm01t013.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t014/cm01t014.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t015/cm01t015.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t016/cm01t016.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t017/cm01t017.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t018/cm01t018.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t019/cm01t019.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t020/cm01t020.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t021/cm01t021.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM02/cm02t001/cm02t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM03/cm03t001/cm03t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC01/tc01t001/tc01t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC02/tc02t001/tc02t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC03/tc03t001/tc03t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC03/tc03t002/tc03t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC04/tc04t001/tc04t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC05/tc05t001/tc05t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM01/em01t001/em01t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM01/em01t002/em01t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t001/em02t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t002/em02t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t003/em02t003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t004/em02t004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t005/em02t005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t006/em02t006.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t007/em02t007.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t008/em02t008.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t009/em02t009.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t010/em02t010.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t011/em02t011.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t012/em02t012.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM04/em04t001/em04t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM05/em05t001/em05t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM05/em05t002/em05t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM06/em06t001/em06t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM07/em07t001/em07t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM07/em07t002/em07t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/extension/EX03/ex03t001/ex03t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/general_functions/GF01/gf01t001/gf01t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/general_functions/GF04/gf04t001/gf04t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/general_functions/GF06/gf06t001/gf06t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/general_functions/GF08/gf08t001/gf08t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/general_functions/GF08/gf08t002/gf08t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/general_functions/GF08/gf08t003/gf08t003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS103/hs103t002/hs103t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS104/hs104t001/hs104t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS104/hs104t002/hs104t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS201/hs201t001/hs201t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS201/hs201t002/hs201t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS201/hs201t003/hs201t003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS202/hs202t001/hs202t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS202/hs202t002/hs202t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS203/hs203t001/hs203t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS203/hs203t002/hs203t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS203/hs203t003/hs203t003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS203/hs203t004/hs203t004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS204/hs204t002/hs204t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS204/hs204t003/hs204t003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS204/hs204t004/hs204t004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS301/hs301t001/hs301t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS301/hs301t002/hs301t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS301/hs301t003/hs301t003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS301/hs301t004/hs301t004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS301/hs301t005/hs301t005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS302/hs302t001/hs302t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS302/hs302t002/hs302t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS302/hs302t003/hs302t003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS302/hs302t004/hs302t004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS302/hs302t005/hs302t005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS302/hs302t006/hs302t006.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS302/hs302t007/hs302t007.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS302/hs302t008/hs302t008.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS302/hs302t009/hs302t009.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS302/hs302t010/hs302t010.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS302/hs302t011/hs302t011.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS302/hs302t012/hs302t012.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/jni_interception/JI01/ji01t001/ji01t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/jni_interception/JI03/ji03t001/ji03t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/jni_interception/JI03/ji03t002/ji03t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/jni_interception/JI03/ji03t003/ji03t003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/jni_interception/JI03/ji03t004/ji03t004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/jni_interception/JI05/ji05t001/ji05t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/jni_interception/JI06/ji06t001/ji06t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA01/ma01t001/ma01t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA01/ma01t001/ma01t001a.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA02/ma02t001/ma02t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA02/ma02t001/ma02t001a.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA03/ma03t001/ma03t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA03/ma03t001/ma03t001a.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA04/ma04t001/ma04t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA04/ma04t001/ma04t001a.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA04/ma04t002/ma04t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA04/ma04t002/ma04t002a.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA04/ma04t003/ma04t003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA04/ma04t003/ma04t003a.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA05/ma05t001/ma05t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA05/ma05t001/ma05t001a.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA06/ma06t001/ma06t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA06/ma06t001/ma06t001a.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA07/ma07t001/ma07t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA07/ma07t001/ma07t001a.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA08/ma08t001/ma08t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA08/ma08t001/ma08t001a.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t001/ma10t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t001/ma10t001a.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t002/ma10t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t002/ma10t002a.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t003/ma10t003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t003/ma10t003a.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t004/ma10t004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t004/ma10t004a.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t005/ma10t005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t005/ma10t005a.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t006/ma10t006.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t006/ma10t006a.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t007/ma10t007.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t007/ma10t007a.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t008/ma10t008.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t008/ma10t008a.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP01/sp01t001/sp01t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP01/sp01t002/sp01t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP01/sp01t003/sp01t003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP02/sp02t001/sp02t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP02/sp02t002/sp02t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP02/sp02t003/sp02t003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP03/sp03t001/sp03t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP03/sp03t002/sp03t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP04/sp04t001/sp04t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP04/sp04t002/sp04t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP05/sp05t002/sp05t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP05/sp05t003/sp05t003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP06/sp06t001/sp06t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP06/sp06t002/sp06t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP06/sp06t003/sp06t003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP07/sp07t001/sp07t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP07/sp07t002/sp07t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref001/followref001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref002/followref002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref003/followref003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref004/followref004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref005/followref005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref006/followref006.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretbase/earlyretbase.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretfp/earlyretfp.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretint/earlyretint.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretlong/earlyretlong.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretobj/earlyretobj.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretstr/earlyretstr.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretvoid/earlyretvoid.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/GetAllStackTraces/getallstktr001/getallstktr001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/GetConstantPool/getcpool001/getcpool001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/GetLineNumberTable/linetab004/linetab004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/GetLocalVariable/getlocal003/getlocal003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/GetLocalVariable/getlocal004/getlocal004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/IsSynthetic/issynth001/issynth001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/MethodBind/JvmtiTest/JvmtiTest.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/OnUnload/JvmtiTest/JvmtiTest.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/StackTrace/JvmtiTest/JvmtiTest.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/agentthr/agentthr.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/clsldrclss00x/clsldrclss00x.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/events/redefineCFLH/JvmtiTest/JvmtiTest.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/extmech/extmech.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/functions/AddToBootstrapClassLoaderSearch/JvmtiTest/JvmtiTest.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/functions/Dispose/JvmtiTest/JvmtiTest.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/functions/ForceGarbageCollection/gc/gc.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/functions/environment/JvmtiTest/JvmtiTest.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/functions/nosuspendMonitorInfo/JvmtiTest/JvmtiTest.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/functions/nosuspendStackTrace/JvmtiTest/JvmtiTest.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/functions/rawmonitor/rawmonitor.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/heapref/heapref.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/refignore/refignore.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/setNullVMInit/JvmtiTest/JvmtiTest.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/timers/JvmtiTest/JvmtiTest.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/AddToBootstrapClassLoaderSearch/bootclssearch_agent.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/AddToSystemClassLoaderSearch/systemclssearch_agent.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/agent_common/agent_common.cpp = test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/agent_common/agent_common.hpp ! test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/hotswap/HotSwap.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/unit/Heap.cpp ! test/hotspot/jtreg/vmTestbase/vm/mlvm/indy/func/jvmti/share/IndyRedefineClass.cpp ! test/hotspot/jtreg/vmTestbase/vm/mlvm/indy/func/jvmti/stepBreakPopReturn/stepBreakPopReturn.cpp ! test/hotspot/jtreg/vmTestbase/vm/mlvm/share/mlvmJvmtiUtils.cpp Changeset: da14aa46 Author: Magnus Ihse Bursie Date: 2024-02-27 10:26:55 +0000 URL: https://git.openjdk.org/lilliput/commit/da14aa463b8fcd56ba1f1a4cdb3e3f7b19f78964 8017234: Hotspot should stop using mapfiles Reviewed-by: djelinski, erikj, dholmes - make/data/hotspot-symbols/symbols-aix - make/data/hotspot-symbols/symbols-aix-debug - make/data/hotspot-symbols/symbols-linux - make/data/hotspot-symbols/symbols-macosx - make/data/hotspot-symbols/symbols-shared - make/data/hotspot-symbols/symbols-unix + make/data/hotspot-symbols/version-script.txt ! make/hotspot/lib/CompileGtest.gmk ! make/hotspot/lib/CompileJvm.gmk - make/hotspot/lib/JvmMapfile.gmk ! src/hotspot/cpu/aarch64/assembler_aarch64.cpp ! src/hotspot/os_cpu/bsd_aarch64/copy_bsd_aarch64.S ! src/hotspot/os_cpu/bsd_aarch64/safefetch_bsd_aarch64.S ! src/hotspot/os_cpu/bsd_x86/bsd_x86_32.S ! src/hotspot/os_cpu/bsd_x86/bsd_x86_64.S ! src/hotspot/os_cpu/bsd_x86/safefetch_bsd_x86_64.S ! src/hotspot/os_cpu/linux_aarch64/atomic_linux_aarch64.S ! src/hotspot/os_cpu/linux_aarch64/copy_linux_aarch64.S ! src/hotspot/os_cpu/linux_aarch64/safefetch_linux_aarch64.S ! src/hotspot/os_cpu/linux_aarch64/threadLS_linux_aarch64.S ! src/hotspot/os_cpu/linux_arm/linux_arm_32.S ! src/hotspot/os_cpu/linux_arm/safefetch_linux_arm.S ! src/hotspot/os_cpu/linux_ppc/safefetch_linux_ppc.S ! src/hotspot/os_cpu/linux_riscv/safefetch_linux_riscv.S ! src/hotspot/os_cpu/linux_s390/safefetch_linux_s390.S ! src/hotspot/os_cpu/linux_x86/linux_x86_32.S ! src/hotspot/os_cpu/linux_x86/linux_x86_64.S ! src/hotspot/os_cpu/linux_x86/safefetch_linux_x86_32.S ! src/hotspot/os_cpu/linux_x86/safefetch_linux_x86_64.S ! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp ! src/hotspot/share/jvmci/vmStructs_jvmci.cpp ! src/hotspot/share/oops/accessBackend.cpp ! src/hotspot/share/utilities/debug.cpp Changeset: 60cbf292 Author: Viktor Klang Date: 2024-02-27 10:38:36 +0000 URL: https://git.openjdk.org/lilliput/commit/60cbf2925024b1c2253256688ae41741fff0a860 8325754: Dead AbstractQueuedSynchronizer$ConditionNodes survive minor garbage collections Reviewed-by: alanb ! src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedLongSynchronizer.java ! src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedSynchronizer.java Changeset: 16d917a8 Author: Taizo Kurashige <103394724+kurashige23 at users.noreply.github.com> Committer: Erik Gahlin Date: 2024-02-27 10:39:48 +0000 URL: https://git.openjdk.org/lilliput/commit/16d917a85f9311611a14a63f1e53afae970efc73 8313710: jcmd: typo in the documentation of JFR.start and JFR.dump Reviewed-by: dholmes, egahlin ! src/jdk.jfr/share/classes/jdk/jfr/internal/dcmd/DCmdDump.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/dcmd/DCmdStart.java Changeset: bceaed6d Author: Magnus Ihse Bursie Date: 2024-02-27 10:54:49 +0000 URL: https://git.openjdk.org/lilliput/commit/bceaed6d4de391d1fdac0d35384c415a7c484d28 8326406: Remove mapfile support from makefiles Reviewed-by: jwaters, erikj ! make/autoconf/flags-cflags.m4 ! make/autoconf/spec.gmk.template ! make/common/NativeCompilation.gmk ! make/common/native/Link.gmk ! make/common/native/LinkMicrosoft.gmk Changeset: ac3ce2aa Author: Magnus Ihse Bursie Date: 2024-02-27 11:14:11 +0000 URL: https://git.openjdk.org/lilliput/commit/ac3ce2aa156332fc4e6f33018ff669657ab4b797 8326583: Remove over-generalized DefineNativeToolchain solution Reviewed-by: erikj ! make/Hsdis.gmk ! make/common/NativeCompilation.gmk ! make/common/TestFilesCompilation.gmk - make/common/native/ToolchainDefinitions.gmk ! make/hotspot/gensrc/GensrcAdlc.gmk ! make/hotspot/lib/CompileGtest.gmk ! make/hotspot/lib/CompileJvm.gmk ! make/modules/java.base/Lib.gmk ! make/modules/java.base/lib/CoreLibraries.gmk ! make/modules/java.desktop/Lib.gmk ! make/modules/java.desktop/lib/Awt2dLibraries.gmk ! make/modules/jdk.hotspot.agent/Lib.gmk ! make/modules/jdk.internal.le/Lib.gmk ! make/modules/jdk.jpackage/Lib.gmk Changeset: c5c866aa Author: Markus Gr?nlund Date: 2024-02-27 11:41:23 +0000 URL: https://git.openjdk.org/lilliput/commit/c5c866aafe76f51cd5386bf5052c06691c1a0e8c 8326219: applications/kitchensink/Kitchensink8H.java timed out Reviewed-by: egahlin ! src/hotspot/share/jfr/jni/jfrJniMethod.cpp ! src/hotspot/share/jfr/recorder/service/jfrRecorderService.cpp Changeset: 4fcae1ae Author: Zhengyu Gu Date: 2024-02-27 15:09:56 +0000 URL: https://git.openjdk.org/lilliput/commit/4fcae1aef52c7e5b8a76e07adcb2a3dbc5bb215d 8326722: Cleanup unnecessary forward declaration in collectedHeap.hpp Reviewed-by: tschatzl ! src/hotspot/share/gc/shared/collectedHeap.hpp Changeset: 81b065a9 Author: Jiangli Zhou Date: 2024-02-27 16:43:37 +0000 URL: https://git.openjdk.org/lilliput/commit/81b065a95d670ef357c36239d8c408cd72a5c48c 8326714: Make file-local functions static in src/java.base/unix/native/libjava/childproc.c Reviewed-by: djelinski, rriggs ! src/java.base/unix/native/libjava/childproc.c ! src/java.base/unix/native/libjava/childproc.h Changeset: 9f0e7da6 Author: Tobias Hartmann Date: 2024-02-27 16:58:22 +0000 URL: https://git.openjdk.org/lilliput/commit/9f0e7da64e21237322e55ca4f0e3639fa5d1c4ed 8326638: Crash in PhaseIdealLoop::remix_address_expressions due to unexpected Region instead of Loop Reviewed-by: chagedorn, kvn ! src/hotspot/share/opto/loopopts.cpp + test/hotspot/jtreg/compiler/loopopts/TestRemixAddressExpressionsWithIrreducibleLoop.java Changeset: 552411f8 Author: Hamlin Li Date: 2024-02-27 20:08:22 +0000 URL: https://git.openjdk.org/lilliput/commit/552411f832eb35d739c7978b8c1f8d0dfd4b2161 8326824: Test: remove redundant test in compiler/vectorapi/reshape/utils/TestCastMethods.java Reviewed-by: kvn ! test/hotspot/jtreg/compiler/vectorapi/reshape/utils/TestCastMethods.java Changeset: 349df0a0 Author: SendaoYan Committer: Jonathan Gibbons Date: 2024-02-27 22:19:14 +0000 URL: https://git.openjdk.org/lilliput/commit/349df0a0e550599cc4a9cde8bef00e138671b472 8326726: Problem list Exhaustiveness.java due to 8326616 Reviewed-by: jlahoda ! test/langtools/ProblemList.txt Changeset: 419191c6 Author: Weijun Wang Date: 2024-02-27 22:26:08 +0000 URL: https://git.openjdk.org/lilliput/commit/419191c653f787b5dc3032f9da31d8c9b9a08235 8325680: Uninitialised memory in deleteGSSCB of GSSLibStub.c:179 Reviewed-by: valeriep, djelinski ! src/java.security.jgss/share/native/libj2gss/GSSLibStub.c Changeset: 33f23827 Author: William Kemper Date: 2024-02-27 23:06:17 +0000 URL: https://git.openjdk.org/lilliput/commit/33f23827676dc9ff12bd5c0891170cd813b93b96 8325807: Shenandoah: Refactor full gc in preparation for generational mode changes Reviewed-by: shade, ysr, kdnilsen ! src/hotspot/share/gc/shenandoah/shenandoahFullGC.cpp ! src/hotspot/share/gc/shenandoah/shenandoahFullGC.hpp Changeset: 4dd6c44c Author: Robert Toyonaga Committer: Erik Gahlin Date: 2024-02-28 00:50:31 +0000 URL: https://git.openjdk.org/lilliput/commit/4dd6c44cbdb0b5957414fa87b6c559fa4d6f2fa8 8326529: JFR: Test for CompilerCompile events fails due to time out Reviewed-by: egahlin ! test/jdk/jdk/jfr/event/compiler/TestCompilerCompile.java Changeset: 6cad07c2 Author: Christian Hagedorn Date: 2024-02-28 07:03:57 +0000 URL: https://git.openjdk.org/lilliput/commit/6cad07c23b16aa9eb5a5a0674344d494843601dc 8325746: Refactor Loop Unswitching code Reviewed-by: epeter, kvn ! src/hotspot/share/opto/cfgnode.hpp ! src/hotspot/share/opto/ifnode.cpp ! src/hotspot/share/opto/loopUnswitch.cpp ! src/hotspot/share/opto/loopnode.hpp ! src/hotspot/share/opto/loopopts.cpp + test/hotspot/jtreg/compiler/loopopts/TestBaseCountedEndLoopUnswitchCandidate.java Changeset: 9b1f1e52 Author: Matthias Baesken Date: 2024-02-28 08:37:44 +0000 URL: https://git.openjdk.org/lilliput/commit/9b1f1e5294e130ec444b08af1f73d08e86fd91ee 8326389: [test] improve assertEquals failure output Reviewed-by: clanger, jpai ! test/lib/jdk/test/lib/Asserts.java Changeset: 3b90ddfe Author: Andrew Leonard Date: 2024-02-28 08:37:53 +0000 URL: https://git.openjdk.org/lilliput/commit/3b90ddfefea36d9f7f08ff11cd0cb099aa32b02b 8326685: Linux builds not reproducible if two builds configured in different build folders Reviewed-by: ihse, erikj ! make/autoconf/flags-cflags.m4 Changeset: 1ab6bd43 Author: Kuai Wei Committer: Julian Waters Date: 2024-02-28 08:44:49 +0000 URL: https://git.openjdk.org/lilliput/commit/1ab6bd434f560e0cc34a85079949e3839c59568f 8326135: Enhance adlc to report unused operands Reviewed-by: kvn, vlivanov ! src/hotspot/share/adlc/archDesc.cpp ! src/hotspot/share/adlc/archDesc.hpp ! src/hotspot/share/adlc/forms.cpp ! src/hotspot/share/adlc/forms.hpp ! src/hotspot/share/adlc/formsopt.cpp ! src/hotspot/share/adlc/formsopt.hpp ! src/hotspot/share/adlc/formssel.cpp ! src/hotspot/share/adlc/formssel.hpp ! src/hotspot/share/adlc/main.cpp Changeset: e6b3bda2 Author: Magnus Ihse Bursie Date: 2024-02-28 10:31:18 +0000 URL: https://git.openjdk.org/lilliput/commit/e6b3bda2c30ea7932a8a20027e1ef2e805610f14 8326509: Clean up JNIEXPORT in Hotspot after JDK-8017234 Reviewed-by: djelinski, jwaters, dholmes ! src/hotspot/cpu/aarch64/assembler_aarch64.cpp ! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp ! src/hotspot/share/jvmci/vmStructs_jvmci.cpp ! src/hotspot/share/utilities/debug.cpp Changeset: e7e80831 Author: Thomas Schatzl Date: 2024-02-28 10:37:54 +0000 URL: https://git.openjdk.org/lilliput/commit/e7e8083139f2cf7aa3e49dd1d72335ccb4ff00af 8326781: G1ConcurrentMark::top_at_rebuild_start() should take a HeapRegion* not an uint Reviewed-by: iwalulya, ayang ! src/hotspot/share/gc/g1/g1ConcurrentMark.hpp ! src/hotspot/share/gc/g1/g1ConcurrentMark.inline.hpp ! src/hotspot/share/gc/g1/g1ConcurrentRebuildAndScrub.cpp Changeset: eb4b6fa6 Author: Thomas Schatzl Date: 2024-02-28 10:42:44 +0000 URL: https://git.openjdk.org/lilliput/commit/eb4b6fa6212380c9b6d3c94f5aa3384f12a0c125 8326590: Improve description of MarkStackSize[Max] flags Reviewed-by: iwalulya ! src/hotspot/share/gc/shared/gc_globals.hpp Changeset: 5db50aca Author: Zhengyu Gu Date: 2024-02-28 13:55:48 +0000 URL: https://git.openjdk.org/lilliput/commit/5db50aca6925b3922bbd030cf981c5befb3df1e0 8326892: Remove unused PSAdaptiveSizePolicyResizeVirtualSpaceAlot develop flag Reviewed-by: gli, tschatzl ! src/hotspot/share/gc/shared/gc_globals.hpp Changeset: 41242cbe Author: Alexey Ivanov Date: 2024-02-28 14:42:03 +0000 URL: https://git.openjdk.org/lilliput/commit/41242cbe5d01fc6e19859626dd08f6191e7486fb 8325762: Use PassFailJFrame.Builder.splitUI() in PrintLatinCJKTest.java Reviewed-by: honkar, dmarkov ! test/jdk/java/awt/print/PrinterJob/PrintLatinCJKTest.java Changeset: a93605f7 Author: Albert Mingkun Yang Date: 2024-02-28 15:14:43 +0000 URL: https://git.openjdk.org/lilliput/commit/a93605f7fb0fbe22c7bdffc8eb6db4d660eec3d1 8326763: Consolidate print methods in ContiguousSpace Reviewed-by: stefank, gli ! src/hotspot/share/gc/shared/space.cpp ! src/hotspot/share/gc/shared/space.hpp Changeset: b938a5c9 Author: Vladimir Kozlov Date: 2024-02-28 16:04:47 +0000 URL: https://git.openjdk.org/lilliput/commit/b938a5c9edd53821a52b43a8e342b76adb341a3f 8324969: C2: prevent elimination of unbalanced coarsened locking regions Reviewed-by: epeter, vlivanov, dlong ! src/hotspot/share/opto/callnode.cpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/compile.hpp ! src/hotspot/share/opto/escape.cpp ! src/hotspot/share/opto/escape.hpp ! src/hotspot/share/opto/locknode.cpp ! src/hotspot/share/opto/locknode.hpp ! src/hotspot/share/opto/macro.cpp + test/hotspot/jtreg/compiler/locks/TestCoarsenedAndNestedLocksElimination.java Changeset: 38ad5145 Author: Lance Andersen Date: 2024-02-28 17:14:08 +0000 URL: https://git.openjdk.org/lilliput/commit/38ad514589764d16b312152474e2446c3339da39 8326687: Inconsistent use of "ZIP", "Zip" and "zip" in java.util.zip/jar zipfs javadoc Reviewed-by: dfuchs, jpai, gli ! src/java.base/share/classes/java/util/jar/JarFile.java ! src/java.base/share/classes/java/util/zip/ZipCoder.java ! src/java.base/share/classes/java/util/zip/ZipConstants.java ! src/java.base/share/classes/java/util/zip/ZipEntry.java ! src/java.base/share/classes/java/util/zip/ZipException.java ! src/java.base/share/classes/java/util/zip/ZipFile.java ! src/java.base/share/classes/java/util/zip/ZipInputStream.java ! src/java.base/share/classes/java/util/zip/ZipOutputStream.java ! src/java.base/share/classes/java/util/zip/ZipUtils.java ! src/java.base/share/classes/java/util/zip/package-info.java ! src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipCoder.java ! src/jdk.zipfs/share/classes/module-info.java Changeset: be2b92bd Author: Hannes Walln?fer Date: 2024-02-28 18:13:16 +0000 URL: https://git.openjdk.org/lilliput/commit/be2b92bd8b43841cc2b9c22ed4fde29be30d47bb 8326694: Defer setting of autocapitalize attribute Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Navigation.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SearchWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TableOfContents.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlAttr.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script.js.template ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/search-page.js ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/search.js.template ! test/langtools/jdk/javadoc/doclet/testSearch/TestSearch.java ! test/langtools/jdk/javadoc/doclet/testSpecTag/TestSpecTag.java Changeset: 5fa2bdc6 Author: Magnus Ihse Bursie Date: 2024-02-28 22:48:17 +0000 URL: https://git.openjdk.org/lilliput/commit/5fa2bdc6c76d8f70c8d8582889e96b9c0d2b86b5 8326953: Race in creation of win-exports.def with static-libs Reviewed-by: jwaters, erikj, dholmes ! make/hotspot/lib/CompileJvm.gmk Changeset: 0735c8ab Author: David Holmes Date: 2024-02-29 05:28:32 +0000 URL: https://git.openjdk.org/lilliput/commit/0735c8ab266be9c580bd4434305ee1decfe8b589 8318302: ThreadCountLimit.java failed with "Native memory allocation (mprotect) failed to protect 16384 bytes for memory to guard stack pages" Co-authored-by: Stefan Karlsson Reviewed-by: shade, stefank ! src/hotspot/share/utilities/vmError.cpp ! test/hotspot/jtreg/runtime/Thread/ThreadCountLimit.java Changeset: 998d0baa Author: Kim Barrett Date: 2024-02-29 06:24:42 +0000 URL: https://git.openjdk.org/lilliput/commit/998d0baab0fd051c38d9fd6021628eb863b80554 8324799: Use correct extension for C++ test headers Reviewed-by: jwaters, gli, coleenp, lmesnik ! test/hotspot/jtreg/serviceability/jvmti/DynamicCodeGenerated/libDynamicCodeGenerated.cpp ! test/hotspot/jtreg/serviceability/jvmti/FollowReferences/FieldIndices/libFieldIndicesTest.cpp ! test/hotspot/jtreg/serviceability/jvmti/GetClassFields/FilteredFields/libFilteredFieldsTest.cpp ! test/hotspot/jtreg/serviceability/jvmti/GetLocalVariable/libGetSetLocalUnsuspended.cpp ! test/hotspot/jtreg/serviceability/jvmti/SuspendWithCurrentThread/libSuspendWithCurrentThread.cpp ! test/hotspot/jtreg/serviceability/jvmti/events/Breakpoint/breakpoint01/libbreakpoint01.cpp ! test/hotspot/jtreg/serviceability/jvmti/events/ClassLoad/classload01/libclassload01.cpp ! test/hotspot/jtreg/serviceability/jvmti/events/ClassPrepare/classprep01/libclassprep01.cpp ! test/hotspot/jtreg/serviceability/jvmti/events/Exception/exception01/libexception01.cpp ! test/hotspot/jtreg/serviceability/jvmti/events/ExceptionCatch/excatch01/libexcatch01.cpp ! test/hotspot/jtreg/serviceability/jvmti/events/FieldAccess/fieldacc01/libfieldacc01.cpp ! test/hotspot/jtreg/serviceability/jvmti/events/FieldAccess/fieldacc02/libfieldacc02.cpp ! test/hotspot/jtreg/serviceability/jvmti/events/FieldAccess/fieldacc03/libfieldacc03.cpp ! test/hotspot/jtreg/serviceability/jvmti/events/FieldAccess/fieldacc04/libfieldacc04.cpp ! test/hotspot/jtreg/serviceability/jvmti/events/FieldModification/fieldmod01/libfieldmod01.cpp ! test/hotspot/jtreg/serviceability/jvmti/events/FieldModification/fieldmod02/libfieldmod02.cpp ! test/hotspot/jtreg/serviceability/jvmti/events/FramePop/framepop01/libframepop01.cpp ! test/hotspot/jtreg/serviceability/jvmti/events/FramePop/framepop02/libframepop02.cpp ! test/hotspot/jtreg/serviceability/jvmti/events/MethodEntry/mentry01/libmentry01.cpp ! test/hotspot/jtreg/serviceability/jvmti/events/MethodEntry/mentry02/libmentry02.cpp ! test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/mexit01/libmexit01.cpp ! test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/mexit02/libmexit02.cpp ! test/hotspot/jtreg/serviceability/jvmti/events/MonitorContendedEnter/mcontenter01/libmcontenter01.cpp ! test/hotspot/jtreg/serviceability/jvmti/events/MonitorContendedEntered/mcontentered01/libmcontentered01.cpp ! test/hotspot/jtreg/serviceability/jvmti/events/MonitorWait/monitorwait01/libmonitorwait01.cpp ! test/hotspot/jtreg/serviceability/jvmti/events/MonitorWaited/monitorwaited01/libmonitorwaited01.cpp ! test/hotspot/jtreg/serviceability/jvmti/events/NativeMethodBind/nativemethbind01/libnativemethbind01.cpp ! test/hotspot/jtreg/serviceability/jvmti/events/NativeMethodBind/nativemethbind02/libnativemethbind02.cpp ! test/hotspot/jtreg/serviceability/jvmti/events/NativeMethodBind/nativemethbind03/libnativemethbind03.cpp ! test/hotspot/jtreg/serviceability/jvmti/events/NativeMethodBind/nativemethbind04/libnativemethbind04.cpp ! test/hotspot/jtreg/serviceability/jvmti/events/SingleStep/singlestep01/libsinglestep01.cpp ! test/hotspot/jtreg/serviceability/jvmti/events/SingleStep/singlestep02/libsinglestep02.cpp ! test/hotspot/jtreg/serviceability/jvmti/events/SingleStep/singlestep03/libsinglestep03.cpp ! test/hotspot/jtreg/serviceability/jvmti/events/ThreadEnd/threadend01/libthreadend01.cpp ! test/hotspot/jtreg/serviceability/jvmti/events/ThreadEnd/threadend02/libthreadend02.cpp ! test/hotspot/jtreg/serviceability/jvmti/events/ThreadStart/threadstart01/libthreadstart01.cpp ! test/hotspot/jtreg/serviceability/jvmti/events/ThreadStart/threadstart02/libthreadstart02.cpp ! test/hotspot/jtreg/serviceability/jvmti/events/ThreadStart/threadstart03/libthreadstart03.cpp ! test/hotspot/jtreg/serviceability/jvmti/events/VMObjectAlloc/vmobjalloc01/libvmobjalloc01.cpp ! test/hotspot/jtreg/serviceability/jvmti/negative/GetAllThreadsNullTest/libGetAllThreadsNullTest.cpp ! test/hotspot/jtreg/serviceability/jvmti/negative/contmon03/libcontmon03.cpp ! test/hotspot/jtreg/serviceability/jvmti/negative/framecnt02/libframecnt02.cpp ! test/hotspot/jtreg/serviceability/jvmti/negative/framecnt03/libframecnt03.cpp ! test/hotspot/jtreg/serviceability/jvmti/negative/frameloc03/libframeloc03.cpp ! test/hotspot/jtreg/serviceability/jvmti/negative/getstacktr02/libgetstacktr02.cpp ! test/hotspot/jtreg/serviceability/jvmti/negative/getstacktr09/libgetstacktr09.cpp ! test/hotspot/jtreg/serviceability/jvmti/negative/thrinfo02/libthrinfo02.cpp ! test/hotspot/jtreg/serviceability/jvmti/negative/thrstat04/libthrstat04.cpp ! test/hotspot/jtreg/serviceability/jvmti/stress/StackTrace/NotSuspended/libGetStackTraceNotSuspendedStress.cpp ! test/hotspot/jtreg/serviceability/jvmti/stress/StackTrace/Suspended/libGetStackTraceSuspendedStress.cpp ! test/hotspot/jtreg/serviceability/jvmti/stress/ThreadLocalStorage/SetGetThreadLocalStorageStressTest/libSetGetThreadLocalStorageStress.cpp ! test/hotspot/jtreg/serviceability/jvmti/thread/GetAllThreads/allthr01/liballthr01.cpp ! test/hotspot/jtreg/serviceability/jvmti/thread/GetCurrentContendedMonitor/contmon01/libcontmon01.cpp ! test/hotspot/jtreg/serviceability/jvmti/thread/GetCurrentContendedMonitor/contmon02/libcontmon02.cpp ! test/hotspot/jtreg/serviceability/jvmti/thread/GetFrameCount/framecnt01/libframecnt01.cpp ! test/hotspot/jtreg/serviceability/jvmti/thread/GetFrameLocation/frameloc01/libframeloc01.cpp ! test/hotspot/jtreg/serviceability/jvmti/thread/GetFrameLocation/frameloc02/libframeloc02.cpp ! test/hotspot/jtreg/serviceability/jvmti/thread/GetStackTrace/GetStackTraceAndRetransformTest/libGetStackTraceAndRetransformTest.cpp ! test/hotspot/jtreg/serviceability/jvmti/thread/GetStackTrace/GetStackTraceCurrentThreadTest/libGetStackTraceCurrentThreadTest.cpp ! test/hotspot/jtreg/serviceability/jvmti/thread/GetStackTrace/getstacktr03/libgetstacktr03.cpp ! test/hotspot/jtreg/serviceability/jvmti/thread/GetStackTrace/getstacktr04/libgetstacktr04.cpp ! test/hotspot/jtreg/serviceability/jvmti/thread/GetStackTrace/getstacktr05/libgetstacktr05.cpp ! test/hotspot/jtreg/serviceability/jvmti/thread/GetStackTrace/getstacktr06/libgetstacktr06.cpp ! test/hotspot/jtreg/serviceability/jvmti/thread/GetStackTrace/getstacktr07/libgetstacktr07.cpp ! test/hotspot/jtreg/serviceability/jvmti/thread/GetStackTrace/getstacktr08/libgetstacktr08.cpp ! test/hotspot/jtreg/serviceability/jvmti/thread/GetThreadInfo/thrinfo01/libthrinfo01.cpp ! test/hotspot/jtreg/serviceability/jvmti/thread/GetThreadState/thrstat01/libthrstat01.cpp ! test/hotspot/jtreg/serviceability/jvmti/thread/GetThreadState/thrstat02/libthrstat02.cpp ! test/hotspot/jtreg/serviceability/jvmti/thread/GetThreadState/thrstat03/libthrstat03.cpp ! test/hotspot/jtreg/serviceability/jvmti/thread/GetThreadState/thrstat05/libthrstat05.cpp ! test/hotspot/jtreg/serviceability/jvmti/thread/ResumeThread/resumethrd01/libresumethrd01.cpp ! test/hotspot/jtreg/serviceability/jvmti/thread/ResumeThread/resumethrd02/libresumethrd02.cpp ! test/hotspot/jtreg/serviceability/jvmti/thread/ResumeThreadList/resumethrdlst01/libresumethrdlst01.cpp ! test/hotspot/jtreg/serviceability/jvmti/thread/ResumeThreadList/resumethrdlst02/libresumethrdlst02.cpp ! test/hotspot/jtreg/serviceability/jvmti/thread/SuspendThread/suspendthrd01/libsuspendthrd01.cpp ! test/hotspot/jtreg/serviceability/jvmti/thread/SuspendThread/suspendthrd02/libsuspendthrd02.cpp ! test/hotspot/jtreg/serviceability/jvmti/thread/SuspendThreadList/suspendthrdlst01/libsuspendthrdlst01.cpp ! test/hotspot/jtreg/serviceability/jvmti/thread/SuspendThreadList/suspendthrdlst02/libsuspendthrdlst02.cpp ! test/hotspot/jtreg/serviceability/jvmti/vthread/BoundVThreadTest/libBoundVThreadTest.cpp ! test/hotspot/jtreg/serviceability/jvmti/vthread/BreakpointInYieldTest/libBreakpointInYieldTest.cpp ! test/hotspot/jtreg/serviceability/jvmti/vthread/ContFramePopTest/libContFramePopTest.cpp ! test/hotspot/jtreg/serviceability/jvmti/vthread/ContStackDepthTest/libContStackDepthTest.cpp ! test/hotspot/jtreg/serviceability/jvmti/vthread/ContYieldBreakPointTest/libContYieldBreakPointTest.cpp ! test/hotspot/jtreg/serviceability/jvmti/vthread/ContinuationTest/libContinuationTest.cpp ! test/hotspot/jtreg/serviceability/jvmti/vthread/FollowReferences/libVThreadStackRefTest.cpp ! test/hotspot/jtreg/serviceability/jvmti/vthread/ForceEarlyReturnTest/libForceEarlyReturnTest.cpp ! test/hotspot/jtreg/serviceability/jvmti/vthread/GetSetLocalTest/libGetSetLocalTest.cpp ! test/hotspot/jtreg/serviceability/jvmti/vthread/GetThreadStateMountedTest/libGetThreadStateMountedTest.cpp ! test/hotspot/jtreg/serviceability/jvmti/vthread/InterruptThreadTest/libInterruptThreadTest.cpp ! test/hotspot/jtreg/serviceability/jvmti/vthread/MethodExitTest/libMethodExitTest.cpp ! test/hotspot/jtreg/serviceability/jvmti/vthread/NullAsCurrentThreadTest/libNullAsCurrentThreadTest.cpp ! test/hotspot/jtreg/serviceability/jvmti/vthread/PinnedTaskTest/libPinnedTaskTest.cpp ! test/hotspot/jtreg/serviceability/jvmti/vthread/PopFrameTest/libPopFrameTest.cpp ! test/hotspot/jtreg/serviceability/jvmti/vthread/RawMonitorTest/libRawMonitorTest.cpp ! test/hotspot/jtreg/serviceability/jvmti/vthread/SelfSuspendDisablerTest/libSelfSuspendDisablerTest.cpp ! test/hotspot/jtreg/serviceability/jvmti/vthread/StopThreadTest/libStopThreadTest.cpp ! test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendResume1/libSuspendResume1.cpp ! test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendResume2/libSuspendResume2.cpp ! test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendResumeAll/libSuspendResumeAll.cpp ! test/hotspot/jtreg/serviceability/jvmti/vthread/ThreadListStackTracesTest/libThreadListStackTracesTest.cpp ! test/hotspot/jtreg/serviceability/jvmti/vthread/ThreadStateTest/libThreadStateTest.cpp ! test/hotspot/jtreg/serviceability/jvmti/vthread/ToggleNotifyJvmtiTest/libToggleNotifyJvmtiTest.cpp ! test/hotspot/jtreg/serviceability/jvmti/vthread/VThreadEventTest/libVThreadEventTest.cpp ! test/hotspot/jtreg/serviceability/jvmti/vthread/VThreadMonitorTest/libVThreadMonitorTest.cpp ! test/hotspot/jtreg/serviceability/jvmti/vthread/VThreadNotifyFramePopTest/libVThreadNotifyFramePopTest.cpp ! test/hotspot/jtreg/serviceability/jvmti/vthread/VThreadTLSTest/libVThreadTLSTest.cpp ! test/hotspot/jtreg/serviceability/jvmti/vthread/VThreadTest/libVThreadTest.cpp ! test/hotspot/jtreg/serviceability/jvmti/vthread/VThreadUnsupportedTest/libVThreadUnsupportedTest.cpp ! test/hotspot/jtreg/serviceability/jvmti/vthread/VirtualStackTraceTest/libVirtualStackTraceTest.cpp ! test/hotspot/jtreg/serviceability/jvmti/vthread/VirtualThreadStartTest/libVirtualThreadStartTest.cpp ! test/hotspot/jtreg/serviceability/jvmti/vthread/WaitNotifySuspendedVThreadTest/libWaitNotifySuspendedVThread.cpp ! test/hotspot/jtreg/testlibrary/jvmti/libJvmtiUtils.cpp ! test/hotspot/jtreg/vmTestbase/nsk/aod/VirtualMachine/VirtualMachine07/agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/aod/VirtualMachine/VirtualMachine07/agent01.cpp ! test/hotspot/jtreg/vmTestbase/nsk/aod/VirtualMachine/VirtualMachine07/agent02.cpp ! test/hotspot/jtreg/vmTestbase/nsk/aod/VirtualMachine/VirtualMachine07/agent03.cpp ! test/hotspot/jtreg/vmTestbase/nsk/aod/VirtualMachine/VirtualMachine09/agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AddCapabilities/addcaps001/addcaps001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AddCapabilities/addcaps002/addcaps002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AddCapabilities/addcaps003/addcaps003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/Agent_OnLoad/agentonload001/agentonload001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/Agent_OnUnload/agentonunload001/agentonunload001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/Allocate/alloc001/alloc001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach002/attach002Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach002a/attach002aAgent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach008/attach008Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach009/attach009Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach012/attach012Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach014/attach014Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach015/attach015Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach015/attach015Agent01.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach015/attach015Target.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach020/attach020Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach021/attach021Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach022/attach022Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach037/attach037Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach038/attach038Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach039/attach039Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach040/attach040Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach041/attach041Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach042/attach042Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach045/attach045Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach045/attach045Agent01.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach045/attach045Agent02.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach045/attach045Agent03.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach046/attach046Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach050/attach050Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/sharedAgents/simpleAgent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClassFileLoadHook/classfloadhk001/classfloadhk001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClassFileLoadHook/classfloadhk002/classfloadhk002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClassFileLoadHook/classfloadhk003/classfloadhk003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClassFileLoadHook/classfloadhk004/classfloadhk004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClassFileLoadHook/classfloadhk005/classfloadhk005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClassFileLoadHook/classfloadhk006/classfloadhk006.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClassFileLoadHook/classfloadhk007/classfloadhk007.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClassFileLoadHook/classfloadhk008/classfloadhk008.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClassFileLoadHook/classfloadhk009/classfloadhk009.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClearBreakpoint/clrbrk001/clrbrk001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClearBreakpoint/clrbrk002/clrbrk002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClearBreakpoint/clrbrk005/clrbrk005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClearFieldAccessWatch/clrfldw001/clrfldw001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClearFieldAccessWatch/clrfldw002/clrfldw002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClearFieldModificationWatch/clrfmodw001/clrfmodw001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClearFieldModificationWatch/clrfmodw002/clrfmodw002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/CompiledMethodLoad/compmethload001/compmethload001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001/compmethunload001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/CreateRawMonitor/crrawmon001/crrawmon001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/CreateRawMonitor/crrawmon002/crrawmon002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/DataDumpRequest/datadumpreq001/datadumpreq001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/Deallocate/dealloc001/dealloc001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/DestroyRawMonitor/drrawmon001/drrawmon001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/DestroyRawMonitor/drrawmon003/drrawmon003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/DestroyRawMonitor/drrawmon004/drrawmon004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/DisposeEnvironment/disposeenv001/disposeenv001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/DisposeEnvironment/disposeenv002/disposeenv002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/DynamicCodeGenerated/dyncodgen001/dyncodgen001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ForceEarlyReturn/ForceEarlyReturn001/ForceEarlyReturn001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ForceGarbageCollection/forcegc001/forcegc001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ForceGarbageCollection/forcegc002/forcegc002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GarbageCollectionFinish/gcfinish001/gcfinish001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GarbageCollectionStart/gcstart001/gcstart001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GarbageCollectionStart/gcstart002/gcstart002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GenerateEvents/genevents001/genevents001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetArgumentsSize/argsize001/argsize001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetArgumentsSize/argsize002/argsize002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetAvailableProcessors/getavailproc001/getavailproc001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetBytecodes/bytecodes001/bytecodes001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetBytecodes/bytecodes002/bytecodes002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetBytecodes/bytecodes003/bytecodes003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetCapabilities/getcaps001/getcaps001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetCapabilities/getcaps002/getcaps002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassFields/getclfld005/getclfld005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassFields/getclfld006/getclfld006.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassFields/getclfld007/getclfld007.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassLoader/getclsldr001/getclsldr001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassLoader/getclsldr002/getclsldr002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassLoader/getclsldr003/getclsldr003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassLoaderClasses/clsldrclss001/clsldrclss001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassLoaderClasses/clsldrclss002/clsldrclss002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassMethods/getclmthd005/getclmthd005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassMethods/getclmthd006/getclmthd006.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassMethods/getclmthd007/getclmthd007.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassModifiers/getclmdf004/getclmdf004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassModifiers/getclmdf005/getclmdf005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassModifiers/getclmdf006/getclmdf006.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassModifiers/getclmdf007/getclmdf007.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassSignature/getclsig004/getclsig004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassSignature/getclsig005/getclsig005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassSignature/getclsig006/getclsig006.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassStatus/getclstat005/getclstat005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassStatus/getclstat006/getclstat006.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassStatus/getclstat007/getclstat007.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetCurrentThreadCpuTime/curthrcputime001/curthrcputime001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetCurrentThreadCpuTimerInfo/curthrtimerinfo001/curthrtimerinfo001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetEnv/GetEnv001/GetEnv001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetEnvironmentLocalStorage/getenvstor001/getenvstor001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetErrorName/geterrname001/geterrname001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetErrorName/geterrname002/geterrname002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetExtensionEvents/extevents001/extevents001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetExtensionFunctions/extfuncs001/extfuncs001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetFieldDeclaringClass/getfldecl001/getfldecl001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetFieldDeclaringClass/getfldecl002/getfldecl002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetFieldDeclaringClass/getfldecl004/getfldecl004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetFieldModifiers/getfldmdf003/getfldmdf003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetFieldModifiers/getfldmdf004/getfldmdf004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetFieldName/getfldnm003/getfldnm003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetFieldName/getfldnm004/getfldnm004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetFieldName/getfldnm005/getfldnm005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetImplementedInterfaces/getintrf005/getintrf005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetImplementedInterfaces/getintrf006/getintrf006.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetImplementedInterfaces/getintrf007/getintrf007.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetJLocationFormat/getjlocfmt001/getjlocfmt001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetJLocationFormat/getjlocfmt002/getjlocfmt002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetJNIFunctionTable/getjniftab001/getjniftab001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetJNIFunctionTable/getjniftab002/getjniftab002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetLineNumberTable/linetab001/linetab001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetLineNumberTable/linetab002/linetab002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetLineNumberTable/linetab003/linetab003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetLoadedClasses/loadedclss001/loadedclss001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetLoadedClasses/loadedclss002/loadedclss002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetLocalVariable/getlocal001/getlocal001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetLocalVariable/getlocal002/getlocal002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetLocalVariableTable/localtab001/localtab001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetLocalVariableTable/localtab002/localtab002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetLocalVariableTable/localtab003/localtab003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetLocalVariableTable/localtab004/localtab004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetLocalVariableTable/localtab005/localtab005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetMaxLocals/maxloc001/maxloc001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetMaxLocals/maxloc002/maxloc002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetMethodDeclaringClass/declcls001/declcls001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetMethodDeclaringClass/declcls002/declcls002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetMethodDeclaringClass/declcls003/declcls003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetMethodLocation/methloc002/methloc002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetMethodModifiers/methmod001/methmod001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetMethodModifiers/methmod002/methmod002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetMethodName/methname001/methname001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetMethodName/methname002/methname002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetMethodName/methname003/methname003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectHashCode/objhashcode001/objhashcode001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage001/objmonusage001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage002/objmonusage002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage003/objmonusage003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage004/objmonusage004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage005/objmonusage005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage006/objmonusage006.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectSize/objsize001/objsize001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectsWithTags/objwithtags001/objwithtags001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetOwnedMonitorInfo/ownmoninf001/ownmoninf001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetOwnedMonitorInfo/ownmoninf002/ownmoninf002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetOwnedMonitorInfo/ownmoninf003/ownmoninf003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetPhase/getphase001/getphase001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetPhase/getphase002/getphase002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetPotentialCapabilities/getpotcaps001/getpotcaps001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetSourceDebugExtension/srcdebugex001/srcdebugex001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetSourceDebugExtension/srcdebugex002/srcdebugex002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetSourceDebugExtension/srcdebugex003/srcdebugex003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetSourceFileName/getsrcfn004/getsrcfn004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetSourceFileName/getsrcfn005/getsrcfn005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetSourceFileName/getsrcfn006/getsrcfn006.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetSystemProperties/getsysprops001/getsysprops001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetSystemProperties/getsysprops002/getsysprops002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetSystemProperty/getsysprop001/getsysprop001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetSystemProperty/getsysprop002/getsysprop002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetTag/gettag001/gettag001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetThreadCpuTime/thrcputime001/thrcputime001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetThreadCpuTime/thrcputime002/thrcputime002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetThreadCpuTimerInfo/thrtimerinfo001/thrtimerinfo001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetThreadGroupChildren/getthrdgrpchld001/getthrdgrpchld001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetThreadGroupInfo/thrgrpinfo001/thrgrpinfo001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetThreadGroupInfo/thrgrpinfo002/thrgrpinfo002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetThreadLocalStorage/getthrdstor001/getthrdstor001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetTime/gettime001/gettime001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetTimerInfo/timerinfo001/timerinfo001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetTopThreadGroups/topthrgrp001/topthrgrp001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetTopThreadGroups/topthrgrp002/topthrgrp002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetVersionNumber/getvern001/getvern001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/InterruptThread/intrpthrd001/intrpthrd001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/InterruptThread/intrpthrd002/intrpthrd002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/InterruptThread/intrpthrd003/intrpthrd003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IsArrayClass/isarray004/isarray004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IsArrayClass/isarray005/isarray005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IsFieldSynthetic/isfldsin002/isfldsin002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IsFieldSynthetic/isfldsin003/isfldsin003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IsInterface/isintrf004/isintrf004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IsInterface/isintrf005/isintrf005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IsMethodNative/isnative001/isnative001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IsMethodNative/isnative002/isnative002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IsMethodObsolete/isobsolete001/isobsolete001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IsMethodSynthetic/issynth001/issynth001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IsMethodSynthetic/issynth002/issynth002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverHeap/iterheap001/iterheap001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverHeap/iterheap002/iterheap002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverHeap/iterheap003/iterheap003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverHeap/iterheap004/iterheap004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverHeap/iterheap005/iterheap005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverHeap/iterheap006/iterheap006.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverHeap/iterheap007/iterheap007.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverInstancesOfClass/iterinstcls001/iterinstcls001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverInstancesOfClass/iterinstcls002/iterinstcls002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverInstancesOfClass/iterinstcls003/iterinstcls003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverInstancesOfClass/iterinstcls004/iterinstcls004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverInstancesOfClass/iterinstcls005/iterinstcls005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverInstancesOfClass/iterinstcls006/iterinstcls006.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverInstancesOfClass/iterinstcls007/iterinstcls007.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverObjectsReachableFromObject/iterobjreachobj001/iterobjreachobj001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverObjectsReachableFromObject/iterobjreachobj002/iterobjreachobj002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverObjectsReachableFromObject/iterobjreachobj003/iterobjreachobj003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverObjectsReachableFromObject/iterobjreachobj004/iterobjreachobj004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverObjectsReachableFromObject/iterobjreachobj005/iterobjreachobj005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverReachableObjects/iterreachobj001/iterreachobj001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverReachableObjects/iterreachobj002/iterreachobj002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverReachableObjects/iterreachobj003/iterreachobj003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverReachableObjects/iterreachobj004/iterreachobj004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverReachableObjects/iterreachobj005/iterreachobj005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateThroughHeap/abort/Abort.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateThroughHeap/callbacks/Callbacks.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateThroughHeap/concrete-klass-filter/ConcreteKlassFilter.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateThroughHeap/filter-tagged/HeapFilter.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateThroughHeap/non-concrete-klass-filter/NonConcreteKlassFilter.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/NotifyFramePop/nframepop001/nframepop001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/NotifyFramePop/nframepop002/nframepop002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/NotifyFramePop/nframepop003/nframepop003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ObjectFree/objfree001/objfree001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ObjectFree/objfree002/objfree002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/PopFrame/popframe001/popframe001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/PopFrame/popframe002/popframe002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/PopFrame/popframe003/popframe003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/PopFrame/popframe004/popframe004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/PopFrame/popframe005/popframe005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/PopFrame/popframe006/popframe006.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/PopFrame/popframe007/popframe007.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/PopFrame/popframe008/popframe008.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/PopFrame/popframe009/popframe009.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/PopFrame/popframe010/popframe010.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/PopFrame/popframe011/popframe011.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorEnter/rawmonenter001/rawmonenter001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorEnter/rawmonenter002/rawmonenter002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorEnter/rawmonenter003/rawmonenter003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorEnter/rawmonenter004/rawmonenter004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorExit/rawmonexit001/rawmonexit001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorExit/rawmonexit002/rawmonexit002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorExit/rawmonexit003/rawmonexit003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorExit/rawmonexit005/rawmonexit005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorNotify/rawmnntfy001/rawmnntfy001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorNotify/rawmnntfy002/rawmnntfy002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorNotify/rawmnntfy003/rawmnntfy003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorNotify/rawmnntfy004/rawmnntfy004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorNotifyAll/rawmnntfyall001/rawmnntfyall001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorNotifyAll/rawmnntfyall002/rawmnntfyall002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorNotifyAll/rawmnntfyall003/rawmnntfyall003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorNotifyAll/rawmnntfyall004/rawmnntfyall004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorWait/rawmnwait001/rawmnwait001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorWait/rawmnwait002/rawmnwait002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorWait/rawmnwait003/rawmnwait003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorWait/rawmnwait004/rawmnwait004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorWait/rawmnwait005/rawmnwait005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine/stressRedefine.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass001/redefclass001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass002/redefclass002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass003/redefclass003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass004/redefclass004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass005/redefclass005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass006/redefclass006.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass008/redefclass008.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass009/redefclass009.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass010/redefclass010.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass011/redefclass011.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass012/redefclass012.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass013/redefclass013.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass014/redefclass014.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass015/redefclass015.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass016/redefclass016.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass017/redefclass017.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass018/redefclass018.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass019/redefclass019.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass020/redefclass020.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass021/redefclass021.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass022/redefclass022.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass023/redefclass023.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass024/redefclass024.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass025/redefclass025.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass026/redefclass026.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass027/redefclass027.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass028/redefclass028.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass029/redefclass029.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass030/redefclass030.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses/redefclass031/redefclass031.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RelinquishCapabilities/relcaps001/relcaps001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RelinquishCapabilities/relcaps002/relcaps002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ResourceExhausted/resexhausted.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ResumeThread/resumethrd001/resumethrd001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ResumeThread/resumethrd002/resumethrd002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ResumeThreadList/resumethrdlst001/resumethrdlst001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ResumeThreadList/resumethrdlst002/resumethrdlst002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RetransformClasses/retransform002/retransform002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RetransformClasses/retransform003/retransform003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RetransformClasses/retransform004/retransform004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RunAgentThread/agentthr001/agentthr001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RunAgentThread/agentthr002/agentthr002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RunAgentThread/agentthr003/agentthr003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetBreakpoint/setbrk002/setbrk002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetBreakpoint/setbrk003/setbrk003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetBreakpoint/setbrk005/setbrk005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetBreakpoint/setbrk007/setbrk007.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetBreakpoint/setbrk008/setbrk008.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetEnvironmentLocalStorage/setenvstor001/setenvstor001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetEnvironmentLocalStorage/setenvstor002/setenvstor002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetEnvironmentLocalStorage/setenvstor003/setenvstor003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetEventCallbacks/setevntcallb001/setevntcallb001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetEventCallbacks/setevntcallb002/setevntcallb002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetEventCallbacks/setevntcallb003/setevntcallb003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetEventNotificationMode/setnotif001/setnotif001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetExtensionEventCallback/setextevent001/setextevent001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetFieldAccessWatch/setfldw001/setfldw001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetFieldAccessWatch/setfldw002/setfldw002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetFieldAccessWatch/setfldw003/setfldw003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetFieldAccessWatch/setfldw004/setfldw004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetFieldAccessWatch/setfldw005/setfldw005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetFieldAccessWatch/setfldw006/setfldw006.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetFieldModificationWatch/setfmodw001/setfmodw001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetFieldModificationWatch/setfmodw002/setfmodw002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetFieldModificationWatch/setfmodw003/setfmodw003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetFieldModificationWatch/setfmodw004/setfmodw004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetFieldModificationWatch/setfmodw005/setfmodw005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetFieldModificationWatch/setfmodw006/setfmodw006.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetJNIFunctionTable/setjniftab001/setjniftab001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetJNIFunctionTable/setjniftab002/setjniftab002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetLocalVariable/setlocal001/setlocal001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetLocalVariable/setlocal002/setlocal002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetLocalVariable/setlocal003/setlocal003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetLocalVariable/setlocal004/setlocal004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetNativeMethodPrefix/SetNativeMethodPrefix001/SetNativeMethodPrefix001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetNativeMethodPrefix/SetNativeMethodPrefix002/SetNativeMethodPrefix002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetNativeMethodPrefix/SetNativeMethodPrefix002/SetNativeMethodPrefix002Main.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetSystemProperty/setsysprop002/setsysprop002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetSystemProperty/setsysprop003/setsysprop003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetTag/settag001/settag001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetThreadLocalStorage/setthrdstor001/setthrdstor001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetThreadLocalStorage/setthrdstor002/setthrdstor002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetThreadLocalStorage/setthrdstor003/setthrdstor003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetVerboseFlag/setvrbflag001/setvrbflag001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetVerboseFlag/setvrbflag002/setvrbflag002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/StopThread/stopthrd006/stopthrd006.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/StopThread/stopthrd007/stopthrd007.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SuspendThread/suspendthrd001/suspendthrd001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SuspendThread/suspendthrd002/suspendthrd002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SuspendThread/suspendthrd003/suspendthrd003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SuspendThreadList/suspendthrdlst001/suspendthrdlst001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SuspendThreadList/suspendthrdlst002/suspendthrdlst002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/VMDeath/vmdeath001/vmdeath001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/VMInit/vminit001/vminit001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP01/ap01t001/ap01t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP02/ap02t001/ap02t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP03/ap03t001/ap03t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP04/ap04t001/ap04t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP04/ap04t002/ap04t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP04/ap04t003/ap04t003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP05/ap05t001/ap05t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP05/ap05t002/ap05t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP06/ap06t001/ap06t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP07/ap07t001/ap07t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP07/ap07t002/ap07t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP09/ap09t001/ap09t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP10/ap10t001/ap10t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP11/ap11t001/ap11t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP12/ap12t001/ap12t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI01/bi01t001/bi01t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI01/bi01t002/bi01t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI02/bi02t001/bi02t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI02/bi02t002/bi02t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI03/bi03t001/bi03t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI03/bi03t002/bi03t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI04/bi04t002/bi04t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t001/cm01t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t002/cm01t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t003/cm01t003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t004/cm01t004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t005/cm01t005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t006/cm01t006.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t007/cm01t007.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t008/cm01t008.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t009/cm01t009.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t010/cm01t010.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t011/cm01t011.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t012/cm01t012.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t013/cm01t013.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t014/cm01t014.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t015/cm01t015.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t016/cm01t016.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t017/cm01t017.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t018/cm01t018.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t019/cm01t019.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t020/cm01t020.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM01/cm01t021/cm01t021.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM02/cm02t001/cm02t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM03/cm03t001/cm03t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC01/tc01t001/tc01t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC02/tc02t001/tc02t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC03/tc03t001/tc03t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC03/tc03t002/tc03t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC04/tc04t001/tc04t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC05/tc05t001/tc05t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM01/em01t001/em01t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM01/em01t002/em01t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t001/em02t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t002/em02t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t003/em02t003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t004/em02t004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t005/em02t005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t006/em02t006.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t007/em02t007.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t008/em02t008.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t009/em02t009.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t010/em02t010.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t011/em02t011.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t012/em02t012.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM04/em04t001/em04t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM05/em05t001/em05t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM05/em05t002/em05t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM06/em06t001/em06t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM07/em07t001/em07t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM07/em07t002/em07t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/extension/EX03/ex03t001/ex03t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/general_functions/GF01/gf01t001/gf01t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/general_functions/GF04/gf04t001/gf04t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/general_functions/GF06/gf06t001/gf06t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/general_functions/GF08/gf08t001/gf08t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/general_functions/GF08/gf08t002/gf08t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/general_functions/GF08/gf08t003/gf08t003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS103/hs103t002/hs103t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS104/hs104t001/hs104t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS104/hs104t002/hs104t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS201/hs201t001/hs201t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS201/hs201t002/hs201t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS201/hs201t003/hs201t003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS202/hs202t001/hs202t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS202/hs202t002/hs202t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS203/hs203t001/hs203t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS203/hs203t002/hs203t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS203/hs203t003/hs203t003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS203/hs203t004/hs203t004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS204/hs204t002/hs204t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS204/hs204t003/hs204t003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS204/hs204t004/hs204t004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS301/hs301t001/hs301t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS301/hs301t002/hs301t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS301/hs301t003/hs301t003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS301/hs301t004/hs301t004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS301/hs301t005/hs301t005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS302/hs302t001/hs302t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS302/hs302t002/hs302t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS302/hs302t003/hs302t003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS302/hs302t004/hs302t004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS302/hs302t005/hs302t005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS302/hs302t006/hs302t006.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS302/hs302t007/hs302t007.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS302/hs302t008/hs302t008.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS302/hs302t009/hs302t009.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS302/hs302t010/hs302t010.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS302/hs302t011/hs302t011.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS302/hs302t012/hs302t012.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/jni_interception/JI01/ji01t001/ji01t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/jni_interception/JI03/ji03t001/ji03t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/jni_interception/JI03/ji03t002/ji03t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/jni_interception/JI03/ji03t003/ji03t003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/jni_interception/JI03/ji03t004/ji03t004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/jni_interception/JI05/ji05t001/ji05t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/jni_interception/JI06/ji06t001/ji06t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA01/ma01t001/ma01t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA01/ma01t001/ma01t001a.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA02/ma02t001/ma02t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA02/ma02t001/ma02t001a.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA03/ma03t001/ma03t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA03/ma03t001/ma03t001a.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA04/ma04t001/ma04t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA04/ma04t001/ma04t001a.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA04/ma04t002/ma04t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA04/ma04t002/ma04t002a.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA04/ma04t003/ma04t003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA04/ma04t003/ma04t003a.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA05/ma05t001/ma05t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA05/ma05t001/ma05t001a.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA06/ma06t001/ma06t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA06/ma06t001/ma06t001a.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA07/ma07t001/ma07t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA07/ma07t001/ma07t001a.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA08/ma08t001/ma08t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA08/ma08t001/ma08t001a.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t001/ma10t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t001/ma10t001a.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t002/ma10t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t002/ma10t002a.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t003/ma10t003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t003/ma10t003a.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t004/ma10t004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t004/ma10t004a.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t005/ma10t005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t005/ma10t005a.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t006/ma10t006.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t006/ma10t006a.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t007/ma10t007.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t007/ma10t007a.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t008/ma10t008.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t008/ma10t008a.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP01/sp01t001/sp01t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP01/sp01t002/sp01t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP01/sp01t003/sp01t003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP02/sp02t001/sp02t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP02/sp02t002/sp02t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP02/sp02t003/sp02t003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP03/sp03t001/sp03t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP03/sp03t002/sp03t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP04/sp04t001/sp04t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP04/sp04t002/sp04t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP05/sp05t002/sp05t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP05/sp05t003/sp05t003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP06/sp06t001/sp06t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP06/sp06t002/sp06t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP06/sp06t003/sp06t003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP07/sp07t001/sp07t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP07/sp07t002/sp07t002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref001/followref001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref002/followref002.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref003/followref003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref004/followref004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref005/followref005.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref006/followref006.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretbase/earlyretbase.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretfp/earlyretfp.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretint/earlyretint.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretlong/earlyretlong.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretobj/earlyretobj.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretstr/earlyretstr.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretvoid/earlyretvoid.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/GetAllStackTraces/getallstktr001/getallstktr001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/GetConstantPool/getcpool001/getcpool001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/GetLineNumberTable/linetab004/linetab004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/GetLocalVariable/getlocal003/getlocal003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/GetLocalVariable/getlocal004/getlocal004.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/IsSynthetic/issynth001/issynth001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/agentthr/agentthr.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/clsldrclss00x/clsldrclss00x.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/events/redefineCFLH/JvmtiTest/JvmtiTest.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/heapref/heapref.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/refignore/refignore.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/setNullVMInit/JvmtiTest/JvmtiTest.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/timers/JvmtiTest/JvmtiTest.cpp ! test/hotspot/jtreg/vmTestbase/nsk/monitoring/share/StackTraceController.cpp ! test/hotspot/jtreg/vmTestbase/nsk/monitoring/share/ThreadController.cpp ! test/hotspot/jtreg/vmTestbase/nsk/monitoring/share/thread/Deadlock.cpp ! test/hotspot/jtreg/vmTestbase/nsk/monitoring/share/thread/LockingThreads.cpp ! test/hotspot/jtreg/vmTestbase/nsk/monitoring/share/thread/RecursiveMonitoringThread.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/JVMTIagent.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/aod/aod.cpp = test/hotspot/jtreg/vmTestbase/nsk/share/aod/aod.hpp ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jni/BooleanArrayCriticalLocker.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jni/ByteArrayCriticalLocker.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jni/CharArrayCriticalLocker.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jni/DoubleArrayCriticalLocker.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jni/FloatArrayCriticalLocker.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jni/IntArrayCriticalLocker.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jni/LongArrayCriticalLocker.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jni/ShortArrayCriticalLocker.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jni/StringCriticalLocker.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNILocalRefLocker.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIRefLocker.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIWeakGlobalRefLocker.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/jdi/MonitorEnterExecutor.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/jni/ExceptionCheckingJniEnv.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/jni/JNIreferences.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/jni/README ! test/hotspot/jtreg/vmTestbase/nsk/share/jni/jni_tools.cpp = test/hotspot/jtreg/vmTestbase/nsk/share/jni/jni_tools.hpp ! test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/AddToBootstrapClassLoaderSearch/bootclssearch_agent.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/AddToSystemClassLoaderSearch/systemclssearch_agent.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/Injector.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/JVMTITools.cpp - test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/JVMTITools.h + test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/JVMTITools.hpp ! test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/README ! test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/agent_common/agent_common.hpp ! test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/agent_tools.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/aod/jvmti_aod.hpp ! test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/hotswap/HotSwap.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_FollowRefObjects.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.cpp = test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.hpp ! test/hotspot/jtreg/vmTestbase/nsk/share/locks/JNIMonitorLocker.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/locks/LockingThread.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/native/README ! test/hotspot/jtreg/vmTestbase/nsk/share/native/nsk_list.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/native/nsk_tools.cpp = test/hotspot/jtreg/vmTestbase/nsk/share/native/nsk_tools.hpp ! test/hotspot/jtreg/vmTestbase/nsk/stress/strace/nsk_strace.hpp ! test/hotspot/jtreg/vmTestbase/nsk/stress/strace/strace005.cpp ! test/hotspot/jtreg/vmTestbase/vm/mlvm/indy/func/jvmti/share/IndyRedefineClass.cpp ! test/hotspot/jtreg/vmTestbase/vm/mlvm/indy/func/jvmti/stepBreakPopReturn/stepBreakPopReturn.cpp ! test/hotspot/jtreg/vmTestbase/vm/mlvm/meth/stress/jni/nativeAndMH/nativeAndMH.cpp ! test/hotspot/jtreg/vmTestbase/vm/mlvm/share/mlvmJvmtiUtils.cpp ! test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/shared/redefineClasses.cpp ! test/hotspot/jtreg/vmTestbase/vm/share/ProcessUtils.cpp ! test/jdk/java/foreign/enablenativeaccess/org/openjdk/foreigntest/unnamed/libLinkerInvokerUnnamed.cpp ! test/jdk/java/foreign/enablenativeaccess/panama_module/org/openjdk/foreigntest/libLinkerInvokerModule.cpp ! test/jdk/java/foreign/libAsyncInvokers.cpp ! test/jdk/java/foreign/loaderLookup/libLoaderLookupInvoker.cpp ! test/jdk/java/foreign/stackwalk/libAsyncStackWalk.cpp = test/lib/jdk/test/lib/jvmti/jvmti_common.hpp = test/lib/jdk/test/lib/jvmti/jvmti_thread.hpp - test/lib/native/testlib_threads.h + test/lib/native/testlib_threads.hpp From rkennke at openjdk.org Tue Mar 5 10:50:20 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 5 Mar 2024 10:50:20 GMT Subject: [omworld-jdk] RFR: Merge jdk:jdk-23+12 Message-ID: Let's merge jdk-23+12 into the omworld-jdk branch. ------------- Commit messages: - Merge tag 'jdk-23+12' into omworld-jdk-merge-jdk-23+12 - 8324799: Use correct extension for C++ test headers - 8318302: ThreadCountLimit.java failed with "Native memory allocation (mprotect) failed to protect 16384 bytes for memory to guard stack pages" - 8326953: Race in creation of win-exports.def with static-libs - 8326694: Defer setting of autocapitalize attribute - 8326687: Inconsistent use of "ZIP", "Zip" and "zip" in java.util.zip/jar zipfs javadoc - 8324969: C2: prevent elimination of unbalanced coarsened locking regions - 8326763: Consolidate print methods in ContiguousSpace - 8325762: Use PassFailJFrame.Builder.splitUI() in PrintLatinCJKTest.java - 8326892: Remove unused PSAdaptiveSizePolicyResizeVirtualSpaceAlot develop flag - ... and 149 more: https://git.openjdk.org/lilliput/compare/3aadead0...c14c8023 The webrevs contain the adjustments done while merging with regards to each parent branch: - omworld-jdk: https://webrevs.openjdk.org/?repo=lilliput&pr=143&range=00.0 - jdk:jdk-23+12: https://webrevs.openjdk.org/?repo=lilliput&pr=143&range=00.1 Changes: https://git.openjdk.org/lilliput/pull/143/files Stats: 21454 lines in 1363 files changed: 11275 ins; 4532 del; 5647 mod Patch: https://git.openjdk.org/lilliput/pull/143.diff Fetch: git fetch https://git.openjdk.org/lilliput.git pull/143/head:pull/143 PR: https://git.openjdk.org/lilliput/pull/143 From rkennke at openjdk.org Tue Mar 5 10:54:41 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 5 Mar 2024 10:54:41 GMT Subject: [omworld] RFR: Merge jdk:jdk-23+12 Message-ID: Let's merge jdk-23+12 into the omworld-lilliput branch. ------------- Commit messages: - Merge branch 'master' into omworld-merge-jdk-23+12 - Merge jdk:jdk-23+12 - 8324799: Use correct extension for C++ test headers - 8318302: ThreadCountLimit.java failed with "Native memory allocation (mprotect) failed to protect 16384 bytes for memory to guard stack pages" - 8326953: Race in creation of win-exports.def with static-libs - 8326694: Defer setting of autocapitalize attribute - 8326687: Inconsistent use of "ZIP", "Zip" and "zip" in java.util.zip/jar zipfs javadoc - 8324969: C2: prevent elimination of unbalanced coarsened locking regions - 8326763: Consolidate print methods in ContiguousSpace - 8325762: Use PassFailJFrame.Builder.splitUI() in PrintLatinCJKTest.java - ... and 152 more: https://git.openjdk.org/lilliput/compare/7c8acdcc...8a816046 The webrevs contain the adjustments done while merging with regards to each parent branch: - omworld: https://webrevs.openjdk.org/?repo=lilliput&pr=144&range=00.0 - jdk:jdk-23+12: https://webrevs.openjdk.org/?repo=lilliput&pr=144&range=00.1 Changes: https://git.openjdk.org/lilliput/pull/144/files Stats: 21247 lines in 1360 files changed: 11146 ins; 4480 del; 5621 mod Patch: https://git.openjdk.org/lilliput/pull/144.diff Fetch: git fetch https://git.openjdk.org/lilliput.git pull/144/head:pull/144 PR: https://git.openjdk.org/lilliput/pull/144 From rkennke at openjdk.org Tue Mar 5 14:19:22 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 5 Mar 2024 14:19:22 GMT Subject: [omworld-jdk] RFR: Merge jdk:jdk-23+12 [v2] In-Reply-To: References: Message-ID: > Let's merge jdk-23+12 into the omworld-jdk branch. Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: - Merge tag 'jdk-23+12' into omworld-jdk-merge-jdk-23+12 Added tag jdk-23+12 for changeset 998d0baa - 8326753: Lilliput: OMCache: Use AoS Reviewed-by: rkennke - 8326823: Lilliput: OMWorld: Separate NMT category Reviewed-by: aboldtch - 8326752: Lilliput: OMCache: Add cache lookup unrolling Reviewed-by: rkennke - 8326761: Lilliput: OMWorld: Fix invalid markWord transition Reviewed-by: rkennke - Merge - Minor cleanups - Initial Split ------------- Changes: https://git.openjdk.org/lilliput/pull/143/files Webrev: https://webrevs.openjdk.org/?repo=lilliput&pr=143&range=01 Stats: 3365 lines in 65 files changed: 3204 ins; 16 del; 145 mod Patch: https://git.openjdk.org/lilliput/pull/143.diff Fetch: git fetch https://git.openjdk.org/lilliput.git pull/143/head:pull/143 PR: https://git.openjdk.org/lilliput/pull/143 From rkennke at openjdk.org Tue Mar 5 14:19:22 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 5 Mar 2024 14:19:22 GMT Subject: [omworld-jdk] RFR: Merge jdk:jdk-23+12 In-Reply-To: References: Message-ID: On Tue, 5 Mar 2024 10:41:48 GMT, Roman Kennke wrote: > Let's merge jdk-23+12 into the omworld-jdk branch. One unrelated GHA failure in RISCV build. Let's ------------- PR Comment: https://git.openjdk.org/lilliput/pull/143#issuecomment-1978871073 From rkennke at openjdk.org Tue Mar 5 14:19:23 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 5 Mar 2024 14:19:23 GMT Subject: [omworld-jdk] Integrated: Merge jdk:jdk-23+12 In-Reply-To: References: Message-ID: On Tue, 5 Mar 2024 10:41:48 GMT, Roman Kennke wrote: > Let's merge jdk-23+12 into the omworld-jdk branch. This pull request has now been integrated. Changeset: 77adf50d Author: Roman Kennke URL: https://git.openjdk.org/lilliput/commit/77adf50d168ca5ffd5854395016de8cae1979ba0 Stats: 21454 lines in 1363 files changed: 11275 ins; 4532 del; 5647 mod Merge ------------- PR: https://git.openjdk.org/lilliput/pull/143 From dan.heidinga at oracle.com Tue Mar 5 15:06:30 2024 From: dan.heidinga at oracle.com (Dan Heidinga) Date: Tue, 5 Mar 2024 15:06:30 +0000 Subject: Sharing the markword (aka Valhalla's markword use) Message-ID: (Cross-posting to both valhalla-dev and lilliput-dev) Valhalla?s markword usage and Lilliput?s desire to shrink the object header require some careful collaboration to find a design that let?s both projects move forward. I?d like to lay out the current Valhalla markword use so that we can look at how it fits with Lilliput?s plans and ensure we can make the right trade-offs together. There may be clever encodings (reusing the locking bits?) but it makes sense to do that together ? hence the cross-post. Valhalla uses 4 markword bits [0], two for instances and two for arrays. The bits are: * is_larval: This is bit is dynamic and indicates the state change from when a value instance can be updated (during construction) to when it becomes immutable. We need this bit to ensure correctness of off-label construction and debugging apis as well as to ensure values being constructed are never aliased with fully constructed values. * is_value_type: this bit is static and is used to identify value instances. This bit speeds acmp and other identity sensitive operations so that non-value code doesn?t experience a regression. Before values, acmp could use pointer comparison to test if two instance were the same. With values a ?substitutability? test is required. For value instances, neither the hash code nor their locking bits are required. Value hash codes are computed similarly to the substitutability test and values cannot be locked or synchronized on. Arrays of values are identity objects and, like other reference array types, are compatible with Object[] or interface arrays (assuming the values implement the interface). We use two bits to identify the special cases of arrays: * is_flat_array: Indicates that the array elements have been flattened and that data must be copied in/out of the array when accessing the elements. * is_null_free_array: indicates that the array rejects null elements and will throw an exception when code attempts to store null into the array. Arrays ? being identity objects ? need both their hash codes and locking bits. This is what Valhalla is using the current prototypes. Early performance experiments led us to this design and we?re working on reconfirming those results. How does this approach fit with the current Lilliput plans? --Dan [0] https://github.com/openjdk/valhalla/blob/1f410430df6ef023b82d971a10ee4f0f8dfa2d6b/src/hotspot/share/oops/markWord.hpp#L69 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rkennke at amazon.de Tue Mar 5 15:31:59 2024 From: rkennke at amazon.de (Kennke, Roman) Date: Tue, 5 Mar 2024 15:31:59 +0000 Subject: Sharing the markword (aka Valhalla's markword use) In-Reply-To: References: Message-ID: Hi Dan, Thank you for the information, that is very useful! Yes, I agree that we should negotiate about this ;-) I have two questions: - Are there requirements/constraints on your side on the position of some of the bits? For example, in Lilliput, we use the 3rd bit (ex-biased-locking-bit) to indicate self-forwarding in the GC. It kinda needs to be that bit, because we expect that the header can also be overlaid with a forwarding pointer, and those use all bits except the lowest 3. (See: https://github.com/openjdk/jdk/pull/17755) - Are any of the bits required during (full) GC? For example, in Lilliput, we want to make the hash-code use only 2 bits, and allocate the storage for the actual hash-code on-demand. However, this means that we need the hash-code bits to determine the object?s size, and therefore must not displace the hash-bits during GC (not even temporarily). This is also true for the Klass* bits, that we plan to go into the object header as well. (See: https://wiki.openjdk.org/display/lilliput/Compact+Identity+Hashcode and https://github.com/openjdk/lilliput/pull/137) For a descriptions of our current plans (which are likely to change until we?re done), see the JEP: https://openjdk.org/jeps/450 Thanks, Roman > On Mar 5, 2024, at 4:06?PM, Dan Heidinga wrote: > > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > (Cross-posting to both valhalla-dev and lilliput-dev) > Valhalla?s markword usage and Lilliput?s desire to shrink the object header require some careful collaboration to find a design that let?s both projects move forward. I?d like to lay out the current Valhalla markword use so that we can look at how it fits with Lilliput?s plans and ensure we can make the right trade-offs together. There may be clever encodings (reusing the locking bits?) but it makes sense to do that together ? hence the cross-post. > Valhalla uses 4 markword bits [0], two for instances and two for arrays. The bits are: > * is_larval: This is bit is dynamic and indicates the state change from when a value instance can be updated (during construction) to when it becomes immutable. We need this bit to ensure correctness of off-label construction and debugging apis as well as to ensure values being constructed are never aliased with fully constructed values. > * is_value_type: this bit is static and is used to identify value instances. This bit speeds acmp and other identity sensitive operations so that non-value code doesn?t experience a regression. Before values, acmp could use pointer comparison to test if two instance were the same. With values a ?substitutability? test is required. > For value instances, neither the hash code nor their locking bits are required. Value hash codes are computed similarly to the substitutability test and values cannot be locked or synchronized on. > Arrays of values are identity objects and, like other reference array types, are compatible with Object[] or interface arrays (assuming the values implement the interface). > We use two bits to identify the special cases of arrays: > * is_flat_array: Indicates that the array elements have been flattened and that data must be copied in/out of the array when accessing the elements. > * is_null_free_array: indicates that the array rejects null elements and will throw an exception when code attempts to store null into the array. > Arrays ? being identity objects ? need both their hash codes and locking bits. > This is what Valhalla is using the current prototypes. Early performance experiments led us to this design and we?re working on reconfirming those results. > How does this approach fit with the current Lilliput plans? > --Dan > [0] https://github.com/openjdk/valhalla/blob/1f410430df6ef023b82d971a10ee4f0f8dfa2d6b/src/hotspot/share/oops/markWord.hpp#L69 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 thomas.stuefe at gmail.com Tue Mar 5 16:28:56 2024 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 5 Mar 2024 17:28:56 +0100 Subject: Sharing the markword (aka Valhalla's markword use) In-Reply-To: References: Message-ID: Hi Dan, In addition to Roman's answer, we plan to reduce the Klasspointer to 22 bits [1]. For 64-bit headers, this would give us 31-bit i-hash back and still leave us with 4 unused bits. Unfortunately, outside of our heads and the FOSDEM talk [2] we gave this year I think this is nowhere documented yet. I feel guilty but have been swamped since returning from FOSDEM. [1] https://github.com/openjdk/lilliput/pull/128 [2] https://fosdem.org/2024/schedule/event/fosdem-2024-3015-project-lilliput-compact-object-headers/ Cheers, Thomas On Tue, Mar 5, 2024 at 4:06?PM Dan Heidinga wrote: > (Cross-posting to both valhalla-dev and lilliput-dev) > > > > Valhalla?s markword usage and Lilliput?s desire to shrink the object > header require some careful collaboration to find a design that let?s both > projects move forward. I?d like to lay out the current Valhalla markword > use so that we can look at how it fits with Lilliput?s plans and ensure we > can make the right trade-offs together. There may be clever encodings > (reusing the locking bits?) but it makes sense to do that together ? hence > the cross-post. > > > > Valhalla uses 4 markword bits [0], two for instances and two for arrays. > The bits are: > > > > * is_larval: This is bit is dynamic and indicates the state change from > when a value instance can be updated (during construction) to when it > becomes immutable. We need this bit to ensure correctness of off-label > construction and debugging apis as well as to ensure values being > constructed are never aliased with fully constructed values. > > > > * is_value_type: this bit is static and is used to identify value > instances. This bit speeds acmp and other identity sensitive operations so > that non-value code doesn?t experience a regression. Before values, acmp > could use pointer comparison to test if two instance were the same. With > values a ?substitutability? test is required. > > > > For value instances, neither the hash code nor their locking bits are > required. Value hash codes are computed similarly to the substitutability > test and values cannot be locked or synchronized on. > > > > Arrays of values are identity objects and, like other reference array > types, are compatible with Object[] or interface arrays (assuming the > values implement the interface). > > > > We use two bits to identify the special cases of arrays: > > > > * is_flat_array: Indicates that the array elements have been flattened and > that data must be copied in/out of the array when accessing the elements. > > > > * is_null_free_array: indicates that the array rejects null elements and > will throw an exception when code attempts to store null into the array. > > > > Arrays ? being identity objects ? need both their hash codes and locking > bits. > > > > This is what Valhalla is using the current prototypes. Early performance > experiments led us to this design and we?re working on reconfirming those > results. > > > > How does this approach fit with the current Lilliput plans? > > > > --Dan > > > > [0] > https://github.com/openjdk/valhalla/blob/1f410430df6ef023b82d971a10ee4f0f8dfa2d6b/src/hotspot/share/oops/markWord.hpp#L69 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Wed Mar 6 09:11:39 2024 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 6 Mar 2024 10:11:39 +0100 (CET) Subject: Sharing the markword (aka Valhalla's markword use) In-Reply-To: References: Message-ID: <1144724541.22149694.1709716299480.JavaMail.zimbra@univ-eiffel.fr> ----- Original Message ----- > From: "Roman Kennke" > To: "Dan Heidinga" > Cc: "valhalla-dev" , "lilliput-dev" > Sent: Tuesday, March 5, 2024 4:31:59 PM > Subject: Re: Sharing the markword (aka Valhalla's markword use) > Hi Dan, > > Thank you for the information, that is very useful! Yes, I agree that we should > negotiate about this ;-) > > I have two questions: > - Are there requirements/constraints on your side on the position of some of the > bits? For example, in Lilliput, we use the 3rd bit (ex-biased-locking-bit) to > indicate self-forwarding in the GC. It kinda needs to be that bit, because we > expect that the header can also be overlaid with a forwarding pointer, and > those use all bits except the lowest 3. (See: > https://github.com/openjdk/jdk/pull/17755) > - Are any of the bits required during (full) GC? For example, in Lilliput, we > want to make the hash-code use only 2 bits, and allocate the storage for the > actual hash-code on-demand. However, this means that we need the hash-code bits > to determine the object?s size, and therefore must not displace the hash-bits > during GC (not even temporarily). This is also true for the Klass* bits, that > we plan to go into the object header as well. (See: > https://wiki.openjdk.org/display/lilliput/Compact+Identity+Hashcode and > https://github.com/openjdk/lilliput/pull/137) > > For a descriptions of our current plans (which are likely to change until we?re > done), see the JEP: > https://openjdk.org/jeps/450 > For the compact identity hashcode, i wonder if for arrays the hashCode storage should be always present. Independantly of Valhalla, relocating a big array just for the hashCode does not seem to be a good strategy, and it also exacerbates the allocation failure issue. In that case, is_flat_array and is_null_free_array can be bits that share the same storage as the hashCode. > Thanks, > Roman > R?mi > >> On Mar 5, 2024, at 4:06?PM, Dan Heidinga wrote: >> >> CAUTION: This email originated from outside of the organization. Do not click >> links or open attachments unless you can confirm the sender and know the >> content is safe. >> >> (Cross-posting to both valhalla-dev and lilliput-dev) >> Valhalla?s markword usage and Lilliput?s desire to shrink the object header >> require some careful collaboration to find a design that let?s both projects >> move forward. I?d like to lay out the current Valhalla markword use so that we >> can look at how it fits with Lilliput?s plans and ensure we can make the right >> trade-offs together. There may be clever encodings (reusing the locking bits?) >> but it makes sense to do that together ? hence the cross-post. >> Valhalla uses 4 markword bits [0], two for instances and two for arrays. The >> bits are: >> * is_larval: This is bit is dynamic and indicates the state change from when a >> value instance can be updated (during construction) to when it becomes >> immutable. We need this bit to ensure correctness of off-label construction >> and debugging apis as well as to ensure values being constructed are never >> aliased with fully constructed values. >> * is_value_type: this bit is static and is used to identify value instances. >> This bit speeds acmp and other identity sensitive operations so that non-value >> code doesn?t experience a regression. Before values, acmp could use pointer >> comparison to test if two instance were the same. With values a >> ?substitutability? test is required. >> For value instances, neither the hash code nor their locking bits are required. >> Value hash codes are computed similarly to the substitutability test and >> values cannot be locked or synchronized on. >> Arrays of values are identity objects and, like other reference array types, are >> compatible with Object[] or interface arrays (assuming the values implement the >> interface). >> We use two bits to identify the special cases of arrays: >> * is_flat_array: Indicates that the array elements have been flattened and that >> data must be copied in/out of the array when accessing the elements. >> * is_null_free_array: indicates that the array rejects null elements and will >> throw an exception when code attempts to store null into the array. >> Arrays ? being identity objects ? need both their hash codes and locking bits. >> This is what Valhalla is using the current prototypes. Early performance >> experiments led us to this design and we?re working on reconfirming those >> results. >> How does this approach fit with the current Lilliput plans? >> --Dan >> [0] >> https://github.com/openjdk/valhalla/blob/1f410430df6ef023b82d971a10ee4f0f8dfa2d6b/src/hotspot/share/oops/markWord.hpp#L69 > > > > > > 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 dan.heidinga at oracle.com Wed Mar 6 15:20:06 2024 From: dan.heidinga at oracle.com (Dan Heidinga) Date: Wed, 6 Mar 2024 15:20:06 +0000 Subject: Sharing the markword (aka Valhalla's markword use) In-Reply-To: References: Message-ID: Values lack identity so it?s possible for them to be deduplicated (or even duplicated!) at any point when they are not in the larval state. That would mean we?d need the is_larval bit to be stable to any process (gc?) that may be responsible for (de)duplication. The other three bits shouldn?t be required during GC and can be re-derived from the klass metadata. --Dan From: Kennke, Roman Date: Tuesday, March 5, 2024 at 10:36?AM To: Dan Heidinga Cc: valhalla-dev at openjdk.org , lilliput-dev at openjdk.org Subject: [External] : Re: Sharing the markword (aka Valhalla's markword use) Hi Dan, Thank you for the information, that is very useful! Yes, I agree that we should negotiate about this ;-) I have two questions: - Are there requirements/constraints on your side on the position of some of the bits? For example, in Lilliput, we use the 3rd bit (ex-biased-locking-bit) to indicate self-forwarding in the GC. It kinda needs to be that bit, because we expect that the header can also be overlaid with a forwarding pointer, and those use all bits except the lowest 3. (See: https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/17755__;!!ACWV5N9M2RV99hQ!JxZ8PqhuJWDsPahgznChIyJFjicveLxZzz6sXkeFcm1qVUooZnn1vWmVrT_U3_NTTffaeWpr2d9q-7N6zqFW$ ) - Are any of the bits required during (full) GC? For example, in Lilliput, we want to make the hash-code use only 2 bits, and allocate the storage for the actual hash-code on-demand. However, this means that we need the hash-code bits to determine the object?s size, and therefore must not displace the hash-bits during GC (not even temporarily). This is also true for the Klass* bits, that we plan to go into the object header as well. (See: https://wiki.openjdk.org/display/lilliput/Compact+Identity+Hashcode and https://urldefense.com/v3/__https://github.com/openjdk/lilliput/pull/137__;!!ACWV5N9M2RV99hQ!JxZ8PqhuJWDsPahgznChIyJFjicveLxZzz6sXkeFcm1qVUooZnn1vWmVrT_U3_NTTffaeWpr2d9q-5pRnCoP$ ) For a descriptions of our current plans (which are likely to change until we?re done), see the JEP: https://openjdk.org/jeps/450 Thanks, Roman > On Mar 5, 2024, at 4:06?PM, Dan Heidinga wrote: > > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > (Cross-posting to both valhalla-dev and lilliput-dev) > Valhalla?s markword usage and Lilliput?s desire to shrink the object header require some careful collaboration to find a design that let?s both projects move forward. I?d like to lay out the current Valhalla markword use so that we can look at how it fits with Lilliput?s plans and ensure we can make the right trade-offs together. There may be clever encodings (reusing the locking bits?) but it makes sense to do that together ? hence the cross-post. > Valhalla uses 4 markword bits [0], two for instances and two for arrays. The bits are: > * is_larval: This is bit is dynamic and indicates the state change from when a value instance can be updated (during construction) to when it becomes immutable. We need this bit to ensure correctness of off-label construction and debugging apis as well as to ensure values being constructed are never aliased with fully constructed values. > * is_value_type: this bit is static and is used to identify value instances. This bit speeds acmp and other identity sensitive operations so that non-value code doesn?t experience a regression. Before values, acmp could use pointer comparison to test if two instance were the same. With values a ?substitutability? test is required. > For value instances, neither the hash code nor their locking bits are required. Value hash codes are computed similarly to the substitutability test and values cannot be locked or synchronized on. > Arrays of values are identity objects and, like other reference array types, are compatible with Object[] or interface arrays (assuming the values implement the interface). > We use two bits to identify the special cases of arrays: > * is_flat_array: Indicates that the array elements have been flattened and that data must be copied in/out of the array when accessing the elements. > * is_null_free_array: indicates that the array rejects null elements and will throw an exception when code attempts to store null into the array. > Arrays ? being identity objects ? need both their hash codes and locking bits. > This is what Valhalla is using the current prototypes. Early performance experiments led us to this design and we?re working on reconfirming those results. > How does this approach fit with the current Lilliput plans? > --Dan > [0] https://urldefense.com/v3/__https://github.com/openjdk/valhalla/blob/1f410430df6ef023b82d971a10ee4f0f8dfa2d6b/src/hotspot/share/oops/markWord.hpp*L69__;Iw!!ACWV5N9M2RV99hQ!JxZ8PqhuJWDsPahgznChIyJFjicveLxZzz6sXkeFcm1qVUooZnn1vWmVrT_U3_NTTffaeWpr2d9q-7L0Qht7$ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan.heidinga at oracle.com Wed Mar 6 15:32:29 2024 From: dan.heidinga at oracle.com (Dan Heidinga) Date: Wed, 6 Mar 2024 15:32:29 +0000 Subject: [External] : Re: Sharing the markword (aka Valhalla's markword use) In-Reply-To: References: Message-ID: 4 free bits ? just what we need! =) One of the challenges for J9 over the last few years has been finding header bits. J9 went to a ?single word header?, uses the has_been_hashed | has_been_moved trick for identity hash, and has a more complicated scheme for which classes get lock words (or not) and where they?re put per class (layout gaps are a pretty common choice). This has limited the ability of new features to get header bits without decreasing gc age bits or stealing a bit from existing use cases. Small headers are good but how small is small enough? This isn?t a Valhalla concern per se, but a general observation that if we are bumping the limit on bits now, we are limiting all future project?s ability to use bits. There?s a trade-off here that my experience fighting for bits on J9 says we should be making cautiously. --Dan From: Thomas St?fe Date: Tuesday, March 5, 2024 at 11:29?AM To: Dan Heidinga Cc: valhalla-dev at openjdk.org , lilliput-dev at openjdk.org , Kennke, Roman Subject: [External] : Re: Sharing the markword (aka Valhalla's markword use) Hi Dan, In addition to Roman's answer, we plan to reduce the Klasspointer to 22 bits [1]. For 64-bit headers, this would give us 31-bit i-hash back and still leave us with 4 unused bits. Unfortunately, outside of our heads and the FOSDEM talk [2] we gave this year I think this is nowhere documented yet. I feel guilty but have been swamped since returning from FOSDEM. [1] https://github.com/openjdk/lilliput/pull/128 [2] https://fosdem.org/2024/schedule/event/fosdem-2024-3015-project-lilliput-compact-object-headers/ Cheers, Thomas On Tue, Mar 5, 2024 at 4:06?PM Dan Heidinga > wrote: (Cross-posting to both valhalla-dev and lilliput-dev) Valhalla?s markword usage and Lilliput?s desire to shrink the object header require some careful collaboration to find a design that let?s both projects move forward. I?d like to lay out the current Valhalla markword use so that we can look at how it fits with Lilliput?s plans and ensure we can make the right trade-offs together. There may be clever encodings (reusing the locking bits?) but it makes sense to do that together ? hence the cross-post. Valhalla uses 4 markword bits [0], two for instances and two for arrays. The bits are: * is_larval: This is bit is dynamic and indicates the state change from when a value instance can be updated (during construction) to when it becomes immutable. We need this bit to ensure correctness of off-label construction and debugging apis as well as to ensure values being constructed are never aliased with fully constructed values. * is_value_type: this bit is static and is used to identify value instances. This bit speeds acmp and other identity sensitive operations so that non-value code doesn?t experience a regression. Before values, acmp could use pointer comparison to test if two instance were the same. With values a ?substitutability? test is required. For value instances, neither the hash code nor their locking bits are required. Value hash codes are computed similarly to the substitutability test and values cannot be locked or synchronized on. Arrays of values are identity objects and, like other reference array types, are compatible with Object[] or interface arrays (assuming the values implement the interface). We use two bits to identify the special cases of arrays: * is_flat_array: Indicates that the array elements have been flattened and that data must be copied in/out of the array when accessing the elements. * is_null_free_array: indicates that the array rejects null elements and will throw an exception when code attempts to store null into the array. Arrays ? being identity objects ? need both their hash codes and locking bits. This is what Valhalla is using the current prototypes. Early performance experiments led us to this design and we?re working on reconfirming those results. How does this approach fit with the current Lilliput plans? --Dan [0] https://github.com/openjdk/valhalla/blob/1f410430df6ef023b82d971a10ee4f0f8dfa2d6b/src/hotspot/share/oops/markWord.hpp#L69 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rkennke at amazon.de Wed Mar 6 18:43:29 2024 From: rkennke at amazon.de (Kennke, Roman) Date: Wed, 6 Mar 2024 18:43:29 +0000 Subject: Sharing the markword (aka Valhalla's markword use) In-Reply-To: References: Message-ID: <3751A866-5B63-461F-8CA4-C8448004D367@amazon.de> Hi Dan, > 4 free bits ? just what we need! =) Yes, but my questions about constraints remain. > One of the challenges for J9 over the last few years has been finding header bits. J9 went to a ?single word header?, uses the has_been_hashed | has_been_moved trick for identity hash, and has a more complicated scheme for which classes get lock words (or not) and where they?re put per class (layout gaps are a pretty common choice). This has limited the ability of new features to get header bits without decreasing gc age bits or stealing a bit from existing use cases. > Small headers are good but how small is small enough? This isn?t a Valhalla concern per se, but a general observation that if we are bumping the limit on bits now, we are limiting all future project?s ability to use bits. There?s a trade-off here that my experience fighting for bits on J9 says we should be making cautiously. I understand. My point of view is that it doesn?t make a lot of sense to not do a tremendously useful optimization like 8- or 4-byte headers, just because we may need something in the future. But I agree that we should try to make it flexible enough to accommodate future needs, or at least make it relatively easy. Let?s first lay out a rough plan about what we?re planning to do with class-pointers. Currently, compressed class-pointers are 32 bits wide, and from what I can tell, is more than enough to address as many classes as anybody would want. For 8-byte headers, our plan is to use 22 bits and still address enough classes (see Thomas? part of the FOSDEM presentation). This leaves enough bits for 31 bit hashcode, 4 Valhalla bits, 4 age bits, 1 self-forwarding bits and 2 lock bits. We have a plan how we can make the class-pointer much smaller. Based on the observation that most workloads only require a few 10000 classes, let?s say 15 bits is ?enough? and not wasteful. Workloads that require more often generate those classes, which often don?t have many instances (e.g. only 1). In order to address arbitrary many classes, we would require one more bit that indicates that the class-pointer should be loaded from a dedicated field - this could be compressed 32 bits, or uncompressed 64 bits, or somehow be combined with the 15 class-bits from the header, we can determine the details later. We can also determine the exact number of bits later. The point is that we can make the class-pointer small enough to accommodate, say, 99% of all workloads and flexible enough for everything else. Using those 16 class-bits, and assuming 2(hash)+4(Valhalla)+4(age)+3(locking), we?d still have a reserve of 3 bits. We could use them for more classes, or reserve them for future use. It does not seem unreasonable to make the class-bits even smaller, in case we ever need more bits. Also, if we ever need a bit only for arrays (wasn?t one of the Valhalla bits only for arrays?), we?d have one bit that we can use from the array-length field. Let me know what you think. Roman > --Dan > From: Thomas St?fe > Date: Tuesday, March 5, 2024 at 11:29?AM > To: Dan Heidinga > Cc: valhalla-dev at openjdk.org , lilliput-dev at openjdk.org , Kennke, Roman > Subject: [External] : Re: Sharing the markword (aka Valhalla's markword use) > Hi Dan, > In addition to Roman's answer, we plan to reduce the Klasspointer to 22 bits [1]. For 64-bit headers, this would give us 31-bit i-hash back and still leave us with 4 unused bits. > Unfortunately, outside of our heads and the FOSDEM talk [2] we gave this year I think this is nowhere documented yet. I feel guilty but have been swamped since returning from FOSDEM. > [1] https://github.com/openjdk/lilliput/pull/128 > [2] https://fosdem.org/2024/schedule/event/fosdem-2024-3015-project-lilliput-compact-object-headers/ > Cheers, Thomas > On Tue, Mar 5, 2024 at 4:06?PM Dan Heidinga wrote: > (Cross-posting to both valhalla-dev and lilliput-dev) > Valhalla?s markword usage and Lilliput?s desire to shrink the object header require some careful collaboration to find a design that let?s both projects move forward. I?d like to lay out the current Valhalla markword use so that we can look at how it fits with Lilliput?s plans and ensure we can make the right trade-offs together. There may be clever encodings (reusing the locking bits?) but it makes sense to do that together ? hence the cross-post. > Valhalla uses 4 markword bits [0], two for instances and two for arrays. The bits are: > * is_larval: This is bit is dynamic and indicates the state change from when a value instance can be updated (during construction) to when it becomes immutable. We need this bit to ensure correctness of off-label construction and debugging apis as well as to ensure values being constructed are never aliased with fully constructed values. > * is_value_type: this bit is static and is used to identify value instances. This bit speeds acmp and other identity sensitive operations so that non-value code doesn?t experience a regression. Before values, acmp could use pointer comparison to test if two instance were the same. With values a ?substitutability? test is required. > For value instances, neither the hash code nor their locking bits are required. Value hash codes are computed similarly to the substitutability test and values cannot be locked or synchronized on. > Arrays of values are identity objects and, like other reference array types, are compatible with Object[] or interface arrays (assuming the values implement the interface). > We use two bits to identify the special cases of arrays: > * is_flat_array: Indicates that the array elements have been flattened and that data must be copied in/out of the array when accessing the elements. > * is_null_free_array: indicates that the array rejects null elements and will throw an exception when code attempts to store null into the array. > Arrays ? being identity objects ? need both their hash codes and locking bits. > This is what Valhalla is using the current prototypes. Early performance experiments led us to this design and we?re working on reconfirming those results. > How does this approach fit with the current Lilliput plans? > --Dan > [0] https://github.com/openjdk/valhalla/blob/1f410430df6ef023b82d971a10ee4f0f8dfa2d6b/src/hotspot/share/oops/markWord.hpp#L69 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 rkennke at amazon.de Wed Mar 6 18:47:09 2024 From: rkennke at amazon.de (Kennke, Roman) Date: Wed, 6 Mar 2024 18:47:09 +0000 Subject: Sharing the markword (aka Valhalla's markword use) In-Reply-To: <3751A866-5B63-461F-8CA4-C8448004D367@amazon.de> References: <3751A866-5B63-461F-8CA4-C8448004D367@amazon.de> Message-ID: <02B3277A-354B-46C1-B44E-018A4D973A4D@amazon.de> > > We have a plan how we can make the class-pointer much smaller. Based on the observation that most workloads only require a few 10000 classes, let?s say 15 bits is ?enough? and not wasteful. Workloads that require more often generate those classes, which often don?t have many instances (e.g. only 1). In order to address arbitrary many classes, we would require one more bit that indicates that the class-pointer should be loaded from a dedicated field - this could be compressed 32 bits, or uncompressed 64 bits, or somehow be combined with the 15 class-bits from the header I shall add that this is possible because we know at class-loading time whether or not we?re going to exceed the class-addressing-limit, and reserve the extra Klass* field at class-loading time, during field layout, and allocate all affected instances with that extra field right from the start, no stunts needed like with the compact I-hash stuff. 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 forax at univ-mlv.fr Thu Mar 7 00:53:36 2024 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 7 Mar 2024 01:53:36 +0100 (CET) Subject: Sharing the markword (aka Valhalla's markword use) In-Reply-To: <02B3277A-354B-46C1-B44E-018A4D973A4D@amazon.de> References: <3751A866-5B63-461F-8CA4-C8448004D367@amazon.de> <02B3277A-354B-46C1-B44E-018A4D973A4D@amazon.de> Message-ID: <1565557114.22597080.1709772816897.JavaMail.zimbra@univ-eiffel.fr> ----- Original Message ----- > From: "Roman Kennke" > To: "Dan Heidinga" > Cc: "Thomas St?fe" , "valhalla-dev" , "lilliput-dev" > > Sent: Wednesday, March 6, 2024 7:47:09 PM > Subject: Re: Sharing the markword (aka Valhalla's markword use) >> >> We have a plan how we can make the class-pointer much smaller. Based on the >> observation that most workloads only require a few 10000 classes, let?s say 15 >> bits is ?enough? and not wasteful. Workloads that require more often generate >> those classes, which often don?t have many instances (e.g. only 1). In order to >> address arbitrary many classes, we would require one more bit that indicates >> that the class-pointer should be loaded from a dedicated field - this could be >> compressed 32 bits, or uncompressed 64 bits, or somehow be combined with the 15 >> class-bits from the header > > I shall add that this is possible because we know at class-loading time whether > or not we?re going to exceed the class-addressing-limit, and reserve the extra > Klass* field at class-loading time, during field layout, and allocate all > affected instances with that extra field right from the start, no stunts needed > like with the compact I-hash stuff. and > Using those 16 class-bits, and assuming 2(hash)+4(Valhalla)+4(age)+3(locking), > we?d still have a reserve of 3 bits. We could use them for more classes, or > reserve them for future use. It does not seem unreasonable to make the > class-bits even smaller, in case we ever need more bits. If you have 2 bits for the hash, you need the compact identity hash optimization too. So splitting the classpointer to save more bits is a third optimization. Liliput 64 uses compressed classpointer (22 bits) and lightweight locking, Liliput 32 uses compact identity hash (2 bits) with storage inflation on demand (plus all the above), Liliput 16 uses split classpointer (plus all the above). > > Roman > R?mi > > > > 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 rkennke at amazon.de Thu Mar 7 08:59:47 2024 From: rkennke at amazon.de (Kennke, Roman) Date: Thu, 7 Mar 2024 08:59:47 +0000 Subject: Sharing the markword (aka Valhalla's markword use) In-Reply-To: <1565557114.22597080.1709772816897.JavaMail.zimbra@univ-eiffel.fr> References: <3751A866-5B63-461F-8CA4-C8448004D367@amazon.de> <02B3277A-354B-46C1-B44E-018A4D973A4D@amazon.de> <1565557114.22597080.1709772816897.JavaMail.zimbra@univ-eiffel.fr> Message-ID: <27A37359-093E-4763-ABA9-A5AEA7C7CCDD@amazon.de> >>> We have a plan how we can make the class-pointer much smaller. Based on the >>> observation that most workloads only require a few 10000 classes, let?s say 15 >>> bits is ?enough? and not wasteful. Workloads that require more often generate >>> those classes, which often don?t have many instances (e.g. only 1). In order to >>> address arbitrary many classes, we would require one more bit that indicates >>> that the class-pointer should be loaded from a dedicated field - this could be >>> compressed 32 bits, or uncompressed 64 bits, or somehow be combined with the 15 >>> class-bits from the header >> >> I shall add that this is possible because we know at class-loading time whether >> or not we?re going to exceed the class-addressing-limit, and reserve the extra >> Klass* field at class-loading time, during field layout, and allocate all >> affected instances with that extra field right from the start, no stunts needed >> like with the compact I-hash stuff. > > and > >> Using those 16 class-bits, and assuming 2(hash)+4(Valhalla)+4(age)+3(locking), >> we?d still have a reserve of 3 bits. We could use them for more classes, or >> reserve them for future use. It does not seem unreasonable to make the >> class-bits even smaller, in case we ever need more bits. > > If you have 2 bits for the hash, you need the compact identity hash optimization too. > So splitting the classpointer to save more bits is a third optimization. > > Liliput 64 uses compressed classpointer (22 bits) and lightweight locking, > Liliput 32 uses compact identity hash (2 bits) with storage inflation on demand (plus all the above), > Liliput 16 uses split classpointer (plus all the above). Not quite. Lilliput 64 uses 22 bit compressed class-pointer, 31 bits I-hash and 4 age, 4 Valhalla, 1 self-forwarding and 2 lock bits. Lilliput 32 would use 16 (possibly up to 19) bits class-pointer, 2 I-hash-bits, and the others same as above. We don?t currently have plans for Lilliput 16. While that may be possible, I would expect diminishing returns because of extra efforts (CPU cycles and/or out-of-heap storage) to squeeze the bits. 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 rkennke at openjdk.org Thu Mar 7 13:23:02 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Thu, 7 Mar 2024 13:23:02 GMT Subject: [omworld] RFR: Merge jdk:jdk-23+12 [v2] In-Reply-To: References: Message-ID: > Let's merge jdk-23+12 into the omworld-lilliput branch. Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 130 commits: - Merge branch 'master' into omworld-merge-jdk-23+12 - Merge jdk:jdk-23+12 - Merge jdk:jdk-23+11 - Merge jdk:jdk-23+10 Reviewed-by: stuefe - Merge lilliput:omworld-jdk - Merge - Minor cleanups - Initial Split - Merge branch 'master' into omworld - Merge jdk:jdk-23+8 - ... and 120 more: https://git.openjdk.org/lilliput/compare/998d0baa...8a816046 ------------- Changes: https://git.openjdk.org/lilliput/pull/144/files Webrev: https://webrevs.openjdk.org/?repo=lilliput&pr=144&range=01 Stats: 6292 lines in 191 files changed: 5606 ins; 158 del; 528 mod Patch: https://git.openjdk.org/lilliput/pull/144.diff Fetch: git fetch https://git.openjdk.org/lilliput.git pull/144/head:pull/144 PR: https://git.openjdk.org/lilliput/pull/144 From rkennke at openjdk.org Thu Mar 7 13:23:03 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Thu, 7 Mar 2024 13:23:03 GMT Subject: [omworld] Integrated: Merge jdk:jdk-23+12 In-Reply-To: References: Message-ID: On Tue, 5 Mar 2024 10:49:42 GMT, Roman Kennke wrote: > Let's merge jdk-23+12 into the omworld-lilliput branch. This pull request has now been integrated. Changeset: 84180a2c Author: Roman Kennke URL: https://git.openjdk.org/lilliput/commit/84180a2c6985be71788fab10dbf3e67bbf5ee95c Stats: 21247 lines in 1360 files changed: 11146 ins; 4480 del; 5621 mod Merge jdk:jdk-23+12 ------------- PR: https://git.openjdk.org/lilliput/pull/144 From dan.heidinga at oracle.com Fri Mar 8 14:59:14 2024 From: dan.heidinga at oracle.com (Dan Heidinga) Date: Fri, 8 Mar 2024 14:59:14 +0000 Subject: Sharing the markword (aka Valhalla's markword use) In-Reply-To: <3751A866-5B63-461F-8CA4-C8448004D367@amazon.de> References: <3751A866-5B63-461F-8CA4-C8448004D367@amazon.de> Message-ID: (Response in line) From: Kennke, Roman Date: Wednesday, March 6, 2024 at 1:43?PM To: Dan Heidinga Cc: Thomas St?fe , valhalla-dev at openjdk.org , lilliput-dev at openjdk.org Subject: [External] : Re: Re: Sharing the markword (aka Valhalla's markword use) Hi Dan, > 4 free bits ? just what we need! =) Yes, but my questions about constraints remain. Apologies. I thought I had responded in the other thread. Three of the bits can be rediscovered / determined from the Klass metadata and I?m not aware of any requirements on the specific bit position. The 4th bit ? the is_larval bit ? needs to be preserved and we envision uses of it by future (de)duplication processes that may run as part of the gc. Particular bit position doesn?t matter as long as we can find the bit. Does that answer your questions? > One of the challenges for J9 over the last few years has been finding header bits. J9 went to a ?single word header?, uses the has_been_hashed | has_been_moved trick for identity hash, and has a more complicated scheme for which classes get lock words (or not) and where they?re put per class (layout gaps are a pretty common choice). This has limited the ability of new features to get header bits without decreasing gc age bits or stealing a bit from existing use cases. > Small headers are good but how small is small enough? This isn?t a Valhalla concern per se, but a general observation that if we are bumping the limit on bits now, we are limiting all future project?s ability to use bits. There?s a trade-off here that my experience fighting for bits on J9 says we should be making cautiously. I understand. My point of view is that it doesn?t make a lot of sense to not do a tremendously useful optimization like 8- or 4-byte headers, just because we may need something in the future. But I agree that we should try to make it flexible enough to accommodate future needs, or at least make it relatively easy. I?m offering some caution on the value of shrinking the header as small as possible today as it severally restricts future options. I know you and Thomas and others are taking a principled look at this space to find the best encodings and I want to be a voice for keeping additional slack in the encoding for future projects (Java?s not done after all =) Let?s first lay out a rough plan about what we?re planning to do with class-pointers. Currently, compressed class-pointers are 32 bits wide, and from what I can tell, is more than enough to address as many classes as anybody would want. For 8-byte headers, our plan is to use 22 bits and still address enough classes (see Thomas? part of the FOSDEM presentation). This leaves enough bits for 31 bit hashcode, 4 Valhalla bits, 4 age bits, 1 self-forwarding bits and 2 lock bits. That?s great. If we start by planning on 4 Valhalla bits then we can always look at clever encodings as follow tasks when the need for more bits surfaces. We have a plan how we can make the class-pointer much smaller. Based on the observation that most workloads only require a few 10000 classes, let?s say 15 bits is ?enough? and not wasteful. Workloads that require more often generate those classes, which often don?t have many instances (e.g. only 1). In order to address arbitrary many classes, we would require one more bit that indicates that the class-pointer should be loaded from a dedicated field - this could be compressed 32 bits, or uncompressed 64 bits, or somehow be combined with the 15 class-bits from the header, we can determine the details later. We can also determine the exact number of bits later. The point is that we can make the class-pointer small enough to accommodate, say, 99% of all workloads and flexible enough for everything else. Using those 16 class-bits, and assuming 2(hash)+4(Valhalla)+4(age)+3(locking), we?d still have a reserve of 3 bits. We could use them for more classes, or reserve them for future use. It does not seem unreasonable to make the class-bits even smaller, in case we ever need more bits. Also, if we ever need a bit only for arrays (wasn?t one of the Valhalla bits only for arrays?), we?d have one bit that we can use from the array-length field. Two of the bits are for arrays and in the Valhalla we?ve also floated the idea of clever encodings like using the array-length. The challenge is that such encodings float through the rest of the system and have surprising knock on effects. As an example, we looked at overloading the high bit of array length in J9 and, although I don?t recall the details, there was an issue with some array bounds checks getting slower as they required additional masks. It sounds like we have a path forward with bits available for Valhalla without affecting Lilliput?s plans. Do you see any concerns not listed here? --Dan Let me know what you think. Roman > --Dan > From: Thomas St?fe > Date: Tuesday, March 5, 2024 at 11:29?AM > To: Dan Heidinga > Cc: valhalla-dev at openjdk.org , lilliput-dev at openjdk.org , Kennke, Roman > Subject: [External] : Re: Sharing the markword (aka Valhalla's markword use) > Hi Dan, > In addition to Roman's answer, we plan to reduce the Klasspointer to 22 bits [1]. For 64-bit headers, this would give us 31-bit i-hash back and still leave us with 4 unused bits. > Unfortunately, outside of our heads and the FOSDEM talk [2] we gave this year I think this is nowhere documented yet. I feel guilty but have been swamped since returning from FOSDEM. > [1] https://urldefense.com/v3/__https://github.com/openjdk/lilliput/pull/128__;!!ACWV5N9M2RV99hQ!NEUrYwA0GRM8U1H-5SrLV7vXMk0nr9mDhhPK7lnoKFZQKloskZA2uEpPbroQKnz_-8DCexbKx7peCEZfQ9I9$ > [2] https://urldefense.com/v3/__https://fosdem.org/2024/schedule/event/fosdem-2024-3015-project-lilliput-compact-object-headers/__;!!ACWV5N9M2RV99hQ!NEUrYwA0GRM8U1H-5SrLV7vXMk0nr9mDhhPK7lnoKFZQKloskZA2uEpPbroQKnz_-8DCexbKx7peCCetCSuA$ > Cheers, Thomas > On Tue, Mar 5, 2024 at 4:06?PM Dan Heidinga wrote: > (Cross-posting to both valhalla-dev and lilliput-dev) > Valhalla?s markword usage and Lilliput?s desire to shrink the object header require some careful collaboration to find a design that let?s both projects move forward. I?d like to lay out the current Valhalla markword use so that we can look at how it fits with Lilliput?s plans and ensure we can make the right trade-offs together. There may be clever encodings (reusing the locking bits?) but it makes sense to do that together ? hence the cross-post. > Valhalla uses 4 markword bits [0], two for instances and two for arrays. The bits are: > * is_larval: This is bit is dynamic and indicates the state change from when a value instance can be updated (during construction) to when it becomes immutable. We need this bit to ensure correctness of off-label construction and debugging apis as well as to ensure values being constructed are never aliased with fully constructed values. > * is_value_type: this bit is static and is used to identify value instances. This bit speeds acmp and other identity sensitive operations so that non-value code doesn?t experience a regression. Before values, acmp could use pointer comparison to test if two instance were the same. With values a ?substitutability? test is required. > For value instances, neither the hash code nor their locking bits are required. Value hash codes are computed similarly to the substitutability test and values cannot be locked or synchronized on. > Arrays of values are identity objects and, like other reference array types, are compatible with Object[] or interface arrays (assuming the values implement the interface). > We use two bits to identify the special cases of arrays: > * is_flat_array: Indicates that the array elements have been flattened and that data must be copied in/out of the array when accessing the elements. > * is_null_free_array: indicates that the array rejects null elements and will throw an exception when code attempts to store null into the array. > Arrays ? being identity objects ? need both their hash codes and locking bits. > This is what Valhalla is using the current prototypes. Early performance experiments led us to this design and we?re working on reconfirming those results. > How does this approach fit with the current Lilliput plans? > --Dan > [0] https://urldefense.com/v3/__https://github.com/openjdk/valhalla/blob/1f410430df6ef023b82d971a10ee4f0f8dfa2d6b/src/hotspot/share/oops/markWord.hpp*L69__;Iw!!ACWV5N9M2RV99hQ!NEUrYwA0GRM8U1H-5SrLV7vXMk0nr9mDhhPK7lnoKFZQKloskZA2uEpPbroQKnz_-8DCexbKx7peCB8WCdsM$ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.r.rose at oracle.com Sun Mar 10 03:38:35 2024 From: john.r.rose at oracle.com (John Rose) Date: Sat, 09 Mar 2024 19:38:35 -0800 Subject: Sharing the markword (aka Valhalla's markword use) In-Reply-To: References: Message-ID: What Dan said. Here?s more color commentary: The larval state of a value object can be viewed as an analog of the locked state of an identity object. In both cases, one specific thread is doing something exclusive to the object. For values, this larval state is indeed highly exclusive: The thread that made the value object is also filling in its fields, protected either by the verifier (if it is constructor code) or by some other means (if the fields are being set by privileged non-constructor code). Unlike a locked identity object, once a value exits the larval state, it is forever an adult; an identity object can be relocked many times. All that said, the lifecycles are different, but they are similar enough that we can envision using some of the same bit-patterns in parallel. I am pretty sure that whatever locked state indicator (a bit pattern) that we invent for the object header of an identity object is more than adequate for a value object in its larval state. So, just have each GC process larvae very much like locked objects, and arrange the header bit patterns to make this easy, by making them be similar. And, as an aside, in the future the GC or JIT may perform deduplication (or, say, NUMA-sensitive duplication) of values, or any other reorganization that reassigns varying pointers which alias equivalent copies of the same value state. In such a case, please be sure to treat every larval value object as unique and never aliased to any other value object, however similar. A larval value is likely to be side-effected to a new state before it becomes adult, which would cause bad failures if it were accidentally treated as aliased to some unrelated value. Only adult values are legitimate subjects for alias-based optimizations, whether in the JIT or GC. Regarding the other bits (is-value, is-flat-array, is-null-free-array), those can all be re-hoisted from the Klass object, if for some reason the header needs to be restored or reset. After all, those bits are just optimized copies (hoisted into a convenient place in the header), copied from the original information in the Klass object itself. This hoisting is a performance hack. We are discussing it at length here because the Valhalla team has determined, at least provisionally, that acceptable product performance requires such a ?hoisting hack?. I suggest adding, to Klass itself, a field which is a prototype header for the object, with all the right bits in place. The GC can use that as a starting point when repairing headers that it had to reset. (I thought we already had something like this somewhere, but a quick check came up empty?) Currently, it appears we reset object headers from markWord::prototype which is an absolute constant. Perhaps this function should be refactored to a query to non-static Klass::prototype_mark_word. That?s just my $0.02; probably stuff like this has been discussed several times. A final suggestion, which I?ve mentioned elsewhere, but it?s worth repeating: If we don?t choose to burn whole a bit on the is-value test, we can use a joint bit encoding. (Similar point for an is-array test, in fact, or for particular subkinds of arrays.) In either the klass or IHC subfield of the header, we might be able to get away with stating something like, ?if there 10 or more zeroes at the high end of the subfield, then the object is a value, and otherwise it?s not?. That would steal dynamic range from the subfield for values, but would leave the non-values unscathed (except for the responsibility to avoid that 1/1024 fraction of reserved encodings). For more details, please see: https://cr.openjdk.org/~jrose/jvm/joint-bit-encodings.html On 6 Mar 2024, at 7:20, Dan Heidinga wrote: > Values lack identity so it?s possible for them to be deduplicated (or even duplicated!) at any point when they are not in the larval state. That would mean we?d need the is_larval bit to be stable to any process (gc?) that may be responsible for (de)duplication. > > > > The other three bits shouldn?t be required during GC and can be re-derived from the klass metadata. From john.r.rose at oracle.com Sun Mar 10 05:06:01 2024 From: john.r.rose at oracle.com (John Rose) Date: Sat, 09 Mar 2024 21:06:01 -0800 Subject: Sharing the markword (aka Valhalla's markword use) In-Reply-To: References: Message-ID: On 5 Mar 2024, at 8:28, Thomas St?fe wrote: > Hi Dan, > > In addition to Roman's answer, we plan to reduce the Klasspointer to 22 bits [1]. For 64-bit headers, this would give us 31-bit i-hash back and still leave us with 4 unused bits. Thank you for making that clear. It looks like there are plenty of bits in the 64-bit header for Valhalla, so some of the tricky bit-twiddling suggested in my previous mail is not needed, unless (at some future date) we go to 32-bit headers. I?m going to make a wild guess that Valhalla is likely to come before 32-bit headers. IMO, the proposal about loading the prototype header bits out of the Klass metadata is still reasonable to consider, regardless of header size. From john.r.rose at oracle.com Sun Mar 10 05:53:25 2024 From: john.r.rose at oracle.com (John Rose) Date: Sat, 09 Mar 2024 21:53:25 -0800 Subject: Sharing the markword (aka Valhalla's markword use) In-Reply-To: <02B3277A-354B-46C1-B44E-018A4D973A4D@amazon.de> References: <3751A866-5B63-461F-8CA4-C8448004D367@amazon.de> <02B3277A-354B-46C1-B44E-018A4D973A4D@amazon.de> Message-ID: <4BA1192F-97F8-4857-9C13-2DEDDFD5E49B@oracle.com> On 6 Mar 2024, at 10:47, Kennke, Roman wrote: > I shall add that this is possible because we know at class-loading time whether or not we?re going to exceed the class-addressing-limit, and reserve the extra Klass* field at class-loading time, during field layout, and allocate all affected instances with that extra field right from the start, no stunts needed like with the compact I-hash stuff. (What follows is speculation oriented towards an indefinite future? Apologies in advance to Valhalla-dev for irrelevant stuff.) Yes, I think this could work. You could say that if the narrow-klass field is all-zero-bits, or if some separate mode bit is set, then we have to fish the full-klass field out from side storage somewhere in the object. It?s a new expanded mode of klass storage. Where is that side storage? Well, it can?t be a fixed location in the object, so there?s a gap in that design; just a mode bit or an all-zero-bits condition doesn?t help you. (Why not a fixed location, like offset=4? Because you might overflow the narrow-klass field?s encoding range, when loading a subclass of a class which already uses the desirable offset=4 slot for a regular instance field. You can get around this by using offset=-4, but that opens different cans of worms. Better to assume instance fields will compete for offsets with the injected full-klass field.) You might want to store the offset of the full-klass field in the narrow-klass field, and use your mode bit to decide which access mode to use. Hence 15 for the narrow-klass, plus 1 for the expansion mode bit. But, the joint bit encoding trick could be helpful here, to reduce the impact of the mode bit on header density. Use 16 bits for the narrow-klass field. Then, if the top 8 bits are nonzero, interpret the narrow-klass field as the identifier of one of the pre-eminent 65280 (2^16-2^8) klasses. If the top 8 bits are zero, the field encodes an offset to find the full-klass field. With a separate mode bit, you would only be able to represent 32768 distinct klasses in the narrow-klass field. This is a typical result for joint bit encodings. If the bottom 8 bits of the narrow-klass field are available to represent an offset (in the second mode), then the full-klass field can be anywhere in the instance as long as the instance size is at most 256 words. (Assume scaled access, or else say the limit is 256 bytes.) Surely if an instance is larger than that, we will know when we load the class into the VM, and before we allocate a klass ID. If the class is non-final there is a hazard of a subclass requiring a full-klass field. Thus, loading a non-final class of size 255 or larger requires the VM to allocate a full-klass field, whether it uses that field or not. But, that?s a 0.4% overhead in instance size, so it?s tolerable. The 0.4% parameter is a function of the number of bits (8) chosen for the joint bit encoding. (So don?t take the example too literally. It might not be 8 bits, and it might not be the actual top or bottom bits. If your CPU doesn?t have a good scaled-load instruction, maybe the zero bits you want are the bottom 3 and the top 5 of a 16-bit narrow-klass field. Making any such masked test is easy on all our CPUs. That?s why I think joint bit encodings can be interesting today.) However, it?s not clear to me whether the cost of a modal narrow-klass field is going to be bearable. We?ll have to measure it when the time comes. Testing one bit (or 8 bits) in an object header is one instruction, but it?s an extra instruction, and in general loading the klass of an instance will be a branchy operations with tiny klass fields, where it is not branchy today. That could be a problem. It will at least be a challenge to optimize. If the increased branchiness is a problem, the solution might well be to stay with the larger 64-bit headers. When we get there we can test. Different CPUs will give different results. Idea to reduce branchiness: Always load the full-klass pointer, let?s say a 64-bit pointer, from an effective address computed from the object and its header. The narrow-klass field ALWAYS, without branchiness, contributes the offset (scaled or not) to such a load. The mode bit and/or joint bits contribute the base address. The base address is a conditional-move instruction whose inputs are the current object and a constant base address where the first 65280 klasses are on display. This would push the modality into a single CMOV instruction, removing all branching, at the cost of an extra unconditional indirection. hdr = *(int *)obj; base0 = (Klass *)obj; base1 = Universe::narrow_klass_table(); //constant base = is_narrow_klass(hdr) ? base0 : base1; //CMOV offset = narrow_klass_field(hdr); klass = base[ offset ]; // look folks, no branches! Example optimization: If static type information in the JIT can prove that an object reference has no subclasses with non-narrow klass IDs, then the JIT can assume that the ?is_narrow_klass? query above is always true, and fold up the CMOV. Another example optimization: If I am doing some x instanceof C operation, and C is final, then I can compare the narrow-klass field of x against the narrow encoding of C, and take that as my final answer. It?s OK if the narrow-klass field is an expansion signal to look for the full-klass field; I don?t need to do that fetch to finish this particular operation. There may be several more techniques of this kind to remove branchiness from code that looks at object klasses. As I said before, all this kind of trickery is relevant mainly to 32-bit headers, not 64-bit headers. And 32-bit headers may well be in the future, relative to Valhalla. At that future point, little or none of my speculation at this point may apply. And yet I speculate, FTR. From david.holmes at oracle.com Mon Mar 11 01:22:31 2024 From: david.holmes at oracle.com (David Holmes) Date: Mon, 11 Mar 2024 11:22:31 +1000 Subject: Sharing the markword (aka Valhalla's markword use) In-Reply-To: References: Message-ID: <442947d3-6257-46f0-9354-30c1a7877854@oracle.com> On 10/03/2024 1:38 pm, John Rose wrote: > What Dan said. Here?s more color commentary: > I suggest adding, to Klass itself, a field which is a prototype > header for the object, with all the right bits in place ... > (I thought we already had something like this somewhere, but > a quick check came up empty?) We used to have the biased-locking prototype header. klass.hpp // Biased locking support // Note: the prototype header is always set up to be at least the // prototype markOop. If biased locking is enabled it may further be // biasable and have an epoch. markOop prototype_header() const { return _prototype_header; } Cheers, David From thomas.stuefe at gmail.com Mon Mar 11 08:55:24 2024 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 11 Mar 2024 09:55:24 +0100 Subject: Sharing the markword (aka Valhalla's markword use) In-Reply-To: <442947d3-6257-46f0-9354-30c1a7877854@oracle.com> References: <442947d3-6257-46f0-9354-30c1a7877854@oracle.com> Message-ID: In Lilliput, the prototype header contains the nKlass ID. Cheers, Thomas On Mon, Mar 11, 2024 at 2:23?AM David Holmes wrote: > On 10/03/2024 1:38 pm, John Rose wrote: > > What Dan said. Here?s more color commentary: > > > I suggest adding, to Klass itself, a field which is a prototype > > header for the object, with all the right bits in place ... > > (I thought we already had something like this somewhere, but > > a quick check came up empty?) > > We used to have the biased-locking prototype header. > > klass.hpp > // Biased locking support > // Note: the prototype header is always set up to be at least the > // prototype markOop. If biased locking is enabled it may further be > // biasable and have an epoch. > markOop prototype_header() const { return _prototype_header; } > > Cheers, > David > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rkennke at amazon.de Mon Mar 11 12:41:16 2024 From: rkennke at amazon.de (Kennke, Roman) Date: Mon, 11 Mar 2024 12:41:16 +0000 Subject: Sharing the markword (aka Valhalla's markword use) In-Reply-To: References: Message-ID: <647B95C3-385F-4698-8867-3D0629896CBE@amazon.de> Hi John, > The larval state of a value object can be viewed as an analog of the locked state of an identity object. In both cases, one specific thread is doing something exclusive to the object. For values, this larval state is indeed highly exclusive: The thread that made the value object is also filling in its fields, protected either by the verifier (if it is constructor code) or by some other means (if the fields are being set by privileged non-constructor code). Unlike a locked identity object, once a value exits the larval state, it is forever an adult; an identity object can be relocked many times. > > All that said, the lifecycles are different, but they are similar enough that we can envision using some of the same bit-patterns in parallel. I am pretty sure that whatever locked state indicator (a bit pattern) that we invent for the object header of an identity object is more than adequate for a value object in its larval state. > > So, just have each GC process larvae very much like locked objects, and arrange the header bit patterns to make this easy, by making them be similar. Can value objects be locked? If not, could value objects use the same bits that are used for locking of identity objects? Other than that, it should be easy to preserve larvae bit across GC, pretty much like lock-bits. > And, as an aside, in the future the GC or JIT may perform deduplication (or, say, NUMA-sensitive duplication) of values, or any other reorganization that reassigns varying pointers which alias equivalent copies of the same value state. In such a case, please be sure to treat every larval value object as unique and never aliased to any other value object, however similar. A larval value is likely to be side-effected to a new state before it becomes adult, which would cause bad failures if it were accidentally treated as aliased to some unrelated value. Only adult values are legitimate subjects for alias-based optimizations, whether in the JIT or GC. Ok, that is good to know. > Regarding the other bits (is-value, is-flat-array, is-null-free-array), those can all be re-hoisted from the Klass object, if for some reason the header needs to be restored or reset. After all, those bits are just optimized copies (hoisted into a convenient place in the header), copied from the original information in the Klass object itself. This hoisting is a performance hack. We are discussing it at length here because the Valhalla team has determined, at least provisionally, that acceptable product performance requires such a ?hoisting hack?. That is also very good to know. It means we don?t have to preserve those bits across GCs or other destructive ops, and can always restore them. Makes life easier. > I suggest adding, to Klass itself, a field which is a prototype header for the object, with all the right bits in place. In Lilliput we already have that field, for the Klass-pointer (pretty much restored from the earlier prototype for biased locking). We can add more info bits to that prototype header. > The GC can use that as a starting point when repairing headers that it had to reset. (I thought we already had something like this somewhere, but a quick check came up empty?) Currently, it appears we reset object headers from markWord::prototype which is an absolute constant. Perhaps this function should be refactored to a query to non-static Klass::prototype_mark_word. That?s just my $0.02; probably stuff like this has been discussed several times. Yup, no problem with that. > A final suggestion, which I?ve mentioned elsewhere, but it?s worth repeating: If we don?t choose to burn whole a bit on the is-value test, we can use a joint bit encoding. (Similar point for an is-array test, in fact, or for particular subkinds of arrays.) In either the klass or IHC subfield of the header, we might be able to get away with stating something like, ?if there 10 or more zeroes at the high end of the subfield, then the object is a value, and otherwise it?s not?. That would steal dynamic range from the subfield for values, but would leave the non-values unscathed (except for the responsibility to avoid that 1/1024 fraction of reserved encodings). For more details, please see: https://cr.openjdk.org/~jrose/jvm/joint-bit-encodings.html Nice, that might be useful. Thanks! 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 rkennke at amazon.de Mon Mar 11 12:58:34 2024 From: rkennke at amazon.de (Kennke, Roman) Date: Mon, 11 Mar 2024 12:58:34 +0000 Subject: Sharing the markword (aka Valhalla's markword use) In-Reply-To: <4BA1192F-97F8-4857-9C13-2DEDDFD5E49B@oracle.com> References: <3751A866-5B63-461F-8CA4-C8448004D367@amazon.de> <02B3277A-354B-46C1-B44E-018A4D973A4D@amazon.de> <4BA1192F-97F8-4857-9C13-2DEDDFD5E49B@oracle.com> Message-ID: <5EF45CD6-ABC1-42F3-9212-4260C362FCE0@amazon.de> > > (What follows is speculation oriented towards an indefinite future? Apologies in advance to Valhalla-dev for irrelevant stuff.) > I removed valhalla-dev from this this thread. > Yes, I think this could work. You could say that if the narrow-klass field is all-zero-bits, or if some separate mode bit is set, then we have to fish the full-klass field out from side storage somewhere in the object. It?s a new expanded mode of klass storage. > > Where is that side storage? Well, it can?t be a fixed location in the object, so there?s a gap in that design; just a mode bit or an all-zero-bits condition doesn?t help you. > Quite the opposite, I think. It *has* to be a fixed offset. Why? Because if it depends on the field layout, then we?d have to find that first, and we can only find it only via the Klass. > (Why not a fixed location, like offset=4? Because you might overflow the narrow-klass field?s encoding range, when loading a subclass of a class which already uses the desirable offset=4 slot for a regular instance field. You can get around this by using offset=-4, but that opens different cans of worms. Better to assume instance fields will compete for offsets with the injected full-klass field.) I don?t think it?s a problem. Either we agree that narrow-32-encoding range is enough, then we can put it at 4, or, if we *really* think we?d need the whole 64 range, then we stick it at offset 8. Since we know all this at class-loading-time, we can lay out the fields around this. Putting at 4 seems preferable because of smaller chance of gap and higher chance to save more memory, but I don?t think it matters all that much. This way, we can use all-zeroes to indicate ?look for Klass* elsewhere, and not spend an extra bit for the special case (that is a neat idea!). Unless I am missing something. > However, it?s not clear to me whether the cost of a modal narrow-klass field is going to be bearable. I don?t think it is a problem. Current Lilliput already tests the header bits, and branches when the object is monitor-locked. That cost is not measurable (need to make sure that the test-and-branch is laid out in a way that does not mess up static branch prediction, but that is easy, using stubs). The monitor-test will go away, but we can have an all-zeroes check in that same place. Handling the all-zeroes case would be slightly more costly, but not much, if we can use a fixed offset. > We?ll have to measure it when the time comes. Testing one bit (or 8 bits) in an object header is one instruction, but it?s an extra instruction, and in general loading the klass of an instance will be a branchy operations with tiny klass fields, where it is not branchy today. That could be a problem. It will at least be a challenge to optimize. If the increased branchiness is a problem, the solution might well be to stay with the larger 64-bit headers. When we get there we can test. Different CPUs will give different results. > > Idea to reduce branchiness: Always load the full-klass pointer, let?s say a 64-bit pointer, from an effective address computed from the object and its header. The narrow-klass field ALWAYS, without branchiness, contributes the offset (scaled or not) to such a load. The mode bit and/or joint bits contribute the base address. The base address is a conditional-move instruction whose inputs are the current object and a constant base address where the first 65280 klasses are on display. This would push the modality into a single CMOV instruction, removing all branching, at the cost of an extra unconditional indirection. > > hdr = *(int *)obj; > base0 = (Klass *)obj; > base1 = Universe::narrow_klass_table(); //constant > base = is_narrow_klass(hdr) ? base0 : base1; //CMOV > offset = narrow_klass_field(hdr); > klass = base[ offset ]; // look folks, no branches! > > Example optimization: If static type information in the JIT can prove that an object reference has no subclasses with non-narrow klass IDs, then the JIT can assume that the ?is_narrow_klass? query above is always true, and fold up the CMOV. > > Another example optimization: If I am doing some x instanceof C operation, and C is final, then I can compare the narrow-klass field of x against the narrow encoding of C, and take that as my final answer. It?s OK if the narrow-klass field is an expansion signal to look for the full-klass field; I don?t need to do that fetch to finish this particular operation. There may be several more techniques of this kind to remove branchiness from code that looks at object klasses. > > As I said before, all this kind of trickery is relevant mainly to 32-bit headers, not 64-bit headers. And 32-bit headers may well be in the future, relative to Valhalla. At that future point, little or none of my speculation at this point may apply. And yet I speculate, FTR. Let?s keep all of that in mind (or better yet, the wiki ;-) ) Thanks for all your suggestions and clarifications, that?s all very useful. 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 rkennke at amazon.de Mon Mar 11 14:23:19 2024 From: rkennke at amazon.de (Kennke, Roman) Date: Mon, 11 Mar 2024 14:23:19 +0000 Subject: Sharing the markword (aka Valhalla's markword use) In-Reply-To: <4BA1192F-97F8-4857-9C13-2DEDDFD5E49B@oracle.com> References: <3751A866-5B63-461F-8CA4-C8448004D367@amazon.de> <02B3277A-354B-46C1-B44E-018A4D973A4D@amazon.de> <4BA1192F-97F8-4857-9C13-2DEDDFD5E49B@oracle.com> Message-ID: <6B9E47EA-CEE0-46F0-9EC1-39894E938113@amazon.de> > (Why not a fixed location, like offset=4? Because you might overflow the narrow-klass field?s encoding range, when loading a subclass of a class which already uses the desirable offset=4 slot for a regular instance field. You can get around this by using offset=-4, but that opens different cans of worms. Better to assume instance fields will compete for offsets with the injected full-klass field.) Ah I just carefully re-read this. You are right, this would be a problem, indeed. Very good point. I also like the joint-bit encoding. However, we?d have to ensure that the relevant mode bit-pattern (e.g. upper 8 bits zero) would not happen in normal encoding. Currently, I think this is in-fact a very common situation. 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 john.r.rose at oracle.com Mon Mar 11 17:25:18 2024 From: john.r.rose at oracle.com (John Rose) Date: Mon, 11 Mar 2024 10:25:18 -0700 Subject: Sharing the markword (aka Valhalla's markword use) In-Reply-To: References: <442947d3-6257-46f0-9354-30c1a7877854@oracle.com> Message-ID: <574A5F2B-CB68-4163-AA89-3D4B9FC84F67@oracle.com> Thanks, David; I wondered when Klass::prototype_header came and went. Thomas, a peek at klass.hpp shows that Klass::prototype_header has returned to us in Lilliput, with helpers like oopDesc::init_mark. Nice. That looks like a good way to manage Valhalla?s new hoisted metadata bits as well as other header bits. On 11 Mar 2024, at 1:55, Thomas St?fe wrote: > In Lilliput, the prototype header contains the nKlass ID. > > Cheers, Thomas > > On Mon, Mar 11, 2024 at 2:23?AM David Holmes > > wrote: > >> On 10/03/2024 1:38 pm, John Rose wrote: >>> What Dan said. Here?s more color commentary: >> >>> I suggest adding, to Klass itself, a field which is a prototype >>> header for the object, with all the right bits in place ... >>> (I thought we already had something like this somewhere, but >>> a quick check came up empty?) >> >> We used to have the biased-locking prototype header. >> >> klass.hpp >> // Biased locking support >> // Note: the prototype header is always set up to be at least the >> // prototype markOop. If biased locking is enabled it may further >> be >> // biasable and have an epoch. >> markOop prototype_header() const { return _prototype_header; >> } >> >> Cheers, >> David >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.r.rose at oracle.com Mon Mar 11 19:49:46 2024 From: john.r.rose at oracle.com (John Rose) Date: Mon, 11 Mar 2024 12:49:46 -0700 Subject: Sharing the markword (aka Valhalla's markword use) In-Reply-To: <6B9E47EA-CEE0-46F0-9EC1-39894E938113@amazon.de> References: <3751A866-5B63-461F-8CA4-C8448004D367@amazon.de> <02B3277A-354B-46C1-B44E-018A4D973A4D@amazon.de> <4BA1192F-97F8-4857-9C13-2DEDDFD5E49B@oracle.com> <6B9E47EA-CEE0-46F0-9EC1-39894E938113@amazon.de> Message-ID: <23526D2E-D289-4B30-88FB-9C48642467C9@oracle.com> On 11 Mar 2024, at 7:23, Kennke, Roman wrote: >> (Why not a fixed location, like offset=4? Because you might overflow the narrow-klass field?s encoding range, when loading a subclass of a class which already uses the desirable offset=4 slot for a regular instance field. You can get around this by using offset=-4, but that opens different cans of worms. Better to assume instance fields will compete for offsets with the injected full-klass field.) > > Ah I just carefully re-read this. You are right, this would be a problem, indeed. Very good point. I also like the joint-bit encoding. However, we?d have to ensure that the relevant mode bit-pattern (e.g. upper 8 bits zero) would not happen in normal encoding. Currently, I think this is in-fact a very common situation. Yes, it would be common (1/2^N probability for N joint bits) unless there is a specific filter applied by whatever library is responsible for allocating those bit encodings. But if there is a single factory for those codes, the factory can be adjusted to skip the codes reserved by the joint-bit-encoding for other uses. If it?s a storage allocator, there will be (a very small bit of) fragmentation loss because of the unusable addresses. From john.r.rose at oracle.com Mon Mar 11 20:01:36 2024 From: john.r.rose at oracle.com (John Rose) Date: Mon, 11 Mar 2024 13:01:36 -0700 Subject: Sharing the markword (aka Valhalla's markword use) In-Reply-To: <5EF45CD6-ABC1-42F3-9212-4260C362FCE0@amazon.de> References: <3751A866-5B63-461F-8CA4-C8448004D367@amazon.de> <02B3277A-354B-46C1-B44E-018A4D973A4D@amazon.de> <4BA1192F-97F8-4857-9C13-2DEDDFD5E49B@oracle.com> <5EF45CD6-ABC1-42F3-9212-4260C362FCE0@amazon.de> Message-ID: On 11 Mar 2024, at 5:58, Kennke, Roman wrote: >> ? >> However, it?s not clear to me whether the cost of a modal narrow-klass field is going to be bearable. > > I don?t think it is a problem. Current Lilliput already tests the header bits, and branches when the object is monitor-locked. That cost is not measurable (need to make sure that the test-and-branch is laid out in a way that does not mess up static branch prediction, but that is easy, using stubs). The monitor-test will go away, but we can have an all-zeroes check in that same place. Handling the all-zeroes case would be slightly more costly, but not much, if we can use a fixed offset. The key principle here is probably that there should be a slow path which is rare and easy to test. That slow path (actually two distinct slow paths) would handle the locked state we have today and could handle the case of an ?inflated klass? tomorrow. (I just thought of the term ?inflated klass?; maybe that has legs.) Optimizations based on rare slow paths are a foundational concept in HotSpot, so they are something we know how to manage. There is a second principle related to slow paths. If you have two rare conditions, you should at least try to detect them in a common test. Why? Because for every different slow-path conditional test, your fast path gets a little slower, since it has to work through all of the slow-path tests before it can get on with the fast path. first_fast_and_slow_accessor() { if (fast_path_works()) return inline_first_fast_path_accessor(); // slow path return first_slow_path_accessor(); } second_fast_and_slow_accessor() { if (fast_path_works()) return inline_second_fast_path_accessor(); // slow path return second_slow_path_accessor(); } In the above sketch, one fast path condition bit protects two slow paths. If both accessors are used in C++ or JIT code, the compiler can hoist the one fast-path expression. Same point for hand-written assembly. The point also applies if there is a common ?get real header? operation that factors out of both accessors, which might be the case here. So? If the inflated klass condition and the locked condition are both slow paths, it suggests that some LOCK BIT might play a central part in the combined optimization story. > ? > Thanks for all your suggestions and clarifications, that?s all very useful. You are welcome; I enjoy this sort of thing and am very glad it is sometimes useful. From john.r.rose at oracle.com Mon Mar 11 20:11:37 2024 From: john.r.rose at oracle.com (John Rose) Date: Mon, 11 Mar 2024 13:11:37 -0700 Subject: Sharing the markword (aka Valhalla's markword use) In-Reply-To: <647B95C3-385F-4698-8867-3D0629896CBE@amazon.de> References: <647B95C3-385F-4698-8867-3D0629896CBE@amazon.de> Message-ID: On 11 Mar 2024, at 5:41, Kennke, Roman wrote: > > Can value objects be locked? If not, could value objects use the same bits that are used for locking of identity objects? Fair question. NO, a larval object is never visible outside the thread which created it, so there is no need to lock. The blanket rule is that value objects (in larval or adult state) are NEVER locked, and the JVM can throw an exception if somebody tries to lock one. (There are minor exceptions to the rule about visibility of larvae, but they don?t relate to locking. The GC needs to look at larvae from its worker threads. So the GC might needs to distinguish the states with care. But of course the GC doesn?t perform object locking. A debugger might ask JVMTI to peek inside a thread, and might even try to call a toString method on objects it sees in there. We will need some special-casing there to prevent larvae from escaping by that route.) > Other than that, it should be easy to preserve larvae bit across GC, pretty much like lock-bits. That would be perfect, IMO. And if the GC ever does identity-shifting optimizations on values, it can consult those saved larval-bits to get the optimizations. Full disclosure: The GC does NOT do such things today, AFAIK. The JIT?s deoptimization logic DOES create new value identities from debug info, when non-allocated objects must be allocated along slow paths. In that case, the larval bit might be significant even today. In any case, good JVM architecture not only supports the optimizations we do today, but anticipates a reasonable range of future optimizations. Designing such a ?future-proof? architecture is inherently difficult and fallible, but IMO it has been one of Java?s distinctive strengths. For the other points, it looks like we are on the same page. Thanks for the responses, Roman. From john.r.rose at oracle.com Mon Mar 11 20:57:59 2024 From: john.r.rose at oracle.com (John Rose) Date: Mon, 11 Mar 2024 13:57:59 -0700 Subject: 32 bits header and alignment slack In-Reply-To: References: <77699604.19300095.1709375128835.JavaMail.zimbra@univ-eiffel.fr> <17C905C3-649E-488C-A478-863C1C7F7E52@amazon.de> <1249027529.20510860.1709556761626.JavaMail.zimbra@univ-eiffel.fr> Message-ID: On 4 Mar 2024, at 5:10, Kennke, Roman wrote: >> ? Thinking a little more about it. >> The aligment gap is not necessary at the end of the object, a j.l.Long with a 32 bits header has a 32 bits gap in between the mark/class word and the field containing the value. > > This is a very good point, and a nice improvement! And should not be very difficult to implement, either. > > Thanks for suggesting that! This is starting to feel a little like the parallel task for hunting around for a good place to put the ?inflated klass? field (if we ever do such a thing). The ?inflated identity hash? field is different, since it is optional. As an optional thing, it wants to go at the end of the object with a size increase. (Or before the beginning, yuck.) And then placing that field in a fragmentation-loss space is a win, since there?s no size increase. BUT ALSO, if the object is large enough, preallocating an injected ?inflated identity hash? field is just as good, within some epsilon. (So that?s the suggestion that comes from comparing the problem with the problem of inflated klass fields.) What epsilon, exactly? Well, that?s a configuration parameter to the VM. The larger the minimum object size (for preallocated IHC), the smaller the epsilon. The meaningful scale here is a few cache lines. Given all of the above, an object might have two possible layouts, IF it is (a) small and (b) already tightly packed. But other objects would have just one layout, a layout which includes an inflated-IHC field. A bit in the Klass would say whether its objects have (in fact) two layouts. A bit in the header would select the second layout, if relevant. Bonus Leyden tactic: If a training run shows that some classes have frequent uses of IHCs, then a CDS archive could mention that fact, and the JVM could inject IHC fields even if they would otherwise be classified as too small and too dense. Do preallocated IHC fields really matter, do they justify their static cost? Yes, they might matter if IHC codes are important for some classes in some workload. In that case, the clever derivation of IHC from new-space pointers would be less of a bottleneck. After all, if ask an object 3 times for its IHC, and the derivation cost is X, you pay 3X instead of X plus two cache reads. And X is probably somewhat greater than a cache read, especially if it creates a strong result. BTW, the ?clever derivation? should be more clever than just adding the VA of the object into some salt. (You read read salt from a cache, so it?s still at least as expensive than a cache read of the finished result.) Weak IHCs are something we try to avoid in HotSpot. I recommend at least a multiply or two to mix salt with VA, with non-linear operations like XOR or variable ROR. An object with a preallocated IHC field would perform the mixing once, making the tradeoffs easier. And FTR, I have been experimenting with some strong mixing algorithms that run in about a nanosecond but produce results that pass RNG stress tests. They can also be progressively detuned to trade strength for speed. One such hash is used in this experiment: https://github.com/openjdk/jdk/commit/aff6e45224e3241fd22321a8effb760ebe388bc0#diff-0a958b47af7932e08b14e833e8daa3a2c2b23db33c02effab4422f1ddcd82a97 There are others in the literature as well. My main point there would be, let?s use something better than, ?oh, I think I?ll XOR the high 15 bits now?? or ?let?s see what Objects::hash does?? Today?s hardware multipliers change the game significantly, relative to such 1980?s techniques. From rkennke at openjdk.org Wed Mar 20 12:41:23 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Wed, 20 Mar 2024 12:41:23 GMT Subject: [lilliput-jdk21u:lilliput] RFR: Merge jdk21u:jdk-21.0.3+7 Message-ID: Let's merge the tag jdk-21.0.3+7. ------------- Commit messages: - Merge tag 'jdk-21.0.3+7' into merge-jdk-21.0.3+7 - 8327391: Add SipHash attribution file - 8322750: Test "api/java_awt/interactive/SystemTrayTests.html" failed because A blue ball icon is added outside of the system tray - 8323664: java/awt/font/JNICheck/FreeTypeScalerJNICheck.java still fails with JNI warning on some Windows configurations - 8325496: Make TrimNativeHeapInterval a product switch - 8321151: JDK-8294427 breaks Windows L&F on all older Windows versions - 8325876: crashes in docker container tests on Linuxppc64le Power8 machines - 8325470: [AIX] use fclose after fopen in read_psinfo - 8320303: Allow PassFailJFrame to accept single window creator - 8326000: Remove obsolete comments for class sun.security.ssl.SunJSSE - ... and 559 more: https://git.openjdk.org/lilliput-jdk21u/compare/e3adaa5b...5eadae09 The webrevs contain the adjustments done while merging with regards to each parent branch: - lilliput: https://webrevs.openjdk.org/?repo=lilliput-jdk21u&pr=17&range=00.0 - jdk21u:jdk-21.0.3+7: https://webrevs.openjdk.org/?repo=lilliput-jdk21u&pr=17&range=00.1 Changes: https://git.openjdk.org/lilliput-jdk21u/pull/17/files Stats: 79715 lines in 2383 files changed: 42913 ins; 20667 del; 16135 mod Patch: https://git.openjdk.org/lilliput-jdk21u/pull/17.diff Fetch: git fetch https://git.openjdk.org/lilliput-jdk21u.git pull/17/head:pull/17 PR: https://git.openjdk.org/lilliput-jdk21u/pull/17 From rkennke at openjdk.org Wed Mar 20 17:40:59 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Wed, 20 Mar 2024 17:40:59 GMT Subject: [lilliput-jdk21u:lilliput] RFR: Merge jdk21u:jdk-21.0.3+7 In-Reply-To: References: Message-ID: On Wed, 20 Mar 2024 12:36:14 GMT, Roman Kennke wrote: > Let's merge the tag jdk-21.0.3+7. GHA failure looks unrelated. ------------- PR Comment: https://git.openjdk.org/lilliput-jdk21u/pull/17#issuecomment-2010197710 From rkennke at openjdk.org Wed Mar 20 18:19:27 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Wed, 20 Mar 2024 18:19:27 GMT Subject: [lilliput-jdk21u:lilliput] RFR: Merge jdk21u:jdk-21.0.3+7 [v2] In-Reply-To: References: Message-ID: > Let's merge the tag jdk-21.0.3+7. Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits: - Merge tag 'jdk-21.0.3+7' into merge-jdk-21.0.3+7 Added tag jdk-21.0.3+7 for changeset 07fc624683c5 - 8321134: [Lilliput/JDK21] Fix repo permissions Reviewed-by: shade - Merge - 8319724: [Lilliput] ParallelGC: Forwarded objects found during heap inspection Backport-of: 0568386e062474b1fc31e2e7106db0079ded7d76 - 8319524: [Lilliput] Only warn when compact headers are explicitly enabled Backport-of: 3f73f014097262455cc42a71c32af374b77b6efd - 8319135: [Lilliput] Fix objArrayOop gtest Backport-of: fc9020fbf193b1c6d2b2fb5d80192c3082dbcf2e - 8319163: [Lilliput/JDK21] Fix arrayOopDesc gtest Reviewed-by: shade - 8317954: [Lilliput/JDK21] Make C2 LoadNKlassCompactHeader more robust Reviewed-by: shade - 8316687: [Lilliput/JDK21] Various cleanups Reviewed-by: shade - 8316442: [Lilliput/JDK21] Problem-list compiler/ciReplay tests Reviewed-by: shade - ... and 7 more: https://git.openjdk.org/lilliput-jdk21u/compare/07fc6246...5eadae09 ------------- Changes: https://git.openjdk.org/lilliput-jdk21u/pull/17/files Webrev: https://webrevs.openjdk.org/?repo=lilliput-jdk21u&pr=17&range=01 Stats: 3348 lines in 162 files changed: 2797 ins; 186 del; 365 mod Patch: https://git.openjdk.org/lilliput-jdk21u/pull/17.diff Fetch: git fetch https://git.openjdk.org/lilliput-jdk21u.git pull/17/head:pull/17 PR: https://git.openjdk.org/lilliput-jdk21u/pull/17 From rkennke at openjdk.org Wed Mar 20 18:19:29 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Wed, 20 Mar 2024 18:19:29 GMT Subject: [lilliput-jdk21u:lilliput] Integrated: Merge jdk21u:jdk-21.0.3+7 In-Reply-To: References: Message-ID: On Wed, 20 Mar 2024 12:36:14 GMT, Roman Kennke wrote: > Let's merge the tag jdk-21.0.3+7. This pull request has now been integrated. Changeset: 5ae2e0e0 Author: Roman Kennke URL: https://git.openjdk.org/lilliput-jdk21u/commit/5ae2e0e057664c3c8e8854a0866e22c31e579f11 Stats: 79715 lines in 2383 files changed: 42913 ins; 20667 del; 16135 mod Merge ------------- PR: https://git.openjdk.org/lilliput-jdk21u/pull/17 From rkennke at openjdk.org Mon Mar 25 14:09:15 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 25 Mar 2024 14:09:15 GMT Subject: [lilliput-jdk21u:lilliput] RFR: 8317452: [JVMCI] Export symbols used by lightweight locking to JVMCI compilers. Message-ID: <98P8AV3e9tGhKMRaAEqP_pC2cm8yUqm0IpeMwiZeebU=.f2f27b2d-0f69-4971-baf6-5144a54143ba@github.com> Hi all, This pull request contains a backport of commit [9718f490](https://github.com/openjdk/jdk/commit/9718f490fb76f6712ac8f9c7f5248ca10bf83e6f) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was authored by Yudi Zheng on 4 Oct 2023 and was reviewed by Doug Simon. The original change has not applied cleanly due to minor context changes. Thanks! ------------- Commit messages: - Backport 9718f490fb76f6712ac8f9c7f5248ca10bf83e6f Changes: https://git.openjdk.org/lilliput-jdk21u/pull/18/files Webrev: https://webrevs.openjdk.org/?repo=lilliput-jdk21u&pr=18&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8317452 Stats: 16 lines in 5 files changed: 11 ins; 5 del; 0 mod Patch: https://git.openjdk.org/lilliput-jdk21u/pull/18.diff Fetch: git fetch https://git.openjdk.org/lilliput-jdk21u.git pull/18/head:pull/18 PR: https://git.openjdk.org/lilliput-jdk21u/pull/18 From stuefe at openjdk.org Mon Mar 25 14:18:52 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 25 Mar 2024 14:18:52 GMT Subject: [master] RFR: JDK-8325104: Lilliput: Shrink Classpointers [v2] In-Reply-To: References: <5Hg3aWe6cymqJix7XUhQeSrbqWYsGpICXCNQPtsEzRc=.ab9bd02b-afdb-4ac8-acd1-c92e363f79ee@github.com> Message-ID: On Sat, 10 Feb 2024 10:56:19 GMT, Thomas Stuefe wrote: >> make/Images.gmk line 196: >> >>> 194: ) >>> 195: endif >>> 196: endif >> >> Is creating the COH archives necessary for this change to work or work well? If not, I would suggest to make this a separate change or a prerequisite change. > > It is necessary for some of the tests. I guess I could make it a prerequisite, but that would not work for the mainline version of this patch, since that one still lacks UseCOH. What would be the advantage of making this a separate change? Okay, I'll split out the COH archive changes. ------------- PR Review Comment: https://git.openjdk.org/lilliput/pull/128#discussion_r1537669886 From shade at openjdk.org Mon Mar 25 14:32:53 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 25 Mar 2024 14:32:53 GMT Subject: [lilliput-jdk21u:lilliput] RFR: 8317452: [JVMCI] Export symbols used by lightweight locking to JVMCI compilers. In-Reply-To: <98P8AV3e9tGhKMRaAEqP_pC2cm8yUqm0IpeMwiZeebU=.f2f27b2d-0f69-4971-baf6-5144a54143ba@github.com> References: <98P8AV3e9tGhKMRaAEqP_pC2cm8yUqm0IpeMwiZeebU=.f2f27b2d-0f69-4971-baf6-5144a54143ba@github.com> Message-ID: On Mon, 25 Mar 2024 14:02:46 GMT, Roman Kennke wrote: > Hi all, > > This pull request contains a backport of commit [9718f490](https://github.com/openjdk/jdk/commit/9718f490fb76f6712ac8f9c7f5248ca10bf83e6f) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Yudi Zheng on 4 Oct 2023 and was reviewed by Doug Simon. > > The original change has not applied cleanly due to minor context changes. > > Thanks! Marked as reviewed by shade (Committer). ------------- PR Review: https://git.openjdk.org/lilliput-jdk21u/pull/18#pullrequestreview-1957909171 From rkennke at openjdk.org Mon Mar 25 14:39:53 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 25 Mar 2024 14:39:53 GMT Subject: [lilliput-jdk21u:lilliput] Integrated: 8317452: [JVMCI] Export symbols used by lightweight locking to JVMCI compilers. In-Reply-To: <98P8AV3e9tGhKMRaAEqP_pC2cm8yUqm0IpeMwiZeebU=.f2f27b2d-0f69-4971-baf6-5144a54143ba@github.com> References: <98P8AV3e9tGhKMRaAEqP_pC2cm8yUqm0IpeMwiZeebU=.f2f27b2d-0f69-4971-baf6-5144a54143ba@github.com> Message-ID: On Mon, 25 Mar 2024 14:02:46 GMT, Roman Kennke wrote: > Hi all, > > This pull request contains a backport of commit [9718f490](https://github.com/openjdk/jdk/commit/9718f490fb76f6712ac8f9c7f5248ca10bf83e6f) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Yudi Zheng on 4 Oct 2023 and was reviewed by Doug Simon. > > The original change has not applied cleanly due to minor context changes. > > Thanks! This pull request has now been integrated. Changeset: 6799201f Author: Roman Kennke URL: https://git.openjdk.org/lilliput-jdk21u/commit/6799201fb707627d8d768a4bb8db36e6f044dcf3 Stats: 16 lines in 5 files changed: 11 ins; 5 del; 0 mod 8317452: [JVMCI] Export symbols used by lightweight locking to JVMCI compilers. Reviewed-by: shade Backport-of: 9718f490fb76f6712ac8f9c7f5248ca10bf83e6f ------------- PR: https://git.openjdk.org/lilliput-jdk21u/pull/18 From stuefe at openjdk.org Mon Mar 25 14:51:14 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 25 Mar 2024 14:51:14 GMT Subject: [master] RFR: JDK-8325104: Lilliput: Shrink Classpointers [v3] In-Reply-To: References: Message-ID: > Hi, > > I wanted to get input on the following improvement for Lilliput. Testing is still ongoing, but things look really good, so this patch is hopefully near its final form (barring any objections from reviewers, of course). > > Note: I have a companion patch prepared for upstream, minus the markword changes. I will attempt to get that one upstream quickly in order to not have a large delta between upstream and lilliput, especially in Metaspace. > > ## High-Level Overview > > (for a short sequence of slides, please see https://github.com/tstuefe/fosdem24/blob/master/classpointers-and-liliput.pdf - these accompanied a talk we held at FOSDEM 24). > > We want to reduce the bit size of narrow Klass to free up bits in the MarkWord. > > We cannot just reduce the Klass encoding range size (well, we could, and maybe we will later, but for now we decided not to). We instead increase the alignment Klass is stored at, and use that alignment shadow to store other information. > > In other words, this patch changes the narrow Klass Pointer to a Klass ID, since now (almost) every value in its value range points to a different class. Therefore, we use the value range of nKlass much more efficiently. > > We then use the newly freed bits in the MarkWord to restore the iHash to 31 bits: > > > [ 22-bit nKlass | 31-bit iHash | 4 free bits | age | fwd | lck ] > > nKlass gets reduced to 22 bits. Identity hash gets re-inflated to 31 bits. Preceding iHash are now 4 unused bits. Rest is unchanged. > > (Note: I originally wanted to swap iHash and nKlass such that either of them could be loaded with a 32-bit load, but I found that tricky since C2 seems to rely on the nKlass offset in the Markword being > 0.) > > ## nKlass reduction: > > The reduction in nKlass size is made by only storing them at 10-bit aligned addresses. That alignment (1KB) works well in practice since Klass - although var sized - typically is between 512 bytes and 1KB in size. Outliers are possible, but the size distribution is bell-curvish [1], so far-away outliers are very rare. > > To not lose memory to alignment waste, metaspace is reshaped to handle arbitrarily aligned allocations efficiently. Basically, we allow the non-Klass arena of a class loader to steal the alignment waste storage from the class arena. So, alignment waste blocks are filled with non-Klass metadata. That works very well in practice since non-Klass metadata is numerous and fine-granular compared to the big Klass blocks. Total footprint loss in metaspace is, therefore, almost ... Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: - Roman feedback - small stuff - Merge branch 'master' into Smaller-ClassPointers - revert COH archive generation - Remove files that accidentally slipped in - Merge branch 'master' into Smaller-ClassPointers - Merge - Merge commit 'c1281e6b45ed167df69d29a6039d81854c145ae6~1' into Smaller-ClassPointers - Fix Typo - Better CDS arch generation - Fix error in COH archive generation - ... and 10 more: https://git.openjdk.org/lilliput/compare/b2fcfb73...1260f2d6 ------------- Changes: https://git.openjdk.org/lilliput/pull/128/files Webrev: https://webrevs.openjdk.org/?repo=lilliput&pr=128&range=02 Stats: 2531 lines in 72 files changed: 1767 ins; 414 del; 350 mod Patch: https://git.openjdk.org/lilliput/pull/128.diff Fetch: git fetch https://git.openjdk.org/lilliput.git pull/128/head:pull/128 PR: https://git.openjdk.org/lilliput/pull/128 From rkennke at openjdk.org Mon Mar 25 14:54:12 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 25 Mar 2024 14:54:12 GMT Subject: [lilliput-jdk21u:lilliput] RFR: 8318015: Lock inflation not needed for OSR or Deopt for new locking modes Message-ID: Hi all, This pull request contains a backport of commit [d0ea2a51](https://github.com/openjdk/jdk/commit/d0ea2a51111bd5de5a6465e7de6a4950aae89c71) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was authored by Martin Doerr on 17 Oct 2023 and was reviewed by Patricio Chilano Mateo and Dean Long. Thanks! ------------- Commit messages: - Backport d0ea2a51111bd5de5a6465e7de6a4950aae89c71 Changes: https://git.openjdk.org/lilliput-jdk21u/pull/19/files Webrev: https://webrevs.openjdk.org/?repo=lilliput-jdk21u&pr=19&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8318015 Stats: 40 lines in 3 files changed: 16 ins; 0 del; 24 mod Patch: https://git.openjdk.org/lilliput-jdk21u/pull/19.diff Fetch: git fetch https://git.openjdk.org/lilliput-jdk21u.git pull/19/head:pull/19 PR: https://git.openjdk.org/lilliput-jdk21u/pull/19 From rkennke at openjdk.org Mon Mar 25 15:19:53 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 25 Mar 2024 15:19:53 GMT Subject: [lilliput-jdk21u:lilliput] Integrated: 8318015: Lock inflation not needed for OSR or Deopt for new locking modes In-Reply-To: References: Message-ID: On Mon, 25 Mar 2024 14:49:35 GMT, Roman Kennke wrote: > Hi all, > > This pull request contains a backport of commit [d0ea2a51](https://github.com/openjdk/jdk/commit/d0ea2a51111bd5de5a6465e7de6a4950aae89c71) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Martin Doerr on 17 Oct 2023 and was reviewed by Patricio Chilano Mateo and Dean Long. > > Thanks! This pull request has now been integrated. Changeset: c76a1bf4 Author: Roman Kennke URL: https://git.openjdk.org/lilliput-jdk21u/commit/c76a1bf4d3d8b9f99041425ec937f38def02e0d6 Stats: 40 lines in 3 files changed: 16 ins; 0 del; 24 mod 8318015: Lock inflation not needed for OSR or Deopt for new locking modes Backport-of: d0ea2a51111bd5de5a6465e7de6a4950aae89c71 ------------- PR: https://git.openjdk.org/lilliput-jdk21u/pull/19 From rkennke at openjdk.org Mon Mar 25 15:25:38 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 25 Mar 2024 15:25:38 GMT Subject: [lilliput-jdk21u:lilliput] RFR: 8319778: Remove unreachable code in ObjectSynchronizer::exit Message-ID: Hi all, This pull request contains a backport of commit [91279fcf](https://github.com/openjdk/jdk/commit/91279fcf058a6bb16a7749c328179ab94227bb8d) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was authored by Axel Boldt-Christmas on 27 Nov 2023 and was reviewed by Roman Kennke, David Holmes, Patricio Chilano Mateo and Daniel D. Daugherty. Thanks! ------------- Commit messages: - Backport 91279fcf058a6bb16a7749c328179ab94227bb8d Changes: https://git.openjdk.org/lilliput-jdk21u/pull/20/files Webrev: https://webrevs.openjdk.org/?repo=lilliput-jdk21u&pr=20&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8319778 Stats: 23 lines in 3 files changed: 0 ins; 22 del; 1 mod Patch: https://git.openjdk.org/lilliput-jdk21u/pull/20.diff Fetch: git fetch https://git.openjdk.org/lilliput-jdk21u.git pull/20/head:pull/20 PR: https://git.openjdk.org/lilliput-jdk21u/pull/20 From rkennke at openjdk.org Mon Mar 25 15:54:36 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 25 Mar 2024 15:54:36 GMT Subject: [lilliput-jdk21u:lilliput] Integrated: 8319778: Remove unreachable code in ObjectSynchronizer::exit In-Reply-To: References: Message-ID: <73MeyGshfRewTppCpbsZFds60J4lIZVwGFO5-5mNIhE=.09a87bfb-d6f8-46d1-977c-87a28c6e529a@github.com> On Mon, 25 Mar 2024 15:21:01 GMT, Roman Kennke wrote: > Hi all, > > This pull request contains a backport of commit [91279fcf](https://github.com/openjdk/jdk/commit/91279fcf058a6bb16a7749c328179ab94227bb8d) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Axel Boldt-Christmas on 27 Nov 2023 and was reviewed by Roman Kennke, David Holmes, Patricio Chilano Mateo and Daniel D. Daugherty. > > Thanks! This pull request has now been integrated. Changeset: e8f5152c Author: Roman Kennke URL: https://git.openjdk.org/lilliput-jdk21u/commit/e8f5152c7b944576041749bf2c02968a66c93090 Stats: 23 lines in 3 files changed: 0 ins; 22 del; 1 mod 8319778: Remove unreachable code in ObjectSynchronizer::exit Backport-of: 91279fcf058a6bb16a7749c328179ab94227bb8d ------------- PR: https://git.openjdk.org/lilliput-jdk21u/pull/20 From rkennke at openjdk.org Mon Mar 25 16:15:15 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 25 Mar 2024 16:15:15 GMT Subject: [lilliput-jdk21u:lilliput] Integrated: 8319773: Avoid inflating monitors when installing hash codes for LM_LIGHTWEIGHT In-Reply-To: References: Message-ID: On Mon, 25 Mar 2024 16:07:46 GMT, Roman Kennke wrote: > Hi all, > > This pull request contains a backport of commit [65a06727](https://github.com/openjdk/jdk/commit/65a0672791f868556776fc435b37319ed69f7c84) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Axel Boldt-Christmas on 12 Jan 2024 and was reviewed by Roman Kennke, Daniel D. Daugherty and Tobias Hartmann. > > Thanks! This pull request has now been integrated. Changeset: 95218a6a Author: Roman Kennke URL: https://git.openjdk.org/lilliput-jdk21u/commit/95218a6a128ead75de762ce0936b631d4f494ea7 Stats: 76 lines in 4 files changed: 29 ins; 23 del; 24 mod 8319773: Avoid inflating monitors when installing hash codes for LM_LIGHTWEIGHT Backport-of: 65a0672791f868556776fc435b37319ed69f7c84 ------------- PR: https://git.openjdk.org/lilliput-jdk21u/pull/21 From rkennke at openjdk.org Mon Mar 25 16:15:15 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 25 Mar 2024 16:15:15 GMT Subject: [lilliput-jdk21u:lilliput] Integrated: 8319773: Avoid inflating monitors when installing hash codes for LM_LIGHTWEIGHT Message-ID: Hi all, This pull request contains a backport of commit [65a06727](https://github.com/openjdk/jdk/commit/65a0672791f868556776fc435b37319ed69f7c84) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was authored by Axel Boldt-Christmas on 12 Jan 2024 and was reviewed by Roman Kennke, Daniel D. Daugherty and Tobias Hartmann. Thanks! ------------- Commit messages: - Backport 65a0672791f868556776fc435b37319ed69f7c84 Changes: https://git.openjdk.org/lilliput-jdk21u/pull/21/files Webrev: https://webrevs.openjdk.org/?repo=lilliput-jdk21u&pr=21&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8319773 Stats: 76 lines in 4 files changed: 29 ins; 23 del; 24 mod Patch: https://git.openjdk.org/lilliput-jdk21u/pull/21.diff Fetch: git fetch https://git.openjdk.org/lilliput-jdk21u.git pull/21/head:pull/21 PR: https://git.openjdk.org/lilliput-jdk21u/pull/21 From rkennke at openjdk.org Mon Mar 25 16:29:09 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 25 Mar 2024 16:29:09 GMT Subject: [lilliput-jdk21u:lilliput] Integrated: 8324881: ObjectSynchronizer::inflate(Thread* current...) is invoked for non-current thread Message-ID: <-hBuJVDRuxp4_hAh3k4lf3UGCQGah5FbZHEoYU6umUs=.45ec262b-7248-4cb1-8ab2-db67a2578025@github.com> Hi all, This pull request contains a backport of commit [a3a2b1fb](https://github.com/openjdk/jdk/commit/a3a2b1fbbf00577ce1d0e3a44e9537e997b30b05) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was authored by Axel Boldt-Christmas on 7 Feb 2024 and was reviewed by Richard Reingruber, David Holmes, Coleen Phillimore and Daniel D. Daugherty. Thanks! ------------- Commit messages: - Backport a3a2b1fbbf00577ce1d0e3a44e9537e997b30b05 Changes: https://git.openjdk.org/lilliput-jdk21u/pull/22/files Webrev: https://webrevs.openjdk.org/?repo=lilliput-jdk21u&pr=22&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8324881 Stats: 362 lines in 6 files changed: 304 ins; 10 del; 48 mod Patch: https://git.openjdk.org/lilliput-jdk21u/pull/22.diff Fetch: git fetch https://git.openjdk.org/lilliput-jdk21u.git pull/22/head:pull/22 PR: https://git.openjdk.org/lilliput-jdk21u/pull/22 From rkennke at openjdk.org Mon Mar 25 16:29:10 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 25 Mar 2024 16:29:10 GMT Subject: [lilliput-jdk21u:lilliput] Integrated: 8324881: ObjectSynchronizer::inflate(Thread* current...) is invoked for non-current thread In-Reply-To: <-hBuJVDRuxp4_hAh3k4lf3UGCQGah5FbZHEoYU6umUs=.45ec262b-7248-4cb1-8ab2-db67a2578025@github.com> References: <-hBuJVDRuxp4_hAh3k4lf3UGCQGah5FbZHEoYU6umUs=.45ec262b-7248-4cb1-8ab2-db67a2578025@github.com> Message-ID: <79hWVVkMwbj_AFXA0tc2s3qN41in-aBSRu_z5ePTvn0=.d45dd8b1-0be1-4246-acb8-22cb3a2b7549@github.com> On Mon, 25 Mar 2024 16:22:24 GMT, Roman Kennke wrote: > Hi all, > > This pull request contains a backport of commit [a3a2b1fb](https://github.com/openjdk/jdk/commit/a3a2b1fbbf00577ce1d0e3a44e9537e997b30b05) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Axel Boldt-Christmas on 7 Feb 2024 and was reviewed by Richard Reingruber, David Holmes, Coleen Phillimore and Daniel D. Daugherty. > > Thanks! This pull request has now been integrated. Changeset: c7e855dc Author: Roman Kennke URL: https://git.openjdk.org/lilliput-jdk21u/commit/c7e855dc8b4fc21570288d15e65c67aa9e4819f7 Stats: 362 lines in 6 files changed: 304 ins; 10 del; 48 mod 8324881: ObjectSynchronizer::inflate(Thread* current...) is invoked for non-current thread Backport-of: a3a2b1fbbf00577ce1d0e3a44e9537e997b30b05 ------------- PR: https://git.openjdk.org/lilliput-jdk21u/pull/22 From stefank at openjdk.org Mon Mar 25 16:30:51 2024 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 25 Mar 2024 16:30:51 GMT Subject: [master] RFR: JDK-8325104: Lilliput: Shrink Classpointers [v3] In-Reply-To: References: Message-ID: On Mon, 25 Mar 2024 14:51:14 GMT, Thomas Stuefe wrote: >> Hi, >> >> I wanted to get input on the following improvement for Lilliput. Testing is still ongoing, but things look really good, so this patch is hopefully near its final form (barring any objections from reviewers, of course). >> >> Note: I have a companion patch prepared for upstream, minus the markword changes. I will attempt to get that one upstream quickly in order to not have a large delta between upstream and lilliput, especially in Metaspace. >> >> ## High-Level Overview >> >> (for a short sequence of slides, please see https://github.com/tstuefe/fosdem24/blob/master/classpointers-and-liliput.pdf - these accompanied a talk we held at FOSDEM 24). >> >> We want to reduce the bit size of narrow Klass to free up bits in the MarkWord. >> >> We cannot just reduce the Klass encoding range size (well, we could, and maybe we will later, but for now we decided not to). We instead increase the alignment Klass is stored at, and use that alignment shadow to store other information. >> >> In other words, this patch changes the narrow Klass Pointer to a Klass ID, since now (almost) every value in its value range points to a different class. Therefore, we use the value range of nKlass much more efficiently. >> >> We then use the newly freed bits in the MarkWord to restore the iHash to 31 bits: >> >> >> [ 22-bit nKlass | 31-bit iHash | 4 free bits | age | fwd | lck ] >> >> nKlass gets reduced to 22 bits. Identity hash gets re-inflated to 31 bits. Preceding iHash are now 4 unused bits. Rest is unchanged. >> >> (Note: I originally wanted to swap iHash and nKlass such that either of them could be loaded with a 32-bit load, but I found that tricky since C2 seems to rely on the nKlass offset in the Markword being > 0.) >> >> ## nKlass reduction: >> >> The reduction in nKlass size is made by only storing them at 10-bit aligned addresses. That alignment (1KB) works well in practice since Klass - although var sized - typically is between 512 bytes and 1KB in size. Outliers are possible, but the size distribution is bell-curvish [1], so far-away outliers are very rare. >> >> To not lose memory to alignment waste, metaspace is reshaped to handle arbitrarily aligned allocations efficiently. Basically, we allow the non-Klass arena of a class loader to steal the alignment waste storage from the class arena. So, alignment waste blocks are filled with non-Klass metadata. That works very well in practice since non-Klass metadata is numerous and fine-granular compared to the big Klass bloc... > > Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: > > - Roman feedback - small stuff > - Merge branch 'master' into Smaller-ClassPointers > - revert COH archive generation > - Remove files that accidentally slipped in > - Merge branch 'master' into Smaller-ClassPointers > - Merge > - Merge commit 'c1281e6b45ed167df69d29a6039d81854c145ae6~1' into Smaller-ClassPointers > - Fix Typo > - Better CDS arch generation > - Fix error in COH archive generation > - ... and 10 more: https://git.openjdk.org/lilliput/compare/b2fcfb73...1260f2d6 src/hotspot/share/oops/oop.hpp line 345: > 343: constexpr int load_shift = markWord::klass_load_shift; > 344: STATIC_ASSERT(load_shift % 8 == 0); > 345: return mark_offset_in_bytes() + load_shift / 8; Isn't this broken for big-endian machines? The follow-up question then is, should we really be reading the klass pointer with 32-bit loads? If we load the entire 64-bit "object header" and then shift with `klass_shift`, we wouldn't have to think about endianess, right? Do we keep the 32-bit load because we don't want to mess with C2? ------------- PR Review Comment: https://git.openjdk.org/lilliput/pull/128#discussion_r1537875026 From rkennke at openjdk.org Mon Mar 25 16:38:04 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 25 Mar 2024 16:38:04 GMT Subject: [lilliput-jdk21u:lilliput] Integrated: 8319797: Recursive lightweight locking: Runtime implementation In-Reply-To: References: Message-ID: On Mon, 25 Mar 2024 16:30:36 GMT, Roman Kennke wrote: > Hi all, > > This pull request contains a backport of commit [5dbf1373](https://github.com/openjdk/jdk/commit/5dbf13730ee2b57f089c57e9e7ee8ab65d4a67af) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Axel Boldt-Christmas on 13 Feb 2024 and was reviewed by Roman Kennke, Daniel D. Daugherty, Coleen Phillimore and Stefan Karlsson. > > Thanks! This pull request has now been integrated. Changeset: 0d246501 Author: Roman Kennke URL: https://git.openjdk.org/lilliput-jdk21u/commit/0d246501599826c0555a08e86a6f5a09c8177832 Stats: 863 lines in 13 files changed: 815 ins; 7 del; 41 mod 8319797: Recursive lightweight locking: Runtime implementation Backport-of: 5dbf13730ee2b57f089c57e9e7ee8ab65d4a67af ------------- PR: https://git.openjdk.org/lilliput-jdk21u/pull/23 From rkennke at openjdk.org Mon Mar 25 16:38:03 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 25 Mar 2024 16:38:03 GMT Subject: [lilliput-jdk21u:lilliput] Integrated: 8319797: Recursive lightweight locking: Runtime implementation Message-ID: Hi all, This pull request contains a backport of commit [5dbf1373](https://github.com/openjdk/jdk/commit/5dbf13730ee2b57f089c57e9e7ee8ab65d4a67af) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was authored by Axel Boldt-Christmas on 13 Feb 2024 and was reviewed by Roman Kennke, Daniel D. Daugherty, Coleen Phillimore and Stefan Karlsson. Thanks! ------------- Commit messages: - Backport 5dbf13730ee2b57f089c57e9e7ee8ab65d4a67af Changes: https://git.openjdk.org/lilliput-jdk21u/pull/23/files Webrev: https://webrevs.openjdk.org/?repo=lilliput-jdk21u&pr=23&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8319797 Stats: 863 lines in 13 files changed: 815 ins; 7 del; 41 mod Patch: https://git.openjdk.org/lilliput-jdk21u/pull/23.diff Fetch: git fetch https://git.openjdk.org/lilliput-jdk21u.git pull/23/head:pull/23 PR: https://git.openjdk.org/lilliput-jdk21u/pull/23 From rkennke at openjdk.org Mon Mar 25 18:44:04 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 25 Mar 2024 18:44:04 GMT Subject: [lilliput-jdk21u:lilliput] RFR: 8319799: Recursive lightweight locking: x86 implementation Message-ID: Hi all, This pull request contains a backport of commit [7f6bb71e](https://github.com/openjdk/jdk/commit/7f6bb71eb302e8388c959bdaa914b758a766d299) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. Backport wasn't 100% clean due to context differences (includes and the LoadNKlass stubs that are only in Lilliput), and trivial to fix. The commit being backported was authored by Axel Boldt-Christmas on 14 Feb 2024 and was reviewed by Roman Kennke, Coleen Phillimore and Daniel D. Daugherty. Thanks! ------------- Commit messages: - Backport 7f6bb71eb302e8388c959bdaa914b758a766d299 Changes: https://git.openjdk.org/lilliput-jdk21u/pull/24/files Webrev: https://webrevs.openjdk.org/?repo=lilliput-jdk21u&pr=24&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8319799 Stats: 589 lines in 13 files changed: 450 ins; 62 del; 77 mod Patch: https://git.openjdk.org/lilliput-jdk21u/pull/24.diff Fetch: git fetch https://git.openjdk.org/lilliput-jdk21u.git pull/24/head:pull/24 PR: https://git.openjdk.org/lilliput-jdk21u/pull/24 From rkennke at openjdk.org Mon Mar 25 18:47:57 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 25 Mar 2024 18:47:57 GMT Subject: [lilliput-jdk21u:lilliput] Integrated: 8319801: Recursive lightweight locking: aarch64 implementation Message-ID: Hi all, This pull request contains a backport of commit [18cea823](https://github.com/openjdk/jdk/commit/18cea823a173e1b8b48d276daeca67b2a5cf3584) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was authored by Axel Boldt-Christmas on 16 Feb 2024 and was reviewed by Roman Kennke, Coleen Phillimore, Daniel D. Daugherty and Andrew Haley. Thanks! ------------- Commit messages: - Backport 18cea823a173e1b8b48d276daeca67b2a5cf3584 Changes: https://git.openjdk.org/lilliput-jdk21u/pull/25/files Webrev: https://webrevs.openjdk.org/?repo=lilliput-jdk21u&pr=25&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8319801 Stats: 492 lines in 9 files changed: 354 ins; 80 del; 58 mod Patch: https://git.openjdk.org/lilliput-jdk21u/pull/25.diff Fetch: git fetch https://git.openjdk.org/lilliput-jdk21u.git pull/25/head:pull/25 PR: https://git.openjdk.org/lilliput-jdk21u/pull/25 From rkennke at openjdk.org Mon Mar 25 18:47:57 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 25 Mar 2024 18:47:57 GMT Subject: [lilliput-jdk21u:lilliput] Integrated: 8319801: Recursive lightweight locking: aarch64 implementation In-Reply-To: References: Message-ID: On Mon, 25 Mar 2024 18:40:57 GMT, Roman Kennke wrote: > Hi all, > > This pull request contains a backport of commit [18cea823](https://github.com/openjdk/jdk/commit/18cea823a173e1b8b48d276daeca67b2a5cf3584) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Axel Boldt-Christmas on 16 Feb 2024 and was reviewed by Roman Kennke, Coleen Phillimore, Daniel D. Daugherty and Andrew Haley. > > Thanks! This pull request has now been integrated. Changeset: 74e544c7 Author: Roman Kennke URL: https://git.openjdk.org/lilliput-jdk21u/commit/74e544c7fddc3a509c750e5291e7c01383903a31 Stats: 492 lines in 9 files changed: 354 ins; 80 del; 58 mod 8319801: Recursive lightweight locking: aarch64 implementation Backport-of: 18cea823a173e1b8b48d276daeca67b2a5cf3584 ------------- PR: https://git.openjdk.org/lilliput-jdk21u/pull/25 From rkennke at openjdk.org Mon Mar 25 18:50:52 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 25 Mar 2024 18:50:52 GMT Subject: [lilliput-jdk21u:lilliput] RFR: 8319900: Recursive lightweight locking: riscv64 implementation Message-ID: Hi all, This pull request contains a backport of commit [e1b661f8](https://github.com/openjdk/jdk/commit/e1b661f8c1df780cce28fe76d257b44e2fe44058) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was authored by Gui Cao on 5 Mar 2024 and was reviewed by Fei Yang. Thanks! ------------- Commit messages: - Backport e1b661f8c1df780cce28fe76d257b44e2fe44058 Changes: https://git.openjdk.org/lilliput-jdk21u/pull/26/files Webrev: https://webrevs.openjdk.org/?repo=lilliput-jdk21u&pr=26&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8319900 Stats: 613 lines in 9 files changed: 411 ins; 114 del; 88 mod Patch: https://git.openjdk.org/lilliput-jdk21u/pull/26.diff Fetch: git fetch https://git.openjdk.org/lilliput-jdk21u.git pull/26/head:pull/26 PR: https://git.openjdk.org/lilliput-jdk21u/pull/26 From rkennke at openjdk.org Mon Mar 25 19:01:55 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 25 Mar 2024 19:01:55 GMT Subject: [lilliput-jdk21u:lilliput] Integrated: 8307907: [ppc] Remove RTM locking implementation Message-ID: Hi all, This pull request contains a backport of commit [de8aca27](https://github.com/openjdk/jdk/commit/de8aca27ba87427307186ffd25c029b5c6dbc82e) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was authored by Martin Doerr on 15 Jun 2023 and was reviewed by Matthias Baesken, Richard Reingruber and Thomas Stuefe. Thanks! ------------- Commit messages: - Backport de8aca27ba87427307186ffd25c029b5c6dbc82e Changes: https://git.openjdk.org/lilliput-jdk21u/pull/27/files Webrev: https://webrevs.openjdk.org/?repo=lilliput-jdk21u&pr=27&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8307907 Stats: 864 lines in 15 files changed: 0 ins; 842 del; 22 mod Patch: https://git.openjdk.org/lilliput-jdk21u/pull/27.diff Fetch: git fetch https://git.openjdk.org/lilliput-jdk21u.git pull/27/head:pull/27 PR: https://git.openjdk.org/lilliput-jdk21u/pull/27 From rkennke at openjdk.org Mon Mar 25 19:01:55 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 25 Mar 2024 19:01:55 GMT Subject: [lilliput-jdk21u:lilliput] Integrated: 8307907: [ppc] Remove RTM locking implementation In-Reply-To: References: Message-ID: On Mon, 25 Mar 2024 18:55:05 GMT, Roman Kennke wrote: > Hi all, > > This pull request contains a backport of commit [de8aca27](https://github.com/openjdk/jdk/commit/de8aca27ba87427307186ffd25c029b5c6dbc82e) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Martin Doerr on 15 Jun 2023 and was reviewed by Matthias Baesken, Richard Reingruber and Thomas Stuefe. > > Thanks! This pull request has now been integrated. Changeset: 455ada63 Author: Roman Kennke URL: https://git.openjdk.org/lilliput-jdk21u/commit/455ada63c500216b150d7fd414eed34b5dffe59f Stats: 864 lines in 15 files changed: 0 ins; 842 del; 22 mod 8307907: [ppc] Remove RTM locking implementation Backport-of: de8aca27ba87427307186ffd25c029b5c6dbc82e ------------- PR: https://git.openjdk.org/lilliput-jdk21u/pull/27 From rkennke at openjdk.org Mon Mar 25 19:06:37 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 25 Mar 2024 19:06:37 GMT Subject: [lilliput-jdk21u:lilliput] Integrated: 8319900: Recursive lightweight locking: riscv64 implementation In-Reply-To: References: Message-ID: On Mon, 25 Mar 2024 18:46:28 GMT, Roman Kennke wrote: > Hi all, > > This pull request contains a backport of commit [e1b661f8](https://github.com/openjdk/jdk/commit/e1b661f8c1df780cce28fe76d257b44e2fe44058) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Gui Cao on 5 Mar 2024 and was reviewed by Fei Yang. > > Thanks! This pull request has now been integrated. Changeset: a28d30c1 Author: Roman Kennke URL: https://git.openjdk.org/lilliput-jdk21u/commit/a28d30c12edce5cbd3c8fccad6df788c4632f5a0 Stats: 613 lines in 9 files changed: 411 ins; 114 del; 88 mod 8319900: Recursive lightweight locking: riscv64 implementation Backport-of: e1b661f8c1df780cce28fe76d257b44e2fe44058 ------------- PR: https://git.openjdk.org/lilliput-jdk21u/pull/26 From rkennke at openjdk.org Mon Mar 25 19:08:41 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 25 Mar 2024 19:08:41 GMT Subject: [lilliput-jdk21u:lilliput] Integrated: 8319901: Recursive lightweight locking: ppc64le implementation Message-ID: Hi all, This pull request contains a backport of commit [b5cd7efc](https://github.com/openjdk/jdk/commit/b5cd7efcebe0daaf8a85f0f32b65a3bd446674ef) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was authored by Axel Boldt-Christmas on 4 Mar 2024 and was reviewed by Martin Doerr and Richard Reingruber. Thanks! ------------- Commit messages: - Backport b5cd7efcebe0daaf8a85f0f32b65a3bd446674ef Changes: https://git.openjdk.org/lilliput-jdk21u/pull/28/files Webrev: https://webrevs.openjdk.org/?repo=lilliput-jdk21u&pr=28&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8319901 Stats: 509 lines in 9 files changed: 409 ins; 65 del; 35 mod Patch: https://git.openjdk.org/lilliput-jdk21u/pull/28.diff Fetch: git fetch https://git.openjdk.org/lilliput-jdk21u.git pull/28/head:pull/28 PR: https://git.openjdk.org/lilliput-jdk21u/pull/28 From rkennke at openjdk.org Mon Mar 25 19:08:41 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 25 Mar 2024 19:08:41 GMT Subject: [lilliput-jdk21u:lilliput] Integrated: 8319901: Recursive lightweight locking: ppc64le implementation In-Reply-To: References: Message-ID: On Mon, 25 Mar 2024 19:02:03 GMT, Roman Kennke wrote: > Hi all, > > This pull request contains a backport of commit [b5cd7efc](https://github.com/openjdk/jdk/commit/b5cd7efcebe0daaf8a85f0f32b65a3bd446674ef) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Axel Boldt-Christmas on 4 Mar 2024 and was reviewed by Martin Doerr and Richard Reingruber. > > Thanks! This pull request has now been integrated. Changeset: e41b033a Author: Roman Kennke URL: https://git.openjdk.org/lilliput-jdk21u/commit/e41b033a3bb5591796912cc25de227504b8d7aa7 Stats: 509 lines in 9 files changed: 409 ins; 65 del; 35 mod 8319901: Recursive lightweight locking: ppc64le implementation Backport-of: b5cd7efcebe0daaf8a85f0f32b65a3bd446674ef ------------- PR: https://git.openjdk.org/lilliput-jdk21u/pull/28 From jrose at openjdk.org Mon Mar 25 19:40:44 2024 From: jrose at openjdk.org (John R Rose) Date: Mon, 25 Mar 2024 19:40:44 GMT Subject: [master] RFR: JDK-8325104: Lilliput: Shrink Classpointers [v3] In-Reply-To: References: Message-ID: On Mon, 25 Mar 2024 14:51:14 GMT, Thomas Stuefe wrote: >> Hi, >> >> I wanted to get input on the following improvement for Lilliput. Testing is still ongoing, but things look really good, so this patch is hopefully near its final form (barring any objections from reviewers, of course). >> >> Note: I have a companion patch prepared for upstream, minus the markword changes. I will attempt to get that one upstream quickly in order to not have a large delta between upstream and lilliput, especially in Metaspace. >> >> ## High-Level Overview >> >> (for a short sequence of slides, please see https://github.com/tstuefe/fosdem24/blob/master/classpointers-and-liliput.pdf - these accompanied a talk we held at FOSDEM 24). >> >> We want to reduce the bit size of narrow Klass to free up bits in the MarkWord. >> >> We cannot just reduce the Klass encoding range size (well, we could, and maybe we will later, but for now we decided not to). We instead increase the alignment Klass is stored at, and use that alignment shadow to store other information. >> >> In other words, this patch changes the narrow Klass Pointer to a Klass ID, since now (almost) every value in its value range points to a different class. Therefore, we use the value range of nKlass much more efficiently. >> >> We then use the newly freed bits in the MarkWord to restore the iHash to 31 bits: >> >> >> [ 22-bit nKlass | 31-bit iHash | 4 free bits | age | fwd | lck ] >> >> nKlass gets reduced to 22 bits. Identity hash gets re-inflated to 31 bits. Preceding iHash are now 4 unused bits. Rest is unchanged. >> >> (Note: I originally wanted to swap iHash and nKlass such that either of them could be loaded with a 32-bit load, but I found that tricky since C2 seems to rely on the nKlass offset in the Markword being > 0.) >> >> ## nKlass reduction: >> >> The reduction in nKlass size is made by only storing them at 10-bit aligned addresses. That alignment (1KB) works well in practice since Klass - although var sized - typically is between 512 bytes and 1KB in size. Outliers are possible, but the size distribution is bell-curvish [1], so far-away outliers are very rare. >> >> To not lose memory to alignment waste, metaspace is reshaped to handle arbitrarily aligned allocations efficiently. Basically, we allow the non-Klass arena of a class loader to steal the alignment waste storage from the class arena. So, alignment waste blocks are filled with non-Klass metadata. That works very well in practice since non-Klass metadata is numerous and fine-granular compared to the big Klass bloc... > > Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: > > - Roman feedback - small stuff > - Merge branch 'master' into Smaller-ClassPointers > - revert COH archive generation > - Remove files that accidentally slipped in > - Merge branch 'master' into Smaller-ClassPointers > - Merge > - Merge commit 'c1281e6b45ed167df69d29a6039d81854c145ae6~1' into Smaller-ClassPointers > - Fix Typo > - Better CDS arch generation > - Fix error in COH archive generation > - ... and 10 more: https://git.openjdk.org/lilliput/compare/b2fcfb73...1260f2d6 One possible problem with hyper-aligned data structures (such as Klass* pointers allocated zero mod 1024) is interactions with data cache dynamics. If your D$ maps blocks aligned zero mod 64, then your Klass blocks can occupy only 1/16 of possible D$ entries. Sometimes this matters, when you are loading from many Klasses: The effect is of making the D$, just for them, smaller by a factor of 16, causing more frequent collisions and evictions. (This sort of effect has been observed, IIRC, with both stacks and TLABs, in the past. I don?t know if Klass accesses are frequent enough to make similar effects be detectable or not.) A solution is to perturb the hyper-alignment in such a way that the lower bits select all possible D$ frames, instead of just 1/16 of them. The simplest way to do this is to make your hyper-aligned Klass* blocks aligned mod (1024 + 64), where 1024 is your intended size and 64 is your D$ entry size. (Or maybe mod 1024+8, if it is faster to shift by 8 instead of by 64.). Decoding a Klass index consists of multiplying by the sum of a pair of powers of two, instead of by a single power of two. That means an extra instruction in the decode fast-path, unless you can hide the extra shift/add in an addressing mode. Given that we work hard to make the Klass base address be zero, it is clear that every instruction counts, and even if the Klass base is zero, you still need an extra instruction or two to do the extra shift/add. So that is sad, but the fact that we are sensitive to performance of these sequences means that we might possibly be sensitive to D$ collision effects also: Saving one instruction but having the average number of cycles go up, due to D$ misses, could be a net loss. So I suggest considering (even to the point of doing performance tests) the idea of assigning Klass addresses mod 1088 instead of 1024. It might require some imaginative coding to adjust the allocator logic to hand out such addresses, but I don?t think it?s very bad. For allocator performance, multiplication by 1088 is trivial. There will be some divisions by 1088, probably, but those are optimized (usually) to multiplications as well, if the divisor (1088) is a compile time constant. The allocator could search for available blocks mod 1024, and then only at the end, before handing out the block, round up to the next multiple of 1088. That would add a number from 0 to 63 to the base address which has already been selected. If that shift makes the block overflow at the other end, then the allocator has to keep searching. ------------- PR Comment: https://git.openjdk.org/lilliput/pull/128#issuecomment-2018769429 From jrose at openjdk.org Mon Mar 25 20:07:47 2024 From: jrose at openjdk.org (John R Rose) Date: Mon, 25 Mar 2024 20:07:47 GMT Subject: [master] RFR: JDK-8325104: Lilliput: Shrink Classpointers [v3] In-Reply-To: References: Message-ID: On Mon, 25 Mar 2024 19:38:11 GMT, John R Rose wrote: > ? interactions with data cache dynamics ? I see acknowledgement of this issue in a comment in this PR that says "smallest shift possible that still covers the whole range?. This is a good solution as long as that smallest shift is 64 (or less). A shift of 128 would dilute the D$ by 50%, but would reach 2^(22+7-10) distinct Klasses, half a million, which is great. I guess VMs which configure themselves for a quarter million classes or fewer just use the cache line as the allocation modulus, and all is well. So my solution (mod 1088) is really useful only for huge workloads. I retract my suggestion that performance experiments are needed at this time, given the solution you have in place. ------------- PR Comment: https://git.openjdk.org/lilliput/pull/128#issuecomment-2018815640 From stuefe at openjdk.org Tue Mar 26 09:23:43 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 26 Mar 2024 09:23:43 GMT Subject: [master] RFR: JDK-8325104: Lilliput: Shrink Classpointers [v3] In-Reply-To: References: Message-ID: On Mon, 25 Mar 2024 19:38:11 GMT, John R Rose wrote: > One possible problem with hyper-aligned data structures (such as Klass* pointers allocated zero mod 1024) is interactions with data cache dynamics. If your D$ maps blocks aligned zero mod 64, then your Klass blocks can occupy only 1/16 of possible D$ entries. Sometimes this matters, when you are loading from many Klasses: The effect is of making the D$, just for them, smaller by a factor of 16, causing more frequent collisions and evictions. > > (This sort of effect has been observed, IIRC, with both stacks and TLABs, in the past. I don?t know if Klass accesses are frequent enough to make similar effects be detectable or not.) > > A solution is to perturb the hyper-alignment in such a way that the lower bits select all possible D$ frames, instead of just 1/16 of them. The simplest way to do this is to make your hyper-aligned Klass* blocks aligned mod (1024 + 64), where 1024 is your intended size and 64 is your D$ entry size. (Or maybe mod 1024+8, if it is faster to shift by 8 instead of by 64.). Decoding a Klass index consists of multiplying by the sum of a pair of powers of two, instead of by a single power of two. That means an extra instruction in the decode fast-path, unless you can hide the extra shift/add in an addressing mode. > > Given that we work hard to make the Klass base address be zero, it is clear that every instruction counts, and even if the Klass base is zero, you still need an extra instruction or two to do the extra shift/add. So that is sad, but the fact that we are sensitive to performance of these sequences means that we might possibly be sensitive to D$ collision effects also: Saving one instruction but having the average number of cycles go up, due to D$ misses, could be a net loss. > > So I suggest considering (even to the point of doing performance tests) the idea of assigning Klass addresses mod 1088 instead of 1024. It might require some imaginative coding to adjust the allocator logic to hand out such addresses, but I don?t think it?s very bad. For allocator performance, multiplication by 1088 is trivial. There will be some divisions by 1088, probably, but those are optimized (usually) to multiplications as well, if the divisor (1088) is a compile time constant. > > The allocator could search for available blocks mod 1024, and then only at the end, before handing out the block, round up to the next multiple of 1088. That would add a number from 0 to 63 to the base address which has already been selected. If that shift makes the block overflow at the other end, then the allocator has to keep searching. Hi John, I remember well your point from our last interchange (https://github.com/openjdk/lilliput/pull/13#issuecomment-988456995). Last summer, I did a number of performance tests but found no clear result above background noise. But I had planned to revisit this issue and potentially fix it as a follow-up task. One never knows, my test methodology may have been off. Like you, I was worried about the increased cost and complexity of Klass ID decoding. Last summer I investigated how a possible decoding would look like. Since I am not a compiler expert, I just looked at what C compilers do when referencing items in a 1088-stride array. x64 e.g. uses imul, aarch64 uses some form of shift+add. Maybe its not so bad, but the effects need to be measured. My short-term contingency plan had been to use some of the now free four bits to increase the Klass ID bits and thus bring alignment back to 64 bytes. That would work at least for 64-bit headers, as long as Valhalla does not need those bits too. I will re-examine my performance runs, and double-check for methodology errors. > I see acknowledgement of this issue in a comment in this PR that says "smallest shift possible that still covers the whole range?. This is a good solution as long as that smallest shift is 64 (or less). A shift of 128 would dilute the D$ by 50%, but would reach 2^(22+7-10) distinct Klasses, half a million, which is great. I guess VMs which configure themselves for a quarter million classes or fewer just use the cache line as the allocation modulus, and all is well. So my solution (mod 1088) is really useful only for huge workloads. I retract my suggestion that performance experiments are needed at this time, given the solution you have in place. Yes, that was the underlying reason for this logic. Unfortunately, the default is for the class space to be 1G, with some additional space for CDS, so we are at a 2G range, which brings us just one bit. There are knobs to play with, e.g. CDS size is usually very small, so both CDS and class space default together could easily fit into 1G. That brings us 2 bits, back to an alignment of 256. Still only every fourth cache line. ------------- PR Comment: https://git.openjdk.org/lilliput/pull/128#issuecomment-2019911943 From stuefe at openjdk.org Tue Mar 26 10:18:36 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 26 Mar 2024 10:18:36 GMT Subject: [lilliput-jdk21u:lilliput] RFR: 8319799: Recursive lightweight locking: x86 implementation In-Reply-To: References: Message-ID: On Mon, 25 Mar 2024 18:38:53 GMT, Roman Kennke wrote: > Hi all, > > This pull request contains a backport of commit [7f6bb71e](https://github.com/openjdk/jdk/commit/7f6bb71eb302e8388c959bdaa914b758a766d299) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > Backport wasn't 100% clean due to context differences (includes and the LoadNKlass stubs that are only in Lilliput), and trivial to fix. > > The commit being backported was authored by Axel Boldt-Christmas on 14 Feb 2024 and was reviewed by Roman Kennke, Coleen Phillimore and Daniel D. Daugherty. > > Thanks! Looks good. ------------- Marked as reviewed by stuefe (Committer). PR Review: https://git.openjdk.org/lilliput-jdk21u/pull/24#pullrequestreview-1959917245 From shade at openjdk.org Tue Mar 26 10:18:36 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 26 Mar 2024 10:18:36 GMT Subject: [lilliput-jdk21u:lilliput] RFR: 8319799: Recursive lightweight locking: x86 implementation In-Reply-To: References: Message-ID: On Mon, 25 Mar 2024 18:38:53 GMT, Roman Kennke wrote: > Hi all, > > This pull request contains a backport of commit [7f6bb71e](https://github.com/openjdk/jdk/commit/7f6bb71eb302e8388c959bdaa914b758a766d299) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > Backport wasn't 100% clean due to context differences (includes and the LoadNKlass stubs that are only in Lilliput), and trivial to fix. > > The commit being backported was authored by Axel Boldt-Christmas on 14 Feb 2024 and was reviewed by Roman Kennke, Coleen Phillimore and Daniel D. Daugherty. > > Thanks! >From a cursory look, this looks fine. ------------- Marked as reviewed by shade (Committer). PR Review: https://git.openjdk.org/lilliput-jdk21u/pull/24#pullrequestreview-1959920954 From stuefe at openjdk.org Tue Mar 26 10:45:55 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 26 Mar 2024 10:45:55 GMT Subject: [master] RFR: JDK-8328886: Lilliput: Build COH archives Message-ID: This is a breakout from and a prerequisite for [JDK-8325104](https://bugs.openjdk.org/browse/JDK-8325104). To run with +COH and CDS enabled, and to enable tests testing this combination, we need to build archives with +COH too. This patch expands the number of archives built to four: a) **classes.jsa** (+UseCompressedClassPointers, -UseCompactObjectHeaders) b) **classes_nocoops.jsa** (-UseCompressedClassPointers, -UseCompactObjectHeaders) c) **classes_coh.jsa** (+UseCompressedClassPointers, +UseCompactObjectHeaders) d) **classes_nocoops_coh.jsa** (-UseCompressedClassPointers, +UseCompactObjectHeaders) Naming could be more logical, but my aim was to keep compatibility with upstream archive names (no functional or name changes for *classes.jsa* and *classes_nocoops.jsa*). Another design goal was for the name-to-options mapping not to change *even if UseCOH were enabled by default*. So, _classes.jsa_ is not the "default jsa" but explicitly and always signifies the jsa with +coops -coh. The new configure option `--(enable|disable)-cds-archive-coh` allows you to enable/disable the generation of COH archives. By default, it is enabled if the underlying platform supports COH (64-bit) and if standard CDS archive generation is enabled (e.g., not for cross-compilation). Note that the upcoming JEP "CDS Archived Object Streaming" ([JDK-8326035](https://bugs.openjdk.org/browse/JDK-8326035)) will eliminate the +-Coops distinction, thus reducing the number of CDS archives. It may also eliminate the +-COH distinction at some point, though that is harder. But that JEP has to be developed and shipped first. After that, it will run alongside the old implementation for a while, which we keep as a fallback. Only if it is the sole remaining way to load CDS archives can we cut down the number of jsa archives. Until then, I propose to keep +-COH archives in addition to +-Coops archives. ------------- Commit messages: - fix configure script - fix 32-bit tests - fix 32-bit - build COH archives Changes: https://git.openjdk.org/lilliput/pull/145/files Webrev: https://webrevs.openjdk.org/?repo=lilliput&pr=145&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8328886 Stats: 180 lines in 6 files changed: 170 ins; 0 del; 10 mod Patch: https://git.openjdk.org/lilliput/pull/145.diff Fetch: git fetch https://git.openjdk.org/lilliput.git pull/145/head:pull/145 PR: https://git.openjdk.org/lilliput/pull/145 From stuefe at openjdk.org Tue Mar 26 10:45:55 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 26 Mar 2024 10:45:55 GMT Subject: [master] RFR: JDK-8328886: Lilliput: Build COH archives In-Reply-To: References: Message-ID: On Mon, 25 Mar 2024 13:24:35 GMT, Thomas Stuefe wrote: > This is a breakout from and a prerequisite for [JDK-8325104](https://bugs.openjdk.org/browse/JDK-8325104). > > To run with +COH and CDS enabled, and to enable tests testing this combination, we need to build archives with +COH too. > > This patch expands the number of archives built to four: > > a) **classes.jsa** (+UseCompressedClassPointers, -UseCompactObjectHeaders) > b) **classes_nocoops.jsa** (-UseCompressedClassPointers, -UseCompactObjectHeaders) > c) **classes_coh.jsa** (+UseCompressedClassPointers, +UseCompactObjectHeaders) > d) **classes_nocoops_coh.jsa** (-UseCompressedClassPointers, +UseCompactObjectHeaders) > > Naming could be more logical, but my aim was to keep compatibility with upstream archive names (no functional or name changes for *classes.jsa* and *classes_nocoops.jsa*). > > Another design goal was for the name-to-options mapping not to change *even if UseCOH were enabled by default*. So, _classes.jsa_ is not the "default jsa" but explicitly and always signifies the jsa with +coops -coh. > > The new configure option `--(enable|disable)-cds-archive-coh` allows you to enable/disable the generation of COH archives. By default, it is enabled if the underlying platform supports COH (64-bit) and if standard CDS archive generation is enabled (e.g., not for cross-compilation). > > Note that the upcoming JEP "CDS Archived Object Streaming" ([JDK-8326035](https://bugs.openjdk.org/browse/JDK-8326035)) will eliminate the +-Coops distinction, thus reducing the number of CDS archives. It may also eliminate the +-COH distinction at some point, though that is harder. > > But that JEP has to be developed and shipped first. After that, it will run alongside the old implementation for a while, which we keep as a fallback. Only if it is the sole remaining way to load CDS archives can we cut down the number of jsa archives. Until then, I propose to keep +-COH archives in addition to +-Coops archives. Windows aarch64 error is mysterious, but from googling around, it looks like a GitHub issue. Unfortunately, I have no Windows aarch64 machine to repeat the test manually. ------------- PR Comment: https://git.openjdk.org/lilliput/pull/145#issuecomment-2020078602 From stuefe at openjdk.org Tue Mar 26 10:49:51 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 26 Mar 2024 10:49:51 GMT Subject: [master] RFR: JDK-8328886: Lilliput: Build COH archives [v2] In-Reply-To: References: Message-ID: > This is a breakout from and a prerequisite for [JDK-8325104](https://bugs.openjdk.org/browse/JDK-8325104). > > To run with +COH and CDS enabled, and to enable tests testing this combination, we need to build archives with +COH too. > > This patch expands the number of archives built to four: > > a) **classes.jsa** (+UseCompressedClassPointers, -UseCompactObjectHeaders) > b) **classes_nocoops.jsa** (-UseCompressedClassPointers, -UseCompactObjectHeaders) > c) **classes_coh.jsa** (+UseCompressedClassPointers, +UseCompactObjectHeaders) > d) **classes_nocoops_coh.jsa** (-UseCompressedClassPointers, +UseCompactObjectHeaders) > > Naming could be more logical, but my aim was to keep compatibility with upstream archive names (no functional or name changes for *classes.jsa* and *classes_nocoops.jsa*). > > Another design goal was for the name-to-options mapping not to change *even if UseCOH were enabled by default*. So, _classes.jsa_ is not the "default jsa" but explicitly and always signifies the jsa with +coops -coh. > > The new configure option `--(enable|disable)-cds-archive-coh` allows you to enable/disable the generation of COH archives. By default, it is enabled if the underlying platform supports COH (64-bit) and if standard CDS archive generation is enabled (e.g., not for cross-compilation). > > Note that the upcoming JEP "CDS Archived Object Streaming" ([JDK-8326035](https://bugs.openjdk.org/browse/JDK-8326035)) will eliminate the +-Coops distinction, thus reducing the number of CDS archives. It may also eliminate the +-COH distinction at some point, though that is harder. > > But that JEP has to be developed and shipped first. After that, it will run alongside the old implementation for a while, which we keep as a fallback. Only if it is the sole remaining way to load CDS archives can we cut down the number of jsa archives. Until then, I propose to keep +-COH archives in addition to +-Coops archives. Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: copyright changes ------------- Changes: - all: https://git.openjdk.org/lilliput/pull/145/files - new: https://git.openjdk.org/lilliput/pull/145/files/e6e18163..9a09dd1c Webrevs: - full: https://webrevs.openjdk.org/?repo=lilliput&pr=145&range=01 - incr: https://webrevs.openjdk.org/?repo=lilliput&pr=145&range=00-01 Stats: 4 lines in 4 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/lilliput/pull/145.diff Fetch: git fetch https://git.openjdk.org/lilliput.git pull/145/head:pull/145 PR: https://git.openjdk.org/lilliput/pull/145 From stuefe at openjdk.org Tue Mar 26 11:16:44 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 26 Mar 2024 11:16:44 GMT Subject: [master] RFR: JDK-8325104: Lilliput: Shrink Classpointers [v3] In-Reply-To: References: Message-ID: On Mon, 25 Mar 2024 16:27:37 GMT, Stefan Karlsson wrote: >> Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: >> >> - Roman feedback - small stuff >> - Merge branch 'master' into Smaller-ClassPointers >> - revert COH archive generation >> - Remove files that accidentally slipped in >> - Merge branch 'master' into Smaller-ClassPointers >> - Merge >> - Merge commit 'c1281e6b45ed167df69d29a6039d81854c145ae6~1' into Smaller-ClassPointers >> - Fix Typo >> - Better CDS arch generation >> - Fix error in COH archive generation >> - ... and 10 more: https://git.openjdk.org/lilliput/compare/b2fcfb73...1260f2d6 > > src/hotspot/share/oops/oop.hpp line 345: > >> 343: constexpr int load_shift = markWord::klass_load_shift; >> 344: STATIC_ASSERT(load_shift % 8 == 0); >> 345: return mark_offset_in_bytes() + load_shift / 8; > > Isn't this broken for big-endian machines? The follow-up question then is, should we really be reading the klass pointer with 32-bit loads? If we load the entire 64-bit "object header" and then shift with `klass_shift`, we wouldn't have to think about endianess, right? Do we keep the 32-bit load because we don't want to mess with C2? There was a technical problem when I developed the patch, which is that a klass_offset_in_bytes needed to be != mark_offset_in_bytes. See e.g. `Compile::flatten_alias_type`, but I believe there had been other places. Then, a 32-bit load can possibly be encoded with fewer bytes, no? I am not sure if it would be faster beyond that distinction, however. ------------- PR Review Comment: https://git.openjdk.org/lilliput/pull/128#discussion_r1539029186 From rkennke at openjdk.org Tue Mar 26 11:26:43 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 26 Mar 2024 11:26:43 GMT Subject: [master] RFR: JDK-8328886: Lilliput: Build COH archives [v2] In-Reply-To: References: Message-ID: <-ABlvj8t-Qk3RxFdewJjGurFIvqPrbW7aUrmfahmo5o=.cdb8527b-e97b-4d7f-83bc-4cd426b01bb8@github.com> On Tue, 26 Mar 2024 10:49:51 GMT, Thomas Stuefe wrote: >> This is a breakout from and a prerequisite for [JDK-8325104](https://bugs.openjdk.org/browse/JDK-8325104). >> >> To run with +COH and CDS enabled, and to enable tests testing this combination, we need to build archives with +COH too. >> >> This patch expands the number of archives built to four: >> >> a) **classes.jsa** (+UseCompressedClassPointers, -UseCompactObjectHeaders) >> b) **classes_nocoops.jsa** (-UseCompressedClassPointers, -UseCompactObjectHeaders) >> c) **classes_coh.jsa** (+UseCompressedClassPointers, +UseCompactObjectHeaders) >> d) **classes_nocoops_coh.jsa** (-UseCompressedClassPointers, +UseCompactObjectHeaders) >> >> Naming could be more logical, but my aim was to keep compatibility with upstream archive names (no functional or name changes for *classes.jsa* and *classes_nocoops.jsa*). >> >> Another design goal was for the name-to-options mapping not to change *even if UseCOH were enabled by default*. So, _classes.jsa_ is not the "default jsa" but explicitly and always signifies the jsa with +coops -coh. >> >> The new configure option `--(enable|disable)-cds-archive-coh` allows you to enable/disable the generation of COH archives. By default, it is enabled if the underlying platform supports COH (64-bit) and if standard CDS archive generation is enabled (e.g., not for cross-compilation). >> >> Note that the upcoming JEP "CDS Archived Object Streaming" ([JDK-8326035](https://bugs.openjdk.org/browse/JDK-8326035)) will eliminate the +-Coops distinction, thus reducing the number of CDS archives. It may also eliminate the +-COH distinction at some point, though that is harder. >> >> But that JEP has to be developed and shipped first. After that, it will run alongside the old implementation for a while, which we keep as a fallback. Only if it is the sole remaining way to load CDS archives can we cut down the number of jsa archives. Until then, I propose to keep +-COH archives in addition to +-Coops archives. > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > copyright changes Looks good, but I have a question. make/Images.gmk line 137: > 135: $1_$2_COOPS_OPTION := $(if $(findstring _nocoops, $2),-XX:-UseCompressedOops) > 136: # enable and also explicitly disable coh as needed. > 137: ifeq ($(call isTargetCpuBits, 64), true) Not all 64-bit platforms currently support COH. Only aarch64 and x86_64 do. Would that be a problem? ------------- PR Review: https://git.openjdk.org/lilliput/pull/145#pullrequestreview-1960071477 PR Review Comment: https://git.openjdk.org/lilliput/pull/145#discussion_r1539039149 From rkennke at openjdk.org Tue Mar 26 13:27:58 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 26 Mar 2024 13:27:58 GMT Subject: [lilliput-jdk21u:lilliput] RFR: 8329091: [Lilliput/JDK21] Fix tests after LM_LIGHTWEIGHT backports Message-ID: A few tests explicitely test LM_LIGHTWEIGHT locking-mode. In JDK22, LM_LIGHTWEIGHT became a non-experimental product option. Some tests that have been backported from JDK>=22 requires -XX:+UnlockExperimentalVMOptions in JDK21. Testing: - [ ] tier1 - [ ] tier2 ------------- Commit messages: - 8329091: [Lilliput/JDK21] Fix tests after LM_LIGHTWEIGHT backports Changes: https://git.openjdk.org/lilliput-jdk21u/pull/29/files Webrev: https://webrevs.openjdk.org/?repo=lilliput-jdk21u&pr=29&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8329091 Stats: 6 lines in 3 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/lilliput-jdk21u/pull/29.diff Fetch: git fetch https://git.openjdk.org/lilliput-jdk21u.git pull/29/head:pull/29 PR: https://git.openjdk.org/lilliput-jdk21u/pull/29 From stefank at openjdk.org Tue Mar 26 13:36:38 2024 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 26 Mar 2024 13:36:38 GMT Subject: [master] RFR: JDK-8325104: Lilliput: Shrink Classpointers [v3] In-Reply-To: References: Message-ID: On Tue, 26 Mar 2024 11:13:29 GMT, Thomas Stuefe wrote: >> src/hotspot/share/oops/oop.hpp line 345: >> >>> 343: constexpr int load_shift = markWord::klass_load_shift; >>> 344: STATIC_ASSERT(load_shift % 8 == 0); >>> 345: return mark_offset_in_bytes() + load_shift / 8; >> >> Isn't this broken for big-endian machines? The follow-up question then is, should we really be reading the klass pointer with 32-bit loads? If we load the entire 64-bit "object header" and then shift with `klass_shift`, we wouldn't have to think about endianess, right? Do we keep the 32-bit load because we don't want to mess with C2? > > There was a technical problem when I developed the patch, which is that a klass_offset_in_bytes needed to be != mark_offset_in_bytes. See e.g. `Compile::flatten_alias_type`, but I believe there had been other places. > > Then, a 32-bit load can possibly be encoded with fewer bytes, no? I am not sure if it would be faster beyond that distinction, however. I still think it is odd that we return that the klass offset is 4 on big-endian machines. If we ever really try to read the klass at (obj + klass_offset_in_bytes()) on those machines we will not get the klass bits, instead we will get some of the other bits in the object header. My inquiries were more if it really was a good idea to load the klass with 4 byte loads and that it seems safer (more platform independent) to stick with 8 byte loads. When we use 8 byte loads and shifts we don't have to think about endianess. I glanced in the C2 code how klass_byte_in_offset is used. It looks like most places were `klass_offset_in_bytes()` is used, it is used as a sort of a token to figure out that the load (obj + offset) should be interpreted as a load of the klass. We don't actually use that offset for the load / decode of the klass. Instead we perform an 8 byte load from the start of the object, with associated 8 byte shift operation. So, maybe my concern here is more that the name "klass_offset_in_bytes" is a bit misleading as it sounds like this is the offset where the klass bits are located. Code using klass_offset_in_bytes() really need to be written with the understanding that this is the case. ------------- PR Review Comment: https://git.openjdk.org/lilliput/pull/128#discussion_r1539244106 From stuefe at openjdk.org Tue Mar 26 13:45:03 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 26 Mar 2024 13:45:03 GMT Subject: [master] RFR: JDK-8328886: Lilliput: Build COH archives [v3] In-Reply-To: References: Message-ID: > This is a breakout from and a prerequisite for [JDK-8325104](https://bugs.openjdk.org/browse/JDK-8325104). > > To run with +COH and CDS enabled, and to enable tests testing this combination, we need to build archives with +COH too. > > This patch expands the number of archives built to four: > > a) **classes.jsa** (+UseCompressedClassPointers, -UseCompactObjectHeaders) > b) **classes_nocoops.jsa** (-UseCompressedClassPointers, -UseCompactObjectHeaders) > c) **classes_coh.jsa** (+UseCompressedClassPointers, +UseCompactObjectHeaders) > d) **classes_nocoops_coh.jsa** (-UseCompressedClassPointers, +UseCompactObjectHeaders) > > Naming could be more logical, but my aim was to keep compatibility with upstream archive names (no functional or name changes for *classes.jsa* and *classes_nocoops.jsa*). > > Another design goal was for the name-to-options mapping not to change *even if UseCOH were enabled by default*. So, _classes.jsa_ is not the "default jsa" but explicitly and always signifies the jsa with +coops -coh. > > The new configure option `--(enable|disable)-cds-archive-coh` allows you to enable/disable the generation of COH archives. By default, it is enabled if the underlying platform supports COH (64-bit) and if standard CDS archive generation is enabled (e.g., not for cross-compilation). > > Note that the upcoming JEP "CDS Archived Object Streaming" ([JDK-8326035](https://bugs.openjdk.org/browse/JDK-8326035)) will eliminate the +-Coops distinction, thus reducing the number of CDS archives. It may also eliminate the +-COH distinction at some point, though that is harder. > > But that JEP has to be developed and shipped first. After that, it will run alongside the old implementation for a while, which we keep as a fallback. Only if it is the sole remaining way to load CDS archives can we cut down the number of jsa archives. Until then, I propose to keep +-COH archives in addition to +-Coops archives. Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: Build COH archives only on x64 and aarch64 ------------- Changes: - all: https://git.openjdk.org/lilliput/pull/145/files - new: https://git.openjdk.org/lilliput/pull/145/files/9a09dd1c..ad7053dd Webrevs: - full: https://webrevs.openjdk.org/?repo=lilliput&pr=145&range=02 - incr: https://webrevs.openjdk.org/?repo=lilliput&pr=145&range=01-02 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.org/lilliput/pull/145.diff Fetch: git fetch https://git.openjdk.org/lilliput.git pull/145/head:pull/145 PR: https://git.openjdk.org/lilliput/pull/145 From stuefe at openjdk.org Tue Mar 26 13:49:31 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 26 Mar 2024 13:49:31 GMT Subject: [master] RFR: JDK-8328886: Lilliput: Build COH archives [v2] In-Reply-To: <-ABlvj8t-Qk3RxFdewJjGurFIvqPrbW7aUrmfahmo5o=.cdb8527b-e97b-4d7f-83bc-4cd426b01bb8@github.com> References: <-ABlvj8t-Qk3RxFdewJjGurFIvqPrbW7aUrmfahmo5o=.cdb8527b-e97b-4d7f-83bc-4cd426b01bb8@github.com> Message-ID: On Tue, 26 Mar 2024 11:22:06 GMT, Roman Kennke wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> copyright changes > > make/Images.gmk line 137: > >> 135: $1_$2_COOPS_OPTION := $(if $(findstring _nocoops, $2),-XX:-UseCompressedOops) >> 136: # enable and also explicitly disable coh as needed. >> 137: ifeq ($(call isTargetCpuBits, 64), true) > > Not all 64-bit platforms currently support COH. Only aarch64 and x86_64 do. Would that be a problem? Okay, fixed and tested. We now only build COH archives when on x64 or on aarch64, and for the latter, only when not crossbuilding. Tested on Linux x64 (for x64, x32, aarch64 crossbuild) and Mac m1 (aarch64 native) ------------- PR Review Comment: https://git.openjdk.org/lilliput/pull/145#discussion_r1539271588 From rkennke at openjdk.org Tue Mar 26 13:57:34 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 26 Mar 2024 13:57:34 GMT Subject: [master] RFR: JDK-8328886: Lilliput: Build COH archives [v3] In-Reply-To: References: Message-ID: On Tue, 26 Mar 2024 13:45:03 GMT, Thomas Stuefe wrote: >> This is a breakout from and a prerequisite for [JDK-8325104](https://bugs.openjdk.org/browse/JDK-8325104). >> >> To run with +COH and CDS enabled, and to enable tests testing this combination, we need to build archives with +COH too. >> >> This patch expands the number of archives built to four: >> >> a) **classes.jsa** (+UseCompressedClassPointers, -UseCompactObjectHeaders) >> b) **classes_nocoops.jsa** (-UseCompressedClassPointers, -UseCompactObjectHeaders) >> c) **classes_coh.jsa** (+UseCompressedClassPointers, +UseCompactObjectHeaders) >> d) **classes_nocoops_coh.jsa** (-UseCompressedClassPointers, +UseCompactObjectHeaders) >> >> Naming could be more logical, but my aim was to keep compatibility with upstream archive names (no functional or name changes for *classes.jsa* and *classes_nocoops.jsa*). >> >> Another design goal was for the name-to-options mapping not to change *even if UseCOH were enabled by default*. So, _classes.jsa_ is not the "default jsa" but explicitly and always signifies the jsa with +coops -coh. >> >> The new configure option `--(enable|disable)-cds-archive-coh` allows you to enable/disable the generation of COH archives. By default, it is enabled if the underlying platform supports COH (64-bit) and if standard CDS archive generation is enabled (e.g., not for cross-compilation). >> >> Note that the upcoming JEP "CDS Archived Object Streaming" ([JDK-8326035](https://bugs.openjdk.org/browse/JDK-8326035)) will eliminate the +-Coops distinction, thus reducing the number of CDS archives. It may also eliminate the +-COH distinction at some point, though that is harder. >> >> But that JEP has to be developed and shipped first. After that, it will run alongside the old implementation for a while, which we keep as a fallback. Only if it is the sole remaining way to load CDS archives can we cut down the number of jsa archives. Until then, I propose to keep +-COH archives in addition to +-Coops archives. > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Build COH archives only on x64 and aarch64 Looks good now, thanks! ------------- Marked as reviewed by rkennke (Lead). PR Review: https://git.openjdk.org/lilliput/pull/145#pullrequestreview-1960477859 From stuefe at openjdk.org Tue Mar 26 14:01:35 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 26 Mar 2024 14:01:35 GMT Subject: [master] RFR: JDK-8328886: Lilliput: Build COH archives [v3] In-Reply-To: References: Message-ID: On Tue, 26 Mar 2024 13:54:35 GMT, Roman Kennke wrote: > Looks good now, thanks! Okay, will wait for GHAs to finish, then push. ------------- PR Comment: https://git.openjdk.org/lilliput/pull/145#issuecomment-2020506263 From stefank at openjdk.org Tue Mar 26 14:01:38 2024 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 26 Mar 2024 14:01:38 GMT Subject: [master] RFR: JDK-8325104: Lilliput: Shrink Classpointers [v3] In-Reply-To: References: Message-ID: <1ehNRvSE2Szu3FYIia54ni9InAKOHqcy5pq_58t5k7w=.406772cc-3d5a-4a3c-accc-5c747a89d40a@github.com> On Mon, 25 Mar 2024 14:51:14 GMT, Thomas Stuefe wrote: >> Hi, >> >> I wanted to get input on the following improvement for Lilliput. Testing is still ongoing, but things look really good, so this patch is hopefully near its final form (barring any objections from reviewers, of course). >> >> Note: I have a companion patch prepared for upstream, minus the markword changes. I will attempt to get that one upstream quickly in order to not have a large delta between upstream and lilliput, especially in Metaspace. >> >> ## High-Level Overview >> >> (for a short sequence of slides, please see https://github.com/tstuefe/fosdem24/blob/master/classpointers-and-liliput.pdf - these accompanied a talk we held at FOSDEM 24). >> >> We want to reduce the bit size of narrow Klass to free up bits in the MarkWord. >> >> We cannot just reduce the Klass encoding range size (well, we could, and maybe we will later, but for now we decided not to). We instead increase the alignment Klass is stored at, and use that alignment shadow to store other information. >> >> In other words, this patch changes the narrow Klass Pointer to a Klass ID, since now (almost) every value in its value range points to a different class. Therefore, we use the value range of nKlass much more efficiently. >> >> We then use the newly freed bits in the MarkWord to restore the iHash to 31 bits: >> >> >> [ 22-bit nKlass | 31-bit iHash | 4 free bits | age | fwd | lck ] >> >> nKlass gets reduced to 22 bits. Identity hash gets re-inflated to 31 bits. Preceding iHash are now 4 unused bits. Rest is unchanged. >> >> (Note: I originally wanted to swap iHash and nKlass such that either of them could be loaded with a 32-bit load, but I found that tricky since C2 seems to rely on the nKlass offset in the Markword being > 0.) >> >> ## nKlass reduction: >> >> The reduction in nKlass size is made by only storing them at 10-bit aligned addresses. That alignment (1KB) works well in practice since Klass - although var sized - typically is between 512 bytes and 1KB in size. Outliers are possible, but the size distribution is bell-curvish [1], so far-away outliers are very rare. >> >> To not lose memory to alignment waste, metaspace is reshaped to handle arbitrarily aligned allocations efficiently. Basically, we allow the non-Klass arena of a class loader to steal the alignment waste storage from the class arena. So, alignment waste blocks are filled with non-Klass metadata. That works very well in practice since non-Klass metadata is numerous and fine-granular compared to the big Klass bloc... > > Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: > > - Roman feedback - small stuff > - Merge branch 'master' into Smaller-ClassPointers > - revert COH archive generation > - Remove files that accidentally slipped in > - Merge branch 'master' into Smaller-ClassPointers > - Merge > - Merge commit 'c1281e6b45ed167df69d29a6039d81854c145ae6~1' into Smaller-ClassPointers > - Fix Typo > - Better CDS arch generation > - Fix error in COH archive generation > - ... and 10 more: https://git.openjdk.org/lilliput/compare/b2fcfb73...1260f2d6 Hi Thomas, I've started to read through the patch but are far from done. I'm sending a few early comments / questions / suggestions. src/hotspot/share/oops/compressedKlass.cpp line 49: > 47: address CompressedKlassPointers::_base = (address)-1; > 48: int CompressedKlassPointers::_shift = -1; > 49: size_t CompressedKlassPointers::_range = (size_t)-1; Doesn't this put 0x00000000FFFFFFFF in this size_t? I guess this works with the code using it, but it is not obvious that this is what we intended to put into the _range variable as the (uninitialized) value. Related to this. How important is it to do these initialized checks? It seems to add casts and a bit odd code. When this is stable, wouldn't it be nice to clean this up. That would also make _tiny_cp a bool instead of a tri-bool. src/hotspot/share/oops/compressedKlass.hpp line 42: > 40: > 41: // Tiny-class-pointer mode > 42: static int _tiny_cp; // -1, 0=true, 1=false This comment seems wrong. I think it should be `0=false, 1=true`. src/hotspot/share/oops/compressedKlass.hpp line 50: > 48: // Narrow klass pointer bits for an unshifted narrow Klass pointer. > 49: static constexpr int narrow_klass_pointer_bits_legacy = 32; > 50: static constexpr int narrow_klass_pointer_bits_tinycp = 22; It might be nice to have a consistent naming between `*_tinycp` and `_tiny_cp`. src/hotspot/share/oops/compressedKlass.hpp line 128: > 126: > 127: // The maximum possible shift; the actual shift employed later can be smaller (see initialize()) > 128: static int max_shift() { check_init(_max_shift); return _max_shift; } FWIW, you could get rid of the variable name duplication if we changed this to be something like `{ return read_check_init(_max_shift); }` instead. ------------- PR Review: https://git.openjdk.org/lilliput/pull/128#pullrequestreview-1960456794 PR Review Comment: https://git.openjdk.org/lilliput/pull/128#discussion_r1539272989 PR Review Comment: https://git.openjdk.org/lilliput/pull/128#discussion_r1539275135 PR Review Comment: https://git.openjdk.org/lilliput/pull/128#discussion_r1539277333 PR Review Comment: https://git.openjdk.org/lilliput/pull/128#discussion_r1539280234 From rkennke at openjdk.org Tue Mar 26 14:57:51 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 26 Mar 2024 14:57:51 GMT Subject: [master] RFR: JDK-8325104: Lilliput: Shrink Classpointers [v3] In-Reply-To: References: Message-ID: On Tue, 26 Mar 2024 13:34:24 GMT, Stefan Karlsson wrote: >> There was a technical problem when I developed the patch, which is that a klass_offset_in_bytes needed to be != mark_offset_in_bytes. See e.g. `Compile::flatten_alias_type`, but I believe there had been other places. >> >> Then, a 32-bit load can possibly be encoded with fewer bytes, no? I am not sure if it would be faster beyond that distinction, however. > > I still think it is odd that we return that the klass offset is 4 on big-endian machines. If we ever really try to read the klass at (obj + klass_offset_in_bytes()) on those machines we will not get the klass bits, instead we will get some of the other bits in the object header. > > My inquiries were more if it really was a good idea to load the klass with 4 byte loads and that it seems safer (more platform independent) to stick with 8 byte loads. When we use 8 byte loads and shifts we don't have to think about endianess. > > I glanced in the C2 code how klass_byte_in_offset is used. It looks like most places were `klass_offset_in_bytes()` is used, it is used as a sort of a token to figure out that the load (obj + offset) should be interpreted as a load of the klass. We don't actually use that offset for the load / decode of the klass. Instead we perform an 8 byte load from the start of the object, with associated 8 byte shift operation. > > So, maybe my concern here is more that the name "klass_offset_in_bytes" is a bit misleading as it sounds like this is the offset where the klass bits are located. Code using klass_offset_in_bytes() really need to be written with the understanding that this is the case. The trouble with C2 is that, currently, loading the Klass* (pre-lilliput) has its own memory slice, and is totally immutable. With Lilliput, we currently load the Klass* from the mark-word, and need to deal with header displacement in ObjectMonitors. This currently happens in the backend and is totally opaque to C2 IR. However, it all *could* be done in C2 IR, even more so when we get the OMWorld stuff. Then the loads would happen on their true memory slice (the mark-word) and we would do the shifting/masking in IR, too. But it is questionable if we want to do so. The fact that Load(N)Klass can currently be treated as immutable makes the node freely moving in the ideal graph. Wiring it up in the same slice as mark-word loads means that we would have to re-load the Klass* after anything that would potentially touch the mark-word, especially safepoints, calls, etc. even though we know that the actual Klass* portion of the mark-word is still, in-fact, immutable. Therefore I believe it is better to keep the LoadKlass stuff on its own memory slice, with its own offset, even if we never actually load from that offset. offset=4 is a good choice for that, because it would never clash with a true offset of a field. Long-term, something like offset=1 or 2 may be better, when we want to do 4-byte headers, fie lds may start ot offset=4. Also note the weird dance that we need to do in C2 .ad files to figure out the true offset. :-/ We should run this by some C2 experts to figure out the best way to deal with all that. ------------- PR Review Comment: https://git.openjdk.org/lilliput/pull/128#discussion_r1539420415 From stuefe at openjdk.org Tue Mar 26 15:33:32 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 26 Mar 2024 15:33:32 GMT Subject: [master] RFR: JDK-8325104: Lilliput: Shrink Classpointers [v3] In-Reply-To: <1ehNRvSE2Szu3FYIia54ni9InAKOHqcy5pq_58t5k7w=.406772cc-3d5a-4a3c-accc-5c747a89d40a@github.com> References: <1ehNRvSE2Szu3FYIia54ni9InAKOHqcy5pq_58t5k7w=.406772cc-3d5a-4a3c-accc-5c747a89d40a@github.com> Message-ID: <4srWbNs5z4fEDECNONFw83WcKPLuYqOSgCa_YoNjMOY=.c2b25b41-e3e0-4387-98b0-c0c45c93f847@github.com> On Tue, 26 Mar 2024 13:59:05 GMT, Stefan Karlsson wrote: > Hi Thomas, I've started to read through the patch but are far from done. I'm sending a few early comments / questions / suggestions. Many thanks, Stefan. I have to interleave work on this patch with a ton of other stuff, so I may be slow answering. B ut your reviews are appreciated. ------------- PR Comment: https://git.openjdk.org/lilliput/pull/128#issuecomment-2020754157 From stuefe at openjdk.org Tue Mar 26 15:33:45 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 26 Mar 2024 15:33:45 GMT Subject: [master] RFR: JDK-8328886: Lilliput: Build COH archives [v3] In-Reply-To: References: Message-ID: <7Mw0V53YKcr-xXVmiiQlHlqyUL6g1ZZDiVJ7cgalxAA=.bc773c0a-3701-4c71-ba7a-091eff50e4f4@github.com> On Tue, 26 Mar 2024 13:45:03 GMT, Thomas Stuefe wrote: >> This is a breakout from and a prerequisite for [JDK-8325104](https://bugs.openjdk.org/browse/JDK-8325104). >> >> To run with +COH and CDS enabled, and to enable tests testing this combination, we need to build archives with +COH too. >> >> This patch expands the number of archives built to four: >> >> a) **classes.jsa** (+UseCompressedClassPointers, -UseCompactObjectHeaders) >> b) **classes_nocoops.jsa** (-UseCompressedClassPointers, -UseCompactObjectHeaders) >> c) **classes_coh.jsa** (+UseCompressedClassPointers, +UseCompactObjectHeaders) >> d) **classes_nocoops_coh.jsa** (-UseCompressedClassPointers, +UseCompactObjectHeaders) >> >> Naming could be more logical, but my aim was to keep compatibility with upstream archive names (no functional or name changes for *classes.jsa* and *classes_nocoops.jsa*). >> >> Another design goal was for the name-to-options mapping not to change *even if UseCOH were enabled by default*. So, _classes.jsa_ is not the "default jsa" but explicitly and always signifies the jsa with +coops -coh. >> >> The new configure option `--(enable|disable)-cds-archive-coh` allows you to enable/disable the generation of COH archives. By default, it is enabled if the underlying platform supports COH (64-bit) and if standard CDS archive generation is enabled (e.g., not for cross-compilation). >> >> Note that the upcoming JEP "CDS Archived Object Streaming" ([JDK-8326035](https://bugs.openjdk.org/browse/JDK-8326035)) will eliminate the +-Coops distinction, thus reducing the number of CDS archives. It may also eliminate the +-COH distinction at some point, though that is harder. >> >> But that JEP has to be developed and shipped first. After that, it will run alongside the old implementation for a while, which we keep as a fallback. Only if it is the sole remaining way to load CDS archives can we cut down the number of jsa archives. Until then, I propose to keep +-COH archives in addition to +-Coops archives. > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Build COH archives only on x64 and aarch64 Remaining x86 problems unrelated. ------------- PR Comment: https://git.openjdk.org/lilliput/pull/145#issuecomment-2020749270 From stuefe at openjdk.org Tue Mar 26 15:33:46 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 26 Mar 2024 15:33:46 GMT Subject: [master] Integrated: JDK-8328886: Lilliput: Build COH archives In-Reply-To: References: Message-ID: On Mon, 25 Mar 2024 13:24:35 GMT, Thomas Stuefe wrote: > This is a breakout from and a prerequisite for [JDK-8325104](https://bugs.openjdk.org/browse/JDK-8325104). > > To run with +COH and CDS enabled, and to enable tests testing this combination, we need to build archives with +COH too. > > This patch expands the number of archives built to four: > > a) **classes.jsa** (+UseCompressedClassPointers, -UseCompactObjectHeaders) > b) **classes_nocoops.jsa** (-UseCompressedClassPointers, -UseCompactObjectHeaders) > c) **classes_coh.jsa** (+UseCompressedClassPointers, +UseCompactObjectHeaders) > d) **classes_nocoops_coh.jsa** (-UseCompressedClassPointers, +UseCompactObjectHeaders) > > Naming could be more logical, but my aim was to keep compatibility with upstream archive names (no functional or name changes for *classes.jsa* and *classes_nocoops.jsa*). > > Another design goal was for the name-to-options mapping not to change *even if UseCOH were enabled by default*. So, _classes.jsa_ is not the "default jsa" but explicitly and always signifies the jsa with +coops -coh. > > The new configure option `--(enable|disable)-cds-archive-coh` allows you to enable/disable the generation of COH archives. By default, it is enabled if the underlying platform supports COH (64-bit) and if standard CDS archive generation is enabled (e.g., not for cross-compilation). > > Note that the upcoming JEP "CDS Archived Object Streaming" ([JDK-8326035](https://bugs.openjdk.org/browse/JDK-8326035)) will eliminate the +-Coops distinction, thus reducing the number of CDS archives. It may also eliminate the +-COH distinction at some point, though that is harder. > > But that JEP has to be developed and shipped first. After that, it will run alongside the old implementation for a while, which we keep as a fallback. Only if it is the sole remaining way to load CDS archives can we cut down the number of jsa archives. Until then, I propose to keep +-COH archives in addition to +-Coops archives. This pull request has now been integrated. Changeset: e331ea1b Author: Thomas Stuefe URL: https://git.openjdk.org/lilliput/commit/e331ea1b85a07ba6f52dc0dbdc6499451cb34ad7 Stats: 185 lines in 6 files changed: 171 ins; 0 del; 14 mod 8328886: Lilliput: Build COH archives Reviewed-by: rkennke ------------- PR: https://git.openjdk.org/lilliput/pull/145 From shade at openjdk.org Tue Mar 26 17:05:32 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 26 Mar 2024 17:05:32 GMT Subject: [lilliput-jdk21u:lilliput] RFR: 8329091: [Lilliput/JDK21] Fix tests after LM_LIGHTWEIGHT backports In-Reply-To: References: Message-ID: On Tue, 26 Mar 2024 13:23:41 GMT, Roman Kennke wrote: > A few tests explicitely test LM_LIGHTWEIGHT locking-mode. In JDK22, LM_LIGHTWEIGHT became a non-experimental product option. Some tests that have been backported from JDK>=22 requires -XX:+UnlockExperimentalVMOptions in JDK21. > > Testing: > - [x] tier1 > - [ ] tier2 test/jdk/com/sun/jdi/EATests.java line 2002: > 2000: lockInflatedByContention = new XYVal(1, 1); > 2001: // Start thread that tries to enter lockInflatedByContention while the main thread owns it -> inflation > 2002: TestScaffold.newThread(() -> { Is this neccessary? ------------- PR Review Comment: https://git.openjdk.org/lilliput-jdk21u/pull/29#discussion_r1539746367 From rkennke at openjdk.org Tue Mar 26 17:18:37 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 26 Mar 2024 17:18:37 GMT Subject: [lilliput-jdk21u:lilliput] RFR: 8329091: [Lilliput/JDK21] Fix tests after LM_LIGHTWEIGHT backports In-Reply-To: References: Message-ID: On Tue, 26 Mar 2024 17:03:09 GMT, Aleksey Shipilev wrote: >> A few tests explicitely test LM_LIGHTWEIGHT locking-mode. In JDK22, LM_LIGHTWEIGHT became a non-experimental product option. Some tests that have been backported from JDK>=22 requires -XX:+UnlockExperimentalVMOptions in JDK21. >> >> Testing: >> - [x] tier1 >> - [x] tier2 > > test/jdk/com/sun/jdi/EATests.java line 2002: > >> 2000: lockInflatedByContention = new XYVal(1, 1); >> 2001: // Start thread that tries to enter lockInflatedByContention while the main thread owns it -> inflation >> 2002: TestScaffold.newThread(() -> { > > Is this neccessary? Yes, DebuggeeWrapper doesn't exist in 21. I believe it's a rename from 'TestScaffold'. ------------- PR Review Comment: https://git.openjdk.org/lilliput-jdk21u/pull/29#discussion_r1539766180 From shade at openjdk.org Tue Mar 26 18:38:34 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 26 Mar 2024 18:38:34 GMT Subject: [lilliput-jdk21u:lilliput] RFR: 8329091: [Lilliput/JDK21] Fix tests after LM_LIGHTWEIGHT backports In-Reply-To: References: Message-ID: <-71du9opIc6EAtu7YgqPBhfgHdGt2TAV3d1NwWWxy0k=.c63442c7-e65a-4e20-9309-4a255ffd3344@github.com> On Tue, 26 Mar 2024 13:23:41 GMT, Roman Kennke wrote: > A few tests explicitely test LM_LIGHTWEIGHT locking-mode. In JDK22, LM_LIGHTWEIGHT became a non-experimental product option. Some tests that have been backported from JDK>=22 requires -XX:+UnlockExperimentalVMOptions in JDK21. > > Testing: > - [x] tier1 > - [x] tier2 Marked as reviewed by shade (Committer). ------------- PR Review: https://git.openjdk.org/lilliput-jdk21u/pull/29#pullrequestreview-1961394243 From shade at openjdk.org Tue Mar 26 18:38:34 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 26 Mar 2024 18:38:34 GMT Subject: [lilliput-jdk21u:lilliput] RFR: 8329091: [Lilliput/JDK21] Fix tests after LM_LIGHTWEIGHT backports In-Reply-To: References: Message-ID: On Tue, 26 Mar 2024 17:16:22 GMT, Roman Kennke wrote: >> test/jdk/com/sun/jdi/EATests.java line 2002: >> >>> 2000: lockInflatedByContention = new XYVal(1, 1); >>> 2001: // Start thread that tries to enter lockInflatedByContention while the main thread owns it -> inflation >>> 2002: TestScaffold.newThread(() -> { >> >> Is this neccessary? > > Yes, DebuggeeWrapper doesn't exist in 21. I believe it's a rename from 'TestScaffold'. Yes: https://github.com/openjdk/jdk/commit/ee9776fa23e2287b704d4f1a55179e83516d1e4c ------------- PR Review Comment: https://git.openjdk.org/lilliput-jdk21u/pull/29#discussion_r1539895596 From rkennke at openjdk.org Tue Mar 26 18:57:35 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 26 Mar 2024 18:57:35 GMT Subject: [lilliput-jdk21u:lilliput] RFR: 8329091: [Lilliput/JDK21] Fix tests after LM_LIGHTWEIGHT backports In-Reply-To: References: Message-ID: On Tue, 26 Mar 2024 13:23:41 GMT, Roman Kennke wrote: > A few tests explicitely test LM_LIGHTWEIGHT locking-mode. In JDK22, LM_LIGHTWEIGHT became a non-experimental product option. Some tests that have been backported from JDK>=22 requires -XX:+UnlockExperimentalVMOptions in JDK21. > > Testing: > - [x] tier1 > - [x] tier2 Thanks! ------------- PR Comment: https://git.openjdk.org/lilliput-jdk21u/pull/29#issuecomment-2021237549 From rkennke at openjdk.org Tue Mar 26 18:57:35 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 26 Mar 2024 18:57:35 GMT Subject: [lilliput-jdk21u:lilliput] Integrated: 8329091: [Lilliput/JDK21] Fix tests after LM_LIGHTWEIGHT backports In-Reply-To: References: Message-ID: <4DTxy4dB9o2-Lia4V4rb8cg4if-HMV8cKn955BYMchE=.43d97477-e8af-4f03-9ad6-3c64e9ff8d9d@github.com> On Tue, 26 Mar 2024 13:23:41 GMT, Roman Kennke wrote: > A few tests explicitely test LM_LIGHTWEIGHT locking-mode. In JDK22, LM_LIGHTWEIGHT became a non-experimental product option. Some tests that have been backported from JDK>=22 requires -XX:+UnlockExperimentalVMOptions in JDK21. > > Testing: > - [x] tier1 > - [x] tier2 This pull request has now been integrated. Changeset: f40c90ae Author: Roman Kennke URL: https://git.openjdk.org/lilliput-jdk21u/commit/f40c90aececf7c8f3bccb7d8965d23257306d959 Stats: 6 lines in 3 files changed: 0 ins; 0 del; 6 mod 8329091: [Lilliput/JDK21] Fix tests after LM_LIGHTWEIGHT backports Reviewed-by: shade ------------- PR: https://git.openjdk.org/lilliput-jdk21u/pull/29 From stefank at openjdk.org Wed Mar 27 08:52:39 2024 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 27 Mar 2024 08:52:39 GMT Subject: [master] RFR: JDK-8325104: Lilliput: Shrink Classpointers [v3] In-Reply-To: <1ehNRvSE2Szu3FYIia54ni9InAKOHqcy5pq_58t5k7w=.406772cc-3d5a-4a3c-accc-5c747a89d40a@github.com> References: <1ehNRvSE2Szu3FYIia54ni9InAKOHqcy5pq_58t5k7w=.406772cc-3d5a-4a3c-accc-5c747a89d40a@github.com> Message-ID: On Tue, 26 Mar 2024 13:47:28 GMT, Stefan Karlsson wrote: > Doesn't this put 0x00000000FFFFFFFF in this size_t? Ignore that. I checked and this is signed extended out to 0xFFFFFFFFFFFFFFFF. ------------- PR Review Comment: https://git.openjdk.org/lilliput/pull/128#discussion_r1540690140 From rkennke at openjdk.org Wed Mar 27 09:22:52 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Wed, 27 Mar 2024 09:22:52 GMT Subject: [lilliput-jdk21u:lilliput] RFR: 8319799: Recursive lightweight locking: x86 implementation [v2] In-Reply-To: References: Message-ID: > Hi all, > > This pull request contains a backport of commit [7f6bb71e](https://github.com/openjdk/jdk/commit/7f6bb71eb302e8388c959bdaa914b758a766d299) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > Backport wasn't 100% clean due to context differences (includes and the LoadNKlass stubs that are only in Lilliput), and trivial to fix. > > The commit being backported was authored by Axel Boldt-Christmas on 14 Feb 2024 and was reviewed by Roman Kennke, Coleen Phillimore and Daniel D. Daugherty. > > Thanks! Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'lilliput' into backport-rkennke-7f6bb71e - Backport 7f6bb71eb302e8388c959bdaa914b758a766d299 ------------- Changes: - all: https://git.openjdk.org/lilliput-jdk21u/pull/24/files - new: https://git.openjdk.org/lilliput-jdk21u/pull/24/files/d7ab6b84..5828471e Webrevs: - full: https://webrevs.openjdk.org/?repo=lilliput-jdk21u&pr=24&range=01 - incr: https://webrevs.openjdk.org/?repo=lilliput-jdk21u&pr=24&range=00-01 Stats: 2454 lines in 40 files changed: 1155 ins; 1082 del; 217 mod Patch: https://git.openjdk.org/lilliput-jdk21u/pull/24.diff Fetch: git fetch https://git.openjdk.org/lilliput-jdk21u.git pull/24/head:pull/24 PR: https://git.openjdk.org/lilliput-jdk21u/pull/24 From rkennke at openjdk.org Wed Mar 27 11:17:35 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Wed, 27 Mar 2024 11:17:35 GMT Subject: [lilliput-jdk21u:lilliput] RFR: 8319799: Recursive lightweight locking: x86 implementation [v2] In-Reply-To: References: Message-ID: On Wed, 27 Mar 2024 09:22:52 GMT, Roman Kennke wrote: >> Hi all, >> >> This pull request contains a backport of commit [7f6bb71e](https://github.com/openjdk/jdk/commit/7f6bb71eb302e8388c959bdaa914b758a766d299) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. >> >> Backport wasn't 100% clean due to context differences (includes and the LoadNKlass stubs that are only in Lilliput), and trivial to fix. >> >> The commit being backported was authored by Axel Boldt-Christmas on 14 Feb 2024 and was reviewed by Roman Kennke, Coleen Phillimore and Daniel D. Daugherty. >> >> Thanks! > > Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'lilliput' into backport-rkennke-7f6bb71e > - Backport 7f6bb71eb302e8388c959bdaa914b758a766d299 The remaining GHA failures look unrelated. ------------- PR Comment: https://git.openjdk.org/lilliput-jdk21u/pull/24#issuecomment-2022512844 From rkennke at openjdk.org Wed Mar 27 11:17:35 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Wed, 27 Mar 2024 11:17:35 GMT Subject: [lilliput-jdk21u:lilliput] Integrated: 8319799: Recursive lightweight locking: x86 implementation In-Reply-To: References: Message-ID: On Mon, 25 Mar 2024 18:38:53 GMT, Roman Kennke wrote: > Hi all, > > This pull request contains a backport of commit [7f6bb71e](https://github.com/openjdk/jdk/commit/7f6bb71eb302e8388c959bdaa914b758a766d299) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > Backport wasn't 100% clean due to context differences (includes and the LoadNKlass stubs that are only in Lilliput), and trivial to fix. > > The commit being backported was authored by Axel Boldt-Christmas on 14 Feb 2024 and was reviewed by Roman Kennke, Coleen Phillimore and Daniel D. Daugherty. > > Thanks! This pull request has now been integrated. Changeset: cda1aba7 Author: Roman Kennke URL: https://git.openjdk.org/lilliput-jdk21u/commit/cda1aba7fd49208bf9bad7666584141e0908b1df Stats: 589 lines in 13 files changed: 450 ins; 62 del; 77 mod 8319799: Recursive lightweight locking: x86 implementation Reviewed-by: stuefe, shade Backport-of: 7f6bb71eb302e8388c959bdaa914b758a766d299 ------------- PR: https://git.openjdk.org/lilliput-jdk21u/pull/24 From stefank at openjdk.org Wed Mar 27 11:23:36 2024 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 27 Mar 2024 11:23:36 GMT Subject: [master] RFR: JDK-8325104: Lilliput: Shrink Classpointers [v3] In-Reply-To: References: Message-ID: On Mon, 25 Mar 2024 14:51:14 GMT, Thomas Stuefe wrote: >> Hi, >> >> I wanted to get input on the following improvement for Lilliput. Testing is still ongoing, but things look really good, so this patch is hopefully near its final form (barring any objections from reviewers, of course). >> >> Note: I have a companion patch prepared for upstream, minus the markword changes. I will attempt to get that one upstream quickly in order to not have a large delta between upstream and lilliput, especially in Metaspace. >> >> ## High-Level Overview >> >> (for a short sequence of slides, please see https://github.com/tstuefe/fosdem24/blob/master/classpointers-and-liliput.pdf - these accompanied a talk we held at FOSDEM 24). >> >> We want to reduce the bit size of narrow Klass to free up bits in the MarkWord. >> >> We cannot just reduce the Klass encoding range size (well, we could, and maybe we will later, but for now we decided not to). We instead increase the alignment Klass is stored at, and use that alignment shadow to store other information. >> >> In other words, this patch changes the narrow Klass Pointer to a Klass ID, since now (almost) every value in its value range points to a different class. Therefore, we use the value range of nKlass much more efficiently. >> >> We then use the newly freed bits in the MarkWord to restore the iHash to 31 bits: >> >> >> [ 22-bit nKlass | 31-bit iHash | 4 free bits | age | fwd | lck ] >> >> nKlass gets reduced to 22 bits. Identity hash gets re-inflated to 31 bits. Preceding iHash are now 4 unused bits. Rest is unchanged. >> >> (Note: I originally wanted to swap iHash and nKlass such that either of them could be loaded with a 32-bit load, but I found that tricky since C2 seems to rely on the nKlass offset in the Markword being > 0.) >> >> ## nKlass reduction: >> >> The reduction in nKlass size is made by only storing them at 10-bit aligned addresses. That alignment (1KB) works well in practice since Klass - although var sized - typically is between 512 bytes and 1KB in size. Outliers are possible, but the size distribution is bell-curvish [1], so far-away outliers are very rare. >> >> To not lose memory to alignment waste, metaspace is reshaped to handle arbitrarily aligned allocations efficiently. Basically, we allow the non-Klass arena of a class loader to steal the alignment waste storage from the class arena. So, alignment waste blocks are filled with non-Klass metadata. That works very well in practice since non-Klass metadata is numerous and fine-granular compared to the big Klass bloc... > > Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: > > - Roman feedback - small stuff > - Merge branch 'master' into Smaller-ClassPointers > - revert COH archive generation > - Remove files that accidentally slipped in > - Merge branch 'master' into Smaller-ClassPointers > - Merge > - Merge commit 'c1281e6b45ed167df69d29a6039d81854c145ae6~1' into Smaller-ClassPointers > - Fix Typo > - Better CDS arch generation > - Fix error in COH archive generation > - ... and 10 more: https://git.openjdk.org/lilliput/compare/b2fcfb73...1260f2d6 I took another pass over the code and have some more questions. src/hotspot/share/memory/classLoaderMetaspace.cpp line 103: > 101: // Allocate word_size words from Metaspace. > 102: MetaWord* ClassLoaderMetaspace::allocate(size_t word_size, Metaspace::MetadataType mdType) { > 103: word_size = align_up(word_size, Metaspace::min_allocation_word_size); Could you explain why you need to align word_size here? It seems like we perform a very similar alignment inside MetaspaceArena::allocate. src/hotspot/share/memory/classLoaderMetaspace.cpp line 161: > 159: // because it is not needed anymore. > 160: void ClassLoaderMetaspace::deallocate(MetaWord* ptr, size_t word_size, bool is_class) { > 161: NOT_LP64(word_size = align_down(word_size, Metaspace::min_allocation_word_size);) Why is this needed? What code paths passes in non-aligned word_size? (BTW, I started to look at these in more details because I tend to think that we should stay away from modifying the input parameters, since it makes it easier to misunderstand the code). src/hotspot/share/memory/metaspace/binList.hpp line 202: > 200: b_last = b; > 201: } > 202: if (UseNewCode)printf("\n"); This looks like old debugging code. src/hotspot/share/memory/metaspace/blockTree.cpp line 187: > 185: void BlockTree::zap_block(MetaBlock bl) { > 186: memset(bl.base(), 0xF3, bl.word_size() * sizeof(MetaWord)); > 187: } In the header file the parameter is named `block` and here it is named `bl`. In `add_block(MetaBlock mb)` the name is `mb`. Maybe think about trying to use consistent naming for these? src/hotspot/share/memory/metaspace/metablock.hpp line 52: > 50: bool is_empty() const { return _base == nullptr; } > 51: bool is_nonempty() const { return _base != nullptr; } > 52: void reset() { _base = nullptr; _word_size = 0; } Do you need reset? I was wondering if you could make the _base, _word_size const by changing the few places that use this to: `result = MetaBlock();` You would also need to skip having `split_off_tail` and replace its usage with: wastage = MetaBlock(...); result = Metablock(...) Just a thought if you wanted to make MetaBlock an even simpler tiny structure. src/hotspot/share/memory/metaspace/metablock.inline.hpp line 29: > 27: #define SHARE_MEMORY_METASPACE_METABLOCK_INLINE_HPP > 28: > 29: #include "memory/metaspace/metablock.hpp" We have a convention that the .hpp file associated with the .inline.hpp file should come first (as you have here) and then there's a blank line separating it from the rest of the includes. ------------- PR Review: https://git.openjdk.org/lilliput/pull/128#pullrequestreview-1962779347 PR Review Comment: https://git.openjdk.org/lilliput/pull/128#discussion_r1540783269 PR Review Comment: https://git.openjdk.org/lilliput/pull/128#discussion_r1540791019 PR Review Comment: https://git.openjdk.org/lilliput/pull/128#discussion_r1540798030 PR Review Comment: https://git.openjdk.org/lilliput/pull/128#discussion_r1540802163 PR Review Comment: https://git.openjdk.org/lilliput/pull/128#discussion_r1540816389 PR Review Comment: https://git.openjdk.org/lilliput/pull/128#discussion_r1540886764 From stefank at openjdk.org Wed Mar 27 11:23:36 2024 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 27 Mar 2024 11:23:36 GMT Subject: [master] RFR: JDK-8325104: Lilliput: Shrink Classpointers [v3] In-Reply-To: References: <5Hg3aWe6cymqJix7XUhQeSrbqWYsGpICXCNQPtsEzRc=.ab9bd02b-afdb-4ac8-acd1-c92e363f79ee@github.com> Message-ID: On Sat, 10 Feb 2024 14:52:43 GMT, Thomas Stuefe wrote: >> src/hotspot/share/gc/shared/c2/barrierSetC2.cpp line 661: >> >>> 659: if (base_off % BytesPerLong != 0) { >>> 660: assert(UseCompressedClassPointers, ""); >>> 661: assert(!UseCompactObjectHeaders, ""); >> >> What is that for? Is it important? > > Mostly for documentation. The various asserts like this helped me understand a lot of code. It could be nice to include compact headers in the comment above. Maybe something like this. It would make it clearer why this assert was added. // 8 - 32-bit VM // 8 - 64-bit VM, compact object headers // 12 - 64-bit VM, compressed klass // 16 - 64-bit VM, normal klass ------------- PR Review Comment: https://git.openjdk.org/lilliput/pull/128#discussion_r1540760038 From stefank at openjdk.org Wed Mar 27 11:23:36 2024 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 27 Mar 2024 11:23:36 GMT Subject: [master] RFR: JDK-8325104: Lilliput: Shrink Classpointers [v3] In-Reply-To: References: Message-ID: On Tue, 26 Mar 2024 14:55:04 GMT, Roman Kennke wrote: >> I still think it is odd that we return that the klass offset is 4 on big-endian machines. If we ever really try to read the klass at (obj + klass_offset_in_bytes()) on those machines we will not get the klass bits, instead we will get some of the other bits in the object header. >> >> My inquiries were more if it really was a good idea to load the klass with 4 byte loads and that it seems safer (more platform independent) to stick with 8 byte loads. When we use 8 byte loads and shifts we don't have to think about endianess. >> >> I glanced in the C2 code how klass_byte_in_offset is used. It looks like most places were `klass_offset_in_bytes()` is used, it is used as a sort of a token to figure out that the load (obj + offset) should be interpreted as a load of the klass. We don't actually use that offset for the load / decode of the klass. Instead we perform an 8 byte load from the start of the object, with associated 8 byte shift operation. >> >> So, maybe my concern here is more that the name "klass_offset_in_bytes" is a bit misleading as it sounds like this is the offset where the klass bits are located. Code using klass_offset_in_bytes() really need to be written with the understanding that this is the case. > > The trouble with C2 is that, currently, loading the Klass* (pre-lilliput) has its own memory slice, and is totally immutable. With Lilliput, we currently load the Klass* from the mark-word, and need to deal with header displacement in ObjectMonitors. This currently happens in the backend and is totally opaque to C2 IR. > > However, it all *could* be done in C2 IR, even more so when we get the OMWorld stuff. Then the loads would happen on their true memory slice (the mark-word) and we would do the shifting/masking in IR, too. But it is questionable if we want to do so. The fact that Load(N)Klass can currently be treated as immutable makes the node freely moving in the ideal graph. Wiring it up in the same slice as mark-word loads means that we would have to re-load the Klass* after anything that would potentially touch the mark-word, especially safepoints, calls, etc. even though we know that the actual Klass* portion of the mark-word is still, in-fact, immutable. Therefore I believe it is better to keep the LoadKlass stuff on its own memory slice, with its own offset, even if we never actually load from that offset. offset=4 is a good choice for that, because it would never clash with a true offset of a field. Long-term, something like offset=1 or 2 may be better, when we want to do 4-byte headers, f ields may start ot offset=4. > > Also note the weird dance that we need to do in C2 .ad files to figure out the true offset. :-/ > > We should run this by some C2 experts to figure out the best way to deal with all that. Thanks for adding explaining some of the background for this. It sounds like a good idea to get a C2 expert to look at this. ------------- PR Review Comment: https://git.openjdk.org/lilliput/pull/128#discussion_r1540919324 From rkennke at openjdk.org Wed Mar 27 14:48:07 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Wed, 27 Mar 2024 14:48:07 GMT Subject: [lilliput-jdk17u:lilliput] RFR: Merge jdk17u:jdk-17.0.11+7 Message-ID: Let's merge the tag jdk-17.0.11+7. Merge has been clean. ------------- Commit messages: - Merge tag 'jdk-17.0.11+7' into merge-jdk-17.0.11+7 - 8327391: Add SipHash attribution file - 8327036: [macosx-aarch64] SIGBUS in MarkActivationClosure::do_code_blob reached from Unsafe_CopySwapMemory0 - 8322750: Test "api/java_awt/interactive/SystemTrayTests.html" failed because A blue ball icon is added outside of the system tray - 8305900: Use loopback IP addresses in security policy files of httpclient tests - 8326000: Remove obsolete comments for class sun.security.ssl.SunJSSE - 8310380: Handle problems in core-related tests on macOS when codesign tool does not work - 8278312: Update SimpleSSLContext keystore to use SANs for localhost IP addresses - 8321151: JDK-8294427 breaks Windows L&F on all older Windows versions - 8305962: update jcstress to 0.16 - ... and 231 more: https://git.openjdk.org/lilliput-jdk17u/compare/35c51935...b82fdd0c The webrevs contain the adjustments done while merging with regards to each parent branch: - lilliput: https://webrevs.openjdk.org/?repo=lilliput-jdk17u&pr=68&range=00.0 - jdk17u:jdk-17.0.11+7: https://webrevs.openjdk.org/?repo=lilliput-jdk17u&pr=68&range=00.1 Changes: https://git.openjdk.org/lilliput-jdk17u/pull/68/files Stats: 46167 lines in 1078 files changed: 27851 ins; 8011 del; 10305 mod Patch: https://git.openjdk.org/lilliput-jdk17u/pull/68.diff Fetch: git fetch https://git.openjdk.org/lilliput-jdk17u.git pull/68/head:pull/68 PR: https://git.openjdk.org/lilliput-jdk17u/pull/68 From jrose at openjdk.org Wed Mar 27 18:57:44 2024 From: jrose at openjdk.org (John R Rose) Date: Wed, 27 Mar 2024 18:57:44 GMT Subject: [master] RFR: JDK-8325104: Lilliput: Shrink Classpointers [v3] In-Reply-To: References: Message-ID: On Tue, 26 Mar 2024 09:21:20 GMT, Thomas Stuefe wrote: > My short-term contingency plan had been to use some of the now free four bits to increase the Klass ID bits and thus bring alignment back to 64 bytes. That would work at least for 64-bit headers, as long as Valhalla does not need those bits too. Thanks for the response, Thomas. (It looks like you remembered our conversation better than I did.) Taking back the four free bits is a good tactic for now. It may possibly squeeze Valhalla, at which point we will have to evaluate our choices: Should we encode the valhalla bits with a joint multi-bit encoding embedded in the klass-ID? Should we look again at mod-1088 encodings discussed here? Should we use a [joint bit encoding](https://cr.openjdk.org/~jrose/jvm/joint-bit-encodings.html) for all array klass IDs, since Valhalla needs special markings on arrays anyway? Those are the sorts of questions that could arise. ------------- PR Comment: https://git.openjdk.org/lilliput/pull/128#issuecomment-2023717893