RAM Class Persistence: Introducing Frozen Classes

[lzhou2025]

During snapshot creation, the J9Class structures whose class loader is
application class loader are marked as frozen when their classObject
fields are nullified. During the restore phase, these structures are never
used, kept hidden from the GC and other external users as a limitation.
This is achieved by updating the skip logic in the J9HashTable,
J9MemorySegment Iterator, which prevents the GC from encountering
J9Class structures in an unusable state that could lead to crashes.
The class ClassHeapIterator is refactored to use a generic vm interface
segmentIteratorNextClass() to iterate over classes in a segment.

Fixes: #21892

Co-authored-by: Babneet Singh [email protected]
Co-authored-by: Tobi Ajila [email protected]
Co-authored-by: Lige Zhou [email protected]

[lzhou2025]

@babsingh @TobiAjila @dmitripivkine I checked all gc policies using pingLiberty server program, please have a look.

[babsingh]

GC_ClassHeapIterator::nextClass and similar iterators will also need to be updated to skip frozen classes (J9ClassIsFrozenFromSnapshot) until their classObject is initialized.

openj9/runtime/gc_structs/ClassHeapIterator.cpp

Line 40 in 0cf42bd

GC_ClassHeapIterator::nextClass()

[dmitripivkine]

I don't like this solution at all. Make j9classes hidden for GC it is bad idea.
j9class can keep alive other objects. Skipping it these objects never be scanned. You can say you guarantee there is no other objects referenced from j9class at this particular moment. I think this condition can be hard to control, now and in the future.
I am repeating again, let's set a meeting with @amicic, @TobiAjila, @babsingh and myself to discuss options.
And my first question is (may be I don't understand context) - why we set j9class->classObject to NULL before creating snapshot? This object exists in the heap and there is no another GC after this point - so object is transitioned to restore size and can be used.
In the case of you have reason to cleanup and re-create class object this new fundamental behaviour should be added to GC code. We should legally allow NULL pointer in the j9class->classObject, at least during initial restore time. I believe it might require to add significant restrictions to GC activity (like disabling dynamic class unloading but not limited to). Making j9class->classObject alive GC makes j9class itself alive and prevent class loader from unloading.
GC code can be adjusted to allow j9class->classObject be NULL if itv is really necessary, but it should be done properly.

[babsingh]

why we set j9class->classObject to NULL before creating snapshot?

We are caching RAM classes during shutdown in the snapshot, similar to how ROM classes are handled with the Shared Classes Cache. Currently, only the native portions of the J9Module, J9Class, and J9ClassLoader structures are cached in the snapshot. Java heap objects themselves are not cached, so their associated fields are nullified during snapshot creation at shutdown.

During the restore phase, the snapshot is loaded during JVM initialization. However, the corresponding Java objects are not yet initialized; they will be created later through their normal code paths. Despite this, the native structures from the snapshot become visible to the garbage collector as soon as the snapshot is loaded.

The goal is to delay the exposure of these native structures to the GC until their associated Java objects are fully initialized through standard execution paths.

[lzhou2025]

GC_ClassHeapIterator::nextClass and similar iterators will also need to be updated to skip frozen classes (J9ClassIsFrozenFromSnapshot) until their classObject is initialized.

openj9/runtime/gc_structs/ClassHeapIterator.cpp

Line 40 in 0cf42bd

GC_ClassHeapIterator::nextClass()

I will include the update

[lzhou2025]

As per our Teams meeting with @TobiAjila and @amicic, the PR is revised to implement the frozen class into the common class iterator interfaces.

[babsingh]

@lzhou2025 The PR description is slightly inaccurate. We are not freezing the j9class objects; we are freezing j9classes until their classObjects are initialized. Also, the why is missing in the description.

Updated version of the commit message and PR description:

During snapshot creation, J9Class structures are marked as frozen when
their classObject fields are nullified. During the restore phase, these
structures are kept hidden from the GC and other external users until
their classObject fields are properly initialized. This is achieved by
updating the skip logic in the J9HashTable and J9MemorySegment
iterators, which prevents the GC from encountering J9Class structures
in an unusable state that could lead to crashes.

In the PR description, the title is repeated, which should be fixed.

Can you confirm if #21892 is fixed through local testing once the changes are finalized?

[lzhou2025]

Will check it.

[lzhou2025]

I pushed the update, but leave null check. The problem is that if delete "null check", jvm crashes. I spent some time to debug the crash, it appears that those "null check" is applied to classes loaded by the application class loader (saved in snapshot) from the snapshot run, in restore, the class loader is ignored, unused, but new application class loader is created instead

openj9/runtime/jcl/common/stdinit.c

Line 468 in f255919

#if defined(J9VM_OPT_SNAPSHOT)

, does it cause those classes never initialized?

[keithc-ca]

Could someone please expand "RCP" in this context, please?

[babsingh]

RCP – RAM Class Persistence: This refers to the caching of RAM classes in snapshots so they can be reused in subsequent runs.

[keithc-ca]

RCP – RAM Class Persistence: This refers to the caching of RAM classes in snapshots so they can be reused in subsequent runs.

Both the commit message and the description here should spell that out.

[lzhou2025]

Updated

[keithc-ca]

@dmitripivkine Has this changed sufficiently to address your concern?

[dmitripivkine]

@dmitripivkine Has this changed sufficiently to address your concern?

Suggested way of handling of Frozen classes (hiding from GC) introduces number of limitations how such classes should be treated. So, VM component is taking responsibility for correctness. I have suggested to add assertions to control Frozen classes isolation:

• Frozen class should exist for persistent class loaders (never be unloaded) only (System, Application, Extensions).
• Frozen class should not be used to create object instance or used any other way when GC can discover them indirectly (ex. from CP of another class).
• Frozen class should be activated (loaded) using special rules first (including setting class object) and have other required object pointers be introduced after
• etc.
  I can approve this change if VM Team developers like this way.

[tajila]

Frozen class should exist for persistent class loaders (never be unloaded) only (System, Application, Extensions).

This is an implilied restriction as we dont have to the ability to cache classes from non-peristent classloaders

Frozen class should not be used to create object instance or used any other way when GC can discover them indirectly (ex. from CP of another class).

All cached classes have empty constantpools and statics so Frozen classes cant be discovered until they are loaded from the cache (which transforms the class from a frozen to a normal class).

Frozen class should be activated (loaded) using special rules first (including setting class object) and have other required object pointers be introduced after

This is the current behaviour. This PR doesnt change the contract with the GC, NULL == clazz->classObject should not be possible when J9_EXTENDED_RUNTIME_CLASS_OBJECT_ASSIGNED is set, and GC is free to assert this.

[tajila]

jenkins test sanity.functional amac jdk17

[keithc-ca]

For the record, the build underway is at https://openj9-jenkins.osuosl.org/job/PullRequest-OpenJ9/7782.

[lzhou2025]

For the record, the build underway is at https://openj9-jenkins.osuosl.org/job/PullRequest-OpenJ9/7782.

I will cancel my job, I didn't notice that there is "PullRequest-OpenJ9" under job.

[keithc-ca]

There's no need to cancel that job; it completed successfully.

[lzhou2025]

``

There's no need to cancel that job; it completed successfully.

Perfect