On Mon, 28 Apr 2025 12:51:13 GMT, Dan Heidinga <[email protected]> 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
