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

[Andrew Dinn]

On Wed, 22 Oct 2025 14:22:09 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>> 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?

This is probably ok as a supplement to the data that is in the map. The source and target names can be used to associated a CP owning Klass with the corresponding Klass asset that owns the field, or Method asset that is th etarget of the method or handle call
However, this output will only be available at assembly time and only when trace level logging is enabled for aot+resolve. That's not very helpful when a user has built a cache and is trying to use aot+map trace to see what is in it. We could either regenerate the same aot+resolve trace inprocustion and require logging for those tags to be enabled. Alternatively, we could iterate over ConstantPool entries when generating the aot+map log output and print the details as part of the dump of an @@ConstantPool asset. The latter approach provides redundant info but would be easier for a log analyzer to process.
Also, if we add this to the map output we don't actually need use the raw_index to format the target names into the output. We could just use the info in the CPCcahe entry to identify what we have resolved (Klass that owns the field, Method or MethodHandle direct target) and print the offset of the target in the map. These can be translated to the relevant names by the analysis tool. This would also be the right approach for resolved Strings and j.l.Classes linked from the ConstatPool via the resolved_references array.

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

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