Experimentation with build time and runtime class initialization in qbicc

[Kasper Nielsen]

On Tue, 31 May 2022 at 16:50, Dan Heidinga <heidinga at redhat.com> wrote:

> On Fri, May 27, 2022 at 7:53 AM Kasper Nielsen <kasperni at gmail.com> wrote:
> >
> > Hi David,
> >
> > Thanks for the write-up.
> >
> > One thing that isn't completely clear to me after reading this is why
> > language
> > changes (<rtinit>) are needed?
>
> The <rtinit> model was a convenient way for us to explore a model that
> put all class initialization at build time, while allowing a small set
> of fields to be reinitialized at runtime.  It also minimized the
> changes we had to make to the core JDK classes which makes maintaining
> the changes much easier given the rate of JDK updates.  SubstrateVM
> uses a similar approach with their Substitutions for what I assume are
> similar reasons.
>
> Leyden will be able to update the JDK core classes directly and can
> take a more direct approach to indicating in which phase a static
> field should be initialized.
>
> >  It seems to me this could be entirely
> > implemented via a standard API. Using ClassValue as the main inspiration
> you
> > could have something like:
> >
> > abstract class RuntimeLocal<T> {
> >     protected RuntimeLocal() {
> >        checkBuildTime();
> >        VM.registerForRuntimeInitialization(this);
> >     }
> >     protected abstract T computeValue();
> >     public final T get(); // Calls to get are optimized by the vm
> > }
> >
> >
> > Usage would be something similar to:
> >
> > class Usage {
> >
> >  static final LocalDateTime BUILD_TIME = LocalDateTime.now();
> >
> >   static final RuntimeLocal<LocalDateTime> RUNTIME_TIME = new
> > RuntimeLocal<>() {
> >     protected LocalDateTime computeValue() {
> >       return LocalDateTime.now();
> >     }
> >   };
> > }
> >
> > I might be missing some details, but it seems to me that this approach
> would
> > be strongly favorable to needing to change the language as well as adding
> > new bytecodes.
>
> This is a good starting point.  I went a fair ways looking at how to
> group static fields into different classes to decouple their lifetimes
> and found that I couldn't cleanly split them into two groups.


I think there is an important distinction to make here between "phased class
initialization" and "phased field initialization".

Having used GraalVM's native image for some time. My experience is that is
very hard to reason about phased class initialization.

A saner model, I would argue, would be one where all classes are
initialized at
image build-time and never reinitialized. If a class needs laziness or
reinitialization this must be done explicitly using <rtinit>/RuntimeLocal.
If
you have groups of fields that need to be initialized together this can be
done by storing them in a record which can then be stored in a
reinit field. In this model, you would still need to think about the usage
of
reinit fields. But you would never need to spend cycles on figuring out what
phase a class was initialized in.

But this is all something that can be discussed further down the line.


> The problem is that while it's clear that some fields can be
> initialized early (build time) and others must be initialized late
> (runtime), there is a third group that needs to be reinitialized.  I
> list 3 buckets: early, late, and reinit, but that's a minimum number.
> There may be more than 3.  And due to the "soupy" nature of <clinit>,
> it's not always easy to avoid depending on a field that's in a
> different bucket.  And values in that 3rd bucket - the fields that
> need to be reinitialized - don't have a clear meaning when their value
> propagates around the program.  Does it need to be cleared everywhere
> and force reinit of all consumers? Lots to figure out here.
>
> We need a better model - whether that's library features or new
> language features - that makes it easier to express when (which phase)
> an operation should occur and some way to talk about the dependency
> chain of that value (all the classes that have to be initialized,
> values calculated, etc).
>

I must admit I'm a bit skeptical about something like dependency tracking.
Take something like System.lineSeparator() and a platform-independent image.
Is it really realistic that we track all strings that are created using this
method doing build-time? But, as you said lots to figure out:)