Implement VM/GC support for JIT constant references by nbhuiyan · Pull Request #23257 · eclipse-openj9/openj9

nbhuiyan · 2026-01-26T18:51:42Z

This PR contributes @jdmpapin's work implementing the necessary VM and GC support for const refs. Please refer to the commit message for a detailed description.

Issue: #16616

nbhuiyan · 2026-01-26T18:56:11Z

@babsingh / @TobiAjila and @dmitripivkine / @amicic Requesting review of the VM and GC changes.

@0xdaryl @vijaysun-omr @hzongaro FYI

dmitripivkine

GC part of the change looks good to me

runtime/gc_structs/ConstRefsIterator.hpp

babsingh · 2026-01-29T18:32:53Z

runtime/gc_structs/ClassIterator.hpp

 #endif /* defined(J9VM_OPT_OPENJDK_METHODHANDLE) */
 		, _valueTypesIterator(clazz)
+#if defined(J9VM_OPT_OPENJDK_METHODHANDLE)
+		, _constRefsIterator(clazz)


This can be moved after line 100 in the existing ifdef.

The reason for this and other cases of multiple J9VM_OPT_OPENJDK_METHODHANDLE ifdef blocks is due to -Werror,-Wreorder-ctor used for GC build phase. This will require some reordering of member declarations as well.

babsingh · 2026-01-29T18:40:03Z

runtime/gc_structs/ClassIterator.hpp

 	GC_ClassStaticsIterator _classStaticsIterator;
 	GC_ConstantPoolObjectSlotIterator _constantPoolObjectSlotIterator;
 	GC_CallSitesIterator _callSitesIterator;
 	GC_MethodTypesIterator _methodTypesIterator;


Unrelated to this PR. Probably an oversight, but this and all other associated code can be placed under the J9VM_OPT_OPENJDK_METHODHANDLE ifdef.

These fields are required in non-OpenJDK MH cases as well. In the case of _methodTypesIterator, there are two ways it is initialized based on the MH implementation:

OpenJDK MH:

openj9/runtime/gc_structs/ClassIterator.hpp

Line 93 in 9ee53e9

, _methodTypesIterator(clazz->romClass->invokeCacheCount, clazz->invokeCache)

OpenJ9 MH:

openj9/runtime/gc_structs/ClassIterator.hpp

Line 95 in 9ee53e9

, _methodTypesIterator(clazz->romClass->methodTypeCount, clazz->methodTypes)

babsingh · 2026-01-29T18:41:13Z

runtime/gc_structs/ClassIterator.hpp

 #endif /* defined(J9VM_OPT_OPENJDK_METHODHANDLE) */
 		, _valueTypesIterator(clazz)
+#if defined(J9VM_OPT_OPENJDK_METHODHANDLE)
+		, _constRefsIterator(clazz)


This can be moved after line 110 in the existing ifdef.

Same explanation #23257 (comment)

Please let me know if I should proceed with changing the member declaration order as necessary to be able to have a single OpenJDK MH ifdef block.

runtime/oti/j9nonbuilder.h

runtime/vm/jvminit.c

runtime/vm/vmthinit.c

runtime/vm/jvminit.c

Constant references will be analyzed by the JIT compiler at compile time and each one will be attributed to an owning class. The slots will be embedded in the JIT body for which they're needed. A run of one or more slots owned by the same class will be described by a J9ConstRefArray, which will be attached to the class in a circular doubly-linked list (J9Class::constRefArrays, J9ConstRefArray::{prev,next}InClass). Additionally, every J9ConstRefArray for a particular JIT body will be part of a circular singly-linked list for the JIT body metadata (J9JITExceptionTable::constRefArrays, J9ConstRefArray::nextInJITBody) so that they can be destroyed in case of code cache reclamation. There is a single global mutex that protects the J9ConstRefArray pool and all of the linked list structures. From a GC perspective, constant references will appear to be additional static slots in the class that owns them. This commit consists only of the changes needed outside of the JIT compiler. Some context about the JIT part that is coming separately: - At the end of a compilation that needs constant references, the JIT compiler will allocate the needed J9ConstRefArray instances, and add them into the appropriate lists. - J9Class::constRefArrays will point to a sentinel entry rather than to an entry that contains actual constant references. This is done to simplify deletion and to avoid needing to add a pointer from each J9ConstRefArray directly to its owning J9Class. The sentinel will be allocated by the JIT compiler. - To reduce overhead and simplify scanning, the GC scans the constant references owned by a class without acquiring the mutex, so it will be possible for the GC to be scanning the list for a class while the JIT is adding to it. The JIT will use a memory barrier to make the addition atomic w.r.t. any concurrent GC scanning. - The JIT will initialize the slots using a write barrier so that the GC can respond appropriately to the new slots. For example, the GC may need to re-scan the class if the slots were initialized during concurrent marking. As another example, in gencon the GC may need to add the class object to the remembered set if any of the slots happens to point to an object that's still in the nursery. - The JIT will avoid calling the write barrier before the GC has been made aware of the slots, i.e. before the J9ConstRefArray has been added to the per-class list. So the full sequence for initializing constant references on the JIT side will be as follows (though note that step 4 is atomic w.r.t. GC scanning, as mentioned above): 1. Allocate the slots in the JIT body (during code generation). 2. Zero-initialize all of the slots. 3. Acquire the constant references mutex. 4. Set up the J9ConstRefArray(s) and add to all applicable lists. 5. Release the constant references mutex. 6. Acquire VM access. 7. Initialize the slots to their correct values via write barrier. 8. Release VM access. - Because the GC scans without the mutex, it is not sufficient to hold the mutex in order to destroy a J9ConstRefArray. It's also necessary to know that no concurrent scanning is ongoing. This is the case during class unloading and code cache reclamation (which will be part of the upcoming JIT changes). It will also be necessary to destroy J9ConstRefArrays on compilation failure in the unlikely event that compilation fails after one or more J9ConstRefArrays have already been successfully created for the JIT body. In that case, the JIT will acquire exclusive VM access to allow for the necessary cleanup.

In ConstRefsIterator, moving JIT write protection toggling from the constructor/destructor to nextSlot() function reduces the duration that JIT write protection remains in disabled state. With this, omrthread_jit_write_protect_disable() is only called the first time nextSlot() is called for a non-empty set of constant reference slots. _jitWriteProtectDisabled field is used to keep track of the state of JIT write protection. When nextSlot() is to return NULL (empty list, or iteration reached the last slot), omrthread_jit_write_protect_enable() is called based on whether JIT write protection is in disabled state or not. Also includes some minor fixes based on review comments. Signed-off-by: Nazim Bhuiyan <nubhuiyan@ibm.com>

gacholio · 2026-02-06T18:01:58Z

jenkins test sanity zlinux jdk25

gacholio · 2026-02-06T18:02:06Z

jenkins compile win jdk8

nbhuiyan · 2026-02-06T22:58:40Z

JDK25 sanity.openjdk test failures on zLinux:

TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.UnsatisfiedLinkError: jdk/test/whitebox/WhiteBox.registerNatives()V
...
#INFO:  AOT header validation failed: AsyncCompilation feature mismatch.
...
TEST: jdk/internal/vm/Continuation/OSRWithManyLocals.java

For this failure, see explanation in #23304 (comment). This failure is unrelated to the changes in this PR.

dmitripivkine added comp:gc comp:vm labels Jan 29, 2026

dmitripivkine approved these changes Jan 29, 2026

View reviewed changes

amicic reviewed Jan 29, 2026

View reviewed changes

runtime/gc_structs/ConstRefsIterator.hpp Outdated Show resolved Hide resolved

babsingh reviewed Jan 29, 2026

View reviewed changes

gacholio reviewed Jan 30, 2026

View reviewed changes

runtime/vm/jvminit.c Show resolved Hide resolved

gacholio approved these changes Feb 2, 2026

View reviewed changes

jdmpapin and others added 2 commits February 5, 2026 13:53

nbhuiyan force-pushed the const-refs-vmgc branch from 64bbd8a to 556bac0 Compare February 5, 2026 18:54

amicic approved these changes Feb 6, 2026

View reviewed changes

babsingh approved these changes Feb 6, 2026

View reviewed changes

gacholio merged commit 933c710 into eclipse-openj9:master Feb 7, 2026
5 of 7 checks passed

0xdaryl added this to Adopt OpenJDK MethodHandles Mar 24, 2026

github-project-automation bot moved this to Done in Adopt OpenJDK MethodHandles Mar 24, 2026

Conversation

nbhuiyan commented Jan 26, 2026 • edited by jdmpapin Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

nbhuiyan commented Jan 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dmitripivkine left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

babsingh Jan 29, 2026

Choose a reason for hiding this comment

Uh oh!

nbhuiyan Feb 5, 2026

Choose a reason for hiding this comment

Uh oh!

babsingh Jan 29, 2026

Choose a reason for hiding this comment

Uh oh!

nbhuiyan Feb 5, 2026

Choose a reason for hiding this comment

Uh oh!

babsingh Jan 29, 2026

Choose a reason for hiding this comment

Uh oh!

nbhuiyan Feb 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

gacholio commented Feb 6, 2026

Uh oh!

gacholio commented Feb 6, 2026

Uh oh!

nbhuiyan commented Feb 6, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

nbhuiyan commented Jan 26, 2026 •

edited by jdmpapin

Loading

nbhuiyan commented Jan 26, 2026 •

edited

Loading

nbhuiyan Feb 5, 2026 •

edited

Loading