On Mon, 28 Apr 2025 21:08:10 GMT, Ioi Lam <ik...@openjdk.org> wrote: >> 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.
That's a great choice! It makes it clear when the method is run, parallels `runtimeSetup`, and differentiates it from the instance method helpers. Thanks Ioi for working thru this with me! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24757#discussion_r2066407185
