Moving from VVT to the L-world value types (LWVT) (original) (raw)

John Rose 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 accessflags would add ACCVALUETYPE 2) when declaring a field, the field accessflags would add ACCVALUETYPE (small note - can we use 0x100?) Fixed

+100 ...

6 invoke special Where do we throw an exception if we have an 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 methods in value classes, as a local structural constraint. We can be lax to start with, since such methods will never run.

Alternatively, we could allow value types to define 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 default value.

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 "new" expression.

var x = Complex(0.0, -1.0); // invokestatic Complex.(DD)Complex

This is a point we should discuss with the langtools team.

Yes; if they want to repurpose , we can do it. Or if they want to make a new token , or some some standard string, it's up to them, I think.

Today, even Valhalla Value Types have an 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 method for value class, but there might be consequences I cannot see yet.

I think it's safe to remove . I suggest we start by removing , and let the langtools people tell us what to put back in its place.

— John

More information about the valhalla-dev mailing list