----- Mail original ----- > De: "John Rose" <john.r.r...@oracle.com> > À: "Remi Forax" <fo...@univ-mlv.fr> > Cc: "valhalla-spec-experts" <valhalla-spec-experts@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. yes, it's a sub-item item of the issue "when VT/VBC should be loaded" ? Rémi > >> On Jul 23, 2018, at 1:32 PM, Remi Forax <fo...@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 >> adapters. >> >> 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
