RFR: 8373114: Redundant MethodCounters in the preimage generated by training run [v3]

[Ioi Lam]

On Tue, 9 Dec 2025 02:39:41 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>> Details are mentioned in the bug report and this mail thread https://mail.openjdk.org/pipermail/leyden-dev/2025-December/002843.html
>> After this patch the number of MethodCounters in the preimage are much less than before this patch. Also the number of MethodCounters in the preimage is the same as in the final AOTCache (these numbers are obtained using -Xlog:aot=trace).
>> 
>> Before this patch for the training run:
>> 
>> [18.610s][debug  ][aot         ]                         ro_cnt   ro_bytes     % |   rw_cnt   rw_bytes     % |  all_cnt  all_bytes     %
>> [18.610s][debug  ][aot         ] MethodCounters      :        0          0   0.0 |    22471    1438144   6.2 |    22471    1438144   2.6
>> 
>> Before this patch for the assembly phase:
>> 
>> [6.680s][debug][aot         ]                         ro_cnt   ro_bytes     % |   rw_cnt   rw_bytes     % |  all_cnt  all_bytes     %
>> [6.680s][debug][aot         ] MethodCounters      :        0          0   0.0 |     8588     549632   2.5 |     8588     549632   1.0
>> 
>> 
>> After this patch for the training run:
>> 
>> [49.371s][debug  ][aot         ]                         ro_cnt   ro_bytes     % |   rw_cnt   rw_bytes     % |  all_cnt  all_bytes     %
>> [49.371s][debug  ][aot         ] MethodTrainingData  :        0          0   0.0 |     4658     521696   2.1 |     4658     521696   0.9
>> 
>> 
>> After this patch for the assembly phase:
>> 
>> [12.580s][debug][aot         ]                         ro_cnt   ro_bytes     % |   rw_cnt   rw_bytes     % |  all_cnt  all_bytes     %
>> [12.580s][debug][aot         ] MethodTrainingData  :        0          0   0.0 |     4658     521696   2.1 |     4658     521696   0.9
>
> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove blank line
>   
>   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

> > > Another approach I thought of was to add the filtering in ArchiveBuilder::get_follow_mode such that only the MethodCounters referenced by MTDs are stored in the AOTCache. It is possible to get the enclosing MetaspaceObj for the MetaspaceClosure::Ref passed to get_follow_mode but I couldn't find an easy way to get the type of the enclosing object, which makes it difficult to check if the MethodCounters being added came from Method or MTD.
> 
> > Hi Ashutosh, I've created a patch for finding the type of the enclosing obj:
> > [iklam at cef9437](https://github.com/iklam/jdk/commit/cef9437484e119fde1b4eb07a809b33d83e35bdd)
> > Could you try to see if that works for you?
> 
> @iklam thanks for the changes. This is indeed what I wanted and updated the patch with the following change:
> 
> ```
>           address enclosing_obj = ref->enclosing_obj();
>           if (ref->enclosing_obj_msotype() == MetaspaceObj::MethodTrainingDataType) {
>             return make_a_copy;
>           }
> ```
> 
> But it seems like this is not sufficient. With this approach number of MethodCounters are only 1142 while the MTDs are around 4k. This is because in `ArchiveBuilder::gather_one_source_obj` the MCs that are first reached from Method get stored in the `_src_obj_table` with `_follow_mode=set_to_null`. Subsequent visits to such MCs through MTDs are ignored.

Currently `set_to_null` means that the referenced object should be always be excluded (with all subsequent references). Maybe we can change the meaning to "set the current reference to null, but allow the referenced object to be included via other references". If we make this change, it will be easier to handle similar situations in the future.

I am not sure if there's a compatibility issue -- probably not. Currently, we have never had a situation where the follow-mode of a referenced object is sometimes `set_to_null` and sometimes `make_a_copy`.

However, the implementation will be more complicated, as we have to remember the decision on each reference (currently the decision is remembered on the referenced object).

Maybe we should go with your first approach for now, and experiment with the second approach in a later RFE.

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

PR Comment: https://git.openjdk.org/jdk/pull/28670#issuecomment-3640384909