Loading AOT alongside bytecode / caching JIT optimisations

[elias vasylenko]

Yes that was all I could find. It does refer to Java Platform, Standard
Edition Tools Reference for more information but it is in fact not
mentioned there that I can see. At least the search doesn't come up with
it. Oh well, as I said, early days, I'm sure there will be more once it
matures a little. And yes I realise now that this is not specifically a
Graal project, so I'll not pollute this mailing list with any more of it.
Thanks again.

On Tue, 2 Oct 2018 at 16:48 Gilles Duboscq <gilles.m.duboscq at oracle.com>
wrote:

> Regarding documentation, see for example:
>
> https://docs.oracle.com/javase/10/vm/java-hotspot-virtual-machine-performance-enhancements.htm#GUID-F33D8BD0-5C4A-4CE8-8259-FD9D73C7C7C6
>
> As Christian said, this is a feature of the underlying JDK, it is not
> specific to GraalVM (although it is implemented using the Graal compiler).
>
>  Gilles
>
> On 02/10/2018 17:16, elias vasylenko wrote:
> > Oh well that is surprising, thank you! All the documentation I've seen
> has
> > been about the full closed-world native image AOT and I've missed all
> > discussion of this entirely. I suppose it is still a preview feature
> > without much documentation so I hope you'll forgive me for missing it ;)
> >
> > Thanks for pointing me in the right direction, glad to hear this is here.
> >
> > On Tue, 2 Oct 2018 at 14:55 Christian Thalinger <cthalinger at twitter.com>
> > wrote:
> >
> >> On Oct 2, 2018, at 4:22 AM, elias vasylenko <eliasvasylenko at gmail.com>
> >> wrote:
> >>
> >> Hello,
> >>
> >> As I understand it Graal AOT has two main advertised advantages, which
> >> appear to be orthogonal: smaller distributions and faster startup. The
> >> tradeoffs made to achieve these goals are: no dynamic loading of code,
> no
> >> dynamic recompilation, and limited reflection.
> >>
> >> These trade-offs make perfect sense for certain short-lifecycle
> >> minimal-dependency use cases e.g. cloud/microservices/CLI. But for
> larger
> >> applications with more traditional long-term workloads we may start to
> miss
> >> them.
> >>
> >> So what if we sacrificed our ability to distribute smaller binaries and
> >> focused on the singular goal of faster startup, could we eliminate the
> need
> >> for some of these trade-offs?
> >>
> >> For example, if we stored out (partially?) AOT compiled code *alongside*
> >>
> >>
> >> our original bytecode could we theoretically load it into the standard
> >> GraalVM instead of SubstrateVM and enjoy fast cold-starts without
> giving up
> >> all the bells and whistles?
> >>
> >> Alternatively I recall that some time ago there was a JEP which explored
> >> caching JIT optimisations between runs in Hotspot, but I don't know what
> >> came of it.
> >>
> >>
> >> It’s in OpenJDK since 9:
> >>
> >> http://openjdk.java.net/jeps/295
> >>
> >> Have any of these things been revisited/explored with Graal?
> >>
> >> Thanks for the help, I hope these questions make sense!
> >>
> >>
> >>
>