RFR: 8354897: Support Soft/Weak Reference in AOT cache [v4]

Ioi Lam iklam at openjdk.org
Mon Apr 28 21:10:46 UTC 2025


On Mon, 28 Apr 2025 12:51:13 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:

>> In my mind, `MethodType::prepareForAOTCache()` makes sure all data used by `MethodType` are ready to be cached. `ReferenceKeySet::prepareForAOTCache()` does the same for this particular `ReferenceKeySet` instance.
>> 
>> Potentially we could have
>> 
>> 
>> class MethodType {
>>     static void prepareForAOTCache() {
>>         table1.prepareForAOTCache();
>>         table2.prepareForAOTCache();
>>         ....
>>     }
>> }
>> 
>> 
>> We can have many levels of `prepareForAOTCache()` calls where each level delegates the operations to its sub-components. There are no obvious "frontend/backend" or "interface/implementation" boundaries.
>
> We're creating a set of hooks - right now, there is one in MT - that are called by the VM at the appropriate time during the assembly phase to massage the class's state before we write the AOTCache out.
> 
> Conceptually any class could have a `prepareForAOTCache` method that would act as a front door for the VM to know how to set up its state.  
> 
> Right now we have a hard coded list of one class - MT - that we call `prepareForAOTCache` on.  Another way to implement this would be to loop through all classes that AOTCache candidates and call their `prepareForAOTCache` method (fi they have one).
> 
> If we expand this beyond MT, how does a reader of the code know which classes have VM call-in points and which don't?
> 
> (I'll mention here I missed the static modifier was only on MT which changes the argument a little but I still think different names would be clearer to diffierntiate between what the VM is expected to call and what may happen to the instances)

How about `MethodType::assemblySetup()` for the entry point? This kind of mirrors the `runtimeSetup()` entry points that are called after the AOT cache is loaded. In the future, we can use annotation to mark such entry points to avoid explicit calls from the JVM.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24757#discussion_r2064743394


More information about the hotspot-dev mailing list