Updated SoV documents

[Frederic Parain]

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.goetz at 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-bounces at openjdk.java.net> wrote on 2020/03/27 03:59:38 PM:
>> 
>> > From: Brian Goetz <brian.goetz at oracle.com>
>> > To: valhalla-spec-experts <valhalla-spec-experts at openjdk.java.net>
>> > Date: 2020/03/27 03:59 PM
>> > Subject: [EXTERNAL] Updated SoV documents
>> > Sent by: "valhalla-spec-experts" <valhalla-spec-experts-
>> > bounces at 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
>> > 
>> 
>> 
>