Hi Karen, With my ASM Hat, both CONSTANT_Class_info “;Q<name>” and CONSTANT_ValueType_info that references an UTF8 are Ok for me.
Weirdly, having a CONSTANT_Value_info that reference a CONSTANT_Class_info is little harder to implement because the implementation of ASM is sensitive to the number of levels of indirection (it's hardcoded to be 4, a constant method handle has 4 levels). On the longer term, I think that the spec of CONSTANT_Class should changed to accept a class descriptor and not a class name (which is not BTW because array are accepted in order to encode a method call to an array clone()). It will allow more sharing and unlike a class name, a class descriptor is an extensible format. >From the VM point of view, it's easy to know if a CONSTANT_Class is a >descriptor or not, if it's a descriptor, the last character is a ';'. I also think that the bytecode version corresponding to 10 should requires that all CONSTANT_Class are encoded as class descriptor. regards, Rémi ----- Mail original ----- > De: "Karen Kinnear" <karen.kinn...@oracle.com> > À: "Dan Smith" <daniel.sm...@oracle.com> > Cc: valhalla-spec-experts@openjdk.java.net > Envoyé: Mercredi 14 Juin 2017 17:54:07 > Objet: Re: What's in a CONSTANT_Class? > Update from hotspot implementation: > > We would like to request that for the MVT Early Access we keep the TEMPORARY > CONSTANT_Class_info “;Q<name>”. > > This is far easier for us to implement (we have a prototype in progress) and > we > believe that it will be easier > for bytecode generators to adopt - which will allow us to get more people > trying > MVT so we get more feedback. > > We would also like to keep the explicit separate name for the derived value > class, so that from an implementation > standpoint we are able to continue to use the name, class loader pair as a > unique lookup. > So the JVMS as proposed explicitly calls out 5.3 Creation and Loading that the > derived value class has the name ClassName$Value. > > For Early Access we would like to keep this naming convention, stable across > reboots, so people can generate byte codes > that reference value types by name distinctly from their value capable class. > > thanks, > Karen > > p.s. this will allow us time to do the longer-term exploration of where the > class/type/constant pool forms should evolve
