notes from Valhalla meeting 5/24/17

Frederic Parain frederic.parain at
Sun Jul 23 23:34:37 UTC 2017

> On Jun 21, 2017, at 14:24, Paul Sandoz <paul.sandoz at> wrote:
>> On 21 Jun 2017, at 09:03, John Rose <john.r.rose at> wrote:
>> On Jun 21, 2017, at 8:46 AM, Remi Forax <forax at> wrote:
>>> but i do not like with this proposal as is, i will explain why and how to fix it:
>>> - condy is linked to a static final field but unlike invokedynamic which is a link from an invokedynamic instruction to a CONSTANT_InvokeDynamic_info,
>>>  there is no link from the static final field to the CONSTANT_ConstantDynamic_info.
>>>  Why not reuse the ConstantValue attribute [1] to reference the CONSTANT_ConstantDynamic_info instead (the constantvalue_index can be extended to allow a CONSTANT_ConstantDynamic).
>>> - condy if a 'dy' like indy, so it should do late late binding, i.e. being initialized (run the bootstrap method) only the first time someone access to the static field exactly like with indy the bsm is called the first time you try to access the instruction. 
>>> In term of semantics, my proposal does not introduce an item in the constant pool which is resolved only by the virtue of being in the constant pool unlike any other items. If condy is linked to the ConstantValue of a field, the condy item is resolved when necessary as usual. With my ASM hat, i see how to implement it easily without having to surface the constant pool itself (at least until the items are pointed by the j.l.i.BootstrapCallInfo).
>> Indeed, repurposing ConstantValue in the way you describe is an add-on to this proposal.
> Can we get away with changing all static final fields to be lazily initialized without some explicit opt-in? It would be nice but it might induce subtle changes in behaviour and expectations (especially for where exceptions may occur).

Whatever solution is chosen, it will induce changes in behavior and new places where exceptions
can be thrown. Lazy initialized static fields allow us to support value types in static fields without
having to modify the class loading/class initialization logic. Today if a class A has a static field
of type class B, then class A can be initialized without having to load or initialized class B.
If the rule is changed for value types, meaning that if class A has a static field of type value
type V, then V has to be loaded and initialized before A can be initialized. And of course,
loading and initialization of V can fail, leading to a new kind of initialization failure for A.

The class loading/class initialization is way more complex than field access (at least in the VM),
so we have to balance pros and cons of each solution.


>> I almost threw it in, but didn't want to muddy the basic proposal.
>> In the basic proposal, condy is *not* linked to static finals.
>> It only repurposes the concept of field names and field types
>> (as if from Fieldref but not using Fieldref) but does not actually link to fields.
>> — John

More information about the valhalla-spec-observers mailing list