notes from Valhalla meeting 5/24/17

[John Rose]

On Jun 21, 2017, at 8:46 AM, Remi Forax <forax at univ-mlv.fr> 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.
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/attachments/20170621/3a78278a/attachment.html>