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

[Dan Heidinga]

On Mon, 28 Apr 2025 05:28:58 GMT, Ioi Lam <iklam at 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