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.sm...@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).
