What's in a CONSTANT_Class?

Karen Kinnear karen.kinnear at oracle.com
Mon Jun 12 19:15:09 UTC 2017


I am really glad we are exploring the longer term picture of how to handle the constant pool.

(note: not to be confused with the Minimal Value Types exercise)

I would like to add a couple of constraints/questions/concerns please:

1) No change in meaning of any existing constant pool entries
   Dan Heidinga correctly pointed out the challenge, that while we may have a classfile version on the classfile as generated originally,
   tools will be injecting byte codes assuming the meaning of existing constant pool entries, and will be adding constant pool entries
   prior to having any knowledge of classfile version changes.

2) impact on APIs
  I need a better understanding on how a user is going to represent the difference between a QFoo and an LFoo in source?
  And whether we are going to be changing/augmenting APIs that currently take a class name if we want them to extend to support
  value types rather than always requiring boxing. Today we have a name/loader unique runtime type guarantee and the loader can be
  determined from context. 

3) impact on tools
   We need feedback from tool developers.
   Maurizio has mentioned concerns relative to ASM.
   Please look at the JNI and JVMTI type signatures - they expose for instance the JVMS BasicTypes
   so changes here break tools.


4) prototype support
   For value types and for specialization, let’s make sure that any proposal could have a prototype/ implementation that allows generation
   of separate classfiles, so two UTF8s. (e.g. what I was proposing was that any derived type would have both its own name
   and a link to the “root” type from which it derived. I think that could apply to species as well as to value types but you have
   probably thought this through more than I have). 

5) Adding Type information rather than Class information has a ripple effect on the JVM implementation - we need to study in more
  detail how this changes other constant pool entries such as StackMapTable etc.

6) Descriptor ambiguity
   We need to make sure that we design descriptors after we have figured out what a UType is.
   Descriptor matching (nominal or structural) works with exact matches. If you introduce a polymorphism that allows for
   multiple potential correct matches, you have to work out resolution, overriding and selection rules in great detail (and pay the performance cost).

> On Jun 9, 2017, at 11:43 AM, Dan Smith <daniel.smith at oracle.com> wrote:
>> On Jun 8, 2017, at 8:44 PM, John Rose <john.r.rose at oracle.com> wrote:
>> The void quasi-type should be lumped into PrimitiveType, for the sake
>> of ldc (void.class).
> I see the appeal, though it also, unfortunately, expands the set of "primitive types" and means we have to restrict that set at the use sites:
> CONSTANT_ArrayType_info {
>  u1 tag; // 21
>  u2 component_index; // PrimitiveType **but not void**, ClassType, ArrayType, or SpeciesType
> }
> CONSTANT_SpeciesType_info {
>   u1 tag; //22
>   u1 mode_code; // 'L'=76 or 12, 'Q'=81 or 13
>   u2 class_index; // Class
>   u2 enclosing_index; // ClassType or SpeciesType
>   u2 typearg_count;
>   u2 typeargs[typearg_count]; // PrimitiveType **but not void**, ClassType, ArrayType, or SpeciesType
> }
> CONSTANT_MethodDescriptor_info {
>  u1 tag; // 23
>  u2 parameter_count;
>  u2 parameter_descriptors[parameter_count]; // PrimitiveType **but not void**, ClassType, ArrayType, or SpeciesType
>  u2 return_descriptor; // PrimitiveType, ClassType, ArrayType, SpeciesType, or 0 (void)
> }
> CONSTANT_FieldDescriptor_info { // is this wrapper useful?
>   u1 tag; // 24
>   u2 type_index; // PrimitiveType **but not void**, ClassType, ArrayType, or SpeciesType
> }
> - Any non-void type (CONSTANT_Class, CONSTANT_ArrayType, CONSTANT_ClassType, CONSTANT_SpeciesType, or CONSTANT_PrimitiveType **that isn't void**):
> anewarray
> verification_type_info.Object_variable_info
> - Any type or void (CONSTANT_Class, CONSTANT_ArrayType, CONSTANT_ClassType, CONSTANT_SpeciesType, or CONSTANT_PrimitiveType):
> ldc
> BootstrapMethods.bootstrap_arguments
> I prefer the discipline of making 'void' a separate entity (CONSTANT_Void?) that we don't necessarily call a "type", although not sure that carries its weight.
>> Note that very small integer constants
>> (which would correspond to PT sub-tags) are *not* usually
>> stored in the CP; they are loaded with short instructions
>> like "bipush", not "ldc".
> Yes, and that works fine for instructions (see also newarray). The new requirement here is for another constant pool entry to need to talk about one of these very small things, and in a polymorphic way (e.g., the component type of an array may be a primitive or some other type).
> —Dan

More information about the valhalla-spec-observers mailing list