Call for Discussion: New Project: Leyden

[Claes Redestad]

I think it's important to remember that while leyden is about static,
closed world images, this doesn't preclude work on optimizations that
help full, open world JVM deployments. Just that such work will most
likely be out of scope for _this_ project.

Ideally I think we'd all like to see some cross-pollination where
improvements done to help deliver leyden can also be made to benefit
full JVM deployments - if only partially.

/Claes


On 2020-06-04 12:32, Andrew Dinn wrote:
> On 04/06/2020 11:11, Mike Hearn wrote:
>> If your hypothesis about the benefits primarily coming from discarding
>> data is correct (vs the more direct linkage forms the different AOT
>> compiler can use), is it strictly necessary to discard the data or just
>> not load it on the hot paths? How much research is done on which
>> benefits users are most sensitive to and to what extent it's the closed
>> world optimisations that are driving them, vs all the pre-initialisation
>> and heap snapshotting?
> 
> Reorganizing the data so that hot and cold elements were not interleaved
> on the same page would be a help. However. that means you need to know
> what is hot and what is cold. So, yes a different metadata partitioning
> would win back some of the image size reductions. It's harder to do with
> static field data. You could put the stuff you know for sure gets
> referenced into one segment and stuff that you don't know about into
> another but that's about it.
> 
>> Losing open world is quite painful from a frameworks perspective. A lot
>> of projects that are startup-time sensitive will be unable to go closed
>> world easily or at all, because they are heavily plugin based. Many
>> projects will be forced to pick between convenience and footprint. If
>> it's truly unavoidable then so be it.
> Yes, that's true for some users and some uses. However, I think the need
> for dynamic capabilities is over-estimated. In many cases they are used
> simply because they were there without consideration as to the cost.
> 
> For example, Red Hat's Quarkus product has made it possible to to remove
> many unnecessary uses of dynamic capabilities from most of the common
> enterprise middleware libraries. An enormous number of applications have
> been able to benefit from that to improve footprint and startup time.
> Note those benefits arise when deploying both on the dynamic JVM and as
> native images using Graal Native, although obviusly the JVM savings are
> not as down to the bone as those for Graal (for the reasons I outlined
> earlier).
> 
> n.b. Quarkus operates largely as a build preprocessor that explicitly
> unpicks and substitutes build-time alternatives to replace uses of
> dynamic capabilities (using a variety of code analyses and bytecode
> transformations). Quarkus was not originally developed in order to
> profit from Graal Native deployment. It was developed in response to the
> significant costs that were observed from using dynamic capablilities in
> Java frameworks when a static model was actually all that was really needed.
> 
> n.b. apologies if this comes across as a blurb for a Red Hat product --
> it's not intended to be that.
> 
> regards,
> 
> 
> Andrew Dinn
> -----------
> Senior Principal Software Engineer
> Red Hat UK Ltd
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham, Michael ("Mike") O'Neill
>