JDK-8207381 : Provide internal Java API for archiving object sub-graph reachable from static field
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 12
  • Priority: P3
  • Status: Resolved
  • Resolution: Won't Fix
  • Submitted: 2018-07-17
  • Updated: 2019-05-28
  • Resolved: 2018-12-06
Related Reports
Relates :  
JDK-8214932 - Implement more checks for archiving object subgraphs
Relates :  
JDK-8194759 - Support caching class mirror objects
Relates :  
JDK-8202035 - Archive the set of ModuleDescriptor and ModuleReference objects for observable system modules with unnamed initial module
Relates :  
JDK-8207795 - Change VM.initializeFromArchive() to return a boolean
Description
It might be helpful to provide a java API like the following to specify entry point (static field) for archiving a sub-graph in Java code:

In VM class:
public static native void archive(Class<?> c, String fieldName);

Suggested by Ioi and Karen.

The new API will make adding new sub-graph archiving an easier task. No new CDS/VM code change will be required for registering the entry fields (currently several VM files need to be modified in order to add a new entry) with the java API.

In addition to the API, we need a mechanism to validate that the new sub-graph for archiving is 'preservable'. There are following starter approaches:

Approach 1) 
Author driven approach. The author who's adding a new sub-graph archiving need to specify all classes included in the graph are 'preservable'. Method for how to specify 'preservable' state is not determined yet currently.

Approach 2) 
Add guards to the archived sub-graph during dump time. When archiving a sub-graph, checks can be done for the objects within the sub-graph to make sure they are not the ones with known issues (such as Thread, etc). 

Approach 3)
This is suggested by Ioi. Dump time can consult a list of classes maintained internally by the sub-graph archiving mechanism. Only instances of classes on the list can be included in the archived sub-graph. When new sub-graphs are archived, new classes may be added to the list. Only classes with no runtime dependencies should be added to the list.
Comments
I'm closing this RFE based on the above conclusion as the API approach does not work in all cases. We still want to implement the checks/guards that described in this REF for archiving subgraphs. I will open a new RFE for tracking that work.
06-12-2018
Discussed with Ioi further on this yesterday. We realized the Java API approach has a drawback comparing to the current approach (statically registering the entry point). The Java API approach requires the API being called during dump time in order to properly register a new entry point. That means for any code that's not executed during CDS dump time, subgraphs created by the code can not be registered. With the current approach, there is no such issue.
08-11-2018
After some thinking, I'm in favor of Ioi's proposal (third option in the description section) for validation, augmented with the following optimization to limit the size of the list: If an object's class is a sub-type of Serializable, the object is allowed to be part of an archived sub-graph, otherwise the list is consulted at dump time. Only classes that are not Serializable and have no dependencies on runtime context need to be maintained in the list (when their instances are part of archived sub-graphs). In the future, when any of the classes in the list become sub-types of Serializable, they can be removed from the list.
21-07-2018
As the number of entry fields can be different for different classes, there are following two approaches for the API: 1) Using an array to specify the entry fields: public static native void archive(Class<?> c, String[] fieldName); 2) Provide several APIs with different argument sizes: public static native void archive(Class<?> c, String fieldName); public static native void archive(Class<?> c, String fieldName1, String fielName2); public static native void archive(Class<?> c, String fieldName1, String fielName2, String fieldName3); ... Approach 1) requires to construct an array to specify the entry fields, which adds overhead to normal operations. Approach 2) has minimum overhead. For normal operation, the method call can return immediately if DumpSharedSpaces is false.
18-07-2018