I haven’t mentioned bytecodes that are using CONSTANT_Class_info indirectly, all the get/put and invoke bytecodes which are using CONSTANT_Class_info through CONSTANT_Methodref_info and CONSTANT_Fieldref_info. Anyway, they don’t need ReferenceType either.
Fred > On Apr 3, 2020, at 13:08, Frederic Parain <frederic.par...@oracle.com> wrote: > > Hi, > > This is a good question. > > The ReferenceType descriptor was added to make the distinction between the > two VM-level > type sharing the same class name. The CONSTANT_Class_info is used by the > following bytecodes: > - ldc > - new > - defaultvalue > - anewarray > - multianewarray > - checkcast > - instanceof > > I’m not seeing any case now where a ReferenceType would be needed. All these > bytecodes can > work properly with the old fashioned CONSTANT_Class_info. For bytecodes like > new, defaultvalue, > anewarray, multianewarray, the class is loaded, so verifications are > performed at runtime > (for instance, new can throw an InstantiationError if the loaded type is an > inline type), > and layout information are available to allocate structures likes arrays. > > The Q-signature is used as a marker for inline types > (null-free/immutable/identity-free), > but also as a pre-loading and eager-loading signal. The places where it is > used as such a > signal are the descriptors in field_info and method_info, which point > directly to an > Utf8 entry. > > CONSTANT_Class_info is also used for the this_class and super_class fields at > the classfile > top-level structure. In both cases, there’s no need to have a ReferenceType: > no distinction > is needed, and these types are loaded anyway, so verification is performed on > loaded types. > > Unless I’ve missed something, I would say that we are clear to return > CONSTANT_Class_info > to its pre-LW2 format, supporting only "binary class or interface name”. > > Fred > > >> On Apr 2, 2020, at 12:26, Brian Goetz <brian.go...@oracle.com> wrote: >> >> Hi Tobi; >> >> I don't have an answer for you offhand, but the current "eclair" model >> eliminates one of the reasons we needed the new syntax for C_Class -- that a >> class name could refer to two VM-level types. This is no longer the case; >> each VM type corresponds to exactly one classfile. >> >> The reason I can't give you an unqualified yes at this point is that I am >> not sure whether we still need to include a "Q" somewhere as a preload >> signal. When Q descriptors appear in certain places (e.g., field >> declarations), they generate load order constraints, and in other places, >> they generate nullity assumptions. >> >> I will leave it to Frederic to answer whether we have run out of reasons to >> need anything other than binary class names in C_Class structures. (It >> would be nice if we have!) >> >> On 4/1/2020 10:19 AM, Tobi Ajila wrote: >>> Hi Brian >>> >>> Thanks for the updated SoV docs. In section 4, it mentions: >>> >>>> In most cases, such as field descriptors and method descriptors, uses of >>>> C.ref is translated as LC$ref;, uses of C.val is translated as QC$val;, >>> >>> In the LW2 spec the `name_index` in `CONSTANT_Class_info` structures could >>> refer to "binary class or interface name" as well as "ReferenceType >>> descriptors" which referenced UTF8s with 'Q' descriptors. In LW2 >>> inline-types were both nullable and null-free so it was necessary to have >>> ReferenceType descriptors in order make a distinction in >>> CONSTANT_Class_info structures for things like allocating arrays. With the >>> new model inline-types can only be null-free, so will the >>> CONSTANT_Class_info structures be limited to binary class or interface >>> names? or will ReferenceType descriptors be used for inline-types? >>> >>> --Tobi >>> >>> "valhalla-spec-experts" <valhalla-spec-experts-boun...@openjdk.java.net> >>> wrote on 2020/03/27 03:59:38 PM: >>> >>>> From: Brian Goetz <brian.go...@oracle.com> >>>> To: valhalla-spec-experts <valhalla-spec-experts@openjdk.java.net> >>>> Date: 2020/03/27 03:59 PM >>>> Subject: [EXTERNAL] Updated SoV documents >>>> Sent by: "valhalla-spec-experts" <valhalla-spec-experts- >>>> boun...@openjdk.java.net> >>>> >>>> I've updated the SoV documents, including the new sections on VM >>>> model and translation: >>>> >>>> http://cr.openjdk.java.net/~briangoetz/valhalla/sov/01-background.html >>>> >>> >>> >> >
