On Mon, 28 Apr 2025 12:51:13 GMT, Dan Heidinga <heidi...@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

Reply via email to