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

[Andrew Dinn]

On Wed, 22 Oct 2025 15:26:06 GMT, María Arias de Reyna Domínguez <duke at openjdk.org> wrote:

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

The (cp) index identifies the offset of slot for the resolved entry in the ConstantPool's data array. There is a corresponding raw index which identifies the offset of the slot in the ConstantPoolCache's ResolvedField/Method/Handle data array. The loaded method bytecode starts off using the cp index. However, it is rewritten during class loading to use the raw index. The ResolvedField/Method/Handle entry caches the raw index so it can be translated back to the cp index.
Fo rlog analysis we either need to print the same info with a cache map offset or else you need to translate the printed name to an asset of the type indicated by the bytecode (e.g.Method when the bytecode is, say, invokevirtual).

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

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