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