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 b
On May 30, 2018, at 1:14 PM, Karen Kinnear 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
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-: of the con
On May 25, 2018, at 8:18 AM, Frederic Parain wrote:
> … Let’s consider the model for minimal L-world 1, where all value
> fields are flattenable. Static value fields must be initialized to their
> default value at preparation time, which implies the initialization
> of their value class. Here’s th
The JVMS has to be modified to cover the initialization of
static value fields. However, the implications of the change
should be evaluated carefully before committing them.
The JVMS10, section 5.4.2 Preparation says:
"Preparation involves creating the static fields for a class or
interface and i
