On Mon, 28 Apr 2025 05:28:58 GMT, Ioi Lam <ik...@openjdk.org> wrote:
>> src/hotspot/share/cds/aotReferenceObjSupport.cpp line 106:
>>
>>> 104: assert(CDSConfig::allow_only_single_java_thread(), "Required");
>>> 105:
>>> 106: TempNewSymbol method_name =
>>> SymbolTable::new_symbol("prepareForAOTCache");
>>
>> I'm slightly uncomfortable with using the same method name
>> (`prepareForAOTCache`) on MethodType and on ReferenceKeyMap &
>> ReferenceKeySet as they have different expected use cases. The one on MT is
>> the "front door" the VM calls to remove stale Reference objects while the
>> RKMap/RKSet are internal mechanisms that the VM would never call except for
>> MT triggering it.
>>
>> Does it make sense to use different names for these methods? The MT one is
>> a hook that could be extended to other classes to prepare them for cache
>> creation while we wouldn't treat the RKMap/RKSet ones in the same way.
>> Maybe append "_internal" or "_helper" to the RFMap/Set methods to
>> distinguish them?
>
> 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)
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/24757#discussion_r2063590811
