Experimentation with build time and runtime class initialization in qbicc

Kasper Nielsen kasperni at gmail.com
Fri May 27 11:53:09 UTC 2022


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? 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.

/Kasper

On Thu, 26 May 2022 at 21:22, David P Grove <groved at us.ibm.com> wrote:

> Hi,
>   I’ve appended the contents of the referenced wiki page in this email.
> Apologies in advance if the formatting doesn’t come through as intended.
>
>                 There is a full implementation of this (GPLv2 + Classpath
> exception) as part of the qbicc project on GitHub.  There is also a GitHub
> discussion in the qbicc project that links to various GitHub issues that
> capture the history that led to the current design.  I will not hyperlink
> to those here so that if people have any IP concerns, they can avoid seeing
> them.  They are easily findable.
>
> Regards,
>
> --dave
>
>


More information about the leyden-dev mailing list