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

[María Arias de Reyna Domínguez]

On Wed, 22 Oct 2025 15:25:10 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

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

Maybe I am a bit out of context here, but: The index there between "[" and "]", does it correspond to anything on the AOT Cache (map file)? Maybe the order of elements on the CP is the same as in the map file so I can count and index them? Can I rely on that to know what element we are talking about? And on the right hand side of the arrow, can I map that to anything on the cache too? Maybe to `Class` and `Method` assets inside the cache with the same name?

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

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