You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The goal is to cache modularity related structures in the snapshot. From a high level, this requires us to save and restore instances of J9Module, J9Package and J9ModuleExtraInfo.
Add new fields in SavedJ9JavaVMStructures to save and restore J9JavaVM->modularityPool, J9JavaVM->javaBaseModule and J9JavaVM->unnamedModuleForSystemLoader.
Use the snapshot port library to allocate the related hashtables. We already do this for hashPackageTableNew and hashModuleNameTableNew. We want to extend this to hashModuleExtraInfoTableNew and hashModulePointerTableNew.
Similarly, make sure that all the memory, for the internal fields of the above three native structures, is allocated using the snapshot port library. This will allow them to be successfully cached in the snapshot.
If the fields cannot be cached (e.g. the object fields moduleName/moduleObject/version in J9Module), add appropriate code to initialize them during every run once the cached data is loaded.
During the creation paths, add logic to restore the native structures from the snapshot, and then initialize the required fields.
For J9Module, createModule will need to be updated to load the cached J9Module during the restore phase. J9ClassLoader->moduleHashTable will be used to find the cached J9Module. J9Module->moduleName will be cleared during shutdown before the snapshot is written, and it is needed for comparisons to resolve hashtable collisions. Since objects can't persist across runs, the module name will need to be stored as a string in J9Module. The moduleName pointer and other GC code to persist the object pointer can be removed. The usage of J9Module->moduleName will need to be replaced by the string that is stored in J9Module. If the moduleName object is needed, it can be accessed through J9Module->moduleObject (via vmconstantpool.xml).
The remaining object fields in J9Module will need to be cleared during shutdown and reinitialized once a J9Module entry is restored from the snapshot in createModule.
For J9ModuleExtraInfo, caching the hashtable should be sufficient. The current code checks in the hashtable before creating a new J9ModuleExtraInfo.
Memory, for the J9UTF8 strings and other native memory for the fields within these structs, will need to be allocated using the vmsnapshot_allocate_memory.
Make sure that pointers to J9Module stored in other structs are valid and if needed fixed: J9Package->module, J9ModuleExtraInfo->j9module and J9Class->module. No pointers to J9Package and J9ModuleExtraInfo exist in other structs.
Check the exit paths (e.g. where freeJ9Module, freePackage, freeClassLoader are being invoked) to make sure that entities are written to the snapshot and not being freed early.
The text was updated successfully, but these errors were encountered:
The goal is to cache modularity related structures in the snapshot. From a high level, this requires us to save and restore instances of
J9Module
,J9Package
andJ9ModuleExtraInfo
.openj9/runtime/oti/j9nonbuilder.h
Lines 1845 to 1855 in efaa4f6
openj9/runtime/oti/j9nonbuilder.h
Lines 1857 to 1864 in efaa4f6
openj9/runtime/oti/j9nonbuilder.h
Lines 1866 to 1871 in efaa4f6
Implementation
SavedJ9JavaVMStructures
to save and restoreJ9JavaVM->modularityPool
,J9JavaVM->javaBaseModule
andJ9JavaVM->unnamedModuleForSystemLoader
.openj9/runtime/oti/j9nonbuilder.h
Lines 6129 to 6131 in efaa4f6
openj9/runtime/oti/SnapshotFileFormat.h
Lines 35 to 36 in efaa4f6
openj9/runtime/vm/VMSnapshotImpl.cpp
Lines 804 to 806 in efaa4f6
openj9/runtime/vm/VMSnapshotImpl.cpp
Lines 816 to 823 in efaa4f6
Make sure that the restored fields are not re-initialized during the restore run through proper macros (e.g.
IS_RESTORE_RUN
).Use the snapshot port library to allocate
J9JavaVM->modularityPool
similar to the existing logic that is used forJ9JavaVM->classLoaderBlocks
.openj9/runtime/vm/jvminit.c
Lines 2641 to 2644 in efaa4f6
Use the snapshot port library to allocate the related hashtables. We already do this for
hashPackageTableNew
andhashModuleNameTableNew
. We want to extend this tohashModuleExtraInfoTableNew
andhashModulePointerTableNew
.openj9/runtime/vm/ModularityHashTables.c
Lines 154 to 159 in efaa4f6
openj9/runtime/vm/ModularityHashTables.c
Lines 199 to 204 in efaa4f6
Similarly, make sure that all the memory, for the internal fields of the above three native structures, is allocated using the snapshot port library. This will allow them to be successfully cached in the snapshot.
If the fields cannot be cached (e.g. the object fields
moduleName/moduleObject/version
inJ9Module
), add appropriate code to initialize them during every run once the cached data is loaded.During the creation paths, add logic to restore the native structures from the snapshot, and then initialize the required fields.
J9Module
,createModule
will need to be updated to load the cachedJ9Module
during the restore phase.J9ClassLoader->moduleHashTable
will be used to find the cachedJ9Module
.J9Module->moduleName
will be cleared during shutdown before the snapshot is written, and it is needed for comparisons to resolve hashtable collisions. Since objects can't persist across runs, the module name will need to be stored as a string inJ9Module
. ThemoduleName
pointer and other GC code to persist the object pointer can be removed. The usage ofJ9Module->moduleName
will need to be replaced by the string that is stored inJ9Module
. If themoduleName
object is needed, it can be accessed throughJ9Module->moduleObject
(viavmconstantpool.xml
).J9Module
will need to be cleared during shutdown and reinitialized once aJ9Module
entry is restored from the snapshot increateModule
.openj9/runtime/j9vm/java11vmi.c
Lines 272 to 276 in efaa4f6
openj9/runtime/vm/classsupport.c
Lines 378 to 385 in efaa4f6
J9Package
,createPackage
will need to be updated similarly, and the cached value can be found usingJ9ClassLoader->packageHashTable
.openj9/runtime/j9vm/java11vmi.c
Lines 218 to 222 in efaa4f6
openj9/runtime/util/modularityHelper.c
Lines 106 to 110 in efaa4f6
openj9/runtime/util/modularityHelper.c
Lines 153 to 157 in efaa4f6
J9ModuleExtraInfo
, caching the hashtable should be sufficient. The current code checks in the hashtable before creating a newJ9ModuleExtraInfo
.J9UTF8
strings and other native memory for the fields within these structs, will need to be allocated using thevmsnapshot_allocate_memory
.Make sure that pointers to
J9Module
stored in other structs are valid and if needed fixed:J9Package->module
,J9ModuleExtraInfo->j9module
andJ9Class->module
. No pointers toJ9Package
andJ9ModuleExtraInfo
exist in other structs.Check the exit paths (e.g. where
freeJ9Module
,freePackage
,freeClassLoader
are being invoked) to make sure that entities are written to the snapshot and not being freed early.The text was updated successfully, but these errors were encountered: