Alternative ways to mark the end of a training run

[ioi.lam at oracle.com]

With JEP 483 [1], the profiling data (AOT config file) are captured when 
the training run exits. In the Leyden repo, we have implemented a 
mechanism [2] to  capture the profiler data at an earlier point. Excerpt 
from [2]:


===

It may be difficult for users to run to normal completion for all 
training runs - some may prefer to only record data until the 
application framework has started or prior to some method being invoked.

This RFE is to track other possible triggers for CDS data to be 
collected and / or for the _assembly phase_ to being.

(a) JCMD: a new jcmd can be developed to attach to a running JVM and 
signal the training run has ended. For classic CDS, this may be the 
point at which the classlist is dumped to the file. For premain CDS, 
this may trigger the start of the assembly phase and the creation of the 
CDS archive.

(b) API: a new Leyden-specific API may be created that allows developers 
to indicate programatically the point at which the training run should 
end. This could be as simple as a static method `Leyden.endTraining()` 
or something that exposes more state such as the name of the CDS file. 
Details TBD based on need.

(c) Commandline: a new option could specify when to trigger the end of 
the training run. ie: 
`-XX:CDSEndTrainingOnEntry=org.foo.bar.someMethod`. This can be extended 
beyond single entry to also include a counted entry ie: the 1000 time 
this method is entered.

===


As of today, (a) and (c) have been implemented in the Leyden repo. We 
have received positive feedback from developers who found this mechanism 
to be useful and are requesting for similar features in the JDK mainline.

I think now will be a good time to have a wider discussion with the 
community about:

- The use case and requirements for such a mechanism

- The solution space -- besides the 3 options listed above, are there 
other approaches? Pros & cons?

For example, an API might be more precise. However, many apps are built 
with 3rd libraries that cannot be modified easily, so an external 
mechanism would be preferable. JCMD might be least intrusive, but it's 
timing dependent and may not be available (in containers, etc).


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

[1] https://openjdk.org/jeps/483

[2] https://bugs.openjdk.org/browse/JDK-8335358
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20250306/dfa6eb0a/attachment.htm>