Currently, -XXAOTMode=record causes the VM to execute a training run, which collects data (classes, profiles, etc.) until the application exits. The data is then analyzed by a post-pass in a separate VM execution (the "assembly phase") and dumped into an AOT cache.

Users are asking for more control over the span of a training run. For various reasons they are unwilling simply to call System::exit as a proxy for the request, "Please take my training data now, because I am done training." We can call the VM's decision to end training the "ETR" or "End Training Run" event.

Users want more ways to trigger an ETR.

We need (at minimum) a new API, working title java.lang.System::endTrainingRun.
If a training run is active, it would end the training run.
If a training run is inactive, it might nop, warn, or throw.

(This requires discussion. It should be OK for several
threads to concurrently request ETR, and the race losers
should not throw. But an ETR without -XX:AOTMode=record
might throw.)

That's one basic requirement, and this RFE is enough to get the ball rolling.

As a follow-on RFE, we expect also to support some breakpoint-like
mechanism, where one or more methods can be mentioned on the
command line as causing ETR events (perhaps after a breakpoint-like
count). This function is much more problematic than a simple
System::endTrainingRun API, and so should be addressed in
following work.

For the record, framework maintainers have asked for this
breakpoint-like mechanism because the simple System::ETR
API requires source editing and recompilation to use, but
some use cases for frameworks need to work with "dusty JARs"
containing code that is difficult to recompile. Instrumentation
might be used (as a heroic measure) to inject calls to
System::ETR at the right points, but bytecode editing interferes
badly with Leyden technology, causing it to reject the instrumented
class file.