On Fri, 31 May 2024 12:21:09 GMT, Dan Heidinga <heidi...@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
