RFR: 8370377: Avoid resolving constant pool entries during preimage generation in the training run

[Ashutosh Mehra]

On Wed, 22 Oct 2025 07:39:19 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> This patch prevents constant pool entries from getting stored in resolved state in the preimage generated by the training run. Now the information about the constant pool entries to be pre-resolved in the assembly phase is only conveyed through FinalImageRecipes, making it easier to trace the resolution of CP entries.
>> Note that this change broke the pre-resolution of CP entries referred by getfield and putfield bytecodes. This is because `AOTConstantPoolResolver::preresolve_field_and_method_cp_entries` was only looking for `getfield` and `putfield` bytecodes, but during the training run, these bytecodes may get replaced by their "fast" versions by the interpreter, or by the "nofast" versions during preimage dumping. So I have to add cases for handling the "fast" and "nofast" variations of the bytecodes as well.
>> I also added logging to dump the list of CP entries to be pre-resolved which is stored as part of FinalImageRecipes in preimage.
>
> src/hotspot/share/cds/finalImageRecipes.cpp line 130:
> 
>> 128: 
>> 129:     if (cp_indices.length() > 0) {
>> 130:       LogStreamHandle(Trace, aot, resolve) log;
> 
> This is very helpful information However, am I right in thinking this log output is going to be emitted during the training run?
> 
> It would really help if we could log details of which CP entries are resolved during an assembly run and/or a production run so we could associate linkage info, including any referenced metadata and/or heap roots, with the corresponding CP/CPCache/Klass. That would allow the map analysis to be extended to show how assets in the cache are connected to their owning Klass(es).

There is existing logging (enabled by -Xlog:aot+resolve=trace) during the assembly phase when the pre-resolution happens. It prints information like this:

[0.556s][trace][aot,resolve] Resolved class  [  8] java.lang.Object -> java.lang.Object
[0.556s][trace][aot,resolve] Resolved class  [ 50] java.lang.Object -> java.lang.Thread
[0.556s][trace][aot,resolve] Resolved class  [ 55] java.lang.Object -> java.lang.VirtualThread
[0.556s][trace][aot,resolve] Resolved invokevirtual [ 57] java.lang.Object -> java.lang.Object.wait0:(J)V
[0.556s][trace][aot,resolve] Resolved invokevirtual [ 38] java.lang.Object -> java.lang.Object.wait:(J)V

Can you please add what additional information is needed here to help with the map analysis?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27927#discussion_r2452283946