Moving from VVT to the L-world value types (LWVT)
john.r.rose at oracle.com
Wed Jan 24 21:53:47 UTC 2018
On Jan 24, 2018, at 12:24 PM, Frederic Parain <frederic.parain at oracle.com> wrote:
>> Do we want to describe the default value of a value class type?
>> Perhaps we can leave these changes for Dan.
> The default value for the _reference_ type is null.
> Which is different from the default value of an instance of a value class.
> The content of the default value for value class is define with the
> defaultvalue bytecode:
> "All instance variables of the instance must have their default initial values (§2.3, §2.4)."
> This a “pointer" vs “instance designed by the pointer” distinction.
> But it could be confusing. I’m open to better suggestions.
Nullability is the confusing bit. Variables which are not primitives
or flattened values are inherently nullable, and default to null,
they are references. Even though their class is a value class.
We are convincing ourselves that this is OK for variables which
are JVM stack or local variables. It may also be true for fields,
in some corner cases.
Basically, if classfiles get out of sync, you can witness polluting
nulls in variables which are not flattened. Including fields.
We could restrict the confusing pollution if we could somehow
ensure that field variables whose classes are value classes
are *always* flattened, even if the class defining the field
"forgot" to ask for the flattening. The practicalities of classfile
evolution make this hard to enforce, so I think we are stuck
with nullable value fields as a corner case: Exactly when
the class "forgets" to say ACC_VALUE_TYPE.
(BTW, maybe it should be ACC_FLAT. So a class defined
as ACC_FLAT is a value class, and a field defined ACC_FLAT
loads the field class and inlines that class's layout, if it's
a value class. Flatness is a linked but distinct property of
classes and fields.)
>> 4.1/ 4.5
>> From our discussion today, it sounds as though we can try Remi’s original/John’s proposal
>> for just tracking knowledge of a value type in the class file at two places:
>> 1) when declaring a class, the class access_flags would add ACC_VALUE_TYPE
>> 2) when declaring a field, the field access_flags would add ACC_VALUE_TYPE
>> (small note - can we use 0x100?)
>> 6 invoke special
>> Where do we throw an exception if we have an <init> method in a value class? Would that be verifier?
>> Just in case they skip verification, might it be worth throwing an exception if the resolved method is an
>> instance initialization method and the class is a value class - would that be an ICCE? or a NoSuchMethodError?
Eventually we need to forbid object-style <init> methods in
value classes, as a local structural constraint. We can be
lax to start with, since such <init> methods will never run.
Alternatively, we could allow value types to define <init>
methods but require them to be static factories. That is,
they must be ACC_STATIC and must return the value type.
They must also have at least one parameter, since the
nullary constructor should be reserved, to denote the
There's no advantage to this at the JVM level, compared
with regular factory methods. But such a could provide
a translation strategy for the value-type version of a
var x = Complex<double>(0.0, -1.0);
// invokestatic Complex<D>.<init>(DD)Complex<D>
> This is a point we should discuss with the langtools team.
Yes; if they want to repurpose <init>, we can do it. Or if they
want to make a new token <make>, or some some standard
string, it's up to them, I think.
> Today, even Valhalla Value Types have an <init> method because javac refuses to compile a
> class with final fields that are not initialized in a constructor.
That's why we want to be lax today, until we can tighten
up the rules.
> It makes sense to forbid the <init> method for value class, but there might be consequences
> I cannot see yet.
I think it's safe to remove <init>. I suggest we *start* by
removing <init>, and let the langtools people tell us what
to put back in its place.
More information about the valhalla-dev