Static value fields initialization

[Karen Kinnear]

John,

Thank you for the detailed responses. The big remaining issue is the static value field initialization,
so I have extracted that to the top here:

>  In our experiments, I'd like to lift restrictions
> on static field types sooner rather than later.  (A workaround for Java
> coders would be to define a private static inner class to hold the
> problematic statics, but I'd rather not have this sharp edge.)

So my original email was working on the assumption that we would require
pre-loading the value type for all local fields, instance and static. Pre-loading implies
risk of class circularity issues.

What I am hearing here is that you would like to be able to define a static field of the same type as the
defining value class.

With the clarifications below, here is a proposal of how we might do that:
1. pre-load value types used in instance field declarations.

2. for static fields declared to contain a value type:
    JVMS 5.4.2 describes that static fields are created and initialized to their default values at Preparation,
    without requiring execution of any JVM code.
    If we were to load the value types for static fields at link time, prior to Preparation, we would
    have the size information needed to create the default value to fill in the static fields.

With link-time loading, the current value type has already been loaded, so there is no
risk of circularity.

So - it looks like we can lift this restriction on static field types.

Minor corrections below - and thanks for those.
Karen
> On May 30, 2018, at 4:32 PM, John Rose <john.r.rose at oracle.com> wrote:
> 
> On May 30, 2018, at 1:14 PM, Karen Kinnear <karen.kinnear at oracle.com <mailto:karen.kinnear at oracle.com>> wrote:
>> 
>> John,
>> 
>> Very much like the direction of your proposal, which I summarize as:
>> 
>> 1. preparation: continue no code execution
>>  VM determines default value via size information from loaded class 
>>  (flattened fields are pre-loaded, so we have that information at preparation time)
>> 
>> 2. pre-<clinit>: <clinit> of the containing class requires <clinit> for all entries
>> in the ValueTypes attribute prior to completing its own <clinit>
> 
> Yes.  Point 2 expands slightly to be "ensure VT.<clinit> before any bytecode
> usage of VT.”
That is an improvement.
> 
>> 
>> ----
>> 
>> I think we could optimize this to pre-<clinit> for entries in the ValueTypes attribute that
>> are referenced by local flattenable fields, static or instance.
>> 
>> Specifically: we have entries in the ValueTypes attribute for:
NameAndType Descriptors:
>> 1. local fields
>> 2. local method signatures
>> 3. remote fields
>> 4. remote method signatures
5. all CONSTANT_Class_info constant-pool resolution (apologies for missing this) 
>> 
>> I think we only need the pre-<clinit> for #1 
> 
> I agree, and would prefer this.
> 
>> 3. I think we also need to ensure that other bytecodes that can return a default value instance
>> of a value type would also require <clinit> of the value type:
>>  defaultvalue, anewarray, multianewarray (JVMS draft 4d already includes defaultvalue, but not yet array bytecodes)
> 
> Good catch on defaultvalue (what I meant by "vdefault").
> 
> The array bytecodes *do* load the array element class, so we are close
> already.  The missing bit, I think, is to inspect the loaded array class,
> see if it is a value type, and run <clinit> before creating the array.
> This will require us to adjust our initialization barriers a little.
> 
>> Still exploring to see if there are any holes in these assumptions, appreciate additional  eyes on this.
>> So far so good.
> 
> I'm very glad you think so.  In our experiments, I'd like to lift restrictions
> on static field types sooner rather than later.  (A workaround for Java
> coders would be to define a private static inner class to hold the
> problematic statics, but I'd rather not have this sharp edge.)


> 
> — John