Redundant MethodCounters in preimage

[Ashutosh Mehra]

Hi,
While working on the leyden-analyzer tool Maria mentioned that
MethodCounters for a particular method is present in the preimage generated
by the training run but not in the final AOT Cache generated by the
assembly phase. In fact the number of MethodCounters in the preimage is way
more than that in the final image. For an app that Maria was using, map
file for training phase shows:

$ grep "@@ MethodCounters " t.map |wc -l 22495

and the map file for assembly phase shows:

$ grep "@@ MethodCounters " a.map |wc -l 8701

I checked the code and realized there are two ways MethodCounters can get
into the cache:
1. through Method (see Method::metaspace_pointers_do)
2. through MethodTrainingData
(see MethodTrainingData::metaspace_pointers_do)

The first point explains the presence of so many MethodCounters, because
any method that gets executed would have its MethodCounters added to the
cache.
Interestingly the link between Method and MethodCounters is then severed in
Method::unlink_method(). That means the Methods adopted from the preimage
in the assembly phase do not have MethodCounters. And since we don't
execute the application, we don't create MethodCounters for the Methods
loaded from the preimage. Only the MethodCounters discoverable via
MethodTrainingData seep into the AOTCache.

>From the above explanation it looks like not every MethodCounters added to
the preimage is useful. Probably we should only be adding MethodCounters
through the MethodTrainingData and not through Method. This would also
reduce the size of the preimage a bit. In this particular case
MethodCounters size was 1437824 bytes in preimage and 551552 bytes in the
AOT Cache.

Does this make sense?

Thanks,
- Ashutosh Mehra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20251203/c7d48049/attachment.htm>