Call for Discussion: New Project: Leyden

[Hohensee, Paul]

See also this sub-thread.

https://mail.openjdk.java.net/pipermail/discuss/2020-April/005435.html

Others may correct me, but the gestalt answer I think I got was along the lines of "Project Leyden is restricted to the creation of static images, but feel free to propose a similar project that would allow full Java language support".

I agree that such new, relatively-long-compile-time, optimizations are possible and desirable. What amounts to "whole program" (in quotes because you can't see the whole program in the face of native code, but you can see "large chunks of the whole program") type flow analysis can give you much or the majority of the information you can get from profile-driven type flow analysis and inlining.

Thanks,
Paul

On 5/19/20, 7:10 AM, "discuss on behalf of Mike Hearn" <discuss-bounces at openjdk.java.net on behalf of mike at plan99.net> 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!