lazy statics design notes

[John Rose]

On Feb 28, 2019, at 2:00 AM, Remi Forax <forax at univ-mlv.fr> wrote:
> 
> static lazy final is lazy because it shares the same late late binding semantics as indy and condy, i.e it uses the CAS of condy so it doesn't need a specific CAS from T.default.


> I think that trying to come that will encompass lazy instance field and lazy static field is a trap, because in the lazy instance case there is no constant pool to store the value.

Hmm… smells like cheese!  Let's go look. :-).~

In this case it's more than a trap; the trap can be turned around to become
an opportunity.

> Given that we already have condy, i prefer to see the lazy static field as a way to provide a symbolic name to get the condy value from outside the class that store the condy.

Sure we already have condy, and that should provide (a) an easy extension
of the current spec. to cover linkage of these guys, and (b) a good implementation.

Looking at the language and user experiences, we see the cheese in
the trap:  "Hey, why do those fields have to be static?  What if I want
a non-static one?  In fact, I'm in the mood to refactor my code to
get rid of statics."

What I'm proposing is not to back away from the condy semantics
for lazy-statics, but rather add a strategic "tweak" to them so that
non-statics can be lazy too.

In short:  If the BSM returns T.default, don't accept it; throw BSME.

At the cost of excluding one point from the value space from a lazy
variable of type T, we gain a wider range of efficient implementation
choices for JVMs.  The excluded point is almost always `null`, which
is a second-class value already; we are putting it to work in its usual
supporting role as a sentinel value.  The excluded point can serve
as a sentinel for reflection, too; a Field::getUnresolved call can return
the sentinel if the lazy field is not yet resolved.

This tweak is very simple.  It may irritate us a little, but will pave the
way for a comfortable story that extends laziness to non-statics also.

— John