Can Ahead of Time code benefit regular Java applications too?

[Julian Waters]

The prospect of version agnostic jars which any JVM version can use
certainly sounds lucrative, but I don't think it's a must-have, especially
if the issues supporting such a feature makes pursuing the idea not worth
it. To my knowledge, when it was still being actively developed, jaotc
shared libraries were also specific to the OS and JVM they were
compiled for. Likewise, perhaps working in a similar fashion to
intrinsics, you could have certain sections of regularly compiled Java code
within jars replaced by native code compiled by C1 (or C2?) if the JVM it
was compiled by and the target OS/CPU match the current running JVM and
OS/CPU (Indeed, this is how the Velocity project checks if it should load
its own shared libraries or fall back to a Java implementation if it
detects that the current platform is suitable for native code acceleration
- https://github.com/PaperMC/Velocity/tree/dev/3.0.0/native). In a way,
this might be similar to Anton's suggestion of "A closed world start image
that is restored into an open world Java application" on another thread
within this mailing list, and the involvement of CraC within Leyden.

best regards,
Julian

On Wed, Jun 1, 2022 at 5:42 AM Ioi Lam <ioi.lam at oracle.com> wrote:

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