From rkennke at openjdk.org  Tue Feb  6 16:51:39 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 6 Feb 2024 16:51:39 GMT
Subject: [master] RFR: Merge jdk:jdk-23+8
Message-ID: <qDIMk8yMXKojb1aAZu9t75skOsHkuH8clyWrErlJp-4=.2a38f50e-8f56-4ff8-a1a8-dedddeff6879@github.com>

Let's merge jdk-23+8

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

Commit messages:
 - Merge tag 'jdk-23+8' into merge-jdk-23+8
 - 8324174: assert(m->is_entered(current)) failed: invariant
 - 8325042: remove unused JVMDITools test files
 - 8323621: JDK build should exclude snippet class in java.lang.foreign
 - 8324238: [macOS] java/awt/Frame/ShapeNotSetSometimes/ShapeNotSetSometimes.java fails with the shape has not been applied msg
 - 8320342: Use PassFailJFrame for TruncatedPopupMenuTest.java
 - 8324981: Shenandoah: Move commit and soft max heap changed methods into heap
 - 8303374: Implement JEP 455: Primitive Types in Patterns, instanceof, and switch (Preview)
 - 8320712: Rewrite BadFactoryTest in pure Java
 - 8324771: Obsolete RAMFraction related flags
 - ... and 62 more: https://git.openjdk.org/lilliput/compare/96b3ad6d...b067a3ee

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

Changes: https://git.openjdk.org/lilliput/pull/130/files
  Stats: 18822 lines in 1229 files changed: 7186 ins; 1716 del; 9920 mod
  Patch: https://git.openjdk.org/lilliput/pull/130.diff
  Fetch: git fetch https://git.openjdk.org/lilliput.git pull/130/head:pull/130

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

From rkennke at openjdk.org  Wed Feb  7 12:28:10 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 7 Feb 2024 12:28:10 GMT
Subject: [master] Integrated: Merge jdk:jdk-23+8
In-Reply-To: <qDIMk8yMXKojb1aAZu9t75skOsHkuH8clyWrErlJp-4=.2a38f50e-8f56-4ff8-a1a8-dedddeff6879@github.com>
References: <qDIMk8yMXKojb1aAZu9t75skOsHkuH8clyWrErlJp-4=.2a38f50e-8f56-4ff8-a1a8-dedddeff6879@github.com>
Message-ID: <vC9toxjbZEoG7EFAuKQEDxnWzumfdLVE0M8GYTjccqc=.7c49db77-3c70-4526-8b61-88fa55584450@github.com>

On Tue, 6 Feb 2024 16:45:47 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Let's merge jdk-23+8

This pull request has now been integrated.

Changeset: da4ffa35
Author:    Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.org/lilliput/commit/da4ffa35c274e014e1882584f3a133487de8aebe
Stats:     18822 lines in 1229 files changed: 7186 ins; 1716 del; 9920 mod

Merge jdk:jdk-23+8

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

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

From rkennke at openjdk.org  Wed Feb  7 12:28:09 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 7 Feb 2024 12:28:09 GMT
Subject: [master] RFR: Merge jdk:jdk-23+8 [v2]
In-Reply-To: <qDIMk8yMXKojb1aAZu9t75skOsHkuH8clyWrErlJp-4=.2a38f50e-8f56-4ff8-a1a8-dedddeff6879@github.com>
References: <qDIMk8yMXKojb1aAZu9t75skOsHkuH8clyWrErlJp-4=.2a38f50e-8f56-4ff8-a1a8-dedddeff6879@github.com>
Message-ID: <jpi9PbYu8Eh3aD2qJ9vJ2VtQgRs8ahuY0v9bdP_7SKs=.2062efed-e8cc-4d02-acc6-685e34dd53c1@github.com>

> Let's merge jdk-23+8

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

 - Merge tag 'jdk-23+8' into merge-jdk-23+8
   
   Added tag jdk-23+8 for changeset 5b9b176c
 - Merge jdk:jdk-23+7
 - 8324523: Lilliput: if +UseCOH, always use the archive's encoding base and shift
   
   Reviewed-by: rkennke
 - Merge jdk:jdk-23+1
 - Merge jdk:jdk-22+25
 - 8319724: [Lilliput] ParallelGC: Forwarded objects found during heap inspection
   
   Reviewed-by: shade
 - 8319524: [Lilliput] Only warn when compact headers are explicitly enabled
   
   Reviewed-by: shade
 - 8319135: [Lilliput] Fix objArrayOop gtest
   
   Reviewed-by: shade
 - Merge jdk:jdk-22+19
 - 8318011: [Lilliput] Fix CDS narrowKlass encoding
   
   Reviewed-by: shade, stuefe
 - ... and 107 more: https://git.openjdk.org/lilliput/compare/5b9b176c...b067a3ee

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

Changes: https://git.openjdk.org/lilliput/pull/130/files
 Webrev: https://webrevs.openjdk.org/?repo=lilliput&pr=130&range=01
  Stats: 3166 lines in 154 files changed: 2595 ins; 214 del; 357 mod
  Patch: https://git.openjdk.org/lilliput/pull/130.diff
  Fetch: git fetch https://git.openjdk.org/lilliput.git pull/130/head:pull/130

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

From rkennke at amazon.de  Wed Feb  7 12:37:15 2024
From: rkennke at amazon.de (Kennke, Roman)
Date: Wed, 7 Feb 2024 12:37:15 +0000
Subject: CFV: New Lilliput Committer: Axel Boldt-Christmas
Message-ID: <93870E0D-11CA-477B-BB95-C70A297964B3@amazon.de>

I hereby nominate Axel Boldt-Christmas to Lilliput Committer.

Axel is a software engineer at Oracle?s GC group. While Axel has not yet contributed directly to the Lilliput project, he is a prolific contributor (and reviewer) in the upstream JDK project, where he (among many others) contributed fixes and improvements to lightweight locking, and is currently working on improved ObjectMonitor handling, both of which are crucial for Lilliput. I would like to make him a Lilliput committer to facilitate closer collaboration on the project.

See also:
https://github.com/openjdk/lilliput/commits/master/?author=xmas92

https://mail.openjdk.org/pipermail/lilliput-dev/2024-January/001302.html

Votes are due by Feb 21, 2024.

Only current Lilliput Committers [1] are eligible to vote
on this nomination. Votes must be cast in the open by replying
to this mailing list.

For Lazy Consensus voting instructions, see [2].

Roman Kennke

[1] https://openjdk.org/census
[2] https://openjdk.org/projects/#committer-vote



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 duke at openjdk.org  Wed Feb  7 12:42:34 2024
From: duke at openjdk.org (duke)
Date: Wed, 7 Feb 2024 12:42:34 GMT
Subject: git: openjdk/lilliput: omworld: 74 new changesets
Message-ID: <c3a81fce-e920-4d75-a146-699684ab0e72@openjdk.org>

Changeset: c0496069
Author:    Roman Kennke <rkennke at openjdk.org>
Date:      2024-01-30 18:23:00 +0000
URL:       https://git.openjdk.org/lilliput/commit/c04960696376dd226c5efa7eb7b822dbdefc6bd1

8319185: [Lilliput] Enable and fix vectorization tests

Reviewed-by: shade

! test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationMismatchedAccess.java
! test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationNotRun.java
! test/hotspot/jtreg/compiler/lib/ir_framework/TestFramework.java
! test/hotspot/jtreg/compiler/loopopts/superword/TestIndependentPacksWithCyclicDependency.java

Changeset: 7a798d3c
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2024-01-25 10:36:00 +0000
URL:       https://git.openjdk.org/lilliput/commit/7a798d3cebea0915f8a73af57333b3488c2091af

8324598: use mem_unit when working with sysinfo memory and swap related information

Reviewed-by: dholmes, mdoerr

! src/hotspot/os/linux/os_linux.cpp
! src/java.base/linux/native/libjava/CgroupMetrics.c

Changeset: e709842e
Author:    Albert Mingkun Yang <ayang at openjdk.org>
Date:      2024-01-25 14:25:45 +0000
URL:       https://git.openjdk.org/lilliput/commit/e709842eae43029f5cfc509e40bbfb28c8abe348

8324636: Serial: Remove Generation::block_is_obj

Reviewed-by: stefank, ysr

! src/hotspot/share/gc/serial/defNewGeneration.cpp
! src/hotspot/share/gc/serial/defNewGeneration.hpp
! src/hotspot/share/gc/serial/generation.cpp
! src/hotspot/share/gc/serial/generation.hpp
! src/hotspot/share/gc/serial/tenuredGeneration.hpp
! src/hotspot/share/gc/serial/tenuredGeneration.inline.hpp

Changeset: ffe3bb67
Author:    Roger Riggs <rriggs at openjdk.org>
Date:      2024-01-25 14:51:50 +0000
URL:       https://git.openjdk.org/lilliput/commit/ffe3bb67632eeec4b5df4e832d9bd5e78c3f808a

8324657: Intermittent OOME on exception message create

Reviewed-by: lancea, iris, naoto

! src/java.base/share/classes/java/io/ObjectInputStream.java

Changeset: 746a0868
Author:    Emanuel Peter <epeter at openjdk.org>
Date:      2024-01-25 15:50:33 +0000
URL:       https://git.openjdk.org/lilliput/commit/746a08686bfad629fe045a762ed2fbb209763f6b

8306767: Concurrent repacking of extra data in MethodData is potentially unsafe

Reviewed-by: eosterlund, roland, coleenp, never

! src/hotspot/share/ci/ciMethodData.cpp
! src/hotspot/share/interpreter/bytecodeTracer.cpp
! src/hotspot/share/interpreter/interpreterRuntime.cpp
! src/hotspot/share/jfr/support/jfrMethodData.cpp
! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp
! src/hotspot/share/oops/instanceKlass.cpp
! src/hotspot/share/oops/methodData.cpp
! src/hotspot/share/oops/methodData.hpp
! src/hotspot/share/oops/methodData.inline.hpp
! src/hotspot/share/prims/whitebox.cpp
! src/hotspot/share/runtime/deoptimization.cpp
! src/hotspot/share/runtime/javaThread.hpp
! src/hotspot/share/runtime/sharedRuntime.cpp

Changeset: 12b89cd2
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2024-01-25 18:03:16 +0000
URL:       https://git.openjdk.org/lilliput/commit/12b89cd2eeb5c2c43a2ce425c96fc4f718e30514

8323717: Introduce test keyword for tests that need external dependencies

Reviewed-by: dholmes, lmesnik

! test/hotspot/jtreg/TEST.ROOT
! test/hotspot/jtreg/applications/jcstress/TestGenerator.java
! test/hotspot/jtreg/applications/jcstress/accessAtomic.java
! test/hotspot/jtreg/applications/jcstress/acqrel.java
! test/hotspot/jtreg/applications/jcstress/atomicity.java
! test/hotspot/jtreg/applications/jcstress/atomics.java
! test/hotspot/jtreg/applications/jcstress/causality.java
! test/hotspot/jtreg/applications/jcstress/coherence.java
! test/hotspot/jtreg/applications/jcstress/collections.java
! test/hotspot/jtreg/applications/jcstress/copy.java
! test/hotspot/jtreg/applications/jcstress/countdownlatch.java
! test/hotspot/jtreg/applications/jcstress/defaultValues.java
! test/hotspot/jtreg/applications/jcstress/executors.java
! test/hotspot/jtreg/applications/jcstress/fences.java
! test/hotspot/jtreg/applications/jcstress/future.java
! test/hotspot/jtreg/applications/jcstress/init.java
! test/hotspot/jtreg/applications/jcstress/initClass.java
! test/hotspot/jtreg/applications/jcstress/initLen.java
! test/hotspot/jtreg/applications/jcstress/interrupt.java
! test/hotspot/jtreg/applications/jcstress/locks.java
! test/hotspot/jtreg/applications/jcstress/memeffects.java
! test/hotspot/jtreg/applications/jcstress/mxbeans.java
! test/hotspot/jtreg/applications/jcstress/oota.java
! test/hotspot/jtreg/applications/jcstress/seqcst.java
! test/hotspot/jtreg/applications/jcstress/singletons.java
! test/hotspot/jtreg/applications/jcstress/strings.java
! test/hotspot/jtreg/applications/jcstress/tearing.java
! test/hotspot/jtreg/applications/jcstress/threadlocal.java
! test/hotspot/jtreg/applications/jcstress/unsafe.java
! test/hotspot/jtreg/applications/jcstress/varhandles.java
! test/hotspot/jtreg/applications/jcstress/volatiles.java
! test/hotspot/jtreg/applications/scimark/Scimark.java

Changeset: 39b756a0
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2024-01-25 18:35:20 +0000
URL:       https://git.openjdk.org/lilliput/commit/39b756a0d163d60d1b69fbc9bf6e8235080c3721

8324492: Remove Atomic support for OopHandle

Reviewed-by: aboldtch, coleenp

! src/hotspot/share/oops/oopHandle.hpp
! src/hotspot/share/services/memoryManager.cpp
! src/hotspot/share/services/memoryManager.hpp
! src/hotspot/share/services/memoryPool.cpp
! src/hotspot/share/services/memoryPool.hpp

Changeset: 95310eab
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
Date:      2024-01-25 22:01:18 +0000
URL:       https://git.openjdk.org/lilliput/commit/95310eab6ce73512b1afc0a7a26a396dd7b6cb7c

8223696: java/net/httpclient/MaxStreams.java failed with didn't finish within the time-out

Reviewed-by: dfuchs

! test/jdk/java/net/httpclient/MaxStreams.java

Changeset: b5995a76
Author:    Joe Darcy <darcy at openjdk.org>
Date:      2024-01-25 22:17:07 +0000
URL:       https://git.openjdk.org/lilliput/commit/b5995a76f79e0a70e67b0915e782e881efbbdf5e

8302019: Clarify Elements.overrides

Reviewed-by: prappo, jjg

! src/java.compiler/share/classes/javax/lang/model/util/Elements.java
+ test/langtools/tools/javac/processing/model/util/elements/TestOverrides.java

Changeset: bde87895
Author:    Wang Zhuo <wzhuo at openjdk.org>
Committer: Denghui Dong <ddong at openjdk.org>
Date:      2024-01-26 02:30:49 +0000
URL:       https://git.openjdk.org/lilliput/commit/bde87895c8b1b9df198e3883d24cd9ea840efc98

8324123: aarch64: fix prfm literal encoding in assembler

Reviewed-by: aph, dlong

! src/hotspot/cpu/aarch64/assembler_aarch64.cpp
! src/hotspot/cpu/aarch64/assembler_aarch64.hpp

Changeset: 10066cd4
Author:    Alisen Chung <achung at openjdk.org>
Date:      2024-01-26 03:47:19 +0000
URL:       https://git.openjdk.org/lilliput/commit/10066cd4ef93db9d2bff3f7884d24a5c6e714775

8324571: JDK 23 L10n resource files update

Reviewed-by: jlu, jjg

! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets_de.properties
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets_ja.properties
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets_zh_CN.properties
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/resources/javadoc_de.properties
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/resources/javadoc_ja.properties
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/resources/javadoc_zh_CN.properties

Changeset: 33324a59
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2024-01-26 07:57:29 +0000
URL:       https://git.openjdk.org/lilliput/commit/33324a59ccdb220250cb74e15ce13af0e99dcb07

8324637: [aix] Implement support for reporting swap space in jdk.management

Reviewed-by: kevinw, stuefe

! src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c

Changeset: 781f368d
Author:    Sergey Bylokhov <serb at openjdk.org>
Date:      2024-01-26 08:46:34 +0000
URL:       https://git.openjdk.org/lilliput/commit/781f368d421a94857929e4168974f43e890637d8

8324347: Enable "maybe-uninitialized" warning for FreeType 2.13.1

Reviewed-by: erikj, azvegint, jwaters, aivanov

! make/modules/java.desktop/lib/Awt2dLibraries.gmk

Changeset: c313d451
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2024-01-26 08:51:00 +0000
URL:       https://git.openjdk.org/lilliput/commit/c313d451a513eb08de0b295c1ce66d0d849d2374

8324659: GHA: Generic jtreg errors are not reported

Reviewed-by: erikj, jwaters, stuefe

! .github/scripts/gen-test-summary.sh

Changeset: 32ddcf50
Author:    Albert Mingkun Yang <ayang at openjdk.org>
Date:      2024-01-26 13:03:50 +0000
URL:       https://git.openjdk.org/lilliput/commit/32ddcf504c1f67e3d4bb0a6e8c9a523f4898dc74

8324301: Obsolete MaxGCMinorPauseMillis

Reviewed-by: kbarrett, tschatzl

! src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp
! src/hotspot/share/gc/parallel/psAdaptiveSizePolicy.cpp
! src/hotspot/share/gc/parallel/psAdaptiveSizePolicy.hpp
! src/hotspot/share/gc/shared/gc_globals.hpp
! src/hotspot/share/runtime/arguments.cpp
! test/hotspot/jtreg/runtime/CommandLine/VMDeprecatedOptions.java

Changeset: 885e9b76
Author:    Albert Mingkun Yang <ayang at openjdk.org>
Date:      2024-01-26 13:03:59 +0000
URL:       https://git.openjdk.org/lilliput/commit/885e9b76d6a0d6a12ab4f93022500aefdae5926c

8324722: Serial: Inline block_is_obj of subclasses of Generation

Reviewed-by: stefank, tschatzl

! src/hotspot/share/gc/serial/defNewGeneration.cpp
! src/hotspot/share/gc/serial/defNewGeneration.hpp
! src/hotspot/share/gc/serial/serialHeap.cpp
! src/hotspot/share/gc/serial/tenuredGeneration.hpp
! src/hotspot/share/gc/serial/tenuredGeneration.inline.hpp

Changeset: 62b3293d
Author:    Volker Simonis <simonis at openjdk.org>
Date:      2024-01-26 13:11:58 +0000
URL:       https://git.openjdk.org/lilliput/commit/62b3293df0442b06cd00488774db7b608baca774

8324241: Always record evol_method deps to avoid excessive method flushing

Reviewed-by: eastigeevich, phh, coleenp, dlong, shade

! src/hotspot/share/prims/jvmtiExport.hpp
! src/hotspot/share/prims/jvmtiRedefineClasses.cpp
! src/hotspot/share/runtime/globals.hpp
! src/hotspot/share/runtime/init.cpp

Changeset: a65a8952
Author:    Liming Liu <limingliu at os.amperecomputing.com>
Committer: Thomas Stuefe <stuefe at openjdk.org>
Date:      2024-01-26 16:42:46 +0000
URL:       https://git.openjdk.org/lilliput/commit/a65a89522d2f24b1767e1c74f6689a22ea32ca6a

8315923: pretouch_memory by atomic-add-0 fragments huge pages unexpectedly

Reviewed-by: jsjolen, stuefe

! src/hotspot/os/aix/os_aix.cpp
! src/hotspot/os/bsd/os_bsd.cpp
! src/hotspot/os/linux/globals_linux.hpp
! src/hotspot/os/linux/os_linux.cpp
! src/hotspot/os/windows/os_windows.cpp
! src/hotspot/share/gc/shared/pretouchTask.cpp
! src/hotspot/share/runtime/os.cpp
! src/hotspot/share/runtime/os.hpp
! test/hotspot/gtest/runtime/test_os_linux.cpp
+ test/hotspot/jtreg/runtime/os/TestTransparentHugePageUsage.java

Changeset: 91d8ea79
Author:    Vicente Romero <vromero at openjdk.org>
Date:      2024-01-26 18:34:56 +0000
URL:       https://git.openjdk.org/lilliput/commit/91d8ea79d947aa7dad91d8ed550ed34a7d49d885

8323835: Updating ASM to 9.6 for JDK 23

Reviewed-by: mchung

! src/java.base/share/classes/jdk/internal/org/objectweb/asm/AnnotationVisitor.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/ByteVector.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/ClassReader.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/ClassTooLargeException.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/ClassVisitor.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/ClassWriter.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/ConstantDynamic.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/Constants.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/Context.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/CurrentFrame.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/Edge.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/FieldVisitor.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/FieldWriter.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/Frame.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/Handle.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/Handler.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/Label.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/MethodTooLargeException.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/MethodVisitor.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/MethodWriter.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/ModuleVisitor.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/ModuleWriter.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/Opcodes.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/RecordComponentVisitor.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/RecordComponentWriter.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/Symbol.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/SymbolTable.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/Type.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/TypePath.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/TypeReference.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/AdviceAdapter.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/AnalyzerAdapter.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/AnnotationRemapper.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/ClassRemapper.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/CodeSizeEvaluator.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/FieldRemapper.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/GeneratorAdapter.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/InstructionAdapter.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/JSRInlinerAdapter.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/LocalVariablesSorter.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/Method.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/MethodRemapper.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/ModuleHashesAttribute.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/ModuleRemapper.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/ModuleResolutionAttribute.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/ModuleTargetAttribute.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/RecordComponentRemapper.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/Remapper.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/SerialVersionUIDAdder.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/SignatureRemapper.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/SimpleRemapper.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/StaticInitMerger.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/TableSwitchGenerator.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/TryCatchBlockSorter.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/signature/SignatureReader.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/signature/SignatureVisitor.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/signature/SignatureWriter.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/AbstractInsnNode.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/AnnotationNode.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/ClassNode.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/FieldInsnNode.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/FieldNode.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/FrameNode.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/IincInsnNode.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/InnerClassNode.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/InsnList.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/InsnNode.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/IntInsnNode.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/InvokeDynamicInsnNode.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/JumpInsnNode.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/LabelNode.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/LdcInsnNode.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/LineNumberNode.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/LocalVariableAnnotationNode.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/LocalVariableNode.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/LookupSwitchInsnNode.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/MethodInsnNode.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/MethodNode.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/ModuleExportNode.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/ModuleNode.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/ModuleOpenNode.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/ModuleProvideNode.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/ModuleRequireNode.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/MultiANewArrayInsnNode.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/ParameterNode.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/RecordComponentNode.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/TableSwitchInsnNode.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/TryCatchBlockNode.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/TypeAnnotationNode.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/TypeInsnNode.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/UnsupportedClassVersionException.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/Util.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/VarInsnNode.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/Analyzer.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/AnalyzerException.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/BasicInterpreter.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/BasicValue.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/BasicVerifier.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/Frame.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/Interpreter.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/SimpleVerifier.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/SmallSet.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/SourceInterpreter.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/SourceValue.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/Subroutine.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/Value.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/util/ASMifier.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/util/ASMifierSupport.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/util/CheckAnnotationAdapter.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/util/CheckClassAdapter.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/util/CheckFieldAdapter.java
+ src/java.base/share/classes/jdk/internal/org/objectweb/asm/util/CheckFrameAnalyzer.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/util/CheckMethodAdapter.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/util/CheckModuleAdapter.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/util/CheckRecordComponentAdapter.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/util/CheckSignatureAdapter.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/util/Printer.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/util/Textifier.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/util/TextifierSupport.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/util/TraceAnnotationVisitor.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/util/TraceClassVisitor.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/util/TraceFieldVisitor.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/util/TraceMethodVisitor.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/util/TraceRecordComponentVisitor.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/util/TraceSignatureVisitor.java
! src/java.base/share/classes/jdk/internal/org/objectweb/asm/version.txt
! src/java.base/share/legal/asm.md

Changeset: 6d185623
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
Date:      2024-01-26 20:18:08 +0000
URL:       https://git.openjdk.org/lilliput/commit/6d1856234ff25e6851204dd2102d405e67e8a468

8324785: ProblemList two tests on linux due to JDK-8315923

Reviewed-by: rriggs

! test/hotspot/jtreg/ProblemList.txt

Changeset: ed3272cc
Author:    Joe Darcy <darcy at openjdk.org>
Date:      2024-01-26 20:55:46 +0000
URL:       https://git.openjdk.org/lilliput/commit/ed3272cc44a5b1ae918b573e6c3d792665b6bbc7

8042981: Strip type annotations in Types' utility methods

Co-authored-by: Liam Miller-Cushon <cushon at openjdk.org>
Reviewed-by: cushon, jjg, jlahoda

! src/java.compiler/share/classes/javax/lang/model/util/Types.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/model/JavacTypes.java
! test/langtools/tools/javac/lib/JavacTestingAbstractProcessor.java
+ test/langtools/tools/javac/processing/model/util/types/TestAnnotationStripping.java

Changeset: 70f4a4e1
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
Date:      2024-01-26 22:01:07 +0000
URL:       https://git.openjdk.org/lilliput/commit/70f4a4e18e257110f45565ba0d708f1fa48aed76

8324786: validate-source fails after JDK-8042981

Reviewed-by: darcy

! test/langtools/tools/javac/processing/model/util/types/TestAnnotationStripping.java

Changeset: 2e748c99
Author:    Joe Darcy <darcy at openjdk.org>
Date:      2024-01-26 22:33:17 +0000
URL:       https://git.openjdk.org/lilliput/commit/2e748c998ee490d8c3b1c7ab2fadfcb4596fc07b

8175386: Clarify exception behavior of Types utility methods

Reviewed-by: jjg

! src/java.compiler/share/classes/javax/lang/model/util/Types.java

Changeset: 525c0cd0
Author:    Emanuel Peter <epeter at openjdk.org>
Date:      2024-01-29 06:54:50 +0000
URL:       https://git.openjdk.org/lilliput/commit/525c0cd09f98c3a9965cf20d2ac3b306a938a910

8324752: C2 Superword: remove SuperWordRTDepCheck

Reviewed-by: kvn, chagedorn

! src/hotspot/share/opto/c2_globals.hpp
! src/hotspot/share/opto/superword.cpp
! src/hotspot/share/opto/superword.hpp

Changeset: 65d6bc1d
Author:    Emanuel Peter <epeter at openjdk.org>
Date:      2024-01-29 07:00:12 +0000
URL:       https://git.openjdk.org/lilliput/commit/65d6bc1d4c1054e82ace2355d6802e0a7ba24a7f

8324765: C2 SuperWord: remove dead code: SuperWord::insert_extracts

Reviewed-by: kvn, chagedorn

! src/hotspot/share/opto/superword.cpp
! src/hotspot/share/opto/superword.hpp

Changeset: 8950d68d
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2024-01-29 07:38:32 +0000
URL:       https://git.openjdk.org/lilliput/commit/8950d68ddb36d35831fbb4b98969cd0537527070

8324753: [AIX] adjust os_posix after JDK-8318696

Reviewed-by: jkern, stuefe, kbarrett, dholmes

! src/hotspot/os/posix/os_posix.cpp

Changeset: af9cd975
Author:    Julian Waters <jwaters at openjdk.org>
Date:      2024-01-29 08:03:20 +0000
URL:       https://git.openjdk.org/lilliput/commit/af9cd975cec5378214d5d31890150d03250ff3fa

8324800: gcc windows build broken after 8322757

Reviewed-by: kbarrett, dholmes

! src/hotspot/os/windows/os_windows.cpp

Changeset: 0d5f5e15
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2024-01-29 08:36:51 +0000
URL:       https://git.openjdk.org/lilliput/commit/0d5f5e15d43f94a79c6133baecd5af217365d176

8322484: 22-b26 Regression in J2dBench-bimg_misc-G1 (and more) on Windows-x64 and macOS-x64

Reviewed-by: kbarrett, ayang

! src/hotspot/share/gc/g1/g1BarrierSet.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/g1ConcurrentMark.cpp
! src/hotspot/share/gc/g1/g1FullCollector.cpp
+ src/hotspot/share/gc/g1/g1RegionPinCache.hpp
+ src/hotspot/share/gc/g1/g1RegionPinCache.inline.hpp
! src/hotspot/share/gc/g1/g1ThreadLocalData.hpp
! src/hotspot/share/gc/g1/g1YoungCollector.cpp
! src/hotspot/share/gc/g1/g1YoungGCPreEvacuateTasks.cpp
! src/hotspot/share/gc/g1/heapRegion.hpp
! src/hotspot/share/gc/g1/heapRegion.inline.hpp

Changeset: 422020c4
Author:    Tobias Holenstein <tholenstein at openjdk.org>
Date:      2024-01-29 08:37:06 +0000
URL:       https://git.openjdk.org/lilliput/commit/422020c4d691f3ad4c7af4fc2c60e7ada66734e0

8210858: AArch64: remove Math.log intrinsic

Reviewed-by: ngasson, shade

! src/hotspot/cpu/aarch64/c1_LIRGenerator_aarch64.cpp
! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp
- src/hotspot/cpu/aarch64/macroAssembler_aarch64_log.cpp
! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp

Changeset: 6ad78ca8
Author:    Emanuel Peter <epeter at openjdk.org>
Date:      2024-01-29 08:46:34 +0000
URL:       https://git.openjdk.org/lilliput/commit/6ad78ca8a5956d4ada6fd0bedebadddb5f6a0edc

8324775: C2 SuperWord: refactor visited sets

Reviewed-by: kvn, chagedorn

! src/hotspot/share/opto/superword.cpp
! src/hotspot/share/opto/superword.hpp

Changeset: f0bae793
Author:    Emanuel Peter <epeter at openjdk.org>
Date:      2024-01-29 08:50:35 +0000
URL:       https://git.openjdk.org/lilliput/commit/f0bae7939a61a79f3e07de97451c433e91742069

8324750: C2: rename Matcher methods using "superword" -> "autovectorization"

Reviewed-by: kvn, chagedorn

! src/hotspot/cpu/aarch64/aarch64.ad
! src/hotspot/cpu/aarch64/aarch64_vector.ad
! src/hotspot/cpu/aarch64/aarch64_vector_ad.m4
! src/hotspot/cpu/arm/arm.ad
! src/hotspot/cpu/ppc/ppc.ad
! src/hotspot/cpu/riscv/riscv.ad
! src/hotspot/cpu/riscv/riscv_v.ad
! src/hotspot/cpu/s390/s390.ad
! src/hotspot/cpu/x86/x86.ad
! src/hotspot/share/opto/matcher.hpp
! src/hotspot/share/opto/superword.cpp
! src/hotspot/share/opto/vectornode.cpp

Changeset: 69586e7b
Author:    Daniel Lund?n <dlunden at openjdk.org>
Committer: Roberto Casta?eda Lozano <rcastanedalo at openjdk.org>
Date:      2024-01-29 09:14:26 +0000
URL:       https://git.openjdk.org/lilliput/commit/69586e7bdffe1a840c3a86e6ec83568de24c6fe5

8322996: BoxLockNode creation fails with assert(reg < CHUNK_SIZE) failed: sanity

Reviewed-by: rcastanedalo, kvn

! src/hotspot/share/opto/graphKit.cpp
! src/hotspot/share/opto/locknode.cpp
! src/hotspot/share/opto/parse1.cpp
! src/hotspot/share/opto/parse2.cpp
! src/hotspot/share/opto/regmask.hpp
+ test/hotspot/jtreg/compiler/locks/TestNestedSynchronize.java

Changeset: b39b8764
Author:    Hamlin Li <mli at openjdk.org>
Date:      2024-01-29 09:17:46 +0000
URL:       https://git.openjdk.org/lilliput/commit/b39b876493cc932644ad0ab9f689587c7feb7dc8

8324304: RISC-V: add hw probe flags

Reviewed-by: fyang, rehn

! src/hotspot/os_cpu/linux_riscv/riscv_hwprobe.cpp
! src/hotspot/os_cpu/linux_riscv/vm_version_linux_riscv.cpp

Changeset: 72ba8178
Author:    Christian Hagedorn <chagedorn at openjdk.org>
Date:      2024-01-29 09:20:52 +0000
URL:       https://git.openjdk.org/lilliput/commit/72ba8178a8271d4a04a0b789f28b23414b8989ed

8324236: compiler/ciReplay/TestInliningProtectionDomain.java failed with RuntimeException: should only dump inline information for ... expected true, was false

Reviewed-by: kvn

! test/hotspot/jtreg/compiler/ciReplay/TestInliningProtectionDomain.java

Changeset: 628348d3
Author:    Kuai Wei <kuaiwei.kw at alibaba-inc.com>
Committer: Andrew Haley <aph at openjdk.org>
Date:      2024-01-29 09:33:22 +0000
URL:       https://git.openjdk.org/lilliput/commit/628348d3e97b669ab4136b1749b8fccf373eb2a0

8324186: Use "dmb.ishst+dmb.ishld" for release barrier

Reviewed-by: fyang, aph

! src/hotspot/cpu/aarch64/aarch64.ad
! src/hotspot/cpu/aarch64/globals_aarch64.hpp
! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/vm_version_aarch64.cpp
+ test/micro/org/openjdk/bench/vm/compiler/FinalFieldInitialize.java

Changeset: 7a300b63
Author:    Denghui Dong <ddong at openjdk.org>
Date:      2024-01-29 09:47:24 +0000
URL:       https://git.openjdk.org/lilliput/commit/7a300b63b5ca22dfe3e831e641f7a11b9c719b30

8324213: C1: There is no need for Canonicalizer to handle IfOp

Reviewed-by: dlong, chagedorn

! src/hotspot/share/c1/c1_Canonicalizer.cpp

Changeset: 3066d49c
Author:    Emanuel Peter <epeter at openjdk.org>
Date:      2024-01-29 10:13:43 +0000
URL:       https://git.openjdk.org/lilliput/commit/3066d49cc1910bb9ed01558582fdeb2385c484c3

8317572: C2 SuperWord: refactor/improve TraceSuperWord, replace VectorizeDebugOption with TraceAutoVectorization

Reviewed-by: chagedorn, kvn

! src/hotspot/share/compiler/compilerDirectives.cpp
! src/hotspot/share/compiler/compilerDirectives.hpp
! src/hotspot/share/compiler/compilerOracle.cpp
! src/hotspot/share/compiler/compilerOracle.hpp
! src/hotspot/share/compiler/directivesParser.cpp
! src/hotspot/share/opto/phasetype.hpp
! 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
! src/hotspot/share/utilities/stringUtils.cpp
! src/hotspot/share/utilities/stringUtils.hpp
! test/hotspot/jtreg/compiler/oracle/TestInvalidCompileCommand.java

Changeset: 4df04f0e
Author:    Albert Mingkun Yang <ayang at openjdk.org>
Date:      2024-01-29 12:42:10 +0000
URL:       https://git.openjdk.org/lilliput/commit/4df04f0ec910525cdef1dea40a3c2d184213ea3a

8324769: Serial: Remove unused TenuredGeneration::unsafe_max_alloc_nogc

Reviewed-by: tschatzl

! src/hotspot/share/gc/serial/defNewGeneration.hpp
! src/hotspot/share/gc/serial/generation.hpp
! src/hotspot/share/gc/serial/tenuredGeneration.cpp
! src/hotspot/share/gc/serial/tenuredGeneration.hpp

Changeset: fe0eec7e
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2024-01-29 13:55:00 +0000
URL:       https://git.openjdk.org/lilliput/commit/fe0eec7e20bc4c39d6c2b58d81ffd5c0ef1fdeda

8324840: windows-x64-slowdebug does not build anymore after JDK-8317572

Reviewed-by: epeter

! src/hotspot/share/utilities/stringUtils.hpp

Changeset: 951b5f8e
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2024-01-29 15:13:44 +0000
URL:       https://git.openjdk.org/lilliput/commit/951b5f8ecb9cd2a72b3904c110179afe487ada2b

8324723: GHA: Upgrade some actions to avoid deprecated Node 16

Reviewed-by: sgehwolf, ihse

! .github/actions/do-build/action.yml
! .github/actions/get-bootjdk/action.yml
! .github/actions/get-bundles/action.yml
! .github/actions/get-jtreg/action.yml
! .github/actions/get-msys2/action.yml
! .github/actions/upload-bundles/action.yml
! .github/workflows/build-cross-compile.yml
! .github/workflows/main.yml
! .github/workflows/test.yml

Changeset: a6bdee48
Author:    Coleen Phillimore <coleenp at openjdk.org>
Date:      2024-01-29 17:07:32 +0000
URL:       https://git.openjdk.org/lilliput/commit/a6bdee48f39993128d8095d40ab417f0102af0f4

8324681: Replace NULL with nullptr in HotSpot jtreg test native code files

Reviewed-by: kevinw, kbarrett, dholmes

! test/hotspot/jtreg/runtime/Thread/libAsyncExceptionOnMonitorEnter.cpp
! test/hotspot/jtreg/runtime/Thread/libStopAtExit.cpp
! test/hotspot/jtreg/runtime/Thread/libSuspendAtExit.cpp
! test/hotspot/jtreg/runtime/clinit/libClassInitBarrier.cpp
! test/hotspot/jtreg/serviceability/AsyncGetCallTrace/libAsyncGetCallTraceTest.cpp
! test/hotspot/jtreg/serviceability/jvmti/CompiledMethodLoad/libCompiledZombie.cpp
! test/hotspot/jtreg/serviceability/jvmti/DynamicCodeGenerated/libDynamicCodeGenerated.cpp
! test/hotspot/jtreg/serviceability/jvmti/GenerateEvents/libGenerateEvents1.cpp
! test/hotspot/jtreg/serviceability/jvmti/GenerateEvents/libGenerateEvents2.cpp
! test/hotspot/jtreg/serviceability/jvmti/GetClassFields/FilteredFields/libFilteredFieldsTest.cpp
! test/hotspot/jtreg/serviceability/jvmti/GetClassMethods/libOverpassMethods.cpp
! test/hotspot/jtreg/serviceability/jvmti/GetLocalVariable/libGetLocalVars.cpp
! test/hotspot/jtreg/serviceability/jvmti/GetLocalVariable/libGetSetLocalUnsuspended.cpp
! test/hotspot/jtreg/serviceability/jvmti/GetThreadListStackTraces/libOneGetThreadListStackTraces.cpp
! test/hotspot/jtreg/serviceability/jvmti/Heap/libIterateHeapWithEscapeAnalysisEnabled.cpp
! test/hotspot/jtreg/serviceability/jvmti/HeapMonitor/libHeapMonitorTest.cpp
! test/hotspot/jtreg/serviceability/jvmti/HiddenClass/libHiddenClassSigTest.cpp
! test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/MissedStackMapFrames/libMissedStackMapFrames.cpp
! test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/libRedefineRetransform.cpp
! test/hotspot/jtreg/serviceability/jvmti/SetBreakpoint/libTestManyBreakpoints.cpp
! test/hotspot/jtreg/serviceability/jvmti/SetTag/libTagMapTest.cpp
! test/hotspot/jtreg/serviceability/jvmti/SuspendWithCurrentThread/libSuspendWithCurrentThread.cpp
! test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorEnter/libSuspendWithObjectMonitorEnter.cpp
! test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/libSuspendWithObjectMonitorWait.cpp
! test/hotspot/jtreg/serviceability/jvmti/SuspendWithRawMonitorEnter/libSuspendWithRawMonitorEnter.cpp
! test/hotspot/jtreg/serviceability/jvmti/VMObjectAlloc/libVMObjectAlloc.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/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/ForceEarlyReturnTest/libForceEarlyReturnTest.cpp
! test/hotspot/jtreg/serviceability/jvmti/vthread/GetSetLocalTest/libGetSetLocalTest.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/VThreadMonitorTest/libVThreadMonitorTest.cpp
! test/hotspot/jtreg/serviceability/jvmti/vthread/VThreadNotifyFramePopTest/libVThreadNotifyFramePopTest.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/serviceability/monitoring/ThreadInfo/GetLockOwnerName/libGetLockOwnerName.cpp
! test/hotspot/jtreg/testlibrary/jvmti/libJvmtiUtils.cpp
! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/libdefine.cpp
! test/hotspot/jtreg/vmTestbase/gc/gctests/nativeGC03/libnativeGC03.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_OnLoad/agentonload002/agentonload002.cpp
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/Agent_OnLoad/agentonload003/agentonload003.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/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/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/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/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/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/ExceptionCheckingJniEnv/exceptionjni001/exceptionjni001.cpp
! test/hotspot/jtreg/vmTestbase/nsk/share/JVMTIagent.cpp
! test/hotspot/jtreg/vmTestbase/nsk/share/aod/aod.cpp
! 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/jni/ExceptionCheckingJniEnv.cpp
! test/hotspot/jtreg/vmTestbase/nsk/share/jni/ExceptionCheckingJniEnv.hpp
! test/hotspot/jtreg/vmTestbase/nsk/share/jni/JNIreferences.cpp
! test/hotspot/jtreg/vmTestbase/nsk/share/jni/jni_tools.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/Injector.cpp
! test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/agent_tools.cpp
! test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/aod/jvmti_aod.cpp
! 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/unit/Heap.cpp
! test/hotspot/jtreg/vmTestbase/nsk/share/native/native_thread.cpp
! test/hotspot/jtreg/vmTestbase/nsk/share/native/nsk_list.cpp
! test/hotspot/jtreg/vmTestbase/nsk/share/native/nsk_mutex.cpp
! test/hotspot/jtreg/vmTestbase/nsk/share/native/nsk_tools.cpp
! test/hotspot/jtreg/vmTestbase/nsk/stress/jni/gclocker/libgcl001.cpp
! test/hotspot/jtreg/vmTestbase/nsk/stress/jni/libjnistress001.cpp
! test/hotspot/jtreg/vmTestbase/nsk/stress/jni/libjnistress003.cpp
! test/hotspot/jtreg/vmTestbase/nsk/stress/strace/strace005.cpp
! test/hotspot/jtreg/vmTestbase/nsk/stress/strace/strace006.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/awt/JAWT/myfile.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/loaderLookup/libLoaderLookupInvoker.cpp
! test/jdk/jni/nullCaller/CallHelper.hpp
! test/jdk/jni/nullCaller/exeNullCallerTest.cpp

Changeset: c1281e6b
Author:    Coleen Phillimore <coleenp at openjdk.org>
Date:      2024-01-29 17:12:13 +0000
URL:       https://git.openjdk.org/lilliput/commit/c1281e6b45ed167df69d29a6039d81854c145ae6

8324678: Replace NULL with nullptr in HotSpot gtests

Reviewed-by: kbarrett, dholmes, jwaters

! test/hotspot/gtest/compiler/test_directivesParser.cpp
! test/hotspot/gtest/gc/g1/test_freeRegionList.cpp
! test/hotspot/gtest/gc/g1/test_g1CardSet.cpp
! test/hotspot/gtest/gc/g1/test_stressCommitUncommit.cpp
! test/hotspot/gtest/gc/shared/test_bufferNodeAllocator.cpp
! test/hotspot/gtest/gc/shared/test_collectedHeap.cpp
! test/hotspot/gtest/gc/shared/test_collectorPolicy.cpp
! test/hotspot/gtest/gc/shared/test_oopStorage.cpp
! test/hotspot/gtest/gc/shared/test_oopStorage_parperf.cpp
! test/hotspot/gtest/gc/shared/test_workerDataArray.cpp
! test/hotspot/gtest/gc/x/test_xAddress.cpp
! test/hotspot/gtest/gtestMain.cpp
! test/hotspot/gtest/jfr/test_adaptiveSampler.cpp
! test/hotspot/gtest/jfr/test_networkUtilization.cpp
! test/hotspot/gtest/jfr/test_threadCpuLoad.cpp
! test/hotspot/gtest/logging/logTestFixture.cpp
! test/hotspot/gtest/logging/logTestUtils.inline.hpp
! test/hotspot/gtest/logging/test_asynclog.cpp
! test/hotspot/gtest/logging/test_gcTraceTime.cpp
! test/hotspot/gtest/logging/test_log.cpp
! test/hotspot/gtest/logging/test_logConfiguration.cpp
! test/hotspot/gtest/logging/test_logDecorations.cpp
! test/hotspot/gtest/logging/test_logMessageTest.cpp
! test/hotspot/gtest/logging/test_logSelectionList.cpp
! test/hotspot/gtest/logging/test_logStream.cpp
! test/hotspot/gtest/logging/test_logTag.cpp
! test/hotspot/gtest/logging/test_logTagSet.cpp
! test/hotspot/gtest/logging/test_logTagSetDescriptions.cpp
! test/hotspot/gtest/memory/test_arena.cpp
! test/hotspot/gtest/memory/test_guardedMemory.cpp
! test/hotspot/gtest/memory/test_virtualspace.cpp
! test/hotspot/gtest/metaspace/metaspaceGtestCommon.cpp
! test/hotspot/gtest/metaspace/metaspaceGtestCommon.hpp
! test/hotspot/gtest/metaspace/metaspaceGtestContexts.cpp
! test/hotspot/gtest/metaspace/metaspaceGtestContexts.hpp
! test/hotspot/gtest/metaspace/metaspaceGtestSparseArray.hpp
! test/hotspot/gtest/metaspace/test_binlist.cpp
! test/hotspot/gtest/metaspace/test_blocktree.cpp
! test/hotspot/gtest/metaspace/test_chunkManager_stress.cpp
! test/hotspot/gtest/metaspace/test_chunkheaderpool.cpp
! test/hotspot/gtest/metaspace/test_freeblocks.cpp
! test/hotspot/gtest/metaspace/test_is_metaspace_obj.cpp
! test/hotspot/gtest/metaspace/test_metachunk.cpp
! test/hotspot/gtest/metaspace/test_metachunklist.cpp
! test/hotspot/gtest/metaspace/test_metaspacearena.cpp
! test/hotspot/gtest/metaspace/test_metaspacearena_stress.cpp
! test/hotspot/gtest/metaspace/test_virtualspacenode.cpp
! test/hotspot/gtest/nmt/test_nmt_buffer_overflow_detection.cpp
! test/hotspot/gtest/nmt/test_nmtpreinit.cpp
! test/hotspot/gtest/nmt/test_nmtpreinitmap.cpp
! test/hotspot/gtest/runtime/test_ThreadsListHandle.cpp
! test/hotspot/gtest/runtime/test_arguments.cpp
! test/hotspot/gtest/runtime/test_classLoader.cpp
! test/hotspot/gtest/runtime/test_committed_virtualmemory.cpp
! test/hotspot/gtest/runtime/test_globals.cpp
! test/hotspot/gtest/runtime/test_os.cpp
! test/hotspot/gtest/runtime/test_os_linux.cpp
! test/hotspot/gtest/runtime/test_os_linux_cgroups.cpp
! test/hotspot/gtest/runtime/test_os_windows.cpp
! test/hotspot/gtest/runtime/test_perfdata.cpp
! test/hotspot/gtest/runtime/test_safefetch.cpp
! test/hotspot/gtest/runtime/test_threads.cpp
! test/hotspot/gtest/runtime/test_virtualMemoryTracker.cpp
! test/hotspot/gtest/runtime/test_vmStructs.cpp
! test/hotspot/gtest/testutils.cpp
! test/hotspot/gtest/testutils.hpp
! test/hotspot/gtest/utilities/test_concurrentHashtable.cpp
! test/hotspot/gtest/utilities/test_linkedlist.cpp
! test/hotspot/gtest/utilities/test_lockFreeStack.cpp
! test/hotspot/gtest/utilities/test_metaspaceClosure.cpp
! test/hotspot/gtest/utilities/test_nonblockingQueue.cpp
! test/hotspot/gtest/utilities/test_objectBitSet.cpp
! test/hotspot/gtest/utilities/test_quicksort.cpp
! test/hotspot/gtest/utilities/test_vmerror.cpp

Changeset: d1e67636
Author:    Harshitha Onkar <honkar at openjdk.org>
Date:      2024-01-29 18:03:30 +0000
URL:       https://git.openjdk.org/lilliput/commit/d1e676360d5143cf12655ab1175a4a60bf402473

8324733: [macos14] Problem list tests which fail due to macOS bug described in JDK-8322653

Reviewed-by: prr, tr

! test/jdk/ProblemList.txt

Changeset: fb07bbe7
Author:    Doug Simon <dnsimon at openjdk.org>
Date:      2024-01-29 19:12:44 +0000
URL:       https://git.openjdk.org/lilliput/commit/fb07bbe7b2a97b914596ff42105fd867a0916a7a

8324717: Remove HotSpotJVMCICompilerFactory

Reviewed-by: thartmann, never

- src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotJVMCICompilerFactory.java
! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotJVMCIRuntime.java

Changeset: 84deeb6c
Author:    Joshua Cao <joshcao at amazon.com>
Committer: Xin Liu <xliu at openjdk.org>
Date:      2024-01-29 19:54:42 +0000
URL:       https://git.openjdk.org/lilliput/commit/84deeb6cd58884bd794da88e4d5a6c873286383b

8324667: fold Parse::seems_stable_comparison()

Reviewed-by: jkarthikeyan, chagedorn, xliu

! src/hotspot/share/opto/parse.hpp
! src/hotspot/share/opto/parse2.cpp

Changeset: e999dfcb
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2024-01-29 20:25:32 +0000
URL:       https://git.openjdk.org/lilliput/commit/e999dfcb405962bc4d77b9740d36193f1ebe4a2c

8323503: x86: Shorter movptr(reg, imm) for 32-bit unsigned immediates

Reviewed-by: stuefe, kvn, eastigeevich

! src/hotspot/cpu/x86/macroAssembler_x86.cpp
! src/hotspot/share/asm/assembler.hpp

Changeset: 64c3642c
Author:    Vladimir Petko <vpetko at openjdk.org>
Committer: Jonathan Gibbons <jjg at openjdk.org>
Date:      2024-01-29 21:28:49 +0000
URL:       https://git.openjdk.org/lilliput/commit/64c3642c57719940855b220025b33758950b3980

8242564: javadoc crashes:: class cast exception com.sun.tools.javac.code.Symtab$6

Reviewed-by: jjg

! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/ToolEnvironment.java
! test/langtools/jdk/javadoc/doclet/testClassTree/TestClassTree.java

Changeset: b6d364ad
Author:    Vladimir Kozlov <kvn at openjdk.org>
Date:      2024-01-30 01:08:18 +0000
URL:       https://git.openjdk.org/lilliput/commit/b6d364ad88ca0e554a47ef7daba03bb07fd95b01

8324865: windows-x64-slowdebug still does not build after JDK-8324840

Reviewed-by: dholmes, dcubed

! src/hotspot/share/utilities/stringUtils.hpp

Changeset: a1d65eb6
Author:    Gui Cao <gcao at openjdk.org>
Committer: Fei Yang <fyang at openjdk.org>
Date:      2024-01-30 02:07:20 +0000
URL:       https://git.openjdk.org/lilliput/commit/a1d65eb6d87ff9019a9a92a775213be2a8b60fd1

8324125: Improve class initialization barrier in TemplateTable::_new for RISC-V

Reviewed-by: fyang, rehn

! src/hotspot/cpu/riscv/templateTable_riscv.cpp

Changeset: fd8adf30
Author:    Albert Mingkun Yang <ayang at openjdk.org>
Date:      2024-01-30 08:52:17 +0000
URL:       https://git.openjdk.org/lilliput/commit/fd8adf308357355bd33916ad80e2328c35434e5a

8324856: Serial: Move Generation::is_in to DefNewGeneration

Reviewed-by: stefank, tschatzl

! src/hotspot/share/gc/serial/defNewGeneration.cpp
! src/hotspot/share/gc/serial/defNewGeneration.hpp
! src/hotspot/share/gc/serial/generation.cpp
! src/hotspot/share/gc/serial/generation.hpp

Changeset: f0024f58
Author:    Roman Kennke <rkennke at openjdk.org>
Date:      2024-01-30 13:26:10 +0000
URL:       https://git.openjdk.org/lilliput/commit/f0024f585dcc1d8afe5808bf626efd8f514da070

8324734: Relax too-strict assert(VM_Version::supports_evex()) in Assembler::locate_operand()

Co-authored-by: Vladimir Kozlov <kvn at openjdk.org>
Reviewed-by: kvn, shade

! src/hotspot/cpu/x86/assembler_x86.cpp
! src/hotspot/cpu/x86/vm_version_x86.cpp
! src/hotspot/cpu/x86/vm_version_x86.hpp
! src/hotspot/share/runtime/abstract_vm_version.cpp
! src/hotspot/share/runtime/abstract_vm_version.hpp

Changeset: f57c7223
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2024-01-30 18:10:25 +0000
URL:       https://git.openjdk.org/lilliput/commit/f57c7223cf9b732db5255b3e394ee07ff741f074

8324880: Rename get_stack_trace.h

Reviewed-by: dholmes, jwaters, sspitsyn

! 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/get_stack_trace.hpp
! 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

Changeset: d51aaf63
Author:    Calvin Cheung <ccheung at openjdk.org>
Date:      2024-01-30 20:00:10 +0000
URL:       https://git.openjdk.org/lilliput/commit/d51aaf6304e0dd1cde4a85bf6a822332f56c0ff2

8323950: Null CLD while loading shared lambda proxy class with javaagent active

Reviewed-by: matsaave, iklam

! src/hotspot/share/classfile/systemDictionary.cpp
+ test/hotspot/jtreg/runtime/cds/appcds/TransformInterfaceOfLambda.java
+ test/hotspot/jtreg/runtime/cds/appcds/test-classes/SimpleTest.java

Changeset: 11e28bd6
Author:    Emanuel Peter <epeter at openjdk.org>
Date:      2024-01-30 20:14:20 +0000
URL:       https://git.openjdk.org/lilliput/commit/11e28bd61968700956d2155a77688459fd7c028f

8324794: C2 SuperWord: do not ignore reductions in SuperWord::unrolling_analysis

Reviewed-by: chagedorn, kvn

! src/hotspot/share/opto/superword.cpp
! test/hotspot/jtreg/compiler/loopopts/superword/TestUnorderedReductionPartialVectorization.java

Changeset: 8892d45b
Author:    Leonid Mesnik <lmesnik at openjdk.org>
Date:      2024-01-30 21:05:12 +0000
URL:       https://git.openjdk.org/lilliput/commit/8892d45b9f0018c5a58c85094c305a03612749f4

8324582: Replace -Djava.util.concurrent.ForkJoinPool.common.parallelism to -Djdk.virtualThreadScheduler.maxPoolSize in jvmti vthread tests

Reviewed-by: cjplummer, sspitsyn

! test/hotspot/jtreg/serviceability/jvmti/thread/GetAllThreads/allthr01/allthr01.java
! test/hotspot/jtreg/serviceability/jvmti/thread/GetAllThreads/allthr01/liballthr01.cpp
! test/hotspot/jtreg/serviceability/jvmti/vthread/FollowReferences/VThreadStackRefTest.java
! test/hotspot/jtreg/serviceability/jvmti/vthread/HeapDump/VThreadInHeapDump.java
! test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendResume1/SuspendResume1.java
! test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendResume2/SuspendResume2.java
! test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendResumeAll/SuspendResumeAll.java
! test/hotspot/jtreg/serviceability/jvmti/vthread/WaitNotifySuspendedVThreadTest/WaitNotifySuspendedVThreadTest.java

Changeset: c3c1d5bd
Author:    Eirik Bj?rsn?s <eirbjo at openjdk.org>
Date:      2024-01-30 23:52:37 +0000
URL:       https://git.openjdk.org/lilliput/commit/c3c1d5bd12f80c6a720e431961e90b09c2d972f9

8324998: Add test cases for String.regionMatches comparing Turkic dotted/dotless I with uppercase latin I

Reviewed-by: naoto, iris

! test/jdk/java/lang/String/CompactString/RegionMatches.java

Changeset: 7d1a4880
Author:    Leonid Mesnik <lmesnik at openjdk.org>
Date:      2024-01-30 23:56:04 +0000
URL:       https://git.openjdk.org/lilliput/commit/7d1a48807a482cd19156298ce21d9492f0d912da

8324861: Exceptions::wrap_dynamic_exception() doesn't have ResourceMark

Reviewed-by: dholmes, coleenp

! src/hotspot/share/utilities/exceptions.cpp

Changeset: 83b3c9b3
Author:    Amit Kumar <amitkumar at openjdk.org>
Date:      2024-01-31 04:41:50 +0000
URL:       https://git.openjdk.org/lilliput/commit/83b3c9b3eeda33bd5de9b1affb39fb1a8a674e48

8322649: Improve class initialization barrier in TemplateTable::_new for S390

Reviewed-by: mdoerr, lucy

! src/hotspot/cpu/s390/templateTable_s390.cpp

Changeset: 577de17d
Author:    Tejesh R <tr at openjdk.org>
Date:      2024-01-31 05:26:30 +0000
URL:       https://git.openjdk.org/lilliput/commit/577de17d24e83c55ab10a5794f381243a298fc68

8259550: The content of the print out displayed incomplete with the NimbusLAF

Reviewed-by: dnguyen, psadhukhan, abhiscxk

! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthTableUI.java
! test/jdk/javax/swing/JTable/PrintManualTest_FitWidthMultiple.java

Changeset: f7121de4
Author:    Varada M <varadam at openjdk.org>
Committer: Martin Doerr <mdoerr at openjdk.org>
Date:      2024-01-31 06:12:35 +0000
URL:       https://git.openjdk.org/lilliput/commit/f7121de4a080c222e2bbf2468be94950db78530a

8322648: Improve class initialization barrier in TemplateTable::_new for PPC

Reviewed-by: mdoerr

! src/hotspot/cpu/ppc/templateTable_ppc_64.cpp

Changeset: ec56c72b
Author:    Per Minborg <pminborg at openjdk.org>
Date:      2024-01-31 09:54:03 +0000
URL:       https://git.openjdk.org/lilliput/commit/ec56c72b5160ea20ed123c6e1e3379b6b13ecb7d

8323601: Improve LayoutPath.PathElement::toString

Reviewed-by: jvernee

! src/java.base/share/classes/java/lang/foreign/MemoryLayout.java
! src/java.base/share/classes/jdk/internal/foreign/LayoutPath.java
! test/jdk/java/foreign/TestLayoutPaths.java

Changeset: b5c267fc
Author:    Lance Andersen <lancea at openjdk.org>
Date:      2024-01-31 11:06:01 +0000
URL:       https://git.openjdk.org/lilliput/commit/b5c267fc8a0af50be9e3d1d09cdaa6bf4bb29851

8324632: Update Zlib Data Compression Library to Version 1.3.1

Reviewed-by: iris, alanb

! src/java.base/share/native/libzip/zlib/ChangeLog
! src/java.base/share/native/libzip/zlib/README
! src/java.base/share/native/libzip/zlib/deflate.c
! src/java.base/share/native/libzip/zlib/deflate.h
! src/java.base/share/native/libzip/zlib/gzguts.h
! src/java.base/share/native/libzip/zlib/gzlib.c
! src/java.base/share/native/libzip/zlib/inflate.c
! src/java.base/share/native/libzip/zlib/inftrees.c
! src/java.base/share/native/libzip/zlib/inftrees.h
! src/java.base/share/native/libzip/zlib/patches/ChangeLog_java
! src/java.base/share/native/libzip/zlib/trees.c
! src/java.base/share/native/libzip/zlib/zconf.h
! src/java.base/share/native/libzip/zlib/zlib.h
! src/java.base/share/native/libzip/zlib/zutil.h

Changeset: ec6c35c4
Author:    Albert Mingkun Yang <ayang at openjdk.org>
Date:      2024-01-31 12:44:29 +0000
URL:       https://git.openjdk.org/lilliput/commit/ec6c35c4ac4beba91450269fca358178e4632a7d

8324970: Serial: Refactor signature of maintain_old_to_young_invariant

Reviewed-by: tschatzl

! src/hotspot/share/gc/serial/cardTableRS.cpp
! src/hotspot/share/gc/serial/cardTableRS.hpp

Changeset: 725314fb
Author:    Albert Mingkun Yang <ayang at openjdk.org>
Date:      2024-01-31 12:44:39 +0000
URL:       https://git.openjdk.org/lilliput/commit/725314fb739e10aa54e224f46d3c71015cf9d158

8324771: Obsolete RAMFraction related flags

Reviewed-by: dholmes, mbaesken, tschatzl

! src/hotspot/share/gc/shared/gc_globals.hpp
! src/hotspot/share/gc/z/zArguments.cpp
! src/hotspot/share/runtime/arguments.cpp
! src/hotspot/share/runtime/flags/jvmFlag.cpp
! test/hotspot/jtreg/runtime/CommandLine/VMAliasOptions.java
! test/hotspot/jtreg/runtime/CommandLine/VMDeprecatedOptions.java

Changeset: 66971600
Author:    Eirik Bj?rsn?s <eirbjo at openjdk.org>
Date:      2024-01-31 13:59:19 +0000
URL:       https://git.openjdk.org/lilliput/commit/66971600f7ba796ff5bb9714591c3faa0bb2249d

8320712: Rewrite BadFactoryTest in pure Java

Reviewed-by: jpai, sundar

! test/jdk/javax/script/JDK_8196959/BadFactoryTest.java
- test/jdk/javax/script/JDK_8196959/BadFactoryTest.sh

Changeset: 1733d2ea
Author:    Aggelos Biboudis <abimpoudis at openjdk.org>
Date:      2024-01-31 14:18:13 +0000
URL:       https://git.openjdk.org/lilliput/commit/1733d2ea244756238c302d802511eb1557cd46ac

8303374: Implement JEP 455: Primitive Types in Patterns, instanceof, and switch (Preview)

Co-authored-by: Jan Lahoda <jlahoda at openjdk.org>
Co-authored-by: Maurizio Cimadamore <mcimadamore at openjdk.org>
Co-authored-by: Gavin Bierman <gbierman at openjdk.org>
Co-authored-by: Brian Goetz <briangoetz at openjdk.org>
Co-authored-by: Raffaello Giulietti <rgiulietti at openjdk.org>
Co-authored-by: Aggelos Biboudis <abimpoudis at openjdk.org>
Reviewed-by: vromero, jlahoda

+ src/java.base/share/classes/java/lang/runtime/ExactConversionsSupport.java
! src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java
! src/java.base/share/classes/sun/invoke/util/Wrapper.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Preview.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/code/TypeTag.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties
! src/jdk.jshell/share/classes/jdk/jshell/CompletenessAnalyzer.java
+ test/jdk/java/lang/runtime/ExactnessConversionsSupportTest.java
! test/jdk/java/lang/runtime/SwitchBootstrapsTest.java
! test/langtools/jdk/jshell/CompletenessTest.java
+ test/langtools/jdk/jshell/PrimitiveInstanceOfTest.java
+ test/langtools/tools/javac/diags/examples/DefaultAndBothBoolean.java
- test/langtools/tools/javac/diags/examples/NotApplicableTypes.java
+ test/langtools/tools/javac/diags/examples/PrimitivePatternMatching.java
- test/langtools/tools/javac/diags/examples/SelectorTypeNotAllowed.java
! test/langtools/tools/javac/diags/examples/TypeReqClassArray.java
! test/langtools/tools/javac/diags/examples/TypeReqRef.java
+ test/langtools/tools/javac/diags/examples/UnconditionalPatternAndBothBoolean.java
! test/langtools/tools/javac/patterns/CastConversionMatch.java
! test/langtools/tools/javac/patterns/CastConversionMatch.out
! test/langtools/tools/javac/patterns/DeconstructionPatternErrors.java
! test/langtools/tools/javac/patterns/DeconstructionPatternErrors.out
+ test/langtools/tools/javac/patterns/PrimitiveInstanceOfComboTest.java
+ test/langtools/tools/javac/patterns/PrimitiveInstanceOfErrors.java
+ test/langtools/tools/javac/patterns/PrimitiveInstanceOfErrors.out
+ test/langtools/tools/javac/patterns/PrimitiveInstanceOfNumericValueTests.java
+ test/langtools/tools/javac/patterns/PrimitiveInstanceOfPatternOpWithRecordPatterns.java
+ test/langtools/tools/javac/patterns/PrimitiveInstanceOfTypeComparisonOp.java
+ test/langtools/tools/javac/patterns/PrimitivePatternsSwitch.java
+ test/langtools/tools/javac/patterns/PrimitivePatternsSwitchErrors.java
+ test/langtools/tools/javac/patterns/PrimitivePatternsSwitchErrors.out
! test/langtools/tools/javac/patterns/SourceLevelChecks.java
! test/langtools/tools/javac/patterns/SwitchErrors.java
! test/langtools/tools/javac/patterns/SwitchErrors.out
- test/langtools/tools/javac/switchextra/SwitchNoExtraTypes.java
- test/langtools/tools/javac/switchextra/SwitchNoExtraTypes.out
+ test/micro/org/openjdk/bench/jdk/preview/patterns/Exactness.java

Changeset: 2cd1ba6a
Author:    William Kemper <wkemper at openjdk.org>
Committer: Aleksey Shipilev <shade at openjdk.org>
Date:      2024-01-31 16:42:44 +0000
URL:       https://git.openjdk.org/lilliput/commit/2cd1ba6a52eafffa65d0f2532a07fff89f9cea0e

8324981: Shenandoah: Move commit and soft max heap changed methods into heap

Reviewed-by: shade

! src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp
! src/hotspot/share/gc/shenandoah/shenandoahControlThread.hpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp

Changeset: 1f2922ad
Author:    Rajat Mahajan <rmahajan at openjdk.org>
Committer: Alexey Ivanov <aivanov at openjdk.org>
Date:      2024-01-31 17:35:50 +0000
URL:       https://git.openjdk.org/lilliput/commit/1f2922ad8526d378ee7b616e5423ce56f20340db

8320342: Use PassFailJFrame for TruncatedPopupMenuTest.java

Reviewed-by: honkar, aivanov

+ test/jdk/java/awt/PopupMenu/TruncatedPopupMenuTest.java

Changeset: 62c9530c
Author:    Harshitha Onkar <honkar at openjdk.org>
Date:      2024-01-31 17:42:00 +0000
URL:       https://git.openjdk.org/lilliput/commit/62c9530c056dbaaf65be0f43295af3d225326a4c

8324238: [macOS] java/awt/Frame/ShapeNotSetSometimes/ShapeNotSetSometimes.java fails with the shape has not been applied msg

Reviewed-by: azvegint, dnguyen

! test/jdk/java/awt/Frame/ShapeNotSetSometimes/ShapeNotSetSometimes.java

Changeset: f2920533
Author:    Per Minborg <pminborg at openjdk.org>
Date:      2024-01-31 17:59:50 +0000
URL:       https://git.openjdk.org/lilliput/commit/f2920533e97c0e0eef711c1e020a9a5cc610170f

8323621: JDK build should exclude snippet class in java.lang.foreign

Reviewed-by: mcimadamore

! make/modules/java.base/Java.gmk

Changeset: 0cc8e5be
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2024-01-31 19:19:21 +0000
URL:       https://git.openjdk.org/lilliput/commit/0cc8e5beed664a21c2668be86a9d3c5a1b165743

8325042: remove unused JVMDITools test files

Reviewed-by: coleenp

- test/hotspot/jtreg/vmTestbase/nsk/share/JVMDITools.cpp
- test/hotspot/jtreg/vmTestbase/nsk/share/JVMDITools.h
! test/hotspot/jtreg/vmTestbase/nsk/share/README

Changeset: 5b9b176c
Author:    Vladimir Kozlov <kvn at openjdk.org>
Date:      2024-01-31 19:42:02 +0000
URL:       https://git.openjdk.org/lilliput/commit/5b9b176c6729aeff2a70d304a1ef57da3965fb53

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

Reviewed-by: epeter, dlong, thartmann

! src/hotspot/share/runtime/deoptimization.cpp
+ test/hotspot/jtreg/compiler/escapeAnalysis/TestNestedRelockAtDeopt.java

Changeset: da4ffa35
Author:    Roman Kennke <rkennke at openjdk.org>
Date:      2024-02-07 12:24:25 +0000
URL:       https://git.openjdk.org/lilliput/commit/da4ffa35c274e014e1882584f3a133487de8aebe

Merge jdk:jdk-23+8

! .github/workflows/build-cross-compile.yml
! src/hotspot/cpu/aarch64/aarch64.ad
! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp
! src/hotspot/cpu/x86/macroAssembler_x86.cpp
! src/hotspot/share/gc/g1/g1CollectedHeap.cpp
! src/hotspot/share/gc/g1/g1FullCollector.cpp
! src/hotspot/share/gc/serial/defNewGeneration.cpp
! src/hotspot/share/gc/serial/serialHeap.cpp
! src/hotspot/share/gc/shared/gc_globals.hpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp
! src/hotspot/share/runtime/arguments.cpp
! src/hotspot/share/runtime/globals.hpp
! .github/workflows/build-cross-compile.yml
! src/hotspot/cpu/aarch64/aarch64.ad
! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp
! src/hotspot/cpu/x86/macroAssembler_x86.cpp
! src/hotspot/share/gc/g1/g1CollectedHeap.cpp
! src/hotspot/share/gc/g1/g1FullCollector.cpp
! src/hotspot/share/gc/serial/defNewGeneration.cpp
! src/hotspot/share/gc/serial/serialHeap.cpp
! src/hotspot/share/gc/shared/gc_globals.hpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp
! src/hotspot/share/runtime/arguments.cpp
! src/hotspot/share/runtime/globals.hpp

Changeset: 2b2cf5f6
Author:    Roman <rkennke at amazon.de>
Date:      2024-02-07 12:25:49 +0000
URL:       https://git.openjdk.org/lilliput/commit/2b2cf5f63f1582b7e828e075ba6ef33d4a4380ab

Merge branch 'master' into omworld

! src/hotspot/cpu/aarch64/aarch64.ad
! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp
! src/hotspot/cpu/x86/macroAssembler_x86.cpp
! src/hotspot/share/interpreter/interpreterRuntime.cpp
! src/hotspot/share/runtime/arguments.cpp
! src/hotspot/share/runtime/deoptimization.cpp
! src/hotspot/share/runtime/globals.hpp
! src/hotspot/share/runtime/javaThread.hpp
! src/hotspot/share/runtime/sharedRuntime.cpp
! src/hotspot/cpu/aarch64/aarch64.ad
! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp
! src/hotspot/cpu/x86/macroAssembler_x86.cpp
! src/hotspot/share/interpreter/interpreterRuntime.cpp
! src/hotspot/share/runtime/arguments.cpp
! src/hotspot/share/runtime/deoptimization.cpp
! src/hotspot/share/runtime/globals.hpp
! src/hotspot/share/runtime/javaThread.hpp
! src/hotspot/share/runtime/sharedRuntime.cpp


From stefan.karlsson at oracle.com  Wed Feb  7 13:07:42 2024
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Wed, 7 Feb 2024 14:07:42 +0100
Subject: CFV: New Lilliput Committer: Axel Boldt-Christmas
In-Reply-To: <93870E0D-11CA-477B-BB95-C70A297964B3@amazon.de>
References: <93870E0D-11CA-477B-BB95-C70A297964B3@amazon.de>
Message-ID: <e07d801b-c532-4041-ad80-f1bb74dd907f@oracle.com>

Vote: yes

StefanK

On 2024-02-07 13:37, Kennke, Roman wrote:
> I hereby nominate Axel Boldt-Christmas to Lilliput Committer.
>
> Axel is a software engineer at Oracle?s GC group. While Axel has not yet contributed directly to the Lilliput project, he is a prolific contributor (and reviewer) in the upstream JDK project, where he (among many others) contributed fixes and improvements to lightweight locking, and is currently working on improved ObjectMonitor handling, both of which are crucial for Lilliput. I would like to make him a Lilliput committer to facilitate closer collaboration on the project.
>
> See also:
> https://github.com/openjdk/lilliput/commits/master/?author=xmas92
>
> https://mail.openjdk.org/pipermail/lilliput-dev/2024-January/001302.html
>
> Votes are due by Feb 21, 2024.
>
> Only current Lilliput Committers [1] are eligible to vote
> on this nomination. Votes must be cast in the open by replying
> to this mailing list.
>
> For Lazy Consensus voting instructions, see [2].
>
> Roman Kennke
>
> [1] https://openjdk.org/census
> [2] https://openjdk.org/projects/#committer-vote
>
>
>
> 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  Wed Feb  7 13:09:32 2024
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 7 Feb 2024 14:09:32 +0100 (CET)
Subject: CFV: New Lilliput Committer: Axel Boldt-Christmas
In-Reply-To: <93870E0D-11CA-477B-BB95-C70A297964B3@amazon.de>
References: <93870E0D-11CA-477B-BB95-C70A297964B3@amazon.de>
Message-ID: <1520829616.602217.1707311372775.JavaMail.zimbra@univ-eiffel.fr>

vote: yes

R?mi

----- Original Message -----
> From: "Roman Kennke" <rkennke at amazon.de>
> To: lilliput-dev at openjdk.org
> Sent: Wednesday, February 7, 2024 1:37:15 PM
> Subject: CFV: New Lilliput Committer: Axel Boldt-Christmas

> I hereby nominate Axel Boldt-Christmas to Lilliput Committer.
> 
> Axel is a software engineer at Oracle?s GC group. While Axel has not yet
> contributed directly to the Lilliput project, he is a prolific contributor (and
> reviewer) in the upstream JDK project, where he (among many others) contributed
> fixes and improvements to lightweight locking, and is currently working on
> improved ObjectMonitor handling, both of which are crucial for Lilliput. I
> would like to make him a Lilliput committer to facilitate closer collaboration
> on the project.
> 
> See also:
> https://github.com/openjdk/lilliput/commits/master/?author=xmas92
> 
> https://mail.openjdk.org/pipermail/lilliput-dev/2024-January/001302.html
> 
> Votes are due by Feb 21, 2024.
> 
> Only current Lilliput Committers [1] are eligible to vote
> on this nomination. Votes must be cast in the open by replying
> to this mailing list.
> 
> For Lazy Consensus voting instructions, see [2].
> 
> Roman Kennke
> 
> [1] https://openjdk.org/census
> [2] https://openjdk.org/projects/#committer-vote
> 
> 
> 
> 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 coleen.phillimore at oracle.com  Wed Feb  7 13:26:24 2024
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Wed, 7 Feb 2024 08:26:24 -0500
Subject: CFV: New Lilliput Committer: Axel Boldt-Christmas
In-Reply-To: <e07d801b-c532-4041-ad80-f1bb74dd907f@oracle.com>
References: <93870E0D-11CA-477B-BB95-C70A297964B3@amazon.de>
 <e07d801b-c532-4041-ad80-f1bb74dd907f@oracle.com>
Message-ID: <9c81a28d-3448-4e9c-86e8-29ee7d05f8c4@oracle.com>

Vote: yes

On 2/7/24 8:07 AM, Stefan Karlsson wrote:
> Vote: yes
>
> StefanK
>
> On 2024-02-07 13:37, Kennke, Roman wrote:
>> I hereby nominate Axel Boldt-Christmas to Lilliput Committer.
>>
>> Axel is a software engineer at Oracle?s GC group. While Axel has not 
>> yet contributed directly to the Lilliput project, he is a prolific 
>> contributor (and reviewer) in the upstream JDK project, where he 
>> (among many others) contributed fixes and improvements to lightweight 
>> locking, and is currently working on improved ObjectMonitor handling, 
>> both of which are crucial for Lilliput. I would like to make him a 
>> Lilliput committer to facilitate closer collaboration on the project.
>>
>> See also:
>> https://github.com/openjdk/lilliput/commits/master/?author=xmas92
>>
>> https://mail.openjdk.org/pipermail/lilliput-dev/2024-January/001302.html
>>
>> Votes are due by Feb 21, 2024.
>>
>> Only current Lilliput Committers [1] are eligible to vote
>> on this nomination. Votes must be cast in the open by replying
>> to this mailing list.
>>
>> For Lazy Consensus voting instructions, see [2].
>>
>> Roman Kennke
>>
>> [1] https://openjdk.org/census
>> [2] https://openjdk.org/projects/#committer-vote
>>
>>
>>
>> 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 stuefe at openjdk.org  Wed Feb  7 14:22:00 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 7 Feb 2024 14:22:00 GMT
Subject: [master] RFR: JDK-8325104: Lilliput: Shrink Classpointers
Message-ID: <lm7SDOvsKA7Yt1yDQpYx5VPVjke0eAO0BB9ctkIA8qs=.206072f0-3274-492d-9224-d41adb3b842a@github.com>

Hi,

I wanted to get input on the following improvement for Lilliput. Testing is still ongoing, but things look really good, so this patch is hopefully near its final form (barring any objections from reviewers, of course).

Note: I have a companion patch prepared for upstream, minus the markword changes. I will attempt to get that one upstream quickly in order to not have a large delta between upstream and lilliput, especially in Metaspace.

## High-Level Overview

(for a short sequence of slides, please see https://github.com/tstuefe/fosdem24/blob/master/classpointers-and-liliput.pdf - these accompanied a talk we held at FOSDEM 24).

We want to reduce the bit size of narrow Klass to free up bits in the MarkWord. 

We cannot just reduce the Klass encoding range size (well, we could, and maybe we will later, but for now we decided not to). We instead increase the alignment Klass is stored at, and use that alignment shadow to store other information.

In other words, this patch changes the narrow Klass Pointer to a Klass ID, since now (almost) every value in its value range points to a different class. Therefore, we use the value range of nKlass much more efficiently.

We then use the newly freed bits in the MarkWord to restore the iHash to 31 bits: 


[ 22-bit nKlass | 31-bit iHash | 4 free bits | age | fwd | lck ]

nKlass gets reduced to 22 bits. Identity hash gets re-inflated to 31 bits. Preceding iHash are now 4 unused bits. Rest is unchanged.

(Note: I originally wanted to swap iHash and nKlass such that either of them could be loaded with a 32-bit load, but I found that tricky since C2 seems to rely on the nKlass offset in the Markword being > 0.)

## nKlass reduction:

The reduction in nKlass size is made by only storing them at 10-bit aligned addresses. That alignment (1KB) works well in practice since Klass - although var sized - typically is between 512 bytes and 1KB in size. Outliers are possible, but the size distribution is bell-curvish [1], so far-away outliers are very rare. 

To not lose memory to alignment waste, metaspace is reshaped to handle arbitrarily aligned allocations efficiently. Basically, we allow the non-Klass arena of a class loader to steal the alignment waste storage from the class arena. So, alignment waste blocks are filled with non-Klass metadata. That works very well in practice since non-Klass metadata is numerous and fine-granular compared to the big Klass blocks. Total footprint loss in metaspace is, therefore, almost zero (a few KB at most). We see class space to be used more, non-Klass space to be used less, but the total footprint is about the same.

The number of addressable classes is somewhat reduced now. From ~5 million we could fit before into a maxed-out (3 GB) class space, to ~3 million with 10-bit alignment. That is still a very high and acceptable number.

## CDS:

CDS is also modified to store Klass at 10-bit aligned addresses. That works well since CDS contains both non-Klass- and Klass-data both, so things just shift around. As with Metaspace, very little footprint loss here.

We now create four CDS archives: with and without coops, and with and without UseCOH. Since that is potentially contentious, I guarded the +COH versions with the configure option --enable-cds-archive-coh. 

## Costs:

The costs of these improvements are:

- when decoding an nKlass, the shift is not mandatory. Before, it was usually optional (only used on certain platforms when CDS was disabled).
- we reduce the number of loadable classes from ~5 mio to ~ 3 mio
- In theory, hyper-aligning >cache line could be detrimental. I attempted to measure that effect with a custom microbenchmark that aims to overwhelm L1, but so far I have not seen any effect above background noise. I will repeat these tests though, and have mitigations planned in case this should be an issue (basically, vary cadence by cache line size).

## Testing

I tested the default variant (COH disabled) and a variant with +COH as default. GHAs are clean. I ran tier 1 and 2 manually on Linux x64 and MacOS. 

Tests are currently being executed at Adoptium on Linux arm64 and x64.

## Further outlook

Further size reductions are possible. We can probably squeeze a bit or two out of reducing the number of loadable classes. To go further, e.g. to 16-bit class pointers, is possible but would probably need something like the variable-sized-header idea of John Rose.

In any case, this PR is a necessary prerequisite, since it allows us to use the bits in nKlass much more efficiently. So, a 16-bit nKlass can really address ~64k classes.



[1] https://github.com/tstuefe/metaspace-statistics/blob/master/Histogram.svg

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

Commit messages:
 - Fix Typo
 - Better CDS arch generation
 - Fix error in COH archive generation
 - Fixes
 - Fix Windows-Only bug that was caused by !INCLUDE_CDS_JAVA_HEAP
 - fix runtime/cds/appcds/TestCombinedCompressedFlags and runtime/cds/appcds/CommandLineFlagComboNegative.java
 - Fix CdsDifferentCompactObjectHeaders
 - hash->32bit
 - WIP
 - Markword changes
 - ... and 3 more: https://git.openjdk.org/lilliput/compare/c0496069...a86fb8fd

Changes: https://git.openjdk.org/lilliput/pull/128/files
 Webrev: https://webrevs.openjdk.org/?repo=lilliput&pr=128&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8325104
  Stats: 2690 lines in 81 files changed: 1916 ins; 417 del; 357 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  Wed Feb  7 19:34:16 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 7 Feb 2024 19:34:16 GMT
Subject: [master] RFR: JDK-8325104: Lilliput: Shrink Classpointers
In-Reply-To: <lm7SDOvsKA7Yt1yDQpYx5VPVjke0eAO0BB9ctkIA8qs=.206072f0-3274-492d-9224-d41adb3b842a@github.com>
References: <lm7SDOvsKA7Yt1yDQpYx5VPVjke0eAO0BB9ctkIA8qs=.206072f0-3274-492d-9224-d41adb3b842a@github.com>
Message-ID: <5Hg3aWe6cymqJix7XUhQeSrbqWYsGpICXCNQPtsEzRc=.ab9bd02b-afdb-4ac8-acd1-c92e363f79ee@github.com>

On Thu, 1 Feb 2024 10:23:04 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

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

Very nice work!

One comment on your description:
> when decoding an nKlass, the shift is not mandatory.

Did you mean to say 'is *now* mandatory'? Otherwise it doesn't seem to make much sense.

I did a first pass over the changes. Comments inline.

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.

src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 2262:

> 2260:   C2LoadNKlassStub* stub = new (Compile::current()->comp_arena()) C2LoadNKlassStub(dst);
> 2261:   Compile::current()->output()->add_stub(stub);
> 2262: 

There is a stray whitespace change here.

src/hotspot/cpu/aarch64/compressedKlass_aarch64.cpp line 82:

> 80:   return result;
> 81: }
> 82: 

More unnecessary whitespace.

src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 4426:

> 4424: void MacroAssembler::load_nklass(Register dst, Register src) {
> 4425:   assert(UseCompactObjectHeaders, "expects UseCompactObjectHeaders");
> 4426: 

More whitespace.

src/hotspot/cpu/x86/sharedRuntime_x86.cpp line 80:

> 78:   // because it could be larger than 32 bits in a 64-bit vm. See markWord.hpp.
> 79:   if (UseCompactObjectHeaders) {
> 80:     STATIC_ASSERT(markWord::hash_mask_compact < nth_bit(32));

This makes me think if the i-hash should go/stay in its original position, and we could get rid of hash_code_compact and related changes in Lilliput? Or would that not work for some reason?

src/hotspot/share/cds/archiveBuilder.cpp line 642:

> 640:     // Allocate space for the future InstanceKlass with proper alignment
> 641: #ifndef _LP64
> 642:     const size_t al = SharedSpaceObjectAlignment;

'al' seems a weird variable name ('al Bundy'? ;-) ). Maybe 'align' or 'alignment'?

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?

src/hotspot/share/memory/metaspace/fence.hpp line 1:

> 1: /*

Can you explain the purpose of this? It looks like something that you moved out of test and into main sources. I can't tell from the looks of it what it is.
EDIT: Ok maybe it's not really moved, except that the filenames match, but the contents is wholly replaced? In any case, GitHub thinks it's a moved file.

src/hotspot/share/memory/metaspace/fence.inline.hpp line 2:

> (failed to retrieve contents of file, check the PR for context)
Can we simply change the copyright of the file?

src/hotspot/share/memory/metaspace/metachunk.hpp line 31:

> 29: #include "memory/metaspace/chunklevel.hpp"
> 30: #include "memory/metaspace/counters.hpp"
> 31: #include "memory/metaspace/metablock.hpp"

Why is the include needed here?

src/hotspot/share/memory/metaspace/metachunk.hpp line 354:

> 352:     return base() <= p && p < committed_top();
> 353:   }
> 354: 

Stray whitespace change.

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

> 121:   static const int age_shift                      = self_forwarded_shift + self_forwarded_bits;
> 122:   static const int hash_shift                     = age_shift + age_bits + unused_gap_bits;
> 123:   static const int hash_shift_compact             = 11;

It seems odd to have a hole there in the middle. Could we have the hole in the uppermost bits? If we really have to have it here, use a new unused_gap_bits_compact here that has 4 instead of 1?

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

> 139:   // 32 bits and rightshift by the lower 10 foreign bits.
> 140: 
> 141:   // These are for loading the nKlass with a 32-bit load and subsequent masking of the lower

I should mention that currently it is not safe to load the nKlass using 32-bit load. We currently always need to check for monitor. If you do that anywhere, this needs changing.
(That being said, there is ongoing work to get rid of header displacement for Lilliput, at which point we *could* do the 32-bit load, if that fits.)

src/hotspot/share/oops/markWord.inline.hpp line 81:

> 79:   return set_narrow_klass(nklass);
> 80: }
> 81: 

Stray whitespace.

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

Changes requested by rkennke (Lead).

PR Review: https://git.openjdk.org/lilliput/pull/128#pullrequestreview-1868532124
PR Review Comment: https://git.openjdk.org/lilliput/pull/128#discussion_r1481928734
PR Review Comment: https://git.openjdk.org/lilliput/pull/128#discussion_r1481929421
PR Review Comment: https://git.openjdk.org/lilliput/pull/128#discussion_r1481929817
PR Review Comment: https://git.openjdk.org/lilliput/pull/128#discussion_r1481930621
PR Review Comment: https://git.openjdk.org/lilliput/pull/128#discussion_r1481936940
PR Review Comment: https://git.openjdk.org/lilliput/pull/128#discussion_r1481939135
PR Review Comment: https://git.openjdk.org/lilliput/pull/128#discussion_r1481946926
PR Review Comment: https://git.openjdk.org/lilliput/pull/128#discussion_r1481956504
PR Review Comment: https://git.openjdk.org/lilliput/pull/128#discussion_r1481957053
PR Review Comment: https://git.openjdk.org/lilliput/pull/128#discussion_r1481961436
PR Review Comment: https://git.openjdk.org/lilliput/pull/128#discussion_r1481961660
PR Review Comment: https://git.openjdk.org/lilliput/pull/128#discussion_r1481972306
PR Review Comment: https://git.openjdk.org/lilliput/pull/128#discussion_r1481976686
PR Review Comment: https://git.openjdk.org/lilliput/pull/128#discussion_r1481977521

From shipilev at amazon.de  Thu Feb  8 08:53:12 2024
From: shipilev at amazon.de (Aleksey Shipilev)
Date: Thu, 8 Feb 2024 09:53:12 +0100
Subject: CFV: New Lilliput Committer: Axel Boldt-Christmas
In-Reply-To: <93870E0D-11CA-477B-BB95-C70A297964B3@amazon.de>
References: <93870E0D-11CA-477B-BB95-C70A297964B3@amazon.de>
Message-ID: <d35e43e5-ce52-45c9-a371-bcf03cf6c54e@amazon.de>

Vote: yes

On 07.02.24 13:37, Kennke, Roman wrote:
> I hereby nominate Axel Boldt-Christmas to Lilliput Committer.



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 stuefe at openjdk.org  Thu Feb  8 18:06:44 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 8 Feb 2024 18:06:44 GMT
Subject: [master] RFR: JDK-8325104: Lilliput: Shrink Classpointers
In-Reply-To: <5Hg3aWe6cymqJix7XUhQeSrbqWYsGpICXCNQPtsEzRc=.ab9bd02b-afdb-4ac8-acd1-c92e363f79ee@github.com>
References: <lm7SDOvsKA7Yt1yDQpYx5VPVjke0eAO0BB9ctkIA8qs=.206072f0-3274-492d-9224-d41adb3b842a@github.com>
 <5Hg3aWe6cymqJix7XUhQeSrbqWYsGpICXCNQPtsEzRc=.ab9bd02b-afdb-4ac8-acd1-c92e363f79ee@github.com>
Message-ID: <NfDO8ODxIj1o-i1N2erW2eQm9NWoTOq2c1K2zUq_HfQ=.488416a1-41b9-4ae0-91b9-688d431db903@github.com>

On Wed, 7 Feb 2024 19:31:18 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Very nice work!
> 

Thank you!

> > when decoding an nKlass, the shift is not mandatory.
> 
> Did you mean to say 'is _now_ mandatory'? Otherwise it doesn't seem to make much sense.
> 

Yes, you are right; I'll correct that.

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

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

From axel.boldt-christmas at oracle.com  Sat Feb 10 10:48:30 2024
From: axel.boldt-christmas at oracle.com (Axel Boldt-Christmas)
Date: Sat, 10 Feb 2024 10:48:30 +0000
Subject: Object to ObjectMonitor mapping using a HashTable to avoid
 displaced headers
In-Reply-To: <08E8A4A4-39FB-47C5-8138-CF7B12E56207@oracle.com>
References: <08E8A4A4-39FB-47C5-8138-CF7B12E56207@oracle.com>
Message-ID: <0B10511B-07B9-4314-A606-85A8AF5A976D@oracle.com>

Hello Lilliput,

# OMWorld status

I had planned to send this out earlier this week, but got sidetracked by other
issues, and then this email grew a bit larger than I originally imagined it
would be.

The email is split into three sections.

The first section gives a high to medium level overview of the implementation of
OMWorld.

The second section gives my view of what the work going forward will require
with respect to OMWorld and Lilliput.

The third and last section will be a miscellaneous section for some things that
did not fit in the other two, mainly Why LM_PLACEHOLDER (because I know it has
been asked).

This mail turned out to be rather lengthy, unless you want or feel the need to
check the implementation details first. I recommend starting with the Primary
and Secondary issues in the second section `The Work Going Forward` and then
refer back to the first section if needed.

## High to Medium Level Overview of the Implementation

The main goal with OMWorld is to provide a mechanism for associating an
ObjectMonitor with an Object and discovering such an association in a way that
all threads and contexts agree upon which ObjectMonitor to use without
disturbing the non-lock-bits of the mark word.

The association between Objects and ObjectMonitors in OMWorld is done by entries
in a hash table, instead of via a pointer in the Objects header.

A lot of work has also been done to reduce the reasons for having to inflate
ObjectMonitors, some of the work, like not inflating for hash codes when lock
stack based fast locking is used, has already been pushed to mainline. And some
are open PRs like adding recursive locking support for lock stack based fast
locking. The details of those changes will not be explained in this mail.

### Inflation-Deflation Protocol

The first fundamental change is the inflation-deflation protocol. In OMWorld an
ObjectMonitor is created (inflated) if and only if the Object that it will be
associated with is already fast locked by the inflating thread (one exception
with `relock_object` see note below) or that the inflating thread is in the
process of performing a monitorenter.

This change is made to solve the lose of atomicity when a thread publishes a
newly created ObjectMonitor. For reference, LM_LIGHTWEIGHT uses a CAS to publish
the ObjectMonitor directly in the mark word, and LM_MONITOR/LM_LEGACY uses a
spin loop on the mark word with sentinel inflating mark value. Both of these
approaches allows for inflating from a context which is not locked, nor
preforming a monitorenter.

In OMWorld, the fact that inflation is limited to an Object that is already
locked, or is about to be entered allows for constraining the created and
published ObjectMonitors to be created in a locked state. Any newly created
ObjectMonitor is created and published to the rest of the system with an
'anonymous owner'. Such an ObjectMonitor will will be observed as locked by any
observer. Publishing the ObjectMonitor here entails successfully inserting it
into the hash table.

The behavior of each inflating thread then depends on the observed value of the
mark word and the successful transition of the lock bits (successful CAS).

Here is a breakdown of the possible observed lock bits and successful
transitions:
 * `0b10` Monitor is observed.
   * If the locking thread has the object on its lock stack, claim ownership of
     the ObjectMonitor and remove the object from its lock stack.
   * Lock with ObjectMonitor::enter
 * `0b00 -> 0b10` CAS from Fast Locked to Monitor
   * If the locking thread has the object on its lock stack, claim ownership of
     the ObjectMonitor and remove the object from its lock stack.
   * Lock with ObjectMonitor::enter
 * `0b01 -> 0b10` CAS from Unlocked to Monitor
   * The locking thread claims the ownership of the ObjectMonitor
   * ObjectMonitor is successfully locked.
 * On a failed CAS, retry until one of the three above occurs.

We must also allow for a thread which is entered on a Fast Locked Object to
inflate and associate an ObjectMonitor with that specific Object. In this case
the object being on the locking thread's lock stack is a prerequisite and the
only valid observations and transitions for the locking thread are:
 * `0b10` Monitor is observed.
   * Claim ownership of the ObjectMonitor and remove the object from its lock
     stack.
 * `0b00 -> 0b10` CAS from Fast Locked to Monitor
   * Claim ownership of the ObjectMonitor and remove the object from its lock
     stack.

A simplified pseudo code of the inflation.
```C++
void inflate_and_enter(oop object, JavaThread* locking_thread) {
  ObjectMonitor* monitor = get_or_insert_monitor(object);
  LockStack& lock_stack = locking_thread->lock_stack();
  for (;;) {
    const markWord mark = object->mark_acquire();
    if (mark.has_monitor()) {
      if (lock_stack.contains(object)) {
        monitor->set_owner_from_anonymous(locking_thread);
        lock_stack.remove(object);
      }
      break;
    }

    if (mark.is_fast_locked()) {
      if (mark != object->cas_set_mark(mark.set_has_monitor(), mark)) {
        continue; // Retry
      }
      if (lock_stack.contains(object)) {
        monitor->set_owner_from_anonymous(locking_thread);
        lock_stack.remove(object);
      }
      break;
    }

    if (mark != object->cas_set_mark(mark.set_has_monitor(), mark)) {
      continue; // Retry
    }
    monitor->set_owner_from_anonymous(locking_thread);
    return; // Succesfully locked.
  }
  monitor->enter(locking_thread);
}

ObjectMonitor* inflate_fast_locked_object(oop object, JavaThread* locking_thread) {
  ObjectMonitor* monitor = get_or_insert_monitor(object);
  LockStack& lock_stack = locking_thread->lock_stack();
  precond(lock_stack.contains(object));

  markWord mark = object->mark_acquire();
  while (mark.is_fast_locked()) {
    mark = object->cas_set_mark(mark.set_has_monitor(), mark);
  }
  monitor->set_owner_from_anonymous(locking_thread);
  lock_stack.remove(object);

  return monitor;
}
```

In the absence of deflation this mechanism allows for concurrent threads which
observe an object with the lock bits `0b10` (Monitor), to also be able to
retrieve the associated ObjectMonitor from the hash table. It also allows for
concurrent inflating and entering/entered thread to agree on which ObjectMonitor
to use as only one specific instance of an ObjectMonitor will successfully be
inserted in the hash table.

As soon as deflation and memory reclamation gets it the picture things get more
complicated.

The memory reclamation and use after free issue is handled the same way as it is
already done, via a two phased, unlink from the system, handshake, purge from
the system. (One Deflation Cycle)

As for making sure that concurrent threads agree on which ObjectMonitor is
associated with which Object, more care has to be taken. And be wary ABA
problems with the lock bits.

We achieve this by changing the inflation-deflation protocol as follows:
 * Deflation Thread
   * Will always perform these operations in this order:
     * Make an ObjectMonitor `is_being_async_deflated()`, irreversible action
     * Transition the mark word away from `0b10` Monitor
     * Disassociate the ObjectMonitor from the object, by removing the hash
       table entry
 * Locking thread
   * May only transition the mark word to `0b10` Monitor if an associated
     ObjectMonitor is observed where `is_being_async_deflated()` is not true and
     stable across the transition.

The agreement between threads between threads is achieved because only the
deflation thread disassociate ObjectMonitor, and it only does so after it is
marked as `is_being_async_deflated()`. Locking threads cannot insert a new
association while another one exists. So the locking threads will effectively
have to wait until the deflation thread has finished. Sans any ABA problems with
the lock bits, the scenario after having waited for deflation to finish is the
same scenario as before deflation existed.

The ABA problem with the lock bits is solved by locking out the deflation thread
by forcing the `is_being_async_deflated()` to be stable, and only the deflation
thread transitions may the mark word away from `0b10` monitor. So when a locking
thread retrieves an associated  ObjectMonitor, it will either be
`is_being_async_deflated()`, in which case the thread waits until a new monitor
can be associated, or it will not be `is_being_async_deflated()`, in which case
the locking thread can safely transition the mark word to `0b10` Monitor without
ABA problems, as the deflation thread cannot have transitioned the mark word
away from `0b10` Monitor because it must first have set
`is_being_async_deflated()` which is being forced stable during the transition.
So when a locking thread transitions the mark word to `0b10` Monitor it knows
that the ObjectMonitor it is about to enter on will still be the associated
ObjectMonitor, because it cannot have been deflated, and thus not been
disassociated from the Object.

The `inflate_and_enter` function is now changed to return false if it fails
because of deflation.

> Note: In the patch that was sent out last week the ABA issue exists, in some
>       later iteration an invalid optimization was added where a locking thread
>       transitions the mark word away from `0b10` Monitor. A good side effect
>       of doing this writeup is challenging assumptions when having to explain
>       why the code works.
>       It is extremely racy and requires inserting sleeps in the code to
>       reliably be provoked.

Extended pseudo code of inflate_and_enter to handle deflation-inflate.
```C++
bool inflate_and_enter(oop object, JavaThread* locking_thread) {
  ObjectMonitor* monitor = get_or_insert_monitor(object);
  LockStack& lock_stack = locking_thread->lock_stack();

  // Holds is_being_async_deflated() stable throughout this function.
  ObjectMonitorContentionMark mark(monitor);

  if (monitor->is_being_async_deflated()) {
    // The deflation thread must remove the monitor from the hash table.
    return false; // Retry
  }
  for (;;) {
    const markWord mark = object->mark_acquire();
    if (mark.has_monitor()) {
      if (lock_stack.contains(object)) {
        monitor->set_owner_from_anonymous(locking_thread);
        lock_stack.remove(object);
      }
      break;
    }

    if (mark.is_fast_locked()) {
      if (mark != object->cas_set_mark(mark.set_has_monitor(), mark)) {
        continue; // Retry
      }
      if (lock_stack.contains(object)) {
        monitor->set_owner_from_anonymous(locking_thread);
        lock_stack.remove(object);
      }
      break;
    }

    if (mark != object->cas_set_mark(mark.set_has_monitor(), mark)) {
      continue; // Retry
    }
    monitor->set_owner_from_anonymous(locking_thread);
    return true; // Succesfully locked.
  }
  // Should always return true as is_being_async_deflated() is kept stable.
  return monitor->enter(locking_thread);
}
```

As for `inflate_fast_lock_object` it follows the same principle but the
stability of `is_being_async_deflated()` is ensured because the Object is locked
throughout the call and cannot be deflated. It must only be extended with the
waiting for the deflation thread to disassociate any deflated ObjectMonitor that
may exist.

Extended pseudo code for inflate_fast_locked_object.
```C++
ObjectMonitor* inflate_fast_locked_object(oop object, JavaThread* locking_thread) {
  ObjectMonitor* monitor = get_or_insert_monitor(object);
  LockStack& lock_stack = locking_thread->lock_stack();
  precond(lock_stack.contains(object));

  while (monitor->is_being_async_deflated()) {
    monitor = get_or_insert_monitor(object);
  }

  markWord mark = object->mark_acquire();
  while (mark.is_fast_locked()) {
    mark = object->cas_set_mark(mark.set_has_monitor(), mark);
  }
  monitor->set_owner_from_anonymous(locking_thread);
  lock_stack.remove(object);

  return monitor;
}
```

#### relock_object Exception

`relock_object` will use both of these functions from another thread than the
locking_thread, however the locking_thread must be suspended throughout, and for
the sake of correctness it can be treated as if it is the locking_thread
performing the operations.

#### Spinning waiting on Deflation Thread progress

There is an unfortunate property here where the correctness requires progress of
the deflation thread before any locking thread can make progress. The window
where the deflation thread could suffer an unfortunate preemption is small, but
it does exist. Currently if a locking thread fails to `inflate_and_enter`
(due to deflation) it will attempt to fast lock again. Which means that at least
one locking thread can always make progress if the deflation thread as
transitioned away the mark word from `0b10` Monitor. So the window is between
the deflation thread making an ObjectMonitor `is_being_async_deflated()` and
transitioning the mark word away from `0b10` Monitor.

There are schemas that can avoid this property but requires additional mark word
state. Either another bit (want to avoid at all cost) or use the fourth unused
state of the locking bits (`0b11` currently). The second would be an rather
intrusive change (has been prototyped) because the JVM makes a lot of
assumptions based on single bit states in the lock bits.

The idea would be to have the deflation thread first transition the mark word to
the new state, which has the exact same meaning as `0b10` Monitor, and then
attempt deflation, switching back to `0b10` Monitor if it fails. Then allow any
thread to transition the mark word from this new state to `0b01` unlocked (the
deflation thread does not disassociate the ObjectMonitor until it have observed
a transition away from this new state). Because exactly one transition to and
from this new state would occur per deflation cycle (cycles are separated by a
handshake) then the ABA problem would be avoided because no thread would be
stuck trying to transition the mark word away from this new state based on
information from a previous cycle.

### ObjectMonitor Thread-Local Caches

It is not feasible to perform a lookup in our ConcurrentHashTable from the
emitted C2 code, instead to facilitate fast retrieval of an associated
ObjectMonitor from the C2 code without calling into the runtime Thread-Local
Caches are used.

First there is a cache which lives in the JavaThread* native object, which is
used when locking. This cache currently exists of `(oop, ObjectMonitor*)` pairs.
Insertions evicts the least-recently used pair when cache is full (of non stale
entries). A entry is inserted whenever a locking thread successfully enters on
an associated ObjectMonitor it the runtime. C2 fast_lock will linearly scan this
cache from most to least-recently used. On a cache hit it will attempt to enter
on the ObjectMonitor. On a cache miss it will call into the runtime instead. The
entries are cleared out on each safepoint to not artificially extend the
lifetime of Objects (we do not want the GC to treat these objects as thread
roots). The entries are also cleared out once per deflation cycle. The only
reason a cache entry grows stale is when an ObjectMonitor has been deflated. Any
deflated monitor must have its owner be DEFLATER_MARKER, which will cause any
locking that C2 attempts to call into the runtime.

And second there is a cache which lives on the thread stack, and is used when
unlocking. The BasicLock slot is used to cache the ObjectMonitor when it is
entered upon. Because of the symmetry between lock and unlock, the fast_unlock
can then simply read out the ObjectMonitor from this cache and will always get a
cache hit if it also locked on the inflated monitor. Each moniorexit will only
miss at most once per deflation cycle. This cache does not require any cleanup
nor maintenance as nothing can make it stale (no deflation can occur while the
ObjectMonitor is entered). However care needs to be taken (just as is the case
with LM_LEGACY) that the BasicLock on the stack is initialized to a known value
(nullptr), as the fast_unlock path will treat the value as an `ObjectMonitor*`.

## The Work Going Forward

This section will describe some of the work still required for OMWorld. I will
split this into three different catagories, Primary, Secondary and Tertiary
issues. Where the Primary issues are those I believe should be worked on next
and require a solution prior to any integration. The Secondary issues are those
that should at least be  understood prior to any integration. And the Tertiary
issues are those which if time permits would be worth investigating.

### Primary

Should be solved before integration.

#### OMCache

First is finalizing the size, behavior and layout of the Cache used by C2
locking.

In the patch sent out last week the OMCache capacity is set to eight. And the
actual size used can then be tuned from 0 to 8 using the `int OMCacheSize` flag.
It is also possible to turn of the cache completely with the `bool OMUseC2Cache`
flag to evaluate the affect no cache would have on a specific workload.

Different sizes have been tried, when running different benchmark suites
(DaCapo, SPEC*, Renaissance, etc) between 3-5 seem to be required by at least
some benchmark, and for those which had a lot of misses with 3-5 also had a lot
of misses with even larger cache size.

Unrolling the cache scan. This was the initial approach, but just using a loop
(which the patch that was sent out does) performed better in general. But there
are many factors at work here, it may be worthwhile to introduce a flag so that
loop unrolling the cache scan can be evaluated. If I recall correctly the
initial unrolled cache lookup was when both fast_lock and fast_unlock used the
same cache so it got unrolled in both the lock and unlock code. Now that only
fast_lock uses this cache the result may be different.

The OMWorldCache is currently layed out as a struct of arrays, it should
probably be layed out as an array of structs (especially if it turns out that a
larger cache is preferable).

Enabling `bool OMCacheHitRate` will emit hit rate counters in C2, they are
logged to `monitorinflation=info` which can be used to evaluate specific
workloads.

This issue is completely performance driven.

#### OMWorld Hash Table Resizing

In the patch sent out last week the hash table resizing uses a very naive
approach which simply delegates the deflation thread to grow the table if some
other thread encounters a grow hint. Right now it exist to simply grow the table
for those workloads which require a larger amount of monitors.

The first issue is the sizing, it is currently configured to start at a size of
at least 1K and based on processor count and AvgMonitorsPerThreadEstimate (all
of which are wild). And grows up to a size of 2M. And uses the default grow_hint
of 4. Currently the table only grows, there is a flag `bool OMShrinkCHT` which
can be used to enable a very WIP heuristic which also shrinks the table. However
it is unclear if this is desirable, and how it would be designed in such a way
that it avoids unnecessary oscillations. It would be very workload dependent.

The deflation thread is currently resizing while blocked in VM. That may not
be appropriate.

It would also be good to evaluate how good the default FastHashCode is. There
were times when the grow_hint was triggered at low load factors (0.1-0.2). Are
these statistical anomalies or something inherent to our hash codes?
This last point is more of a Secondary issue, but it is probably required for
understanding and creating a resizing policy.

#### Spinning

There are currently two places where a locking thread spins, waiting on some
other thread to make progress.

The first is a fixed pre-spin if a fast locked Object is encountered. This will
attempt to fast lock the object for a fixed number of iterations, the first
`int OMSpins` (tunable flag) number of iterations will be separated by a
`SpinPause()` and the last `int OMYields` (tunable flag) number of iterations
will be separated by an `os::naked_yield()`. The idea is to avoid inflating if
the critical sections are are on the same order of time as the time cost for
inflating, in such a case the  thread would do better to just wait and fast lock
instead of inflating.

The current numbers for the flags were chosen by looking at programs which
exhibited this behavior.

The `monitorinflation=info` logging will print a per thread inflation cause
which can be used to evaluate the behavior of different programs. The following
causes are counted.
```
  Mon: Number of inflations from an `0b01` Unlocked state.
  Rec: Number of unbalanced or interleaved recursions.
 CRec: Number of recursive enter which inflated (not due to the cause above).
 Cont: Number of contended inflations experienced (during exit, wait, notify).
 Wait: Number of inflations cause by wait.
Stack: Number of inflations caused because of a full lock stack.
```

A workload dominated by `Mon:` benefits from this fixed-pre-spin. The `Mon:`
cause means that Object was unlocked during the inflation.

The second spinning that occurs is the one where for correctness a locking
thread must wait for the deflation thread to make progress. It currently does
two iterations each followed by an `os::naked_yield` and for the rest of the
iterations it uses `os::naked_short_nanosleep()`. There are multiple issues
here. This can become an issue on an over-provisioned machine, which may make
the deflation threads progress flaky. In the implementation details above I have
discussed potential a solution to how we can make sure that at least one thread
guaranteed progress. However on an over-provisioned machine even if one thread
is guaranteed to get a lock, such a thread might just also be scheduled out and
never get to run (while holding the lock).

Regardless of the progress issue, the issue with time to safepoint needs to be
addressed. A locking thread that has been blocked by deflation for two
iterations should also transition to blocked in VM for the sleep duration and
participate in the safepoint protocol.

#### Cleanups

The patch contains a number of features/questions which are not mentioned above,
usually they have some TODO comment attached to them. Some will be mentioned in
Secondary or Tertiary issues. These needs to be cleaned out and/or finished
depending on the fallout of said issues.

LM_PLACEHOLDER also belongs under this section but it will be be discussed in
the miscellaneous section `Why LM_PLACEHOLDER`.

The runtime entry for locking and unlocking are also not very clean. It stems
from the lack of registers on x86_32, leading to that the BasicLock register
loses the BasicLock*. In LM_LIGHTWEIGHT this was unused so a second entry to the
runtime was created and the BasicLock* is not provided. As this is now used for
the unlock cache it becomes important again (for performance, not correctness)
to provide the BasicLock. The current patch only patches up and forwards this on
64-bit platforms, however it would probably be better to simply reload the
BasicLock on x86_32 and have one uniform entry point.

#### Performance

The fact that a performance evaluation is required for integration is a
no-brainer, however the exact requirements are harder to pin down. The nature of
the different LockingModes in HotSpot is such that they all have different
workloads for which they are best suited. This could be seen last year when
the default was temporarily switched to LM_LIGHTWEIGHT and there were a lot of
movement in the promoted performance runs. A lot of regressions, but there were
also workloads which showed improvement with LM_LIGHTWEIGHT over LM_LEGACY.

Most of the performance work with OMWorld has been trying to achieve parity with
LM_LEGACY, however there are still known workloads where LM_LEGACY is better,
and also known workloads where OMWorld is better. Then there are all the unknown
workloads for which OMWorld has not been tested.

All I am trying to say is that this is probably one of the issues which will be
the hardest to figure out.

At least now with OMWorld as part of the Lilliput project a more holistic
evaluation can be attempted, where maybe the whole can be greater than the sum
of its parts. (This includes smaller headers, OMWorld and stable klass pointers,
GC algorithms without forwarding pointers in the object header, loom support for
synchronized without pointers from the java heap into thread stacks).

### Secondary

Should be understood before integration.

#### Deflation Heuristics

The current heuristics that drive the deflation thread does not seem like a good
fit for how OMWorld works. In OMWorld the `AvgMonitorsPerThreadEstimate` is
disabled unless unless it is configured via the command line. Instead the
`_in_use_list_ceiling` is grown based on the number of actual inflations. There
is pre-existing weirdness in this heuristics.

Currently, for most observed workloads, deflation is driven by the
`GuaranteedAsyncDeflationInterval` flag.

#### C2 Fast Lock / Fast Unlock

The fast path in the C2 code is where the recursive lightweight initially came
from. Many alternative implementations have been evaluated. The only one which
has been somewhat promising is one which tries to make LM_LIGHTWEIGHT more like
LM_LEGACY by making recursive fast lock enters always take a fast lock exit, by
setting the a value in the BasicLock that signals to the exit paths that a
recursive fast lock  enter was performed and it can simply exit. This also
extended the first fast lock enter to save the previous lock stack top along
with a signal (differentiating it from an ObjectMonitor), which enabled the fast
lock exit paths to restore the top value without loading anything from the lock
stack. Effectively the exit could decode exactly what the enter did by reading
the BasicLock from the stack.

However this change is rather intrusive as it turns the BasicLock from an
optimization property to a correctness property. This prototype was only tested
on x86_64.

There are also things to explore with regards to how inflated locking and
unlocking is performed in the emitted code. This patch and the recursive
lightweight PRs tries to avoid changing things in this area. In this patch there
is currently this flag `bool OMRecursiveFastPath` which enable checking for
inflated recursion with a plain load instead of failing a CAS. On some hardware
just a few code paths which contains a recursive inflated locking is enough to
make the `OMRecursiveFastPath` be more performant.

And lastly most platforms in HotSpot only emitted JITed inflated enter exit code
for C2, even tough both C1 and the native wrapper share the same property of
only performing balanced locking. PPC is one exception, which uses the C2 code
for all but the interpreter (which must correctly handle un-balanced locking,
but could also handle inflated enter exit, though it would not be much better
than calling to the runtime). This issue is exacerbated by the next issue.

#### C2 Compilation Failures

During performance testing two issues came up. For some benchmarks there is
randomness which determines if the hot code of the program gets C1 or C2
compiled.

And some trivial micro-benchmarks using synchronized would cause both C1 and C2
to not compile and run completely in the interpreter.

The performance difference caused by this can be multiple orders of magnitude
larger than any changes to the locking code.

### Tertiary

Distant future work / if time permits.

#### Alternative Hash Table

The ConcurrentHashTable implementation in HotSpot is optimized for many
concurrent readers. There may be workloads where insertions and deletions
dominate. There currently is a boolean parameter try_read on the
`get_or_insert_monitor` method which is always called with true. try_read means
first do a read, then an insert instead of just an `insert_get`. Initially this
was used from contexts where the inflation was probably not caused by
contention, however doing this was many times slower than just opportunistically
always doing a read first. Maybe there usually was contention and it was the 
new/delete that was the culprit.

Regardless little thought has gone into if the current implementation is the
correct one for this purpose. From a maintenance perspective any alternative
solution would have to show significant gains over the current implementation.

#### Effects on 4 Byte Lilliput

The hash table requires a hash for the Object, and that will be the identity
hash. Given that 4 Byte Lilliput will not store this hash inside the header
there might be some interesting interactions here when ObjectMonitors are
inflated.

#### Deflation from Locking Threads

In the patch there is a prototype for allowing a locking thread which owns an
inflated lock to deflate the ObjectMonitor and transition back to fast locking.
Two flags exists:
```
bool OMDeflateAfterWait  // If the wait caused inflation, try to deflate after wait
bool OMDeflateBeforeExit // Attempt to deflate before the final exit
```

Some workloads have been seen to benefit from this, especially the first. But
they are not something which benefits all workloads (for obvious reasons, real
contention is a thing).

For the first issue with wait, there have been tentative ideas flying around
about separating the wait/notify mechanism from the inflated ObjectMonitor and
using something more lightweight. However this is highly theoretical at this
point.

For the second issue with having ObjectMonitors become deflated before the final
exit, I have toyed with the idea of introducing some more proboalistic mechanism
for deciding if deflation should be attempted. The main problem is that we need
per ObjectMonitor state, but when we deflate we lose this state. The main idea
is to let the deflation thread use the state of `_in_use_list` to reason about
if deflation is occurring to frequently for some specific object. Care would
have to be take as this could easily turn into an O(n^2) time or O(n) space
solution (n = #monitors).

A brief note on the deflation from a locking threads works.
The main idea is that deflation thread is blocked out by the virtue of the
ObjectMonitor being owned. The locking thread then sets the owner to anonymous
and act exactly as if it was the deflation thread except it does not use the
DEFLATER_MARKER and transitions the mark word to `0b00` Fast Locked. It is only
done before the final exit, and after a wait which itself cause inflated (and
the most recent entry on the stack) to not create an invalid lock stack order.
(The wait could potentially manage without being the most recent entry by
keeping a local copy of the lock stack from before the inflating, and then
restoring it after deflating).

## Miscellaneous

This will be some concluding words as well as some discussion on Why
LM_PLACEHOLDER

### Why LM_PLACEHOLDER

First LM_PLACEHOLDER is exactly that, a placeholder for the final locking mode,
be that called LM_LIGHTWEIGHT, or something else.

This was mainly because many discussions and changes regarding LM_LIGHTWEIGHT
stalled OMWorld development, and partially a defensive measure to not have
changes to OMWorld stall any other projects with regards to LM_LIGHTWEIGHT.
There is synchronized support for loom on the way, which should fit in
seamlessly with both LM_LIGHTWEIGHT and LM_PLACEHOLDER, but there are incentives
to use a lock stack based locking mode with these loom changes rather than a
LM_LEGACY based one.

One unintended benefit in the short term is that it will be a little easier to
compare and identify the different benefits and drawbacks between LM_LIGHTWEIGHT
and LM_PLACEHOLDER in Lilliput. (Obviously a maintenance burden in the long run,
but both seem rather stable in the Lilliput repo).

The ambition is to harmonize the LockingModes and be able to finally reduce them
to one or two, which would be a maintenance win for the whole of HotSpot.


### Final Words

If you read this whole thing in one go, my hats of too you.

I hope that this can serve as reference point which can be used to get more
contributors engaged in the project. And that it can be an actionable stepping
stone for bringing the Lilliput project closer to integration.

Sincerely
Axel

From stuefe at openjdk.org  Sat Feb 10 10:59:18 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sat, 10 Feb 2024 10:59:18 GMT
Subject: [master] RFR: JDK-8325104: Lilliput: Shrink Classpointers [v2]
In-Reply-To: <lm7SDOvsKA7Yt1yDQpYx5VPVjke0eAO0BB9ctkIA8qs=.206072f0-3274-492d-9224-d41adb3b842a@github.com>
References: <lm7SDOvsKA7Yt1yDQpYx5VPVjke0eAO0BB9ctkIA8qs=.206072f0-3274-492d-9224-d41adb3b842a@github.com>
Message-ID: <9J0ptnM2MWfVOm7EvZ92_lV5__ycFYbfYY1RsAhtSK8=.926e0fcc-33f2-4742-82da-bc69cfd01ca8@github.com>

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

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

 - 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
 - Fixes
 - Fix Windows-Only bug that was caused by !INCLUDE_CDS_JAVA_HEAP
 - fix runtime/cds/appcds/TestCombinedCompressedFlags and runtime/cds/appcds/CommandLineFlagComboNegative.java
 - Fix CdsDifferentCompactObjectHeaders
 - ... and 6 more: https://git.openjdk.org/lilliput/compare/da4ffa35...f665504c

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

Changes: https://git.openjdk.org/lilliput/pull/128/files
 Webrev: https://webrevs.openjdk.org/?repo=lilliput&pr=128&range=01
  Stats: 2693 lines in 81 files changed: 1916 ins; 417 del; 360 mod
  Patch: https://git.openjdk.org/lilliput/pull/128.diff
  Fetch: git fetch https://git.openjdk.org/lilliput.git pull/128/head:pull/128

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

From stuefe at openjdk.org  Sat Feb 10 10:59:19 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sat, 10 Feb 2024 10:59:19 GMT
Subject: [master] RFR: JDK-8325104: Lilliput: Shrink Classpointers [v2]
In-Reply-To: <5Hg3aWe6cymqJix7XUhQeSrbqWYsGpICXCNQPtsEzRc=.ab9bd02b-afdb-4ac8-acd1-c92e363f79ee@github.com>
References: <lm7SDOvsKA7Yt1yDQpYx5VPVjke0eAO0BB9ctkIA8qs=.206072f0-3274-492d-9224-d41adb3b842a@github.com>
 <5Hg3aWe6cymqJix7XUhQeSrbqWYsGpICXCNQPtsEzRc=.ab9bd02b-afdb-4ac8-acd1-c92e363f79ee@github.com>
Message-ID: <IQXEIE1sqSl1dZGDmqmfwX9AE0BlIXB2NPYTje_X8xo=.669389b3-4d6b-4d16-8c84-1ac7a0cdc53b@github.com>

On Wed, 7 Feb 2024 18:42:00 GMT, Roman Kennke <rkennke at openjdk.org> 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 16 commits:
>> 
>>  - 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
>>  - Fixes
>>  - Fix Windows-Only bug that was caused by !INCLUDE_CDS_JAVA_HEAP
>>  - fix runtime/cds/appcds/TestCombinedCompressedFlags and runtime/cds/appcds/CommandLineFlagComboNegative.java
>>  - Fix CdsDifferentCompactObjectHeaders
>>  - ... and 6 more: https://git.openjdk.org/lilliput/compare/da4ffa35...f665504c
>
> 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?

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

PR Review Comment: https://git.openjdk.org/lilliput/pull/128#discussion_r1485057185

From stuefe at openjdk.org  Sat Feb 10 14:55:15 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sat, 10 Feb 2024 14:55:15 GMT
Subject: [master] RFR: JDK-8325104: Lilliput: Shrink Classpointers [v2]
In-Reply-To: <5Hg3aWe6cymqJix7XUhQeSrbqWYsGpICXCNQPtsEzRc=.ab9bd02b-afdb-4ac8-acd1-c92e363f79ee@github.com>
References: <lm7SDOvsKA7Yt1yDQpYx5VPVjke0eAO0BB9ctkIA8qs=.206072f0-3274-492d-9224-d41adb3b842a@github.com>
 <5Hg3aWe6cymqJix7XUhQeSrbqWYsGpICXCNQPtsEzRc=.ab9bd02b-afdb-4ac8-acd1-c92e363f79ee@github.com>
Message-ID: <p7Biv2wAuq4YGRTnQPYOfj3Gsr728RxyWdsqMiQ3Oug=.5496ba41-31ec-4e87-bfbb-2a7d41ee2fa0@github.com>

On Wed, 7 Feb 2024 18:49:36 GMT, Roman Kennke <rkennke at openjdk.org> 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 16 commits:
>> 
>>  - 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
>>  - Fixes
>>  - Fix Windows-Only bug that was caused by !INCLUDE_CDS_JAVA_HEAP
>>  - fix runtime/cds/appcds/TestCombinedCompressedFlags and runtime/cds/appcds/CommandLineFlagComboNegative.java
>>  - Fix CdsDifferentCompactObjectHeaders
>>  - ... and 6 more: https://git.openjdk.org/lilliput/compare/da4ffa35...f665504c
>
> src/hotspot/cpu/x86/sharedRuntime_x86.cpp line 80:
> 
>> 78:   // because it could be larger than 32 bits in a 64-bit vm. See markWord.hpp.
>> 79:   if (UseCompactObjectHeaders) {
>> 80:     STATIC_ASSERT(markWord::hash_mask_compact < nth_bit(32));
> 
> This makes me think if the i-hash should go/stay in its original position, and we could get rid of hash_code_compact and related changes in Lilliput? Or would that not work for some reason?

It would, but we would have one unused bit in the front, three in the back. I am not sure that is an improvement.

> src/hotspot/share/cds/archiveBuilder.cpp line 642:
> 
>> 640:     // Allocate space for the future InstanceKlass with proper alignment
>> 641: #ifndef _LP64
>> 642:     const size_t al = SharedSpaceObjectAlignment;
> 
> 'al' seems a weird variable name ('al Bundy'? ;-) ). Maybe 'align' or 'alignment'?

okay, align it is :)

> 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.

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

PR Review Comment: https://git.openjdk.org/lilliput/pull/128#discussion_r1485148600
PR Review Comment: https://git.openjdk.org/lilliput/pull/128#discussion_r1485149490
PR Review Comment: https://git.openjdk.org/lilliput/pull/128#discussion_r1485151455

From stuefe at openjdk.org  Sat Feb 10 15:07:06 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sat, 10 Feb 2024 15:07:06 GMT
Subject: [master] RFR: JDK-8325104: Lilliput: Shrink Classpointers [v2]
In-Reply-To: <5Hg3aWe6cymqJix7XUhQeSrbqWYsGpICXCNQPtsEzRc=.ab9bd02b-afdb-4ac8-acd1-c92e363f79ee@github.com>
References: <lm7SDOvsKA7Yt1yDQpYx5VPVjke0eAO0BB9ctkIA8qs=.206072f0-3274-492d-9224-d41adb3b842a@github.com>
 <5Hg3aWe6cymqJix7XUhQeSrbqWYsGpICXCNQPtsEzRc=.ab9bd02b-afdb-4ac8-acd1-c92e363f79ee@github.com>
Message-ID: <uqGdUQkwjaU5k3JgH9RcsaUI_wMaxu_M_DB8rkE-PG8=.76eb9655-720d-49d6-ad07-f24ee0be4f0b@github.com>

On Wed, 7 Feb 2024 19:08:12 GMT, Roman Kennke <rkennke at openjdk.org> 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 16 commits:
>> 
>>  - 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
>>  - Fixes
>>  - Fix Windows-Only bug that was caused by !INCLUDE_CDS_JAVA_HEAP
>>  - fix runtime/cds/appcds/TestCombinedCompressedFlags and runtime/cds/appcds/CommandLineFlagComboNegative.java
>>  - Fix CdsDifferentCompactObjectHeaders
>>  - ... and 6 more: https://git.openjdk.org/lilliput/compare/da4ffa35...f665504c
>
> src/hotspot/share/memory/metaspace/fence.hpp line 1:
> 
>> 1: /*
> 
> Can you explain the purpose of this? It looks like something that you moved out of test and into main sources. I can't tell from the looks of it what it is.
> EDIT: Ok maybe it's not really moved, except that the filenames match, but the contents is wholly replaced? In any case, GitHub thinks it's a moved file.

Arrgh, these slipped in accidentally. Thanks for catching this.

Metaspace does have a fencing system (overwrite canaries to catch metaspace overwriters). I debated with myself several times whether or not to remove it. Or whether to move the code out of MetaspaceArena. Guess I confused myself enough for this to happen.

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

PR Review Comment: https://git.openjdk.org/lilliput/pull/128#discussion_r1485158735

From stuefe at openjdk.org  Sat Feb 10 15:10:08 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sat, 10 Feb 2024 15:10:08 GMT
Subject: [master] RFR: JDK-8325104: Lilliput: Shrink Classpointers [v2]
In-Reply-To: <5Hg3aWe6cymqJix7XUhQeSrbqWYsGpICXCNQPtsEzRc=.ab9bd02b-afdb-4ac8-acd1-c92e363f79ee@github.com>
References: <lm7SDOvsKA7Yt1yDQpYx5VPVjke0eAO0BB9ctkIA8qs=.206072f0-3274-492d-9224-d41adb3b842a@github.com>
 <5Hg3aWe6cymqJix7XUhQeSrbqWYsGpICXCNQPtsEzRc=.ab9bd02b-afdb-4ac8-acd1-c92e363f79ee@github.com>
Message-ID: <f_NrqWwNW6fjg1nOcZWpgSOXvnH83a0XYft7f61G2qw=.4a42e7e8-cbe3-489a-9353-b79bc468f51d@github.com>

On Wed, 7 Feb 2024 19:12:47 GMT, Roman Kennke <rkennke at openjdk.org> 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 16 commits:
>> 
>>  - 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
>>  - Fixes
>>  - Fix Windows-Only bug that was caused by !INCLUDE_CDS_JAVA_HEAP
>>  - fix runtime/cds/appcds/TestCombinedCompressedFlags and runtime/cds/appcds/CommandLineFlagComboNegative.java
>>  - Fix CdsDifferentCompactObjectHeaders
>>  - ... and 6 more: https://git.openjdk.org/lilliput/compare/da4ffa35...f665504c
>
> src/hotspot/share/memory/metaspace/metachunk.hpp line 31:
> 
>> 29: #include "memory/metaspace/chunklevel.hpp"
>> 30: #include "memory/metaspace/counters.hpp"
>> 31: #include "memory/metaspace/metablock.hpp"
> 
> Why is the include needed here?

Remnant of some work I reverted. I'll remove it.

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

PR Review Comment: https://git.openjdk.org/lilliput/pull/128#discussion_r1485159659

From stuefe at openjdk.org  Mon Feb 12 08:31:15 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 12 Feb 2024 08:31:15 GMT
Subject: [master] RFR: JDK-8325104: Lilliput: Shrink Classpointers [v2]
In-Reply-To: <f_NrqWwNW6fjg1nOcZWpgSOXvnH83a0XYft7f61G2qw=.4a42e7e8-cbe3-489a-9353-b79bc468f51d@github.com>
References: <lm7SDOvsKA7Yt1yDQpYx5VPVjke0eAO0BB9ctkIA8qs=.206072f0-3274-492d-9224-d41adb3b842a@github.com>
 <5Hg3aWe6cymqJix7XUhQeSrbqWYsGpICXCNQPtsEzRc=.ab9bd02b-afdb-4ac8-acd1-c92e363f79ee@github.com>
 <f_NrqWwNW6fjg1nOcZWpgSOXvnH83a0XYft7f61G2qw=.4a42e7e8-cbe3-489a-9353-b79bc468f51d@github.com>
Message-ID: <U8JPXquviS7V3Hc_31I0SZZjzAmmvr5XPyYa9GZdUI8=.f11d2036-c7b5-4f43-b740-bd27647656f6@github.com>

On Sat, 10 Feb 2024 15:07:10 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> src/hotspot/share/memory/metaspace/metachunk.hpp line 31:
>> 
>>> 29: #include "memory/metaspace/chunklevel.hpp"
>>> 30: #include "memory/metaspace/counters.hpp"
>>> 31: #include "memory/metaspace/metablock.hpp"
>> 
>> Why is the include needed here?
>
> Remnant of some work I reverted. I'll remove it.

Remnant. Removed.

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

PR Review Comment: https://git.openjdk.org/lilliput/pull/128#discussion_r1485856327

From stuefe at openjdk.org  Mon Feb 12 13:23:07 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 12 Feb 2024 13:23:07 GMT
Subject: [master] RFR: JDK-8325104: Lilliput: Shrink Classpointers [v2]
In-Reply-To: <p7Biv2wAuq4YGRTnQPYOfj3Gsr728RxyWdsqMiQ3Oug=.5496ba41-31ec-4e87-bfbb-2a7d41ee2fa0@github.com>
References: <lm7SDOvsKA7Yt1yDQpYx5VPVjke0eAO0BB9ctkIA8qs=.206072f0-3274-492d-9224-d41adb3b842a@github.com>
 <5Hg3aWe6cymqJix7XUhQeSrbqWYsGpICXCNQPtsEzRc=.ab9bd02b-afdb-4ac8-acd1-c92e363f79ee@github.com>
 <p7Biv2wAuq4YGRTnQPYOfj3Gsr728RxyWdsqMiQ3Oug=.5496ba41-31ec-4e87-bfbb-2a7d41ee2fa0@github.com>
Message-ID: <t6Dk_nuFUcVPeBuqRD3srmO7z-a6KKAHRVrayvO2zsk=.fe004620-6233-4dcc-972c-9e235e65d06b@github.com>

On Sat, 10 Feb 2024 14:49:00 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> src/hotspot/cpu/x86/sharedRuntime_x86.cpp line 80:
>> 
>>> 78:   // because it could be larger than 32 bits in a 64-bit vm. See markWord.hpp.
>>> 79:   if (UseCompactObjectHeaders) {
>>> 80:     STATIC_ASSERT(markWord::hash_mask_compact < nth_bit(32));
>> 
>> This makes me think if the i-hash should go/stay in its original position, and we could get rid of hash_code_compact and related changes in Lilliput? Or would that not work for some reason?
>
> It would, but we would have one unused bit in the front, three in the back. I am not sure that is an improvement.

(offlist agreed with Roman to shift hash and nKlass thus that all unused bits are clustered in the MSB.)

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

PR Review Comment: https://git.openjdk.org/lilliput/pull/128#discussion_r1486171845

From rkennke at amazon.de  Wed Feb 14 13:17:04 2024
From: rkennke at amazon.de (Kennke, Roman)
Date: Wed, 14 Feb 2024 13:17:04 +0000
Subject: Object to ObjectMonitor mapping using a HashTable to avoid
 displaced headers
In-Reply-To: <0B10511B-07B9-4314-A606-85A8AF5A976D@oracle.com>
References: <08E8A4A4-39FB-47C5-8138-CF7B12E56207@oracle.com>
 <0B10511B-07B9-4314-A606-85A8AF5A976D@oracle.com>
Message-ID: <7BCD968B-19A5-4A3E-90E7-2261942F1AA4@amazon.de>

Hi Axel,


Thanks for this loooooong write-up! This is very helpful to understand what you are doing in the OMWorld project. I have a few comments:

> ## High to Medium Level Overview of the Implementation
> 

This is very useful, and makes a lot of sense. Thank you!

> ### Inflation-Deflation Protocol
> 

Again very useful information.

> #### Spinning waiting on Deflation Thread progress
> 
> There is an unfortunate property here where the correctness requires progress of
> the deflation thread before any locking thread can make progress. The window
> where the deflation thread could suffer an unfortunate preemption is small, but
> it does exist. Currently if a locking thread fails to `inflate_and_enter`
> (due to deflation) it will attempt to fast lock again. Which means that at least
> one locking thread can always make progress if the deflation thread as
> transitioned away the mark word from `0b10` Monitor. So the window is between
> the deflation thread making an ObjectMonitor `is_being_async_deflated()` and
> transitioning the mark word away from `0b10` Monitor.

How bad is that? Have you ever observed this to be an actual problem? (It seems kind-of the reverse of what is currently done with the INFLATING protocol and doesn?t seem very much worse than that. Correct me if I?m wrong here.)

> There are schemas that can avoid this property but requires additional mark word
> state. Either another bit (want to avoid at all cost) or use the fourth unused
> state of the locking bits (`0b11` currently). The second would be an rather
> intrusive change (has been prototyped) because the JVM makes a lot of
> assumptions based on single bit states in the lock bits.
> 

Yes, and that combination of bit-states is not unused either. GCs use 0b11 to indicate a ?forwarded? state. This is not a problem for most GCs, because it is only a transitional state during GC at safepoint, but it may be a problem with Shenandoah where this state occurs outside of safepoints (albeit only in from-space). In-fact it might still work, because the ?forwarded? state would only be observed in from-space objects, which the locking code never sees (the barriers would ensure that only to-space objects are ever exposed to the runtime). It might work, if the 0b11 is only a transitional state and cannot be observed at safepoints (which would also break other GCs, btw). Then we could never accidentally leak 0b11 into from-space. But it is all quite hairy mess. We might want to avoid it, at least for the first shot, unless it solves a severe issue. Again, it looks kinda-like the reverse of the current INFLATING protocol, and doesn?t seem worse than that.

> ### ObjectMonitor Thread-Local Caches
> 

This is great!

> ## The Work Going Forward
> 
> ### Primary
> 
> Should be solved before integration.
> 
> #### OMCache
> 
> First is finalizing the size, behavior and layout of the Cache used by C2
> locking.
> 
> In the patch sent out last week the OMCache capacity is set to eight. And the
> actual size used can then be tuned from 0 to 8 using the `int OMCacheSize` flag.
> It is also possible to turn of the cache completely with the `bool OMUseC2Cache`
> flag to evaluate the affect no cache would have on a specific workload.
> 
> Different sizes have been tried, when running different benchmark suites
> (DaCapo, SPEC*, Renaissance, etc) between 3-5 seem to be required by at least
> some benchmark, and for those which had a lot of misses with 3-5 also had a lot
> of misses with even larger cache size.
> 

My gut feeling would have been no more than 4, perhaps even less, maybe just 1 (which would make the code much simpler). Rationale is that, how many OMs can you have that *are hot* at the same time on a given thread. If a single thread needs to deal with several nested monitors, then surely only the innermost 1-2 monitors would be hot?
 I am not sure that observed cache-misses is the most relevant metric, here. What?s relevant is how deep does the cache have to be to make a performance difference. Or maybe I am over-optimistic about how complex locking schemes can be ;-)

> Unrolling the cache scan. This was the initial approach, but just using a loop
> (which the patch that was sent out does) performed better in general. But there
> are many factors at work here, it may be worthwhile to introduce a flag so that
> loop unrolling the cache scan can be evaluated. If I recall correctly the
> initial unrolled cache lookup was when both fast_lock and fast_unlock used the
> same cache so it got unrolled in both the lock and unlock code. Now that only
> fast_lock uses this cache the result may be different.

Yeah. And seems only feasible if cache is small enough (~ <=4)

> The OMWorldCache is currently layed out as a struct of arrays, it should
> probably be layed out as an array of structs (especially if it turns out that a
> larger cache is preferable).
> 

Yeah. Array-of-structs would lead to a linear access pattern, which is often preferable. Also, we may want to make sure that the cache starts at a CPU cache line.

> Enabling `bool OMCacheHitRate` will emit hit rate counters in C2, they are
> logged to `monitorinflation=info` which can be used to evaluate specific
> workloads.

Great!

> #### OMWorld Hash Table Resizing
> 
> In the patch sent out last week the hash table resizing uses a very naive
> approach which simply delegates the deflation thread to grow the table if some
> other thread encounters a grow hint. Right now it exist to simply grow the table
> for those workloads which require a larger amount of monitors.
> 
> The first issue is the sizing, it is currently configured to start at a size of
> at least 1K and based on processor count and AvgMonitorsPerThreadEstimate (all
> of which are wild). And grows up to a size of 2M. And uses the default grow_hint
> of 4. Currently the table only grows, there is a flag `bool OMShrinkCHT` which
> can be used to enable a very WIP heuristic which also shrinks the table. However
> it is unclear if this is desirable, and how it would be designed in such a way
> that it avoids unnecessary oscillations. It would be very workload dependent.

Right. I would think that we do want to be able to shrink the table. I don?t think that we want to stick with a large table forever, only because we had an OM spike at some time (e.g. start-up). But I have no data yet to support that.

> The deflation thread is currently resizing while blocked in VM. That may not
> be appropriate.

Is there a way to do it concurrently?

> It would also be good to evaluate how good the default FastHashCode is. 

Uhhh, this reminds me: we have the reverse situation to what we had before, right? Before, I-hashing an object could force monitor inflation, now, monitor-inflation would force I-hashing. Is that correct? I don?t think that this is a problem, in my experience we have far less OM-locked objects than I-hashed objects. But it?s good to keep it in mind.

Are there any notably interaction in the inflation protocol when we have to manipulate both the lock-bits *and* the hash-bits? I don?t think there would be, but maybe you can confirm?

FWIW, looking forward, Lilliput is going to use a different hash-code:
https://github.com/openjdk/lilliput/blob/master/src/hotspot/share/utilities/fastHash.hpp

And looking forward even more, we are going to use a different I-hashing scheme where we don?t store the I-hash in the header at all, but grow the object on-demand (if necessary).

> #### Spinning
> 
> There are currently two places where a locking thread spins, waiting on some
> other thread to make progress.
> 
> The first is a fixed pre-spin if a fast locked Object is encountered. This will
> attempt to fast lock the object for a fixed number of iterations, the first
> `int OMSpins` (tunable flag) number of iterations will be separated by a
> `SpinPause()` and the last `int OMYields` (tunable flag) number of iterations
> will be separated by an `os::naked_yield()`. The idea is to avoid inflating if
> the critical sections are are on the same order of time as the time cost for
> inflating, in such a case the  thread would do better to just wait and fast lock
> instead of inflating.
> 

This sounds useful! I assume this is only done in the runtime, and fast-paths call into the runtime on first CAS-failure?

> The current numbers for the flags were chosen by looking at programs which
> exhibited this behavior.
> 
> The `monitorinflation=info` logging will print a per thread inflation cause
> which can be used to evaluate the behavior of different programs. The following
> causes are counted.
> ```
>  Mon: Number of inflations from an `0b01` Unlocked state.
>  Rec: Number of unbalanced or interleaved recursions.
> CRec: Number of recursive enter which inflated (not due to the cause above).
> Cont: Number of contended inflations experienced (during exit, wait, notify).
> Wait: Number of inflations cause by wait.
> Stack: Number of inflations caused because of a full lock stack.
> ```
> 
> A workload dominated by `Mon:` benefits from this fixed-pre-spin. The `Mon:`
> cause means that Object was unlocked during the inflation.

Nice!


> The second spinning that occurs is the one where for correctness a locking
> thread must wait for the deflation thread to make progress. It currently does
> two iterations each followed by an `os::naked_yield` and for the rest of the
> iterations it uses `os::naked_short_nanosleep()`. There are multiple issues
> here. This can become an issue on an over-provisioned machine, which may make
> the deflation threads progress flaky. In the implementation details above I have
> discussed potential a solution to how we can make sure that at least one thread
> guaranteed progress. However on an over-provisioned machine even if one thread
> is guaranteed to get a lock, such a thread might just also be scheduled out and
> never get to run (while holding the lock).
> 
> Regardless of the progress issue, the issue with time to safepoint needs to be
> addressed. A locking thread that has been blocked by deflation for two
> iterations should also transition to blocked in VM for the sleep duration and
> participate in the safepoint protocol.

Uhhh, ok. Wait a second, aren?t threads that want to inflate a monitor already at a safepoint?

> #### Performance
> 
> The fact that a performance evaluation is required for integration is a
> no-brainer, however the exact requirements are harder to pin down. The nature of
> the different LockingModes in HotSpot is such that they all have different
> workloads for which they are best suited. This could be seen last year when
> the default was temporarily switched to LM_LIGHTWEIGHT and there were a lot of
> movement in the promoted performance runs. A lot of regressions, but there were
> also workloads which showed improvement with LM_LIGHTWEIGHT over LM_LEGACY.
> 
> Most of the performance work with OMWorld has been trying to achieve parity with
> LM_LEGACY, however there are still known workloads where LM_LEGACY is better,
> and also known workloads where OMWorld is better. Then there are all the unknown
> workloads for which OMWorld has not been tested.
> 
> All I am trying to say is that this is probably one of the issues which will be
> the hardest to figure out.
> 
> At least now with OMWorld as part of the Lilliput project a more holistic
> evaluation can be attempted, where maybe the whole can be greater than the sum
> of its parts. (This includes smaller headers, OMWorld and stable klass pointers,
> GC algorithms without forwarding pointers in the object header, loom support for
> synchronized without pointers from the java heap into thread stacks).

Indeed! I did some initial performance runs with OMWorld/Lilliput and found that most workloads show parity. I?ve seen some workloads benefit a lot (>10% improvement) but I strongly suspect this is because of stable class-pointers. I have not yet dived deeper. I figured that for now it would be more useful to make an apples-to-apples comparison. For this, could you, once the recursive-LW stuff is all pushed, update/merge latest jdk into your jdk-based branch?

> ### Secondary
> 
> Should be understood before integration.
> 
> #### Deflation Heuristics
> 
> The current heuristics that drive the deflation thread does not seem like a good
> fit for how OMWorld works. In OMWorld the `AvgMonitorsPerThreadEstimate` is
> disabled unless unless it is configured via the command line. Instead the
> `_in_use_list_ceiling` is grown based on the number of actual inflations. There
> is pre-existing weirdness in this heuristics.
> 
> Currently, for most observed workloads, deflation is driven by the
> `GuaranteedAsyncDeflationInterval` flag.

I?ve lately been thinking that concurrent deflation shares the outpaced-by-the-program property that concurrent GCs suffer. In theory, a sufficiently aggressive  workload could keep generating more OMs than deflation could free up. We might actually have observed this already when running workloads without LW recursive locking.


> #### C2 Fast Lock / Fast Unlock
> 
> The fast path in the C2 code is where the recursive lightweight initially came
> from. Many alternative implementations have been evaluated. The only one which
> has been somewhat promising is one which tries to make LM_LIGHTWEIGHT more like
> LM_LEGACY by making recursive fast lock enters always take a fast lock exit, by
> setting the a value in the BasicLock that signals to the exit paths that a
> recursive fast lock  enter was performed and it can simply exit. This also
> extended the first fast lock enter to save the previous lock stack top along
> with a signal (differentiating it from an ObjectMonitor), which enabled the fast
> lock exit paths to restore the top value without loading anything from the lock
> stack. Effectively the exit could decode exactly what the enter did by reading
> the BasicLock from the stack.
> 

Nice! I?ve been hoping to get rid of BasicLock, but if it?s useful than we may just keep it.

> And lastly most platforms in HotSpot only emitted JITed inflated enter exit code
> for C2, even tough both C1 and the native wrapper share the same property of
> only performing balanced locking.

Right. At least C1 should perhaps also do OM-locking.

> #### C2 Compilation Failures
> 
> During performance testing two issues came up. For some benchmarks there is
> randomness which determines if the hot code of the program gets C1 or C2
> compiled.
> 
> And some trivial micro-benchmarks using synchronized would cause both C1 and C2
> to not compile and run completely in the interpreter.
> 

Ugh. Any idea why that is so?

> 
> ## Miscellaneous
> 
> This will be some concluding words as well as some discussion on Why
> LM_PLACEHOLDER
> 
> ### Why LM_PLACEHOLDER
> 
> First LM_PLACEHOLDER is exactly that, a placeholder for the final locking mode,
> be that called LM_LIGHTWEIGHT, or something else.
> 
> This was mainly because many discussions and changes regarding LM_LIGHTWEIGHT
> stalled OMWorld development, and partially a defensive measure to not have
> changes to OMWorld stall any other projects with regards to LM_LIGHTWEIGHT.
> There is synchronized support for loom on the way, which should fit in
> seamlessly with both LM_LIGHTWEIGHT and LM_PLACEHOLDER, but there are incentives
> to use a lock stack based locking mode with these loom changes rather than a
> LM_LEGACY based one.
> 
> One unintended benefit in the short term is that it will be a little easier to
> compare and identify the different benefits and drawbacks between LM_LIGHTWEIGHT
> and LM_PLACEHOLDER in Lilliput. (Obviously a maintenance burden in the long run,
> but both seem rather stable in the Lilliput repo).
> 
> The ambition is to harmonize the LockingModes and be able to finally reduce them
> to one or two, which would be a maintenance win for the whole of HotSpot.
> 

Indeed! Thanks for the insights.

> 
> ### Final Words
> 
> If you read this whole thing in one go, my hats of too you.
> 
> I hope that this can serve as reference point which can be used to get more
> contributors engaged in the project. And that it can be an actionable stepping
> stone for bringing the Lilliput project closer to integration.

Again, thank you for that! It?s been very helpful to understand and get an idea of the scope of the project.

I would suggest to break up your efforts into tasks that are absolutely essential, and tasks/ideas that can be done after the first big thing has landed and stabilized. This would follow pretty much the structure of this document - focus on primary stuff first, and do most of the rest later. It?s just so hard to handle so many moving parts at the same time.

I?ll do more studying and testing and evaluations and get back to you when more questions arise.

Thanks and best regards!
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 axel.boldt-christmas at oracle.com  Thu Feb 15 06:53:11 2024
From: axel.boldt-christmas at oracle.com (Axel Boldt-Christmas)
Date: Thu, 15 Feb 2024 06:53:11 +0000
Subject: [External] : Re: Object to ObjectMonitor mapping using a
 HashTable to avoid displaced headers
In-Reply-To: <7BCD968B-19A5-4A3E-90E7-2261942F1AA4@amazon.de>
References: <08E8A4A4-39FB-47C5-8138-CF7B12E56207@oracle.com>
 <0B10511B-07B9-4314-A606-85A8AF5A976D@oracle.com>
 <7BCD968B-19A5-4A3E-90E7-2261942F1AA4@amazon.de>
Message-ID: <235661DA-B01F-45FE-93E8-0805AFF0AD62@oracle.com>

Hi Roman,

> How bad is that? Have you ever observed this to be an actual problem? (It seems kind-of the reverse of what is currently done with the INFLATING protocol and doesn?t seem very much worse than that. Correct me if I?m wrong here.)


No, never observed it being an issue. Hitting the window between  `is_being_async_deflated()` transitioning the markWord is so small that I do not believe that it has been observed.

However before we added resizing to the HashTable there were runs where we had internal buckets with linked lists of size >100. Noticable time was then spent in insert, so I would guess that similar times would seen for remove (walking the links was costly). So the window until a thread could inflate again would be significant. This more of a TTS problem. Any safepoint would still need to also wait for the deflation thread to finish removing the ObjectMonitor from the hash table, put polling for safepoint earlier from inflating threads means that the worst time would be MAX(deflation, inflation + enter) instead of deflation +  inflation  + enter. 

> Uhhh, ok. Wait a second, aren?t threads that want to inflate a monitor already at a safepoint?

They are just java threads running in VM. Or do you mean something else? 

> My gut feeling would have been no more than 4, perhaps even less, maybe just 1 (which would make the code much simpler). Rationale is that, how many OMs can you have that *are hot* at the same time on a given thread. If a single thread needs to deal with several nested monitors, then surely only the innermost 1-2 monitors would be hot?
From some of the larger benchmark runs I ran last year a size of 3 outperformed a size of 1. (Some larger improvements, and no significant regressions) But maybe 2 is correct. A lot of the benchmarks that were run last year happened when many things were in flux. As mentioned in the mail a more targeted evaluation of just the cache size should be done now that less things are locked down.
 
> I am not sure that observed cache-misses is the most relevant metric, here. What?s relevant is how deep does the cache have to be to make a performance difference. Or maybe I am over-optimistic about how complex locking schemes can be ;-)
I agree, these metrics are more for evaluating when performance regression are observed to see the actual behaviour of specific workloads. It seems like there are some wild locking out there especially when you run benchmark suites covering over 25 years of software development.

> Right. I would think that we do want to be able to shrink the table. I don?t think that we want to stick with a large table forever, only because we had an OM spike at some time (e.g. start-up). But I have no data yet to support that.
Yes. Worth think about good schemes for deciding when to shrink the table.

> Is there a way to do it concurrently?
I am talking about the thread state. The resizing is concurrent. (With this being done while ThreadBlockInVM it actually resizes straight through safepoints). I need to do more research / ask more knowledgeable people about this. The String and Symbol table does this from the service thread while in VM, but creates its own grow loop which polls for safepoint per bucket. We?ve treated the ConcurrentHashTable very much as a blackbox. It may be time to get some of the runtime engineers that have had more experience with this particular implementation involved in the discussion. Both how to handle resizing, and what to expect w.r.t. performance, and gotchas with this specific	use case. 

> Are there any notably interaction in the inflation protocol when we have to manipulate both the lock-bits *and* the hash-bits? I don?t think there would be, but maybe you can confirm?
There will be multiple CAS?es as we first install the hash and then transition the header to monitor. But the idea is that the only reason this happens is because of ?real" lock contention, so an extra CAS is the least of our problems from a performance perspective.

> This sounds useful! I assume this is only done in the runtime, and fast-paths call into the runtime on first CAS-failure?
Correct.

>  For this, could you, once the recursive-LW stuff is all pushed, update/merge latest jdk into your jdk-based branch?
I will. 

Speaking of which. I was going to ask you how we should handle development (especially if more are getting involved).

For now I will work on changes based on the OMWorld Lilliput branch. And replicate (cherry-pick) these where applicable into my private mainline based branch. Until I am an official committer in the Lilliput I believe me and StefanK can figure out the technicalities around pushing to the branch.

So essentially, work on Lilliput/OMWorld, keep a private branch based the latest mainline merged in Lilliput/master (with OMWorld work replicated) and keep merging in Lilliput/master into Lilliput/OMWorld.

> Ugh. Any idea why that is so?

Only speculations. The compiled vs not compiled issue seems like a more binary thing where we might be (maybe for good reasons) more restrictive than necessary. This is probably the easier of the two to get an understanding of. The C1 vs C2 issue is probably caused by many factors, and I have nothing but educated guesses here. Something for engineers more versed in the compiler to tackle. 

> I would suggest to break up your efforts into tasks that are absolutely essential, and tasks/ideas that can be done after the first big thing has landed and stabilized. This would follow pretty much the structure of this document - focus on primary stuff first, and do most of the rest later. It?s just so hard to handle so many moving parts at the same time.

Sounds good. After recursive lightweight is integrated in mainline and merged into Lilliput (and OMWorld) there should be a lot less code motion surrounding the affected code. I will create sub-tasks (and figure out their dependencies) as you suggest.

 
Thanks for the response.
Sincerely,
Axel


From rkennke at amazon.de  Thu Feb 15 10:00:41 2024
From: rkennke at amazon.de (Kennke, Roman)
Date: Thu, 15 Feb 2024 10:00:41 +0000
Subject: [External] : Re: Object to ObjectMonitor mapping using a
 HashTable to avoid displaced headers
In-Reply-To: <235661DA-B01F-45FE-93E8-0805AFF0AD62@oracle.com>
References: <08E8A4A4-39FB-47C5-8138-CF7B12E56207@oracle.com>
 <0B10511B-07B9-4314-A606-85A8AF5A976D@oracle.com>
 <7BCD968B-19A5-4A3E-90E7-2261942F1AA4@amazon.de>
 <235661DA-B01F-45FE-93E8-0805AFF0AD62@oracle.com>
Message-ID: <7EB85E46-F1B5-452C-B32E-3571D09A85C0@amazon.de>

Hi Axel,

>> How bad is that? Have you ever observed this to be an actual problem? (It seems kind-of the reverse of what is currently done with the INFLATING protocol and doesn?t seem very much worse than that. Correct me if I?m wrong here.)
> 
> 
> No, never observed it being an issue. Hitting the window between  `is_being_async_deflated()` transitioning the markWord is so small that I do not believe that it has been observed.
> 
> However before we added resizing to the HashTable there were runs where we had internal buckets with linked lists of size >100. Noticable time was then spent in insert, so I would guess that similar times would seen for remove (walking the links was costly). So the window until a thread could inflate again would be significant. This more of a TTS problem. Any safepoint would still need to also wait for the deflation thread to finish removing the ObjectMonitor from the hash table, put polling for safepoint earlier from inflating threads means that the worst time would be MAX(deflation, inflation + enter) instead of deflation +  inflation  + enter.

Ok, thanks for the explanation.

>> Uhhh, ok. Wait a second, aren?t threads that want to inflate a monitor already at a safepoint?
> 
> They are just java threads running in VM. Or do you mean something else?

My understanding was that a Java thread in VM would not prevent reaching a safepoint. Maybe I mis-remember.

> Speaking of which. I was going to ask you how we should handle development (especially if more are getting involved).
> 
> For now I will work on changes based on the OMWorld Lilliput branch. And replicate (cherry-pick) these where applicable into my private mainline based branch. Until I am an official committer in the Lilliput I believe me and StefanK can figure out the technicalities around pushing to the branch.
> 
> So essentially, work on Lilliput/OMWorld, keep a private branch based the latest mainline merged in Lilliput/master (with OMWorld work replicated) and keep merging in Lilliput/master into Lilliput/OMWorld.

I am not sure. I tend to think that we should perhaps leave Lilliput itself out of the equation for now. Could we do development in a branch off of mainline JDK? I can set-up such a branch in the Lilliput repo, and I can also do regular merges from mainline JDK and to the omworld-lilliput branch, but I think main work should be based on latest JDK to keep the changes clean from extra Lilliput fluff and also to be able to do proper apples-to-apples comparisons.

>> Ugh. Any idea why that is so?
> 
> Only speculations. The compiled vs not compiled issue seems like a more binary thing where we might be (maybe for good reasons) more restrictive than necessary.

Sounds like this is a ?primary? issue.

> The C1 vs C2 issue is probably caused by many factors, and I have nothing but educated guesses here. Something for engineers more versed in the compiler to tackle.

Yeah, as far as I know this could be a pre-existing problem. At least I know that some workloads are at the mercy of compiler heuristics.

>> I would suggest to break up your efforts into tasks that are absolutely essential, and tasks/ideas that can be done after the first big thing has landed and stabilized. This would follow pretty much the structure of this document - focus on primary stuff first, and do most of the rest later. It?s just so hard to handle so many moving parts at the same time.
> 
> Sounds good. After recursive lightweight is integrated in mainline and merged into Lilliput (and OMWorld) there should be a lot less code motion surrounding the affected code. I will create sub-tasks (and figure out their dependencies) as you suggest.
> 

Great! I?m happy to help!

Cheers!
Roman



Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879



From rkennke at openjdk.org  Tue Feb 20 13:50:33 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 20 Feb 2024 13:50:33 GMT
Subject: [master] RFR: Merge jdk:jdk-23+10
Message-ID: <gXZeseW5S0meVKKrsqUaeB7epbUd1Z2_QxP_zrjcUug=.932837a7-6d23-4433-8f46-695c9d2d91c4@github.com>

Let's merge latest tag jdk-23+10.

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

Commit messages:
 - Merge tag 'jdk-23+10' into merge-jdk-23+10
 - 8321282: RISC-V: SpinPause() not implemented
 - 8323994: gtest runner repeats test name for every single gtest assertion
 - 8325910: Rename jnihelper.h
 - 8325682: Rename nsk_strace.h
 - 8325574: Shenandoah: Simplify and enhance reporting of requested GCs
 - 8252136: Several methods in hotspot are missing "static"
 - 8316340: (bf) Missing {@inheritDoc} for exception in MappedByteBuffer::compact
 - 8325643: G1: Refactor G1FlushHumongousCandidateRemSets
 - 8325403: Add SystemGC JMH benchmarks
 - ... and 170 more: https://git.openjdk.org/lilliput/compare/da4ffa35...afa0ab9e

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

Changes: https://git.openjdk.org/lilliput/pull/131/files
  Stats: 28589 lines in 1026 files changed: 12689 ins; 9874 del; 6026 mod
  Patch: https://git.openjdk.org/lilliput/pull/131.diff
  Fetch: git fetch https://git.openjdk.org/lilliput.git pull/131/head:pull/131

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

From rehn at openjdk.org  Tue Feb 20 14:47:47 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Tue, 20 Feb 2024 14:47:47 GMT
Subject: git: openjdk/lilliput: created branch jdk based on the branch omworld
 containing 179 unique commits
Message-ID: <1f411498-30b1-42e8-8e41-a3fb80ad0a2e@openjdk.org>

The following commits are unique to the jdk branch:
========================================================
fe78c0f1: 8325022: Incorrect error message on client authentication
432756b6: 8325024: java/security/cert/CertPathValidator/OCSP/OCSPTimeout.java incorrect comment information
a2229b18: 8324838: test_nmt_locationprinting.cpp broken in the gcc windows build
a6632487: 8324668: JDWP process management needs more efficient file descriptor handling
1aba78f2: 8324937: GHA: Avoid multiple test suites per job
68206b53: 8324585: JVM native memory leak in PCKS11-NSS security provider
d9331bfd: 8324845: management.properties text "interface name" is misleading
cd11059f: 8325053: Serial: Move Generation::save_used_region to TenuredGeneration
6b84f9bb: 8325001: Typo in the javadocs for the Arena::ofShared method
cab74b07: 8324287: Record total and free swap space in JFR
8e451823: 8324834: Use _LARGE_FILES on AIX
ac1cd319: 8325096: Test java/security/cert/CertPathBuilder/akiExt/AKISerialNumber.java is failing
70e7cdcb: 8323670: A few client tests intermittently throw ConcurrentModificationException
6b09a79d: 8324974: JFR: EventCompilerPhase should be created as UNTIMED
192349ee: 8324066: "clhsdb jstack" should not by default scan for j.u.c locks because it can be very slow
b3ecd556: 8324679: Replace NULL with nullptr in HotSpot .ad files
144a08ee: 8325078: Better escaping of single and double quotes in javac annotation toString() results
d3c3194a: 6285888: ChoiceFormat can support unescaped relational symbols in the Format segment
783ae566: 8311893: Interactive component with ARIA role 'tabpanel' does not have a programmatically associated name
91d8dac9: 8325137: com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java can fail in Xcomp with out of expected range
6787c4c3: 8325055: Rename Injector.h
38c01971: 8318105: [jmh] the test java.security.HSS failed with 2 active threads
1ae85138: 8324858: [vectorapi] Bounds checking issues when accessing memory segments
adc36040: 8325148: Enable restricted javac warning in java.base
f613e133: 8313739: ZipOutputStream.close() should always close the wrapped stream
63cb1f88: 8321396: Retire test/jdk/java/util/zip/NoExtensionSignature.java
7476e290: 8323680: SA PointerFinder code can do a better job of leveraging existing code to determine if an address is in the TLAB
a18b03b8: 8324635: (zipfs) Regression in Files.setPosixFilePermissions called on existing MSDOS entries
ed068469: 8325037: x86: enable and fix hotspot/jtreg/compiler/vectorization/TestRoundVectFloat.java
692c9f88: 8325201: (zipfs) Disable TestPosix.setPermissionsShouldConvertToUnix which fails on Windows
80642dd7: 8324817: Parallel GC does not pre-touch all heap pages when AlwaysPreTouch enabled and large page disabled
8796f43c: 8315762: Update subtype check profile collection on s390x following 8308869
85e32012: 8325159: C2 SuperWord: measure time for CITime
af32262c: 8325049: stubGenerator_ppc.cpp should use alignas
df35462a: 8323502: javac crash with wrongly typed method block in Flow
0377f1ab: 8325133: Missing MEMFLAGS parameter in parts of os API
4da28b40: 8291809: Convert compiler/c2/cr7200264/TestSSE2IntVect.java to IR verification test
cdf918b1: 8325134: Serial: Remove Generation::used_region
51671c0b: 8323809: Serial: Refactor card table verification
d395ac28: 8321373: Build should use LC_ALL=C.UTF-8
89e6a02e: 8325064: C2 SuperWord: refactor construct_bb
19e92201: 8325169: Reduce String::indexOf overheads
55c1446b: 8321468: Remove StringUTF16::equals
19936526: 8324983: race in CompileBroker::possibly_add_compiler_threads
c3adc61e: 8325199: (zipfs) jdk/nio/zipfs/TestPosix.java failed 6 sub-tests
51853f74: 8324724: Add Stub routines for FP16 conversions on aarch64
7777eb5e: 8321931: memory_swap_current_in_bytes reports 0 as "unlimited"
209d87a8: 8324960: Unsafe.allocateMemory documentation incorrect regarding zero return value
fd3042a0: 8318566: Heap walking functions should not use FilteredFieldStream
f31957e6: 8317636: Improve heap walking API tests to verify correctness of field indexes
ab3b9417: 8325270: ProblemList two compiler/intrinsics/float16 tests that fail due to JDK-8324724
f1f93988: 8323699: MessageFormat.toPattern() generates non-equivalent MessageFormat pattern
e0fd3f4d: 8325081: Move '_soft_ref_policy' to 'CollectedHeap'
729ae1d7: 8325266: Enable this-escape javac warning in jdk.javadoc
9ee9f288: 8325213: Flags introduced by configure script are not passed to ADLC build
542b0b66: 8324126: Error message for mistyping -XX:+Unlock...Options is not helpful
6d911f68: 8317299: safepoint scalarization doesn't keep track of the depth of the JVM state
b02599d2: 8298046: Fix hidden but significant trailing whitespace in properties files for serviceability code
4cd31875: 8324874: AArch64: crypto pmull based CRC32/CRC32C intrinsics clobber V8-V15 registers
b75c134f: 8325313: Header format error in TestIntrinsicBailOut after JDK-8317299
f356970b: 8322535: Change default AArch64 SpinPause instruction
d1c82156: 8325194: GHA: Add macOS M1 testing
fd89b334: 8316992: Potential null pointer from get_current_thread JVMCI helper function.
51d7169b: 8320237: C2: late inlining of method handle invoke causes duplicate lines in PrintInlining output
50b17d98: 8316704: Regex-free parsing of Formatter and FormatProcessor specifiers
b814c318: 8321703: jdeps generates illegal dot file containing nodesep=0,500000
2d252ee0: 8325180: Rename jvmti_FollowRefObjects.h
96eb0390: 8324665: Loose matching of space separators in the lenient date/time parsing mode
4b1e367e: 8325152: Clarify specification of java.io.RandomAccessFile.setLength
0f5f3c9b: 8325254: CKA_TOKEN private and secret keys are not necessarily sensitive
1797efd6: 8322218: Better escaping of single and double quotes in annotation toString() results
f2f63444: 8325347: Rename native_thread.h
e0d98dd3: 8325257: jshell reports NoSuchFieldError with instanceof primitive type
3bffe223: 8319463: ClassSignature should have superclass and superinterfaces as ClassTypeSig
4abb10eb: 8317349: Randomize order of macro node expansion in C2
77ee7f0e: 8325221: Obsolete TLABStats
c3a632dc: 8325248: Serial: Remove Generation::space_iterate
1ecf74c2: 8325306: Rename static huge pages to explicit huge pages
a9c6e87c: 8325416: Parallel: Refactor CheckForUnmarkedOops
a3a2b1fb: 8324881: ObjectSynchronizer::inflate(Thread* current...) is invoked for non-current thread
18e24d06: 8325109: Sort method modifiers in canonical order
3a1f4d0f: 8325268: Add policy statement to langtools makefiles concerning warnings
299a8ee6: 8325302: Files.move(REPLACE_EXISTING) throws NoSuchFileException on deleted target
fbd15b20: 8325189: Enable this-escape javac warning in java.base
be7cc1c2: 8323681: SA PointerFinder code should support G1
9cccf051: 8325367: Rename nsk_list.h
1fb9e3d6: 8325304: Several classes in java.util.jar and java.util.zip don't specify the behaviour for null arguments
d1099033: 8325028: (ch) Pipe channels should lazily set socket to non-blocking mode on first use by virtual thread
43089bf0: 8325399: Add tests for virtual threads doing Selector operations
917838e0: 8325150: (tz) Update Timezone Data to 2024a
b58d73b9: 8323746: Add PathElement hashCode and equals
3d3a8f0e: 8325432: enhance assert message "relocation addr must be in this section"
e8ceb718: 6507038: Memory Leak in JTree / BasicTreeUI
3c91b59e: 8325444: GHA: JDK-8325194 causes a regression
ab5e9477: 8325436: G1: Remove unused G1RegionMarkStats::is_clear
0ea75b28: 8325259: Serial: Inline OldGenScanClosure during Young GC
10beb318: 8325456: Rename nsk_mutex.h
d91fb17a: 8325505: Fix Javadoc ResourceBundle::getString
9936aeea: 8324824: AArch64: Detect Ampere-1B core and update default options for Ampere CPUs
b7976522: 8322927: Unused code in LIR_Assembler::verify_oop_map
8d9ad97c: 8324641: [IR Framework] Add Setup method to provide custom arguments and set fields
cc276ff0: 8325516: Shenandoah: Move heap change tracking into ShenandoahHeap
e3dc6a7a: 8314275: Incorrect stepping in switch
71b46c38: 8325471: CHeapBitMap(MEMFLAGS flags) constructor misleading use of super-constructor
d165d124: 8325510: Serial: Remove redundant arg in non_clean_card_iterate
5daf622a: 8325309: Amend "Listeners and Threads" in AWTThreadIssues.html
8b70b8d8: 8325440: Confusing error reported for octal literals with wrong digits
52d49761: 8325437: Safepoint polling in monitor deflation can cause massive logs
69b2674c: 8324648: Avoid NoSuchMethodError when instantiating NativePRNG
8ef918d6: 8324646: Avoid Class.forName in SecureRandom constructor
29d89d48: 8325551: Remove unused obj_is_alive and block_start in Space
40708baf: 8325563: Remove unused Space::is_in
4a3a38d1: 8325517: Shenandoah: Reduce unnecessary includes from shenandoahControlThread.cpp
43684374: 8325264: two compiler/intrinsics/float16 tests fail after JDK-8324724
6944537c: 8325203: System.exit(0) kills the launched 3rd party application
b42b8886: 8325038: runtime/cds/appcds/ProhibitedPackage.java can fail with UseLargePages
ac4607ed: 8226919: attach in linux hangs due to permission denied accessing /proc/pid/root
d39b7bab: 8316460: 4 javax/management tests ignore VM flags
3ebe6c19: 8319578: Few java/lang/instrument ignore test.java.opts and accept test.vm.opts only
6303c0e7: 8325569: ProblemList gc/parallel/TestAlwaysPreTouchBehavior.java on linux
e33d8a21: 8311076: RedefineClasses doesn't check for ConstantPool overflow
6c7029ff: 8318603: Parallelize sun/java2d/marlin/ClipShapeTest.java
71d2dbd0: 8325464: GCCause.java out of sync with gcCause.hpp
232d1368: 8324890: C2 SuperWord: refactor out VLoop, make unrolling_analysis static, remove init/reset mechanism
af7eeffd: 8325565: Remove unused SpaceClosure
2546afe2: 8325451: Missed elimination of assertion predicates
efa071dd: 8323089: networkaddress.cache.ttl is not a system property
e5cb78cc: 8324539: Do not use LFS64 symbols in JDK libs
6a123626: 8325606: compiler/predicates/TestPredicatesBasic.java does not compile
1358850a: 8322694: C1: Handle Constant and IfOp in NullCheckEliminator
16b3be0a: 8325503: Add GC specific prefix for CheckForUnmarked related classes
1e4b7017: 8316931: [macos14] Test "java/awt/TrayIcon/ShowAfterDisposeTest/ShowAfterDisposeTest.html" throws an exception on macOS 14(x64, aarch64)
46287630: 8320302: compiler/arguments/TestC1Globals.java hits SIGSEGV in ContinuationEntry::set_enter_code
d70156d2: 8325529: Remove unused imports from `ModuleGenerator` test file
b3e0587e: 8322874: Redirection loop in index.html
482c1006: 8322865: JavaDoc fails on aggregator modules
7c697123: 8325570: Update to Graphviz 9.0.0
2ed889b7: 8323628: Update license on "pass-through" files
b356fee5: 8325458: Rename mlvmJvmtiUtils.h
62a4be03: 8325635: Serial: Inline verify_used_region_at_save_marks
4513da94: 8325470: [AIX] use fclose after fopen in read_psinfo
5dbf1373: 8319797: Recursive lightweight locking: Runtime implementation
618af397: 8325633: Use stricter assertion in callers of Space::is_aligned
ec20b0aa: 8325626: Allow selection of non-matching configurations using CONF=!string
c266800a: 8325558: Add jcheck whitespace checking for properties files
088e54f5: 8325650: Table of contents scroll timeout not long enough
f8d8eecf: 8325325: Breadcrumb navigation shows preview link for modules and packages
c3c1cdd1: 8325731: Installation instructions for Debian/Ubuntu don't mention autoconf
71ff2d71: 8325616: JFR ZGC Allocation Stall events should record stack traces
7ec2badd: 8323520: Drop unnecessary virtual specifier in Space
7cd25ed6: 8322854: Incorrect rematerialization of scalar replaced objects in C2
57b04e1b: 8325748: Serial: Move Generation::promote to TenuredGeneration
13d9e8ff: 8325590: Regression in round-tripping UTF-16 strings after JDK-8311906
6b7c9718: 8325382: (fc) FileChannel.transferTo throws IOException when position equals size
6dfa7f39: 8325541: C2 SuperWord: refactor filter / split
74b90aa8: 8325672: C2: allocate PhaseIdealLoop::_loop_or_ctrl from C->comp_arena()
243fb461: 8325750: Fix spelling of ForceTranslateFailure help message
842b895f: 8303891: Speed up Zip64SizeTest using a small ZIP64 file
628cd8a4: 8303866: Allow ZipInputStream.readEnd to parse small Zip64 ZIP files
8765b176: 8325800: Drop unused cups declaration from Oracle build configuration
ea419322: 8325395: Missing copyright header in StackFilter.java
7f6bb71e: 8319799: Recursive lightweight locking: x86 implementation
ea98de63: 8325449: [BACKOUT] use "dmb.ishst+dmb.ishld" for release barrier
d0039960: 8325743: test/jdk/java/nio/channels/unixdomain/SocketOptions.java enhance user name output in error case
0c2def0e: 8325653: Erroneous exhaustivity analysis for primitive patterns
84965ea1: 8322630: Remove ICStubs and related safepoints
8dc59763: 8325809: JFR: Remove unnecessary annotation
61f24933: 8325767: Serial: Move transform_stack_chunk out of TenuredGeneration::promote
737b4c51: 8323883: JFR AssertionError: Missing object ID 15101
9c852df6: 8318966: Some methods make promises about Java array element alignment that are too strong
130f429c: 8325403: Add SystemGC JMH benchmarks
53878eef: 8325643: G1: Refactor G1FlushHumongousCandidateRemSets
f6e28510: 8316340: (bf) Missing {@inheritDoc} for exception in MappedByteBuffer::compact
09d49366: 8252136: Several methods in hotspot are missing "static"
b823fa44: 8325574: Shenandoah: Simplify and enhance reporting of requested GCs
22e81810: 8325682: Rename nsk_strace.h
810daf82: 8325910: Rename jnihelper.h
1aae980c: 8323994: gtest runner repeats test name for every single gtest assertion
8cb9b479: 8321282: RISC-V: SpinPause() not implemented

From duke at openjdk.org  Tue Feb 20 14:52:13 2024
From: duke at openjdk.org (duke)
Date: Tue, 20 Feb 2024 14:52:13 GMT
Subject: git: openjdk/lilliput: created branch omworld-jdk based on the branch
 jdk containing 2 unique commits
Message-ID: <7435379c-ae21-4196-bd1d-77c460aac417@openjdk.org>

The following commits are unique to the omworld-jdk branch:
========================================================
85b742b5: Initial Split
40dfe7a3: Minor cleanups

From stuefe at openjdk.org  Tue Feb 20 15:59:13 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 20 Feb 2024 15:59:13 GMT
Subject: [master] RFR: Merge jdk:jdk-23+10
In-Reply-To: <gXZeseW5S0meVKKrsqUaeB7epbUd1Z2_QxP_zrjcUug=.932837a7-6d23-4433-8f46-695c9d2d91c4@github.com>
References: <gXZeseW5S0meVKKrsqUaeB7epbUd1Z2_QxP_zrjcUug=.932837a7-6d23-4433-8f46-695c9d2d91c4@github.com>
Message-ID: <IqYYFDv-KMSOU0lkJC1y8JSK9Ng08VB3CoVhkg1G2ek=.9e86139d-ecf2-4052-bb14-c82937232a52@github.com>

On Tue, 20 Feb 2024 13:43:31 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Let's merge latest tag jdk-23+10.

Looks good to me.

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

Marked as reviewed by stuefe (Committer).

PR Review: https://git.openjdk.org/lilliput/pull/131#pullrequestreview-1890822109

From duke at openjdk.org  Tue Feb 20 16:19:20 2024
From: duke at openjdk.org (duke)
Date: Tue, 20 Feb 2024 16:19:20 GMT
Subject: [lilliput-jdk17u:lilliput] Withdrawn: 8316179: Use consistent naming
 for lightweight locking in MacroAssembler
In-Reply-To: <xJzJ5RLCzHE8wJC34UDKdiuBk5gSCF2KnZURHbfCNio=.1db74dfd-2e9d-41c4-825b-f478dc6cb79a@github.com>
References: <xJzJ5RLCzHE8wJC34UDKdiuBk5gSCF2KnZURHbfCNio=.1db74dfd-2e9d-41c4-825b-f478dc6cb79a@github.com>
Message-ID: <EfOlvMsNI_bNKhTxQFKjuwhSHR0VTrltDrMIRqJpspM=.8ea26f52-97d3-4115-a69e-5e43033035a6@github.com>

On Fri, 24 Nov 2023 19:47:06 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Backport of upstream renaming, preparation for follow-up backports. Leaves out the arm, ppc and riscv parts, which don't have the lightweight locking implementation in Lilliput-JDK17u.
> 
> Testing:
>  - [x] tier1 +UCOH aarch64
>  - [x] tier2 +UCOH aarch64
>  - [x] tier1 +UCOH x86_64
>  - [x] tier2 +UCOH x86_64

This pull request has been closed without being integrated.

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

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

From rkennke at amazon.de  Tue Feb 20 16:41:08 2024
From: rkennke at amazon.de (Kennke, Roman)
Date: Tue, 20 Feb 2024 16:41:08 +0000
Subject: Object to ObjectMonitor mapping using a HashTable to avoid
 displaced headers
In-Reply-To: <08E8A4A4-39FB-47C5-8138-CF7B12E56207@oracle.com>
References: <08E8A4A4-39FB-47C5-8138-CF7B12E56207@oracle.com>
Message-ID: <2F91BF4F-88E0-4C82-BB47-946D9C697BAC@amazon.de>

I have also set-up a non-Lilliput branch:

https://github.com/openjdk/lilliput/tree/omworld-jdk

I suggest to use that as the main branch for working on OMWorld stuff together. From there, we can and should merge to:

https://github.com/openjdk/lilliput/tree/omworld

Axel, could you merge-in the LW recursive work from latest mainline JDK?

Cheers,
Roman

> On Jan 31, 2024, at 4:41?PM, Axel Boldt-Christmas <axel.boldt-christmas at oracle.com> 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.
> 
> Hello, 
> 
> We at Oracle have been working on an effort to make the Klass* stable (and avoid displaced headers) with Lilliput?s 64-bit headers.
> 
> Some background to the issue. 
> With the introduction of Lilliput and 64-bit headers it creates a scenario where both the narrowKlass* and the ObjectMonitor* cannot fit inside the markWord at the same time. The current solution is to place the Klass* in a displaced header. LM_LIGHTWEIGHT was introduced to the JDK project partially because the same issue existed with LM_LEGACY and the BasicLock*. 
> 
> Having the Klass* not be displaced is something we see it as a pre-requisite for integrating Lilliput in the JDK.
> 
> As mentioned we have been working on a solution which uses an external hash table to map objects to their respective ObjectMonitor. With per thread caches to speed up retrieval in compiled code. The work has been done under the name OMWorld (ObjectMonitor World). The solution was initially based on LM_LIGHTWEIGHT but has been separated into a fourth locking mode.
> 
> It is time to open up the work to the broader community, and make it part of the Lilliput project. Creating a central base to work from inside the Lilliput project and repository. 
> 
> Here are the latest rebased branches both on the OpenJDK/JDK master and the OpenJDK/Lilliput master. 
> 
>> Latest OMWorld on Mainline: https://github.com/xmas92/jdk/tree/omworld-as-new-lm
>> Latest OMWorld on Lilliput: https://github.com/xmas92/lilliput/tree/omworld-as-new-lm-on-lilliput
> 
> Hopefully Roman can coordinate the creation of branches in the Lilliput repo which we all can work against.
> 
> Sincerely
> // Axel Boldt-Christmas




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  Wed Feb 21 11:40:07 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 21 Feb 2024 11:40:07 GMT
Subject: [master] RFR: Merge jdk:jdk-23+10 [v2]
In-Reply-To: <gXZeseW5S0meVKKrsqUaeB7epbUd1Z2_QxP_zrjcUug=.932837a7-6d23-4433-8f46-695c9d2d91c4@github.com>
References: <gXZeseW5S0meVKKrsqUaeB7epbUd1Z2_QxP_zrjcUug=.932837a7-6d23-4433-8f46-695c9d2d91c4@github.com>
Message-ID: <g-XKNZA1RSBKmNM1QFV_bE6BwNA6wbHl0cogx3m4tRo=.56ec1ee3-63a6-4e77-8591-6fddee3fd6e1@github.com>

> Let's merge latest tag jdk-23+10.

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

 - Merge tag 'jdk-23+10' into merge-jdk-23+10
   
   Added tag jdk-23+10 for changeset 8cb9b479
 - Merge jdk:jdk-23+8
 - 8319185: [Lilliput] Enable and fix vectorization tests
   
   Reviewed-by: shade
 - Merge jdk:jdk-23+7
 - 8324523: Lilliput: if +UseCOH, always use the archive's encoding base and shift
   
   Reviewed-by: rkennke
 - Merge jdk:jdk-23+1
 - Merge jdk:jdk-22+25
 - 8319724: [Lilliput] ParallelGC: Forwarded objects found during heap inspection
   
   Reviewed-by: shade
 - 8319524: [Lilliput] Only warn when compact headers are explicitly enabled
   
   Reviewed-by: shade
 - 8319135: [Lilliput] Fix objArrayOop gtest
   
   Reviewed-by: shade
 - ... and 109 more: https://git.openjdk.org/lilliput/compare/8cb9b479...afa0ab9e

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

Changes: https://git.openjdk.org/lilliput/pull/131/files
 Webrev: https://webrevs.openjdk.org/?repo=lilliput&pr=131&range=01
  Stats: 3179 lines in 158 files changed: 2602 ins; 213 del; 364 mod
  Patch: https://git.openjdk.org/lilliput/pull/131.diff
  Fetch: git fetch https://git.openjdk.org/lilliput.git pull/131/head:pull/131

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

From rkennke at openjdk.org  Wed Feb 21 11:40:07 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 21 Feb 2024 11:40:07 GMT
Subject: [master] RFR: Merge jdk:jdk-23+10
In-Reply-To: <gXZeseW5S0meVKKrsqUaeB7epbUd1Z2_QxP_zrjcUug=.932837a7-6d23-4433-8f46-695c9d2d91c4@github.com>
References: <gXZeseW5S0meVKKrsqUaeB7epbUd1Z2_QxP_zrjcUug=.932837a7-6d23-4433-8f46-695c9d2d91c4@github.com>
Message-ID: <WGohSNErgdfznLJ9KeGVqp-TS0nLXhbXRSMgavH1Pb4=.d3295916-0c73-439a-b9f0-9435640ababa@github.com>

On Tue, 20 Feb 2024 13:43:31 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Let's merge latest tag jdk-23+10.

GHA is clean, tier1 and tier2 with -CCP are clean, let's

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

PR Comment: https://git.openjdk.org/lilliput/pull/131#issuecomment-1956458395

From rkennke at openjdk.org  Wed Feb 21 11:40:08 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 21 Feb 2024 11:40:08 GMT
Subject: [master] Integrated: Merge jdk:jdk-23+10
In-Reply-To: <gXZeseW5S0meVKKrsqUaeB7epbUd1Z2_QxP_zrjcUug=.932837a7-6d23-4433-8f46-695c9d2d91c4@github.com>
References: <gXZeseW5S0meVKKrsqUaeB7epbUd1Z2_QxP_zrjcUug=.932837a7-6d23-4433-8f46-695c9d2d91c4@github.com>
Message-ID: <E9nTiSNJR9dPa5QgeH8GBJKGJqqHdMzrDE6X4FKYZJ8=.09523806-9153-46ee-a949-b1cbcc48e704@github.com>

On Tue, 20 Feb 2024 13:43:31 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Let's merge latest tag jdk-23+10.

This pull request has now been integrated.

Changeset: 2c2286a8
Author:    Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.org/lilliput/commit/2c2286a87d99edbbb42761772bf3c73aea5dde04
Stats:     28589 lines in 1026 files changed: 12689 ins; 9874 del; 6026 mod

Merge jdk:jdk-23+10

Reviewed-by: stuefe

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

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

From aboldtch at openjdk.org  Thu Feb 22 13:22:29 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 22 Feb 2024 13:22:29 GMT
Subject: [omworld-jdk] RFR: Merge 18cea823a173e1b8b48d276daeca67b2a5cf3584
Message-ID: <b8xSddS0OtUFxTpp5v8UhH7dRYiB7j8Rk65g7hLq8Z4=.cf3b5fe8-908a-4faa-b815-5e79bbc6564c@github.com>

Merge jdk:jdk-23+10 openjdk/lilliput at 8cb9b479c529c058aee50f83920db650b0c18045 into omworld-jdk as well as 18cea823a173e1b8b48d276daeca67b2a5cf3584 because it did not contain the aarch64 implementation of recursive lightweight.

Hopefully using PRs into the specific branches is a sufficient workflow for everyone.

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

Commit messages:
 - Merge commit '18cea823a173e1b8b48d276daeca67b2a5cf3584' into omworld-jdk
 - 8319801: Recursive lightweight locking: aarch64 implementation
 - 8316451: 6 java/lang/instrument/PremainClass tests ignore VM flags
 - 8323664: java/awt/font/JNICheck/FreeTypeScalerJNICheck.java still fails with JNI warning on some Windows configurations
 - 8325983: Build failure after JDK-8324580
 - 8322239: [macos] a11y : java.lang.NullPointerException is thrown when focus is moved on the JTabbedPane
 - 8322750: Test "api/java_awt/interactive/SystemTrayTests.html" failed because A blue ball icon is added outside of the system tray
 - 8324580: SIGFPE on THP initialization on kernels < 4.10
 - 8325906: Problemlist vmTestbase/vm/mlvm/meth/stress/compiler/deoptimize/Test.java#id1 until JDK-8320865 is fixed
 - 8324584: Optimize Symbol and char* handling in ClassLoader
 - ... and 207 more: https://git.openjdk.org/lilliput/compare/40dfe7a3...4356eaf7

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - omworld-jdk: https://webrevs.openjdk.org/?repo=lilliput&pr=133&range=00.0
 - 18cea823a173e1b8b48d276daeca67b2a5cf3584: https://webrevs.openjdk.org/?repo=lilliput&pr=133&range=00.1

Changes: https://git.openjdk.org/lilliput/pull/133/files
  Stats: 36931 lines in 1151 files changed: 18271 ins; 12078 del; 6582 mod
  Patch: https://git.openjdk.org/lilliput/pull/133.diff
  Fetch: git fetch https://git.openjdk.org/lilliput.git pull/133/head:pull/133

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

From rkennke at openjdk.org  Thu Feb 22 13:37:15 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 22 Feb 2024 13:37:15 GMT
Subject: [omworld-jdk] RFR: Merge 18cea823a173e1b8b48d276daeca67b2a5cf3584
In-Reply-To: <b8xSddS0OtUFxTpp5v8UhH7dRYiB7j8Rk65g7hLq8Z4=.cf3b5fe8-908a-4faa-b815-5e79bbc6564c@github.com>
References: <b8xSddS0OtUFxTpp5v8UhH7dRYiB7j8Rk65g7hLq8Z4=.cf3b5fe8-908a-4faa-b815-5e79bbc6564c@github.com>
Message-ID: <dVe-zzrV3lUJhsQLGNM9Drb6tOlHbTwe_FvIDKopQT4=.9238a469-5596-44b0-a53d-b9a097720730@github.com>

On Thu, 22 Feb 2024 08:58:45 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Merge jdk:jdk-23+10 openjdk/lilliput at 8cb9b479c529c058aee50f83920db650b0c18045 into omworld-jdk as well as 18cea823a173e1b8b48d276daeca67b2a5cf3584 because it did not contain the aarch64 implementation of recursive lightweight.
> 
> Hopefully using PRs into the specific branches is a sufficient workflow for everyone.

Yes workflow is ok. Thank you!
Merge PRs don't require extra approval - as soon as GHA and your own sanity testing are good, you can integrate.

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

PR Comment: https://git.openjdk.org/lilliput/pull/133#issuecomment-1959464581

From rkennke at amazon.de  Thu Feb 22 14:16:33 2024
From: rkennke at amazon.de (Kennke, Roman)
Date: Thu, 22 Feb 2024 14:16:33 +0000
Subject: Object to ObjectMonitor mapping using a HashTable to avoid
 displaced headers
In-Reply-To: <2F91BF4F-88E0-4C82-BB47-946D9C697BAC@amazon.de>
References: <08E8A4A4-39FB-47C5-8138-CF7B12E56207@oracle.com>
 <2F91BF4F-88E0-4C82-BB47-946D9C697BAC@amazon.de>
Message-ID: <B445CF40-A254-4794-8A2C-453BC1BB9DB0@amazon.de>

Hi there,

I now have a change vs the omworld branch (adding an NMT category for the OM table). How do we want to handle workflow in this branch? Should we do the usual post a PR, get a review, integrate thing? I think this would be useful to keep people aware of what?s happening.

Also, I have made some experiments with Renaissance?s philosophers benchmark, a brutal OM churner.

First observation without deflation, to get an idea how many OMs the workload allocates:

OMWorld (no deflation):
-           Synchronization (reserved=194421072, committed=194421072)
                            (malloc=194421072 #304595) (peak=194421176 #304596)
-           Object Monitors (reserved=3997340672, committed=3997340672)
                            (malloc=3997340672 #19217984) (at peak)
-                  OM World (reserved=324265096, committed=324265096)
                            (malloc=324265096 #19217988) (at peak)
Legacy (no deflation):
-           Synchronization (reserved=347673408, committed=347673408)
                            (malloc=347673408 #540453) (peak=347673512 #540454)
-           Object Monitors (reserved=7136973168, committed=7136973168)
                            (malloc=7136973168 #34312371) (at peak)

It looks like Legacy locking allocates ~34 million OMs, while OMWorld only 19 million. So far so good.

However, the picture changes with deflation turned on:

OMWorld:
-           Synchronization (reserved=92498024, committed=92498024)
                            (malloc=92498024 #146656) (peak=95537040 #151437)
-           Object Monitors (reserved=1750823568, committed=1750823568)
                            (malloc=1750823568 #8417421) (peak=1958719776 #9416922)
-                  OM World (reserved=151456088, committed=151456088)
                            (malloc=151456088 #8417425) (peak=152173976 #8462293)
Legacy:
-           Synchronization (reserved=27548072, committed=27548072)
                            (malloc=27548072 #46324) (peak=35675592 #59184)
-           Object Monitors (reserved=511949360, committed=511949360)
                            (malloc=511949360 #2461295) (peak=731033680 #3514585)

Here, OM usage peaks at 9.5 million with OMWorld while it?s only 3.5 million with legacy.

I don?t have an explanation, yet. Maybe deflation simply got slower and can?t keep up (or rather, can keep up even less than with legacy, because I believe deflation is overloaded either way). Maybe there are other interactions. Dunno yet.

Also, the NMT stats give a nice view on how much extra memory the table takes (less than 1/10th per OM) and how many extra OMs are allocated because of (presumably) deflation conflicts (11%).

If you have anything that you want me to look at, let me know. I?ll keep looking around and use the problem as a vehicle to familiarize myself with OMWorld.

Cheers,
Roman

> On Feb 20, 2024, at 5:41?PM, Kennke, Roman <rkennke at amazon.de> wrote:
> 
> I have also set-up a non-Lilliput branch:
> 
> https://github.com/openjdk/lilliput/tree/omworld-jdk
> 
> I suggest to use that as the main branch for working on OMWorld stuff together. From there, we can and should merge to:
> 
> https://github.com/openjdk/lilliput/tree/omworld
> 
> Axel, could you merge-in the LW recursive work from latest mainline JDK?
> 
> Cheers,
> Roman
> 
>> On Jan 31, 2024, at 4:41?PM, Axel Boldt-Christmas <axel.boldt-christmas at oracle.com> 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.
>> 
>> Hello, 
>> 
>> We at Oracle have been working on an effort to make the Klass* stable (and avoid displaced headers) with Lilliput?s 64-bit headers.
>> 
>> Some background to the issue. 
>> With the introduction of Lilliput and 64-bit headers it creates a scenario where both the narrowKlass* and the ObjectMonitor* cannot fit inside the markWord at the same time. The current solution is to place the Klass* in a displaced header. LM_LIGHTWEIGHT was introduced to the JDK project partially because the same issue existed with LM_LEGACY and the BasicLock*. 
>> 
>> Having the Klass* not be displaced is something we see it as a pre-requisite for integrating Lilliput in the JDK.
>> 
>> As mentioned we have been working on a solution which uses an external hash table to map objects to their respective ObjectMonitor. With per thread caches to speed up retrieval in compiled code. The work has been done under the name OMWorld (ObjectMonitor World). The solution was initially based on LM_LIGHTWEIGHT but has been separated into a fourth locking mode.
>> 
>> It is time to open up the work to the broader community, and make it part of the Lilliput project. Creating a central base to work from inside the Lilliput project and repository. 
>> 
>> Here are the latest rebased branches both on the OpenJDK/JDK master and the OpenJDK/Lilliput master. 
>> 
>>> Latest OMWorld on Mainline: https://github.com/xmas92/jdk/tree/omworld-as-new-lm
>>> Latest OMWorld on Lilliput: https://github.com/xmas92/lilliput/tree/omworld-as-new-lm-on-lilliput
>> 
>> Hopefully Roman can coordinate the creation of branches in the Lilliput repo which we all can work against.
>> 
>> Sincerely
>> // Axel Boldt-Christmas
> 
> 
> 
> 
> 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
> 
> 




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 Feb 22 18:18:54 2024
From: rkennke at amazon.de (Kennke, Roman)
Date: Thu, 22 Feb 2024 18:18:54 +0000
Subject: Result: New Lilliput Committer: Axel Boldt-Christmas
Message-ID: <45CE2729-5DA0-4AF1-A118-7A6B572ED1A3@amazon.de>

Voting for Axel Boldt-Christmas [1] is now closed.

Yes: 4
Veto: 0
Abstain: 0

According to the Bylaws definition of Lazy Consensus, this is
sufficient to approve the nomination.

Roman Kennke

[1] https://mail.openjdk.org/pipermail/lilliput-dev/2024-February/001309.html



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 Feb 22 18:32:33 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 22 Feb 2024 18:32:33 GMT
Subject: [master] RFR: Merge jdk:jdk-23+11
Message-ID: <QdB-vGDDKnTWvQ4DeVXfaR0lVy23ASCW1BhHDlMuhJ4=.c5d7ea85-439c-459b-82b7-eacd57c7c588@github.com>

Let's merge jdk-23+11. Most notably for Lilliput, this brings in LW recursive locking.

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

Commit messages:
 - Merge tag 'jdk-23+11' into merge-jdk-23+11
 - 8326461: tools/jlink/CheckExecutable.java fails as .debuginfo files are not executable
 - 8325870: Zap end padding bits for ArrayOops in non-release builds
 - 8326414: Serial: Inline SerialHeap::create_rem_set
 - 8323695: RenderPerf (2D) enhancements (23.12)
 - 8324243: Compilation failures in java.desktop module with gcc 14
 - 8325342: Remove unneeded exceptions in compare.sh
 - 8326158: Javadoc for java.time.DayOfWeek#minus(long)
 - 8326351: Update the Zlib version in open/src/java.base/share/legal/zlib.md to 1.3.1
 - 8326235: RISC-V: Size CodeCache for short calls encoding
 - ... and 83 more: https://git.openjdk.org/lilliput/compare/2c2286a8...d57c5993

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

Changes: https://git.openjdk.org/lilliput/pull/135/files
  Stats: 12283 lines in 327 files changed: 6367 ins; 3630 del; 2286 mod
  Patch: https://git.openjdk.org/lilliput/pull/135.diff
  Fetch: git fetch https://git.openjdk.org/lilliput.git pull/135/head:pull/135

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

From rkennke at openjdk.org  Thu Feb 22 18:38:21 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 22 Feb 2024 18:38:21 GMT
Subject: [master] RFR: 8323192: [Lilliput] Implement new Serial Full GC
 [v2]
In-Reply-To: <72okn4lfTqtpQHwooltBlDxcfAqf4Rb_tn4PZCpIJtM=.4a618b9e-f215-4a8c-8d16-47edbf462333@github.com>
References: <N1D2SMxREYg_uvUIXqBHaHF_9tnYT_5pENki_EET0Vw=.7fa8d136-9fc2-4067-8553-aa3d630c222c@github.com>
 <72okn4lfTqtpQHwooltBlDxcfAqf4Rb_tn4PZCpIJtM=.4a618b9e-f215-4a8c-8d16-47edbf462333@github.com>
Message-ID: <qiIhwOllbDHoQqIC6eptUredXsL5gcDPceeXuB6sra8=.5ef0fdc4-a61e-4e43-896f-e120ae0ff0ed@github.com>

On Fri, 12 Jan 2024 21:25:09 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This implements a compressor-style compacting full-GC for the Serial GC, which does not require storing any forwarding pointers in object headers.
>> 
>> For a description of the algorithm, see the text block at the beginning of serialCompressor.hpp.
>> 
>> Notice that the algorithm uses extra memory: 1/64th of the heap-size is allocated for the marking bitmap and another 1/64th of the heap-size is allocated for the block-offset-table. On the other hand, it does not use storage for preserved-marks table, which is very unpredictable (often it is quite small, but if a workload churns locks or mass-i-hashes objects, it can become pretty large).
>> 
>> Performance:
>> I tested performance using the following program, which exxagerates the performance impact of the algorithm. Real-world workloads would be more dominated by the copying.
>> 
>> 
>> public class Retain {
>>         static final int RETAINED = Integer.getInteger("retained", 10_000_000);
>>         static final int GCS      = Integer.getInteger("gcs", 100);
>>         static Object[] OBJECTS = new Object[RETAINED];
>> 
>>         public static void main(String... args) {
>>                 for (int t = 0; t < GCS; t++) {
>>                         for (int c = 0; c < RETAINED; c++) {
>>                                 OBJECTS[c] = new Object();
>>                         }
>>                         System.gc();
>>                 }
>>         }
>> }
>> 
>> 
>> 
>> The new algorithm can be tested by:
>> `java -XX:+UseSerialGC -XX:+UnlockExperimentalVMOptions -XX:+UseCompressorFullGC -Xlog:gc*:file=compressor.txt Retain
>> `
>> 
>> Average time for full-GCs on by machine:
>>  - baseline: 394.61ms
>>  - compressor: 411.61ms (+4.3%)
>> 
>> Testing:
>>  - [x] tier1 +UseSerialGC +UseFullGCCompressor x86_64
>>  - [x] tier1 +UseSerialGC +UseFullGCCompressor x86
>>  - [ ] tier1 +UseSerialGC +UseFullGCCompressor aarch64
>>  - [x] tier1 +UseSerialGC +UseCompactObjectHeaders x86_64
>>  - [x] tier1 +UseSerialGC +UseCompactObjectHeaders x86
>>  - [ ] tier1 +UseSerialGC +UseCompactObjectHeaders aarch64
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Don't use __builtin_popcount()

The proposed new full GC wouldn't work with compact identity hashcode, and is therefore not useful.

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

PR Comment: https://git.openjdk.org/lilliput/pull/122#issuecomment-1960034706

From rkennke at openjdk.org  Thu Feb 22 18:38:21 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 22 Feb 2024 18:38:21 GMT
Subject: [master] Withdrawn: 8323192: [Lilliput] Implement new Serial Full GC
In-Reply-To: <N1D2SMxREYg_uvUIXqBHaHF_9tnYT_5pENki_EET0Vw=.7fa8d136-9fc2-4067-8553-aa3d630c222c@github.com>
References: <N1D2SMxREYg_uvUIXqBHaHF_9tnYT_5pENki_EET0Vw=.7fa8d136-9fc2-4067-8553-aa3d630c222c@github.com>
Message-ID: <zbb5mjBlQIeKm1i8L1_jWYhnnTfWnBSOtAq27A-zxho=.328f979f-5707-4035-8205-3b7df6507146@github.com>

On Mon, 8 Jan 2024 16:42:03 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> This implements a compressor-style compacting full-GC for the Serial GC, which does not require storing any forwarding pointers in object headers.
> 
> For a description of the algorithm, see the text block at the beginning of serialCompressor.hpp.
> 
> Notice that the algorithm uses extra memory: 1/64th of the heap-size is allocated for the marking bitmap and another 1/64th of the heap-size is allocated for the block-offset-table. On the other hand, it does not use storage for preserved-marks table, which is very unpredictable (often it is quite small, but if a workload churns locks or mass-i-hashes objects, it can become pretty large).
> 
> Performance:
> I tested performance using the following program, which exxagerates the performance impact of the algorithm. Real-world workloads would be more dominated by the copying.
> 
> 
> public class Retain {
>         static final int RETAINED = Integer.getInteger("retained", 10_000_000);
>         static final int GCS      = Integer.getInteger("gcs", 100);
>         static Object[] OBJECTS = new Object[RETAINED];
> 
>         public static void main(String... args) {
>                 for (int t = 0; t < GCS; t++) {
>                         for (int c = 0; c < RETAINED; c++) {
>                                 OBJECTS[c] = new Object();
>                         }
>                         System.gc();
>                 }
>         }
> }
> 
> 
> 
> The new algorithm can be tested by:
> `java -XX:+UseSerialGC -XX:+UnlockExperimentalVMOptions -XX:+UseCompressorFullGC -Xlog:gc*:file=compressor.txt Retain
> `
> 
> Average time for full-GCs on by machine:
>  - baseline: 394.61ms
>  - compressor: 411.61ms (+4.3%)
> 
> Testing:
>  - [x] tier1 +UseSerialGC +UseFullGCCompressor x86_64
>  - [x] tier1 +UseSerialGC +UseFullGCCompressor x86
>  - [ ] tier1 +UseSerialGC +UseFullGCCompressor aarch64
>  - [x] tier1 +UseSerialGC +UseCompactObjectHeaders x86_64
>  - [x] tier1 +UseSerialGC +UseCompactObjectHeaders x86
>  - [ ] tier1 +UseSerialGC +UseCompactObjectHeaders aarch64

This pull request has been closed without being integrated.

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

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

From aboldtch at openjdk.org  Fri Feb 23 06:11:28 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 23 Feb 2024 06:11:28 GMT
Subject: [omworld-jdk] RFR: Merge 18cea823a173e1b8b48d276daeca67b2a5cf3584
 [v2]
In-Reply-To: <b8xSddS0OtUFxTpp5v8UhH7dRYiB7j8Rk65g7hLq8Z4=.cf3b5fe8-908a-4faa-b815-5e79bbc6564c@github.com>
References: <b8xSddS0OtUFxTpp5v8UhH7dRYiB7j8Rk65g7hLq8Z4=.cf3b5fe8-908a-4faa-b815-5e79bbc6564c@github.com>
Message-ID: <t0Uu5RSwPgGmvHc5rCKCz90a3UB7IjgXLpWqn9loavo=.9c6b7c61-c163-4c87-adf7-578cf6d4577b@github.com>

> Merge jdk:jdk-23+10 openjdk/lilliput at 8cb9b479c529c058aee50f83920db650b0c18045 into omworld-jdk as well as 18cea823a173e1b8b48d276daeca67b2a5cf3584 because it did not contain the aarch64 implementation of recursive lightweight.
> 
> Hopefully using PRs into the specific branches is a sufficient workflow for everyone.

Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - Merge commit '18cea823a173e1b8b48d276daeca67b2a5cf3584' into omworld-jdk
 - Merge remote-tracking branch 'upstream_lilliput/jdk' into omworld-jdk
 - Minor cleanups
 - Initial Split

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

Changes: https://git.openjdk.org/lilliput/pull/133/files
 Webrev: https://webrevs.openjdk.org/?repo=lilliput&pr=133&range=01
  Stats: 3291 lines in 64 files changed: 3130 ins; 16 del; 145 mod
  Patch: https://git.openjdk.org/lilliput/pull/133.diff
  Fetch: git fetch https://git.openjdk.org/lilliput.git pull/133/head:pull/133

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

From aboldtch at openjdk.org  Fri Feb 23 06:11:29 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 23 Feb 2024 06:11:29 GMT
Subject: [omworld-jdk] Integrated: Merge
 18cea823a173e1b8b48d276daeca67b2a5cf3584
In-Reply-To: <b8xSddS0OtUFxTpp5v8UhH7dRYiB7j8Rk65g7hLq8Z4=.cf3b5fe8-908a-4faa-b815-5e79bbc6564c@github.com>
References: <b8xSddS0OtUFxTpp5v8UhH7dRYiB7j8Rk65g7hLq8Z4=.cf3b5fe8-908a-4faa-b815-5e79bbc6564c@github.com>
Message-ID: <4dkdD1kimTix5y9N1WM4XGFvPYuo4cUtTbDq-xTX-ts=.2c2f3afb-9660-4024-8786-d4db89dd0109@github.com>

On Thu, 22 Feb 2024 08:58:45 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Merge jdk:jdk-23+10 openjdk/lilliput at 8cb9b479c529c058aee50f83920db650b0c18045 into omworld-jdk as well as 18cea823a173e1b8b48d276daeca67b2a5cf3584 because it did not contain the aarch64 implementation of recursive lightweight.
> 
> Hopefully using PRs into the specific branches is a sufficient workflow for everyone.

This pull request has now been integrated.

Changeset: c96cdd69
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
URL:       https://git.openjdk.org/lilliput/commit/c96cdd6982ad09bb3b3778a92482413d9045da9c
Stats:     36931 lines in 1151 files changed: 18271 ins; 12078 del; 6582 mod

Merge

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

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

From axel.boldt-christmas at oracle.com  Fri Feb 23 08:25:33 2024
From: axel.boldt-christmas at oracle.com (Axel Boldt-Christmas)
Date: Fri, 23 Feb 2024 08:25:33 +0000
Subject: [External] : Re: Object to ObjectMonitor mapping using a
 HashTable to avoid displaced headers
In-Reply-To: <B445CF40-A254-4794-8A2C-453BC1BB9DB0@amazon.de>
References: <08E8A4A4-39FB-47C5-8138-CF7B12E56207@oracle.com>
 <2F91BF4F-88E0-4C82-BB47-946D9C697BAC@amazon.de>
 <B445CF40-A254-4794-8A2C-453BC1BB9DB0@amazon.de>
Message-ID: <ADC04747-204E-49CE-B312-CFF981C6D340@oracle.com>

Hi,

> Should we do the usual post a PR, get a review, integrate thing?

Sounds good to me.

> I don?t have an explanation, yet.

Looks like a good benchmark for looking at both the hash table max size and the deflation heuristics. They are probably both playing a role in the difference you are seeing.

> If you have anything that you want me to look at, let me know. I?ll keep looking around and use the problem as a vehicle to familiarize myself with OMWorld.

I will try to get a task list out sometime next week. Not sure where to put it. Could just keep it in the omworld-jdk PR. And keep the OMWorld related discussions, development and results there.

And use the omworld PR  for results and development from testing specifically with CompactObjectHeaders.

Sincerely
// Axel

On 22 Feb 2024, at 15:16, Kennke, Roman <rkennke at amazon.de> wrote:

Renaissance?s philosophers

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/lilliput-dev/attachments/20240223/ba2b818c/attachment-0001.htm>

From rkennke at openjdk.org  Fri Feb 23 10:10:52 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 23 Feb 2024 10:10:52 GMT
Subject: [master] RFR: Merge jdk:jdk-23+11 [v2]
In-Reply-To: <QdB-vGDDKnTWvQ4DeVXfaR0lVy23ASCW1BhHDlMuhJ4=.c5d7ea85-439c-459b-82b7-eacd57c7c588@github.com>
References: <QdB-vGDDKnTWvQ4DeVXfaR0lVy23ASCW1BhHDlMuhJ4=.c5d7ea85-439c-459b-82b7-eacd57c7c588@github.com>
Message-ID: <CyZYHHlWLlAT6bwJWkcZrwHsO3l-_zN8AEDVoskyKgs=.8c55caae-d848-4e3a-9033-9a4e6eff02b6@github.com>

> Let's merge jdk-23+11. Most notably for Lilliput, this brings in LW recursive locking.

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

 - Merge tag 'jdk-23+11' into merge-jdk-23+11
   
   Added tag jdk-23+11 for changeset cc1e216e
 - Merge jdk:jdk-23+10
   
   Reviewed-by: stuefe
 - Merge jdk:jdk-23+8
 - 8319185: [Lilliput] Enable and fix vectorization tests
   
   Reviewed-by: shade
 - Merge jdk:jdk-23+7
 - 8324523: Lilliput: if +UseCOH, always use the archive's encoding base and shift
   
   Reviewed-by: rkennke
 - Merge jdk:jdk-23+1
 - Merge jdk:jdk-22+25
 - 8319724: [Lilliput] ParallelGC: Forwarded objects found during heap inspection
   
   Reviewed-by: shade
 - 8319524: [Lilliput] Only warn when compact headers are explicitly enabled
   
   Reviewed-by: shade
 - ... and 110 more: https://git.openjdk.org/lilliput/compare/cc1e216e...d57c5993

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

Changes: https://git.openjdk.org/lilliput/pull/135/files
 Webrev: https://webrevs.openjdk.org/?repo=lilliput&pr=135&range=01
  Stats: 3179 lines in 158 files changed: 2602 ins; 213 del; 364 mod
  Patch: https://git.openjdk.org/lilliput/pull/135.diff
  Fetch: git fetch https://git.openjdk.org/lilliput.git pull/135/head:pull/135

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

From rkennke at openjdk.org  Fri Feb 23 10:10:52 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 23 Feb 2024 10:10:52 GMT
Subject: [master] RFR: Merge jdk:jdk-23+11
In-Reply-To: <QdB-vGDDKnTWvQ4DeVXfaR0lVy23ASCW1BhHDlMuhJ4=.c5d7ea85-439c-459b-82b7-eacd57c7c588@github.com>
References: <QdB-vGDDKnTWvQ4DeVXfaR0lVy23ASCW1BhHDlMuhJ4=.c5d7ea85-439c-459b-82b7-eacd57c7c588@github.com>
Message-ID: <rui1znQ9nwAyJDXBnQq8Y4wxgOspqq3G_M3py-Hi_z4=.9eb62cc9-3807-40b4-96e7-f981f7028ce6@github.com>

On Thu, 22 Feb 2024 18:26:34 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Let's merge jdk-23+11. Most notably for Lilliput, this brings in LW recursive locking.

GHA is clean, local testing with +UseCOH was clean, let's

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

PR Comment: https://git.openjdk.org/lilliput/pull/135#issuecomment-1961045421

From rkennke at openjdk.org  Fri Feb 23 10:10:53 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 23 Feb 2024 10:10:53 GMT
Subject: [master] Integrated: Merge jdk:jdk-23+11
In-Reply-To: <QdB-vGDDKnTWvQ4DeVXfaR0lVy23ASCW1BhHDlMuhJ4=.c5d7ea85-439c-459b-82b7-eacd57c7c588@github.com>
References: <QdB-vGDDKnTWvQ4DeVXfaR0lVy23ASCW1BhHDlMuhJ4=.c5d7ea85-439c-459b-82b7-eacd57c7c588@github.com>
Message-ID: <Nn0zVbHLQ5GqZWjWTfZGpFWMbz29KkflAq2VAzvg-us=.41386b24-305f-4153-bc4f-1a6fcb13c829@github.com>

On Thu, 22 Feb 2024 18:26:34 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Let's merge jdk-23+11. Most notably for Lilliput, this brings in LW recursive locking.

This pull request has now been integrated.

Changeset: 763dcced
Author:    Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.org/lilliput/commit/763dcced229d8c23c95f3da11b83a2b2ee0080a8
Stats:     12283 lines in 327 files changed: 6367 ins; 3630 del; 2286 mod

Merge jdk:jdk-23+11

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

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

From aboldtch at openjdk.org  Fri Feb 23 10:40:33 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 23 Feb 2024 10:40:33 GMT
Subject: [omworld] RFR: Merge lilliput:omworld-jdk
Message-ID: <DE7IWicvSk4QF_dOm_m47wpCuk3VHH_sO_64XHyFPL0=.38280240-8051-499e-b74e-1b60f463f93f@github.com>

Merge  lilliput:omworld-jdk into omworld

Ran some x86_64 tier1 sanity tests with `+/-UseCOH` x `LockingMode=2,3`

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

Commit messages:
 - Merge remote-tracking branch 'upstream_lilliput/omworld-jdk' into omworld-merge
 - Merge
 - 8319801: Recursive lightweight locking: aarch64 implementation
 - 8316451: 6 java/lang/instrument/PremainClass tests ignore VM flags
 - 8323664: java/awt/font/JNICheck/FreeTypeScalerJNICheck.java still fails with JNI warning on some Windows configurations
 - 8325983: Build failure after JDK-8324580
 - 8322239: [macos] a11y : java.lang.NullPointerException is thrown when focus is moved on the JTabbedPane
 - 8322750: Test "api/java_awt/interactive/SystemTrayTests.html" failed because A blue ball icon is added outside of the system tray
 - 8324580: SIGFPE on THP initialization on kernels < 4.10
 - 8325906: Problemlist vmTestbase/vm/mlvm/meth/stress/compiler/deoptimize/Test.java#id1 until JDK-8320865 is fixed
 - ... and 187 more: https://git.openjdk.org/lilliput/compare/2b2cf5f6...12dffe0f

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

Changes: https://git.openjdk.org/lilliput/pull/136/files
  Stats: 31971 lines in 1061 files changed: 14279 ins; 11472 del; 6220 mod
  Patch: https://git.openjdk.org/lilliput/pull/136.diff
  Fetch: git fetch https://git.openjdk.org/lilliput.git pull/136/head:pull/136

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

From aboldtch at openjdk.org  Tue Feb 27 09:17:13 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 27 Feb 2024 09:17:13 GMT
Subject: [omworld-jdk] RFR: 8326761: Lilliput: OMWorld: Fix invalid markWord
 transition
Message-ID: <B7PcgYAyWyQkGN789rSM9XSH5cwfsBKz8OYZ3ZnaL-0=.76855c84-66ee-47f6-9a21-1c327130126d@github.com>

`PlaceholderSynchronizer::inflate_and_enter` currently performs an invalid transition of the markWord away from monitor. This may lead to an ABA issue.

This got opportunistically added at some point to avoid spinning on the deflation thread progress. The issue of guaranteed progress is not something that has been observed as an issue. If guaranteed progress turns out to be required there are solutions which do not have ABA issues, but it requires extra state in the already heavily contested markWord.

The yielding and spinning will be evaluated in a separate issue.

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

Commit messages:
 - Locking thread cannot help transition the markword

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

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

From aboldtch at openjdk.org  Tue Feb 27 09:23:12 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 27 Feb 2024 09:23:12 GMT
Subject: [omworld-jdk] RFR: 8326752: Lilliput: OMCache: Add cache lookup
 unrolling
Message-ID: <yZe1JsDX4I1YZxrkJmlp9McEkqOuVylqSPMXnkN_hJ4=.92753658-7c6a-4627-9194-275128d5dd4c@github.com>

Implement unrolling of OM cache lookups in C2 so experiments and an evaluation can be performed.

Adds `OMC2UnrollCacheLookup`, `OMC2UnrollCacheLookupLoopTail` and `OMC2UnrollCacheEntires` flags which can be tuned cache lookup unrolling in C2. 

`OMC2UnrollCacheLookup` will unroll up to `OMC2UnrollCacheEntires` (depending on `OMCacheSize`) and if `OMC2UnrollCacheLookupLoopTail` is set and entries are left the rest of the cache will be checked.

All of these flags are temporary to allow for evaluation of the cache lookup in C2 (size and unrolling). See issue JDK-8326759

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

Commit messages:
 - Add flags for unrolled cache lookup in C2

Changes: https://git.openjdk.org/lilliput/pull/139/files
 Webrev: https://webrevs.openjdk.org/?repo=lilliput&pr=139&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8326752
  Stats: 219 lines in 5 files changed: 142 ins; 58 del; 19 mod
  Patch: https://git.openjdk.org/lilliput/pull/139.diff
  Fetch: git fetch https://git.openjdk.org/lilliput.git pull/139/head:pull/139

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

From aboldtch at openjdk.org  Tue Feb 27 09:30:19 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 27 Feb 2024 09:30:19 GMT
Subject: [pr/139] RFR: 8326753 Lilliput: OMCache: Use AoS
Message-ID: <SiIF9Mi3MFoLtsHVrsiYLzXtD359FZt8RWCsjQ9_SRs=.f9465086-46b7-4acf-93db-54dfc94ca3d5@github.com>

The OMCache entries are currently laid out as a struct of arrays. For cache locality layout the entries as an array of structs.

Using structs for the entires also allows for some cleanups. 

Ran through GHA, still need to do some more extensive testing.

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

Depends on: https://git.openjdk.org/lilliput/pull/139

Commit messages:
 - Cleanup OMCache
 - OMCache Array of structs

Changes: https://git.openjdk.org/lilliput/pull/140/files
 Webrev: https://webrevs.openjdk.org/?repo=lilliput&pr=140&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8326753
  Stats: 49 lines in 4 files changed: 12 ins; 11 del; 26 mod
  Patch: https://git.openjdk.org/lilliput/pull/140.diff
  Fetch: git fetch https://git.openjdk.org/lilliput.git pull/140/head:pull/140

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

From rkennke at openjdk.org  Tue Feb 27 10:10:53 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 27 Feb 2024 10:10:53 GMT
Subject: [omworld-jdk] RFR: 8326761: Lilliput: OMWorld: Fix invalid
 markWord transition
In-Reply-To: <B7PcgYAyWyQkGN789rSM9XSH5cwfsBKz8OYZ3ZnaL-0=.76855c84-66ee-47f6-9a21-1c327130126d@github.com>
References: <B7PcgYAyWyQkGN789rSM9XSH5cwfsBKz8OYZ3ZnaL-0=.76855c84-66ee-47f6-9a21-1c327130126d@github.com>
Message-ID: <nmLieoW0FGPyGN4Q8Y8fuLP2tL6_tkQ71pNgnE7jFoM=.61f4970f-22b5-4d92-a41f-7f4fc6f4917a@github.com>

On Tue, 27 Feb 2024 09:11:29 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> `PlaceholderSynchronizer::inflate_and_enter` currently performs an invalid transition of the markWord away from monitor. This may lead to an ABA issue.
> 
> This got opportunistically added at some point to avoid spinning on the deflation thread progress. The issue of guaranteed progress is not something that has been observed as an issue. If guaranteed progress turns out to be required there are solutions which do not have ABA issues, but it requires extra state in the already heavily contested markWord.
> 
> The yielding and spinning will be evaluated in a separate issue.

Looks good! Thanks!

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

Marked as reviewed by rkennke (Reviewer).

PR Review: https://git.openjdk.org/lilliput/pull/138#pullrequestreview-1903074319

From rkennke at openjdk.org  Tue Feb 27 10:19:06 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 27 Feb 2024 10:19:06 GMT
Subject: [omworld-jdk] RFR: 8326752: Lilliput: OMCache: Add cache lookup
 unrolling
In-Reply-To: <yZe1JsDX4I1YZxrkJmlp9McEkqOuVylqSPMXnkN_hJ4=.92753658-7c6a-4627-9194-275128d5dd4c@github.com>
References: <yZe1JsDX4I1YZxrkJmlp9McEkqOuVylqSPMXnkN_hJ4=.92753658-7c6a-4627-9194-275128d5dd4c@github.com>
Message-ID: <3GzT_bLstFb2Nq7MWT-JsZ1EVjApr2w5IYRiAThqNtU=.978da05f-ec9f-459b-9f67-9d76a42d3d36@github.com>

On Tue, 27 Feb 2024 09:18:46 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Implement unrolling of OM cache lookups in C2 so experiments and an evaluation can be performed.
> 
> Adds `OMC2UnrollCacheLookup`, `OMC2UnrollCacheLookupLoopTail` and `OMC2UnrollCacheEntires` flags which can be tuned cache lookup unrolling in C2. 
> 
> `OMC2UnrollCacheLookup` will unroll up to `OMC2UnrollCacheEntires` (depending on `OMCacheSize`) and if `OMC2UnrollCacheLookupLoopTail` is set and entries are left the rest of the cache will be checked.
> 
> All of these flags are temporary to allow for evaluation of the cache lookup in C2 (size and unrolling). See issue JDK-8326759

Hi Axel, only some minor nits.

src/hotspot/share/runtime/globals.hpp line 1997:

> 1995:   product(bool, OMC2UnrollCacheLookupLoopTail, true, "")                    \
> 1996:                                                                             \
> 1997:   product(int, OMC2UnrollCacheEntires, 8, "")                               \

There is a typo: Entires -> Entries

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

Changes requested by rkennke (Reviewer).

PR Review: https://git.openjdk.org/lilliput/pull/139#pullrequestreview-1903083863
PR Review Comment: https://git.openjdk.org/lilliput/pull/139#discussion_r1503977665

From rkennke at openjdk.org  Tue Feb 27 10:19:06 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 27 Feb 2024 10:19:06 GMT
Subject: [omworld-jdk] RFR: 8326752: Lilliput: OMCache: Add cache lookup
 unrolling
In-Reply-To: <3GzT_bLstFb2Nq7MWT-JsZ1EVjApr2w5IYRiAThqNtU=.978da05f-ec9f-459b-9f67-9d76a42d3d36@github.com>
References: <yZe1JsDX4I1YZxrkJmlp9McEkqOuVylqSPMXnkN_hJ4=.92753658-7c6a-4627-9194-275128d5dd4c@github.com>
 <3GzT_bLstFb2Nq7MWT-JsZ1EVjApr2w5IYRiAThqNtU=.978da05f-ec9f-459b-9f67-9d76a42d3d36@github.com>
Message-ID: <BYLJthnrgciTaZRrtKc_KUQXJIP3AfUKXamr1--zrTA=.fbdc8ac4-541b-4680-a3ee-0db02fb051f5@github.com>

On Tue, 27 Feb 2024 10:11:48 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Implement unrolling of OM cache lookups in C2 so experiments and an evaluation can be performed.
>> 
>> Adds `OMC2UnrollCacheLookup`, `OMC2UnrollCacheLookupLoopTail` and `OMC2UnrollCacheEntires` flags which can be tuned cache lookup unrolling in C2. 
>> 
>> `OMC2UnrollCacheLookup` will unroll up to `OMC2UnrollCacheEntires` (depending on `OMCacheSize`) and if `OMC2UnrollCacheLookupLoopTail` is set and entries are left the rest of the cache will be checked.
>> 
>> All of these flags are temporary to allow for evaluation of the cache lookup in C2 (size and unrolling). See issue JDK-8326759
>
> src/hotspot/share/runtime/globals.hpp line 1997:
> 
>> 1995:   product(bool, OMC2UnrollCacheLookupLoopTail, true, "")                    \
>> 1996:                                                                             \
>> 1997:   product(int, OMC2UnrollCacheEntires, 8, "")                               \
> 
> There is a typo: Entires -> Entries

Also, could perhaps collapse some flags, e.g. treat OMC2UnrollCacheEntries==0 as OMC2UnrollCacheLookup==false, and get rid of the latter.

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

PR Review Comment: https://git.openjdk.org/lilliput/pull/139#discussion_r1503979220

From rkennke at openjdk.org  Tue Feb 27 10:33:56 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 27 Feb 2024 10:33:56 GMT
Subject: [pr/139] RFR: 8326753 Lilliput: OMCache: Use AoS
In-Reply-To: <SiIF9Mi3MFoLtsHVrsiYLzXtD359FZt8RWCsjQ9_SRs=.f9465086-46b7-4acf-93db-54dfc94ca3d5@github.com>
References: <SiIF9Mi3MFoLtsHVrsiYLzXtD359FZt8RWCsjQ9_SRs=.f9465086-46b7-4acf-93db-54dfc94ca3d5@github.com>
Message-ID: <K3CpjJuIkDzXbKTwsoe1DgRATjPAj0zlP9wW_BWGWME=.8144c2a4-dc66-4f53-99fa-50ffe6b1b913@github.com>

On Tue, 27 Feb 2024 09:25:13 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> The OMCache entries are currently laid out as a struct of arrays. For cache locality layout the entries as an array of structs.
> 
> Using structs for the entires also allows for some cleanups. 
> 
> Ran through GHA, still need to do some more extensive testing.

Looks good to me! Thank you!

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

Marked as reviewed by rkennke (Reviewer).

PR Review: https://git.openjdk.org/lilliput/pull/140#pullrequestreview-1903130810

From rkennke at openjdk.org  Tue Feb 27 10:45:15 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 27 Feb 2024 10:45:15 GMT
Subject: [omworld-jdk] RFR: 8326823: Lilliput: OMWorld: Separate NMT category
Message-ID: <rnbQe2fHqu22X6cS8HtktJ_jlJ59tmszV7vEJOusSAg=.15c2d911-2136-4027-a66e-9dced061fe9b@github.com>

Currently, the OMWorld table uses mtThread NMT category, which seems very wrong. We could instead add it into the mtObjectMonitor or mtSynchronizer categories, but I think it would be more useful to give the table its own category, for measuring overhead and also compare it to ObjectSynchronizer.

Example NMT output would look like:


-           Object Monitors (reserved=1750823568, committed=1750823568)
                           (malloc=1750823568 #8417421) (peak=1958719776 #9416922)
-                  OM World (reserved=151456088, committed=151456088)
                           (malloc=151456088 #8417425) (peak=152173976 #8462293)

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

Commit messages:
 - 8326823: Lilliput: OMWorld: Separate NMT category

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

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

From aboldtch at openjdk.org  Tue Feb 27 10:48:28 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 27 Feb 2024 10:48:28 GMT
Subject: [omworld-jdk] RFR: 8326752: Lilliput: OMCache: Add cache lookup
 unrolling [v2]
In-Reply-To: <yZe1JsDX4I1YZxrkJmlp9McEkqOuVylqSPMXnkN_hJ4=.92753658-7c6a-4627-9194-275128d5dd4c@github.com>
References: <yZe1JsDX4I1YZxrkJmlp9McEkqOuVylqSPMXnkN_hJ4=.92753658-7c6a-4627-9194-275128d5dd4c@github.com>
Message-ID: <pfYYWXFX_hJl-44WQinsLo6ab4BdDUWdDxr_tlrebFc=.826ff1b8-84cf-43a4-9e12-c343caabb75d@github.com>

> Implement unrolling of OM cache lookups in C2 so experiments and an evaluation can be performed.
> 
> Adds `OMC2UnrollCacheLookup`, `OMC2UnrollCacheLookupLoopTail` and `OMC2UnrollCacheEntires` flags which can be tuned cache lookup unrolling in C2. 
> 
> `OMC2UnrollCacheLookup` will unroll up to `OMC2UnrollCacheEntires` (depending on `OMCacheSize`) and if `OMC2UnrollCacheLookupLoopTail` is set and entries are left the rest of the cache will be checked.
> 
> All of these flags are temporary to allow for evaluation of the cache lookup in C2 (size and unrolling). See issue JDK-8326759

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

  Fix spelling

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

Changes:
  - all: https://git.openjdk.org/lilliput/pull/139/files
  - new: https://git.openjdk.org/lilliput/pull/139/files/8dab34e5..33cd0850

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

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

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

From aboldtch at openjdk.org  Tue Feb 27 10:48:28 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 27 Feb 2024 10:48:28 GMT
Subject: [omworld-jdk] RFR: 8326752: Lilliput: OMCache: Add cache lookup
 unrolling [v2]
In-Reply-To: <BYLJthnrgciTaZRrtKc_KUQXJIP3AfUKXamr1--zrTA=.fbdc8ac4-541b-4680-a3ee-0db02fb051f5@github.com>
References: <yZe1JsDX4I1YZxrkJmlp9McEkqOuVylqSPMXnkN_hJ4=.92753658-7c6a-4627-9194-275128d5dd4c@github.com>
 <3GzT_bLstFb2Nq7MWT-JsZ1EVjApr2w5IYRiAThqNtU=.978da05f-ec9f-459b-9f67-9d76a42d3d36@github.com>
 <BYLJthnrgciTaZRrtKc_KUQXJIP3AfUKXamr1--zrTA=.fbdc8ac4-541b-4680-a3ee-0db02fb051f5@github.com>
Message-ID: <AVkbBLRXPzgrOrhCMFKcEOROBQQKGdjqrCns4vl1A_g=.53e6943f-de29-4942-bdc4-1901ea7a3a01@github.com>

On Tue, 27 Feb 2024 10:12:53 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> src/hotspot/share/runtime/globals.hpp line 1997:
>> 
>>> 1995:   product(bool, OMC2UnrollCacheLookupLoopTail, true, "")                    \
>>> 1996:                                                                             \
>>> 1997:   product(int, OMC2UnrollCacheEntires, 8, "")                               \
>> 
>> There is a typo: Entires -> Entries
>
> Also, could perhaps collapse some flags, e.g. treat OMC2UnrollCacheEntries==0 as OMC2UnrollCacheLookup==false, and get rid of the latter.

It was intentional, because I like`+` vs `-` switching. But maybe unifying them is better so someone does not get confused if they see `-XX:-OMC2UnrollCache -XX:OMC2UnrollCacheEntries=4` as an argument. 
I'll change it.

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

PR Review Comment: https://git.openjdk.org/lilliput/pull/139#discussion_r1504024910

From aboldtch at openjdk.org  Tue Feb 27 10:50:02 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 27 Feb 2024 10:50:02 GMT
Subject: [omworld-jdk] Integrated: 8326761: Lilliput: OMWorld: Fix invalid
 markWord transition
In-Reply-To: <B7PcgYAyWyQkGN789rSM9XSH5cwfsBKz8OYZ3ZnaL-0=.76855c84-66ee-47f6-9a21-1c327130126d@github.com>
References: <B7PcgYAyWyQkGN789rSM9XSH5cwfsBKz8OYZ3ZnaL-0=.76855c84-66ee-47f6-9a21-1c327130126d@github.com>
Message-ID: <5uYNpY0DPfG1_VFrJ7sFOP4J3N3Nl3XERpyn1U20ILA=.be5d1995-d855-4143-8e99-d342196e74fc@github.com>

On Tue, 27 Feb 2024 09:11:29 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> `PlaceholderSynchronizer::inflate_and_enter` currently performs an invalid transition of the markWord away from monitor. This may lead to an ABA issue.
> 
> This got opportunistically added at some point to avoid spinning on the deflation thread progress. The issue of guaranteed progress is not something that has been observed as an issue. If guaranteed progress turns out to be required there are solutions which do not have ABA issues, but it requires extra state in the already heavily contested markWord.
> 
> The yielding and spinning will be evaluated in a separate issue.

This pull request has now been integrated.

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

8326761: Lilliput: OMWorld: Fix invalid markWord transition

Reviewed-by: rkennke

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

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

From aboldtch at openjdk.org  Tue Feb 27 10:52:57 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 27 Feb 2024 10:52:57 GMT
Subject: [omworld] RFR: Merge lilliput:omworld-jdk
In-Reply-To: <DE7IWicvSk4QF_dOm_m47wpCuk3VHH_sO_64XHyFPL0=.38280240-8051-499e-b74e-1b60f463f93f@github.com>
References: <DE7IWicvSk4QF_dOm_m47wpCuk3VHH_sO_64XHyFPL0=.38280240-8051-499e-b74e-1b60f463f93f@github.com>
Message-ID: <9ThwrcP5VLHeGovzuc9cRAg7DleasEzVWX0_ncavOe8=.fcd73b0b-c79e-4a9c-b371-1a18398509d7@github.com>

On Fri, 23 Feb 2024 10:19:33 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Merge  lilliput:omworld-jdk into omworld
> 
> Ran some x86_64 tier1 sanity tests with `+/-UseCOH` x `LockingMode=2,3`

As I am now in the census maybe I can sponsor myself.

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

PR Comment: https://git.openjdk.org/lilliput/pull/136#issuecomment-1966281598

From rkennke at openjdk.org  Tue Feb 27 11:40:56 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 27 Feb 2024 11:40:56 GMT
Subject: [omworld] RFR: Merge lilliput:omworld-jdk
In-Reply-To: <DE7IWicvSk4QF_dOm_m47wpCuk3VHH_sO_64XHyFPL0=.38280240-8051-499e-b74e-1b60f463f93f@github.com>
References: <DE7IWicvSk4QF_dOm_m47wpCuk3VHH_sO_64XHyFPL0=.38280240-8051-499e-b74e-1b60f463f93f@github.com>
Message-ID: <m56qToL1NbT93gawbXFV0VBrCRcScwdBFR88cVpZDtA=.131d39c2-708a-447c-9767-e5f4d6cb01a0@github.com>

On Fri, 23 Feb 2024 10:19:33 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Merge  lilliput:omworld-jdk into omworld
> 
> Ran some x86_64 tier1 sanity tests with `+/-UseCOH` x `LockingMode=2,3`

Simply integrate it as usual.

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

PR Comment: https://git.openjdk.org/lilliput/pull/136#issuecomment-1966358079

From aboldtch at openjdk.org  Tue Feb 27 12:34:38 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 27 Feb 2024 12:34:38 GMT
Subject: [omworld] RFR: Merge lilliput:omworld-jdk [v2]
In-Reply-To: <DE7IWicvSk4QF_dOm_m47wpCuk3VHH_sO_64XHyFPL0=.38280240-8051-499e-b74e-1b60f463f93f@github.com>
References: <DE7IWicvSk4QF_dOm_m47wpCuk3VHH_sO_64XHyFPL0=.38280240-8051-499e-b74e-1b60f463f93f@github.com>
Message-ID: <rxsGaNqEKEOwFEnh9wEOX9AVzu_JsjIs2SZsUTgHVb8=.8eb1889d-9402-4261-ad9b-8fbbafd0ff4e@github.com>

> Merge  lilliput:omworld-jdk into omworld
> 
> Ran some x86_64 tier1 sanity tests with `+/-UseCOH` x `LockingMode=2,3`

Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 123 commits:

 - Merge remote-tracking branch 'upstream_lilliput/omworld-jdk' into omworld-merge
 - Merge branch 'master' into omworld
 - Merge jdk:jdk-23+8
 - 8319185: [Lilliput] Enable and fix vectorization tests
   
   Reviewed-by: shade
 - LM_PLACEHOLDER Lilliput fix
 - Minor cleanups
 - Initial Split
 - Merge jdk:jdk-23+7
 - 8324523: Lilliput: if +UseCOH, always use the archive's encoding base and shift
   
   Reviewed-by: rkennke
 - Merge jdk:jdk-23+1
 - ... and 113 more: https://git.openjdk.org/lilliput/compare/c96cdd69...12dffe0f

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

Changes: https://git.openjdk.org/lilliput/pull/136/files
 Webrev: https://webrevs.openjdk.org/?repo=lilliput&pr=136&range=01
  Stats: 3201 lines in 158 files changed: 2624 ins; 213 del; 364 mod
  Patch: https://git.openjdk.org/lilliput/pull/136.diff
  Fetch: git fetch https://git.openjdk.org/lilliput.git pull/136/head:pull/136

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

From aboldtch at openjdk.org  Tue Feb 27 12:34:39 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 27 Feb 2024 12:34:39 GMT
Subject: [omworld] Integrated: Merge lilliput:omworld-jdk
In-Reply-To: <DE7IWicvSk4QF_dOm_m47wpCuk3VHH_sO_64XHyFPL0=.38280240-8051-499e-b74e-1b60f463f93f@github.com>
References: <DE7IWicvSk4QF_dOm_m47wpCuk3VHH_sO_64XHyFPL0=.38280240-8051-499e-b74e-1b60f463f93f@github.com>
Message-ID: <dWDj-sqlnQhhZpfrjQfSl5F63JE_Vg7A2gPlb7iyyAw=.03968ce5-9041-4401-a1bc-872931c9d7be@github.com>

On Fri, 23 Feb 2024 10:19:33 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Merge  lilliput:omworld-jdk into omworld
> 
> Ran some x86_64 tier1 sanity tests with `+/-UseCOH` x `LockingMode=2,3`

This pull request has now been integrated.

Changeset: 7c8acdcc
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
URL:       https://git.openjdk.org/lilliput/commit/7c8acdccd57c0cd83f8b9a5c500ba3460b0eb500
Stats:     31971 lines in 1061 files changed: 14279 ins; 11472 del; 6220 mod

Merge lilliput:omworld-jdk

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

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

From aboldtch at openjdk.org  Tue Feb 27 12:43:04 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 27 Feb 2024 12:43:04 GMT
Subject: [omworld-jdk] RFR: 8326752: Lilliput: OMCache: Add cache lookup
 unrolling [v3]
In-Reply-To: <yZe1JsDX4I1YZxrkJmlp9McEkqOuVylqSPMXnkN_hJ4=.92753658-7c6a-4627-9194-275128d5dd4c@github.com>
References: <yZe1JsDX4I1YZxrkJmlp9McEkqOuVylqSPMXnkN_hJ4=.92753658-7c6a-4627-9194-275128d5dd4c@github.com>
Message-ID: <igJBreXNJfwy7NJayhpBBI2hb9Y7WFvCVcXOOOLMq6k=.998209b5-cf1b-4981-b2db-f4274d03433d@github.com>

> Implement unrolling of OM cache lookups in C2 so experiments and an evaluation can be performed.
> 
> Adds `OMC2UnrollCacheLookup`, `OMC2UnrollCacheLookupLoopTail` and `OMC2UnrollCacheEntires` flags which can be tuned cache lookup unrolling in C2. 
> 
> `OMC2UnrollCacheLookup` will unroll up to `OMC2UnrollCacheEntires` (depending on `OMCacheSize`) and if `OMC2UnrollCacheLookupLoopTail` is set and entries are left the rest of the cache will be checked.
> 
> All of these flags are temporary to allow for evaluation of the cache lookup in C2 (size and unrolling). See issue JDK-8326759

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

  Remove OMC2UnrollCacheLookup flag

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

Changes:
  - all: https://git.openjdk.org/lilliput/pull/139/files
  - new: https://git.openjdk.org/lilliput/pull/139/files/33cd0850..99147959

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

  Stats: 24 lines in 3 files changed: 2 ins; 6 del; 16 mod
  Patch: https://git.openjdk.org/lilliput/pull/139.diff
  Fetch: git fetch https://git.openjdk.org/lilliput.git pull/139/head:pull/139

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

From rkennke at openjdk.org  Tue Feb 27 13:04:53 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 27 Feb 2024 13:04:53 GMT
Subject: [omworld-jdk] RFR: 8326752: Lilliput: OMCache: Add cache lookup
 unrolling [v3]
In-Reply-To: <igJBreXNJfwy7NJayhpBBI2hb9Y7WFvCVcXOOOLMq6k=.998209b5-cf1b-4981-b2db-f4274d03433d@github.com>
References: <yZe1JsDX4I1YZxrkJmlp9McEkqOuVylqSPMXnkN_hJ4=.92753658-7c6a-4627-9194-275128d5dd4c@github.com>
 <igJBreXNJfwy7NJayhpBBI2hb9Y7WFvCVcXOOOLMq6k=.998209b5-cf1b-4981-b2db-f4274d03433d@github.com>
Message-ID: <xHFg4mmqjKaXisHO5uaUjgZTQ8VfFFuHQVkhW1_3uOE=.f5273ba9-340e-4382-9049-c832f6e37a1d@github.com>

On Tue, 27 Feb 2024 12:43:04 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Implement unrolling of OM cache lookups in C2 so experiments and an evaluation can be performed.
>> 
>> Adds `OMC2UnrollCacheLookup`, `OMC2UnrollCacheLookupLoopTail` and `OMC2UnrollCacheEntires` flags which can be tuned cache lookup unrolling in C2. 
>> 
>> `OMC2UnrollCacheLookup` will unroll up to `OMC2UnrollCacheEntires` (depending on `OMCacheSize`) and if `OMC2UnrollCacheLookupLoopTail` is set and entries are left the rest of the cache will be checked.
>> 
>> All of these flags are temporary to allow for evaluation of the cache lookup in C2 (size and unrolling). See issue JDK-8326759
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove OMC2UnrollCacheLookup flag

Looks good! Thank you!

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

Marked as reviewed by rkennke (Reviewer).

PR Review: https://git.openjdk.org/lilliput/pull/139#pullrequestreview-1903440661

From aboldtch at openjdk.org  Tue Feb 27 14:47:01 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 27 Feb 2024 14:47:01 GMT
Subject: [omworld-jdk] Integrated: 8326752: Lilliput: OMCache: Add cache lookup
 unrolling
In-Reply-To: <yZe1JsDX4I1YZxrkJmlp9McEkqOuVylqSPMXnkN_hJ4=.92753658-7c6a-4627-9194-275128d5dd4c@github.com>
References: <yZe1JsDX4I1YZxrkJmlp9McEkqOuVylqSPMXnkN_hJ4=.92753658-7c6a-4627-9194-275128d5dd4c@github.com>
Message-ID: <IVXb7h7bGV5fO-WSx0iGwXpEd0uYGch-x0lTz1jZGlg=.93c02521-0da1-41b0-80ff-29aedb296df9@github.com>

On Tue, 27 Feb 2024 09:18:46 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Implement unrolling of OM cache lookups in C2 so experiments and an evaluation can be performed.
> 
> Adds `OMC2UnrollCacheLookup`, `OMC2UnrollCacheLookupLoopTail` and `OMC2UnrollCacheEntires` flags which can be tuned cache lookup unrolling in C2. 
> 
> `OMC2UnrollCacheLookup` will unroll up to `OMC2UnrollCacheEntires` (depending on `OMCacheSize`) and if `OMC2UnrollCacheLookupLoopTail` is set and entries are left the rest of the cache will be checked.
> 
> All of these flags are temporary to allow for evaluation of the cache lookup in C2 (size and unrolling). See issue JDK-8326759

This pull request has now been integrated.

Changeset: 28bb8ddc
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
URL:       https://git.openjdk.org/lilliput/commit/28bb8ddc6418b8b4146dcae4a1686f4a0285c4ac
Stats:     215 lines in 5 files changed: 140 ins; 60 del; 15 mod

8326752: Lilliput: OMCache: Add cache lookup unrolling

Reviewed-by: rkennke

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

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

From aboldtch at openjdk.org  Tue Feb 27 14:50:25 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 27 Feb 2024 14:50:25 GMT
Subject: [omworld-jdk] RFR: 8326753 Lilliput: OMCache: Use AoS [v2]
In-Reply-To: <SiIF9Mi3MFoLtsHVrsiYLzXtD359FZt8RWCsjQ9_SRs=.f9465086-46b7-4acf-93db-54dfc94ca3d5@github.com>
References: <SiIF9Mi3MFoLtsHVrsiYLzXtD359FZt8RWCsjQ9_SRs=.f9465086-46b7-4acf-93db-54dfc94ca3d5@github.com>
Message-ID: <EYGzXf8Ac5jipiLDwbPu0F5WeiABsHKCF-H9NhmYOPE=.c790046a-0a3a-476f-8755-85c2a149ece7@github.com>

> The OMCache entries are currently laid out as a struct of arrays. For cache locality layout the entries as an array of structs.
> 
> Using structs for the entires also allows for some cleanups. 
> 
> Ran through GHA, still need to do some more extensive testing.

Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase.

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

Changes:
  - all: https://git.openjdk.org/lilliput/pull/140/files
  - new: https://git.openjdk.org/lilliput/pull/140/files/93fe1c28..93fe1c28

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

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

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

From aboldtch at openjdk.org  Tue Feb 27 14:58:52 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 27 Feb 2024 14:58:52 GMT
Subject: [omworld-jdk] RFR: 8326823: Lilliput: OMWorld: Separate NMT
 category
In-Reply-To: <rnbQe2fHqu22X6cS8HtktJ_jlJ59tmszV7vEJOusSAg=.15c2d911-2136-4027-a66e-9dced061fe9b@github.com>
References: <rnbQe2fHqu22X6cS8HtktJ_jlJ59tmszV7vEJOusSAg=.15c2d911-2136-4027-a66e-9dced061fe9b@github.com>
Message-ID: <KgT3yWUaJ7pZOyQzCPeedgb9fVSIZJdVdAosVpLnEeU=.63e84380-ed44-4b78-b06e-9c3487428039@github.com>

On Tue, 27 Feb 2024 10:39:54 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Currently, the OMWorld table uses mtThread NMT category, which seems very wrong. We could instead add it into the mtObjectMonitor or mtSynchronizer categories, but I think it would be more useful to give the table its own category, for measuring overhead and also compare it to ObjectSynchronizer.
> 
> Example NMT output would look like:
> 
> 
> -           Object Monitors (reserved=1750823568, committed=1750823568)
>                            (malloc=1750823568 #8417421) (peak=1958719776 #9416922)
> -                  OM World (reserved=151456088, committed=151456088)
>                            (malloc=151456088 #8417425) (peak=152173976 #8462293)

Looks good.

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

Marked as reviewed by aboldtch (Reviewer).

PR Review: https://git.openjdk.org/lilliput/pull/141#pullrequestreview-1903756419

From rkennke at openjdk.org  Tue Feb 27 19:06:02 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 27 Feb 2024 19:06:02 GMT
Subject: [omworld-jdk] Integrated: 8326823: Lilliput: OMWorld: Separate NMT
 category
In-Reply-To: <rnbQe2fHqu22X6cS8HtktJ_jlJ59tmszV7vEJOusSAg=.15c2d911-2136-4027-a66e-9dced061fe9b@github.com>
References: <rnbQe2fHqu22X6cS8HtktJ_jlJ59tmszV7vEJOusSAg=.15c2d911-2136-4027-a66e-9dced061fe9b@github.com>
Message-ID: <tRktYE9QCukYVsoS3kQpZ0y7ytym_rJMCimW8dM_sms=.a7568aa6-45ab-4ea2-bc7c-0f2ba77c5394@github.com>

On Tue, 27 Feb 2024 10:39:54 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Currently, the OMWorld table uses mtThread NMT category, which seems very wrong. We could instead add it into the mtObjectMonitor or mtSynchronizer categories, but I think it would be more useful to give the table its own category, for measuring overhead and also compare it to ObjectSynchronizer.
> 
> Example NMT output would look like:
> 
> 
> -           Object Monitors (reserved=1750823568, committed=1750823568)
>                            (malloc=1750823568 #8417421) (peak=1958719776 #9416922)
> -                  OM World (reserved=151456088, committed=151456088)
>                            (malloc=151456088 #8417425) (peak=152173976 #8462293)

This pull request has now been integrated.

Changeset: 9c09cda0
Author:    Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.org/lilliput/commit/9c09cda04e9bbdd0611e0ff567421f68d31821d7
Stats:     4 lines in 2 files changed: 1 ins; 0 del; 3 mod

8326823: Lilliput: OMWorld: Separate NMT category

Reviewed-by: aboldtch

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

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

From aboldtch at openjdk.org  Wed Feb 28 06:17:12 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 28 Feb 2024 06:17:12 GMT
Subject: [omworld-jdk] RFR: 8326753 Lilliput: OMCache: Use AoS [v3]
In-Reply-To: <SiIF9Mi3MFoLtsHVrsiYLzXtD359FZt8RWCsjQ9_SRs=.f9465086-46b7-4acf-93db-54dfc94ca3d5@github.com>
References: <SiIF9Mi3MFoLtsHVrsiYLzXtD359FZt8RWCsjQ9_SRs=.f9465086-46b7-4acf-93db-54dfc94ca3d5@github.com>
Message-ID: <fpYXSahV0HmUQyTt94KKrlPQ-VNSUFTXSJZqycg2KC8=.db5e94a3-aab3-44b1-91ed-bf2ffb60ad01@github.com>

> The OMCache entries are currently laid out as a struct of arrays. For cache locality layout the entries as an array of structs.
> 
> Using structs for the entires also allows for some cleanups. 
> 
> Ran through GHA, still need to do some more extensive testing.

Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - Merge remote-tracking branch 'upstream_lilliput/omworld-jdk' into omcache-aos
 - Cleanup OMCache
 - OMCache Array of structs
 - Add flags for unrolled cache lookup in C2

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

Changes: https://git.openjdk.org/lilliput/pull/140/files
 Webrev: https://webrevs.openjdk.org/?repo=lilliput&pr=140&range=02
  Stats: 49 lines in 4 files changed: 12 ins; 11 del; 26 mod
  Patch: https://git.openjdk.org/lilliput/pull/140.diff
  Fetch: git fetch https://git.openjdk.org/lilliput.git pull/140/head:pull/140

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

From aboldtch at openjdk.org  Wed Feb 28 13:25:04 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 28 Feb 2024 13:25:04 GMT
Subject: [omworld-jdk] Integrated: 8326753 Lilliput: OMCache: Use AoS
In-Reply-To: <SiIF9Mi3MFoLtsHVrsiYLzXtD359FZt8RWCsjQ9_SRs=.f9465086-46b7-4acf-93db-54dfc94ca3d5@github.com>
References: <SiIF9Mi3MFoLtsHVrsiYLzXtD359FZt8RWCsjQ9_SRs=.f9465086-46b7-4acf-93db-54dfc94ca3d5@github.com>
Message-ID: <JTHHXJa_mRufgnN5UdjwAckVzmYI7AW4iSTjS3mP9Sg=.a86aea1c-8ca5-4836-a344-22a875334d8b@github.com>

On Tue, 27 Feb 2024 09:25:13 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> The OMCache entries are currently laid out as a struct of arrays. For cache locality layout the entries as an array of structs.
> 
> Using structs for the entires also allows for some cleanups. 
> 
> Ran through GHA, still need to do some more extensive testing.

This pull request has now been integrated.

Changeset: 3aadead0
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
URL:       https://git.openjdk.org/lilliput/commit/3aadead03aa90c4c4fec4c180b88fe4d9463043f
Stats:     49 lines in 4 files changed: 12 ins; 11 del; 26 mod

8326753: Lilliput: OMCache: Use AoS

Reviewed-by: rkennke

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

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