Alternative ways to mark the end of a training run

[Sebastien Deleuze]

Those 3 alternatives make sense from my POV and look complementary:
 - JCMD could be used by sysops and for testing.
 - API could potentially be used by a Spring Boot actuator [1] exposing a
secured endpoint allowing to trigger the end of a training run.
 - Commandline could be useful for platforms wanting to provide AOT cache
support with the knowledge of the frameworks used. For example, it could be
used to specify
`-XX:CDSEndTrainingOnEntry=org.springframework.web.servlet.DispatcherServlet#doService`
after 10000 invocations.

If that's a new capability, would it make sense to only expose it via
`-XX:AOTEndTrainingOnEntry` instead of `-XX:CDSEndTrainingOnEntry` to avoid
too many options and some confusion?

Providing those capabilities will be very important when AOT profiles and
AOT compiled methods will be available as they could allow target use cases
where the production environment is used to get profiling data (will be the
most popular use case IMO), and you would typically want to dump the
profiling data without killing the instance. That said, it could maybe ease
integrators' work to support those capabilities earlier than AOT profiles
and AOT compiled methods, if that makes sense with the current feature set.
For example, it could allow platforms and frameworks to be "Leyden-ready"
with a Java 25 minimal requirement if we consider those
JCMD/API/Commandline as a subset of "Leyden public API". AOT profiles and
AOT compiled methods support could come later and be almost an
implementation detail from platforms and frameworks POV.

Since the creation of an AOT cache with Spring Petclinic was pretty long
and resource consuming last time I tried, I am wondering if it could be
possible to provide an option to control what kind of output we expect at
the end of the training run. Generating directly the CDS/AOT archive makes
sense, but on production it could be potentially too resource consuming and
would produce too many side effects. Like the JEP 483 differentiates the
AOT configuration recorded (app.aotconf) from the cache (app.aot), would it
be possible with AOT profiles and AOT compiled methods to optionally
generate an intermediate format that would be fast to generate at the end
of the training, and defer the more involved creation of the archive at a
later point (keeping the constraints of same OS, Java version and
classpath)?

On Thu, Mar 6, 2025 at 9:23 PM <ioi.lam at oracle.com> wrote:

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

-- 
This electronic communication and the information and any files transmitted 
with it, or attached to it, are confidential and are intended solely for 
the use of the individual or entity to whom it is addressed and may contain 
information that is confidential, legally privileged, protected by privacy 
laws, or otherwise restricted from disclosure to anyone else. If you are 
not the intended recipient or the person responsible for delivering the 
e-mail to the intended recipient, you are hereby notified that any use, 
copying, distributing, dissemination, forwarding, printing, or copying of 
this e-mail is strictly prohibited. If you received this e-mail in error, 
please return the e-mail to the sender, delete it from your computer, and 
destroy any printed copy of it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20250312/2217072c/attachment.htm>