Can Ahead of Time code benefit regular Java applications too?

[Ioi Lam]

On 5/30/2022 6:07 AM, Julian Waters wrote:
> Hi all,
>
> Since Leyden's goal has shifted from originally exploring only binaries
> compiled directly to native code, to "address the long-term pain points of
> Java’s slow startup time, slow time to peak performance, and large
> footprint", would there be any merit in looking at allowing native code to
> be embedded within jars to bypass the Interpreter at runtime? (Maybe have
> Ahead of Time code that replaces the Interpreter be compiled by C1, and
> treat it as part of the C1 pipeline so it can be profiled while being run)
> Ideally it'd be similar to the now defunct jaotc, but more compact (within
> the jar itself or perhaps the classfiles somehow) instead of compiling the
> Ahead of Time code into an entirely separate file which then needs to be
> explicitly passed to the JVM at runtime. This may or may not be a good
> starting point before advancing to entirely standalone Java binaries, but I
> digress. Perhaps the experience of the CraC team would be of some help in
> this area?
>
> best regards,
> Julian

What kind of interface and dependency between the JVM and the native 
code would be needed to support this?

As far as I can tell, the Leyden discussions have been about producing 
artifacts (native code or heap dumps) that are tightly bound to a 
specific build of the JDK. If you want a (version agnostic) JAR file to 
contain native code that can be used by arbitrary JDKs, that would raise 
the complexity quite significantly.

Thanks
- Ioi