RFR: 8293980: Resolve CONSTANT_FieldRef at CDS dump time [v3]

[Ioi Lam]

On Fri, 31 May 2024 12:21:09 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:

>> If you look at the version in the Leyden repo, there are many different types of references that are handled in `ClassPrelinker::maybe_resolve_fmi_ref`
>> 
>> https://github.com/openjdk/leyden/blob/4faa72029abb86b55cb33b00acf9f3a18ade4b77/src/hotspot/share/cds/classPrelinker.cpp#L307
>> 
>> My goal is to defer all the safety checks to `InterpreterRuntime::resolve_xxx` so that we don't need to think about what is safe to pre-resolve, and what is not. Some of the checks are very complex (see linkResolver.cpp as well) and may change as the language evolve.
>
> The current algorithm says:
> 
> for each bytecode in each method:
>   switch(bytecode) {
>     case getfield:
>     case outfield:
>       InterpreterRuntime::resolve_get_put(bc, raw_index, mh, cp, false /*initialize_holder*/, CHECK);
>       break;
>    ....
>   }
> 
> What I'm proposing is:
> 
> for each ResolvedFieldEntry
>    bool success = InterpreterRuntime::resolve_get_put(getfield, raw_index, nullptr /* mh */, cp, false /*initialize_holder*/, CHECK);
>    if (success) {
>      // also resolve for put
>      InterpreterRuntime::resolve_get_put(putfield, raw_index, nullptr /* mh */, cp, false /*initialize_holder*/, CHECK);
>    }
> 
> 
> The `method` parameter is not critical as the "current" algorithm attempts resolution with multiple methods - once for each method that references the ResolvedFieldEntry.  The resolution logic already has to handle dealing with different rules for different types of methods (ie `<clinit>` & `<init>`) for normal execution and "knows" not to resolve entries (like puts of field fields) regardless of the method as they need to do additional runtime checks on every access.
> 
> The same will apply to invoke bytecodes later.... it feels safer to do only what the bytecodes in some method have asked for but the runtime already has to be robust against different kinds of gets/puts or invokes targeting the same cp entries.  By eagerly resolving we're not giving up any safety.
> 
> If you really want to only resolve the exact cases (ie: gets not puts, etc) that were resolved in the training run, then we need to write out as part of the classlist more explicitly what needs to be resolved:
> ie:
> 
> @cp_resolved_gets 4, 7 8
> @cp_resolved_puts 7 8 10

This makes sense. I will try to prototype it in the Leyden repo and then update this PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19355#discussion_r1622828712