Dan, 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. http://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/types.html#wp16432 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). thanks, Karen > On Jun 9, 2017, at 11:43 AM, Dan Smith <daniel.sm...@oracle.com> wrote: > >> On Jun 8, 2017, at 8:44 PM, John Rose <john.r.r...@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
