Call for Discussion: New Project: Leyden

[Andrew Dinn]

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