How to represent value based classes ?
forax at univ-mlv.fr
forax at univ-mlv.fr
Mon Jul 23 20:51:24 UTC 2018
----- Mail original -----
> De: "John Rose" <john.r.rose at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "valhalla-spec-experts" <valhalla-spec-experts at openjdk.java.net>
> Envoyé: Lundi 23 Juillet 2018 22:46:14
> Objet: Re: How to represent value based classes ?
> Interesting exercise. You don’t need the extra bit in the attributes it you can
> defer null processing decisions until the VT/VBC is actually loaded. I think
> that’s possible.
it's a sub-item item of the issue "when VT/VBC should be loaded" ?
>> On Jul 23, 2018, at 1:32 PM, Remi Forax <forax at univ-mlv.fr> wrote:
>> Hi all,
>> i've plyed for some quite times now to specify in my mind what a value based
>> class can be and i think it's time write that down.
>> First, why we need value based class ?
>> We want to offer a path to refactor a class to a value type but given that class
>> instances are nullable and value type values are not, the proposed solution is
>> to introduce a kind of 'compatible with null' value type i.e. a value based
>> class. Java in its API already specifies that some classess (Optional,
>> LocalDateTime) are value based classes saying that they have no identity.
>> What is the best outcome ?
>> The best case is like checked exceptions, i.e. the VM doesn't know what a value
>> based class is and only javac knows what a value based class is and add some
>> magics, do null tranlation back and forth. But i doubt it's possible because
>> with the ValueTypes attribute, a class can not be a reference class and as a
>> value type inside the same method, so the VM has to do the conversion in
>> Proposed wrapping/unwrapping:
>> A value based class is a value type with one discriminator field. A
>> discriminator field is a field that is annotated with the flag
>> ACC_DISCRIMINATOR (only one by value based class). Technically from the VM
>> implementation point of view, a discriminator is a field_offset + a type.
>> class -> value type
>> if (null) -> vdefault
>> value type -> class
>> if (vt[discriminator_offset] == 0) -> null
>> The Value Type attributes also need to be modified to include a boolean that
>> says if it's a plain value type or a value based class.
>> By example, for java.util.Optional, the field that contains the reference is
>> also the discriminator field, which means that the difference Optional as value
>> type and Optional as value based class is that the interpreter and the JIT may
>> have to execute more tests to do null wrapping/unwrapping.
>> For java.util.OptionalLong, here we need a supplementary field, a boolean (a
>> byte), is enough. In that case, the value based class may take more space +
>> more tests.
>> For the class of java.time, Stephen can choose on per class basis, how to null
>> as to be encoded.
>> To summarize:
>> A value based class can be either a class with some JIT optimizations but the
>> layout of a class or a value type with a way to encode null, i think the former
>> solution is sad.
>> Obviously, i'm not a specialist of the assembly languages so there is maybe
>> another encoding scheme.
>> I think that letting the user to specify the discriminator field solve the issue
>> to have to come with a general scheme that works for all value based classes,
>> because you offload the verification that the discriminator can not be zero in
>> the normal case to the user.
> > Rémi
More information about the valhalla-spec-experts