Call for Discussion: New Project: Leyden

[Jiangli Zhou]

Hi Ioi,

On Thu, May 21, 2020 at 11:59 AM Ioi Lam <ioi.lam at oracle.com> wrote:
>
> On 5/19/20 7:07 AM, Mike Hearn wrote:
> > Although this may be veering into an unwanted "what will it be"
discussion,
> > I'm curious how fundamental it is that an image must be either static or
> > dynamic.
> >
> > HotSpot already does some speculative optimisations on the assumption
that
> > new code isn't loaded e.g. the class hierarchy analysis. Speculative
> > optimisations do a great job of removing costs of dynamic language
features
> > like class redefinition. Leyden seems to be proposed as a new 'mode' of
the
> > Java language, but could it also be envisioned as a new set of
> > optimisations that optimistically assume no dynamic code loading? For
> > instance, could a module be marked as "available to dynamically loaded
> > code" and then the points-to analysis / dead code elimination would pin
the
> > public API of the module before running, and if it's not marked as such,
> > then DCE runs across the boundaries too?
> >
> > A big part of the SubstrateVM startup time win appears to come from a
more
> > aggressive version of the AppCDS heap serialisation feature, and a
general
> > focus on startup time to the exclusion of other factors (e.g. there's no
> > notion of module layers or module boundary enforcement). To what extent
is
> > the closed-world assumption contributing to the footprint/startup time
wins
> > vs other spec changes - is that known?
> >
> > These questions aren't rhetorical, I don't have any view on the answers.
> > After playing around with native-image and seeing mixed results (e.g.
> > smaller wins than I thought for GUI JavaFX apps), and looking at the
work
> > being done on AppCDS, I started to wonder if HotSpot can eventually
match
> > the startup time and footprint wins of native-image without the
> > compatibility breaking changes SVM makes to get there, just through
> > doubling down on current optimisation techniques like jlink and
speculation.
> >
> > Thanks for any insight offered!
> Hi Mike,
>
> Thanks for mentioning AppCDS. As someone working primarily on AppCDS, I
> am happy to hear that you have a good impression on its current state
> and potentials. Over the past few years, we have done many start-up
> optimizations, in AppCDS and many other parts of the JDK (core libs,
> jlink, hotspot, etc). You can see Claes Redestat's excellent
> presentation here:
>
> https://cl4es.github.io/2019/11/20/OpenJDK-Startup-Update.html
>
> Since JDK9, we have cut down the HelloWorld start-up time from about
> 120ms in JDK 9  to less than 40ms in JDK 14. We will be eking out a few
> more ms in JDK 15.
>
> A large part of the improvement is due to archiving heap objects into
> CDS -- mostly related module information. In JDK 16, I hope to finish
> JDK-8244778 (Archive complete module graph in CDS). My prototype shows
> about 7~10ms improvement in start-up time.
>
> The problem with archiving heap objects, though, is currently it
> requires a lot of manual work and knowledge about the code. I am
> spending a lot of effort to take out 7~10ms for JDK-8244778. To be
> useful in general applications, we need to make it much easier to use.
>

Looks like we are shooting for the same goal and both are trying to improve
the Java heap (object subgraph) archiving mechanism for bigger performance
gain. :) That's good to hear! As the author of the original code, I truly
believed it's potential and always wanted to make it for more general
pre-initialization via opt-in approach. To help corrodation and avoid
potential waste of work, please let me know if there will be any
duplication or similar work that's described in the selective class
pre-init proposal
<https://docs.google.com/document/d/17RV8W6iqJj9HhjGSO9k1IXfs_9lvHDNgxxr8pFoeDys/edit?usp=sharing>,
particularly on generalizing subgraph archiving (with multi-phases,
multi-class state, including mirror, etc). I'm hoping to contribute the
proposed work to OpenJDK via project Leyden.

Thanks!

Jiangli

> A key assumption of archiving heap objects is -- part of my program will
> always produce the same set of objects, so I can execute it ahead of
> time and save the results for later use. Maybe "closed world" sounds too
> strong, but at least I need to have a "stable world", where I am
> guaranteed to always see the exact same bytecodes in the exact set of
> classes, so I can analyze them to see if they will indeed always produce
> the same results.
>
> The problem is Java classes are loosely coupled, and the linking happens
> only at execution time. A reference to "Foo" can give you a completely
> different class (an app can even define classes dynamically). I hope we
> can introduce a new "linking" concept in the JLS, so Java classes can be
> more strongly combined together into a bigger execution unit.
>
> For example, a "linked" app will already have Foo in the VM's dictionary
> before any bytecodes are executed. So the app won't be able to
> substitute an different Foo. I think this will help not only AppCDS but
> also AOT compilation.
>
> I don't think speculation can help here -- if we have archived a set of
> objects that involves Foo, and have used these objects part away during
> execution, and (assuming we have not yet touched any archived Foo
> objects yet) the app defines a new Foo class, we are stuck. It would
> take tremendous effort to look at the archived objects to patch the new
> version of the Foo objects, and this won't be possible if you add or
> remove fields in Foo. We would also need to add a lot of run time checks
> at every step to guarantee that we indeed load the same classes. All
> these checks will be counterproductive to start-up.
>
> Thanks
> - Ioi
>
>
>
>
>