Default values of static fields

[John Rose]

On Jan 8, 2019, at 5:13 PM, Ioi Lam <ioi.lam at oracle.com> wrote:
> 
> http://cr.openjdk.java.net/~fparain/L-world/LW2-JVMS-draft-20181009.pdf says:
> 
>   5.4.2. Preparation
> 
>   Preparation involves creating the static fields for a class or
>   interface and initializing such
>   fields to their default values.
> 
> However, in the current implementation, for a class like this:
> 
> class Test {
>     static Point p;
> }
> 
> The slot for p as stored in the mirror object of the Test class is NULL. When the JVM reads Test.p, it must do a NULL check, and return Point.default as appropriate.
> 
> Is there any reason for doing this? Why don't we initialize Test.p to point to Point.default when we allocate the mirror for Test?

I'm pretty sure it would be impossible to do this; is that a good reason?  :-)
I'd love to be proven wrong.

The problem is that class mirror for Test is created very early, before the
instance layout of a related class Point is known.  In fact, Test might need
to be fully prepared before Point is even loaded.

Loading Point more eagerly is desirable, and that's one of the functions
of the Q-descriptor (and of the earlier ACC_FLATTENABLE bits),
to signal the JVM to get more information about the class than it
usually would for a run-of-the-mill L-type.

But eager loading only goes so far; you can easily make circular
dependencies from Test to Point (here), and in reverse back from
Point to Test.  There must be a way to boot up such a cycle.

The only satisfactory way around this, IMO, is to put a hidden
indirection on static variables (of Q-type), initialize it with null,
and later on make sure the nulls don't "leak" into the semantics
of bytecode execution.  (Unless, of course, the Q-type turns
out, on inspection, to be null-friendly, but that's a different issue.)
 
This leads to guards to filter out the hidden nulls, at least during
bootstrapping.  Also it probably involves going back and patching
the hidden static variable pointers to non-null references to the
appropriate all-zero-bits "vull" value, but only after that value's
class is loaded.

— John