Revisiting default values
Peter Levart
peter.levart at gmail.com
Tue Jul 14 12:39:07 UTC 2020
What about a variant of G or J where an inline class would designate a
single field to be used for "isDefault" checks. Instead of comparing all
fields for "zero" value, a single designated field would be used in
checks. So a class is free to choose which of the existing fields is
"never zero/null" in the set of valid class states or can even add a
special-purpose (boolean) field to be used just for that. Often no such
special field would need to be added.
WDYT?
Peter
On 7/13/20 8:19 PM, Dan Smith wrote:
>> On Jul 10, 2020, at 12:23 PM, Dan Smith <daniel.smith at oracle.com> wrote:
>>
>> Option G: JVM support for default instance guards
>>
>> Inline class files can indicate that their default instance is invalid. All attempts to operate on that instance (via field/method accesses, other than 'withfield') result in an exception.
>>
>> This tightens up Option F, making it just as impossible to access members of the default instance as it is to access members of 'null'.
>>
>> Same issues as Option E regarding adding a "new NPE" to the platform.
> There's a variant of this that deserves spelling out:
>
> ---
>
> Option J: JVM treats default instance as 'null'
>
> Like Option G, an inline class file can indicate that its default instance is invalid—in this case, 'null'. All attempts to operate on that instance result in an NPE. Conceptually, the null instance and the null reference are the same, and should generally be indistinguishable.
>
> (We explored this awhile back as a tool for migration, before going in a different direction.)
>
> Some implications:
>
> - The VM probably wants to normalize its encodings (null reference vs. null instance), meaning there's a translation layer on field/array reads, just like Option I, and also for field/array writes, just like Option D.
>
> - Casts to Q types for certain classes should also translate from null reference to null instance, rather than NPE.
>
> - For these classes, the 'withfield' instruction is uniquely able to operate on and produce 'null'.
>
> - In the language, the 'null' literal can be assigned to some inline types. (In the VM, the verifier could require using 'defaultvalue' instead, if it wants to avoid some class loading.)
>
> - We could revisit the question of whether it's possible to migrate an identity class to be an inline-default inline class as long as the default instance is 'null'. (There are additional issues, like binary compatibility. But we could we-open that exploration...)
>
> ---
>
> My sense is that Option I dominates Option J by most measures—it achieves the same result (default value is invalid), with less work at flattened storage barriers, fewer tweaks to the rest of the system, and a more useful programming model (no nulls being passed around).
>
More information about the valhalla-spec-observers
mailing list