Dan - I can’t find it either. We’ll have to ask John.
thanks, Karen > On Jun 21, 2017, at 9:55 AM, Daniel Heidinga <daniel_heidi...@ca.ibm.com> > wrote: > > > AI: John - send out javadoc to EG > > derived class := Class.derivedClassFactory(Class mainClass, T userData, > > String name) > > In the spirit of the usual "5 min before the meeting" ritual action item > panic, I'm trying to review the javadoc for this and can't seem to find it. > Can it be sent again? > > Thanks, > --Dan > > ----- Original message ----- > From: Karen Kinnear <karen.kinn...@oracle.com> > Sent by: "valhalla-spec-experts" > <valhalla-spec-experts-boun...@openjdk.java.net> > To: valhalla-spec-experts@openjdk.java.net > Cc: > Subject: minutes Valhalla EG June 07, 2017 > Date: Wed, Jun 7, 2017 4:28 PM > > Valhalla EG Minutes June 07, 2017 > > attendees: Bjorn, Dan H, Dan S, John, Vlad, Frederic, Lois, Brian, Maurizio, > Karen > > AI ALL: > Dan Smith sent an initial draft of a JVMS with experimental support for MVT > for review. > Feedback in email requested - sooner rather than later please. > AI ALL: > Review embedded proposal for issue 1 - John javadoc to avoid exposing > internal derived value type name > Review embedded proposal for EA for handling CONSTANT_Class > > Timing note: > Value type exploration is following three timeframes: > Minimal Value Types Early Access (EA) - goal: ASAP so we can get > feedback from initial users > Minimal Value Types (MVT) - goal: w/JDK10 for much broader feedback > Valhalla Value Types - "real" vs. shady values - much richer feature set > Some of the issues we are exploring - such as type vs. class will need to > evolve, so we need > to reach decisions on our initial EA stake in the ground ASAP. > For that - review of and conclusions to JVMS and other open issues is > needed. > > Issue 1: Exposure of mirror and mirror name for the value class > Bjorn: (please correct any inaccuracies) > IBM implementation does NOT expose the value type mirror name > ValueType.valueClass is the only way to get the value type mirror > getClassName returns the same answer > 2 java objects, same underlying data > no internal derived value type name is exposed > > John: proposal for breaking the link to the secondary mirror > Model is that there is one primary mirror and multiple secondary mirrors > Brian: one nominal class and multiple derived classes analogous to a > DirectMethodHandle and derived > MethodHandles > Later reflection couild add APIs at the java level to get the secondary > mirrors > - has an initial proposal in which you pass in > head class, user data (e.g. value type descriptor), user-chosen name > name is not resolvable, doesn't work for findClass, but visible when > reflecting > > Dan H: do we need to ensure user name/user data consistent? That has been an > issue in related APIs? > John: no > Karen: assume we can not use this name to look up a class (forName)? just for > reflection to print? > John: not for lookup > > Maurizio: this could be useful today (i.e. for EA) for a value class > Issue: Reflection behavior for EA > Karen: we already agreed reflection will not work - will throw an exception > Maurizio: it could be actually easier to use John's factory than to throw > an exception > > Timing: > AI: John - send out javadoc to EG > derived class := Class.derivedClassFactory(Class mainClass, T userData, > String name) > All: evaluate proposal both for doability > also evaluate for timing: EA vs. MVT? > > > Issue 2: Constant Pool representation for derived value type (JVMS term: > value class) > > Goals: > 1. cache point for usage - need separate storage for DVT and VCC > 2. prefer not to do string parsing over and over to get the mode > 3. verifier ensure type safety without additional eager class loading > 4. ensure single resolution of underlying value-capable-class > (longer-term want single resolution of underlying source classfile) > 5. allow implementations to support older classfiles > 6. tool support - make sure this works for a mix of constant pool changes > e.g. tools that do not know about new versions still instrument new > classfiles > - need to make sure these still work as much as possible > - so for these folks we need to not change the meaning of CONSTANT_Class > 7. future - make sure the model works for future derivation from more than > one type > - e.g. Foo<Bar> > 7a. request that for a Parameterized Type: this_class (name and > CONSTANT_Class today) > allows lazy resolution of the list > (ed. note: need to discuss details of "lazy" here - loading the class > file perhaps, > but instantiating a type from it will need the parameterizations, so far > we have > conceptually recorded the loaded class file under the "head" type, with > default/erased > parameterizations) > 8. upside opportunity: Constable and pattern matching - helpful if all > class objects > were represented the same way when generating bytecode > e.g. int.class vs. Integer.class require different handling today > 9. migration: a class should be able to migrate to being a value type > approach: will require boxing to access, but if you pass for example a > boxed value type > the current client should continue to work > 10. migration: value type to reference? Open question > > 11. ed. note: we did not mention that for MVT we actually have multiple > source classfiles and > at least one potential prototype for parameterized types also generates > separate classfiles. > While we strongly do not want to build in the concept of multiple separate > classfiles, it > would be valuable if the constant pool representation was able to support > that. > This might help extend to nested classes as well. > > John: > > two views of CONSTANT_Class: > 1. is it a type? then need nested CONSTANT_ClassFile: Class[ClassFile] > 2. is it a loaded class file? then need surrounding decoration > Type[Class] > bad third choice: 3. use separately resolved peers Class["name.1"], > Class["name.2"] where name is mangled but > refers to same loaded class file > > Today: CONSTANT_Class represents both the type and the loaded class file. > > Dan S: > Prefers option 1: type with a reference to a raw classfile > (ed. note - Dan S - I didn't get any details on why you prefer this for > longer-term, it would help > to understand) > (ed. note - Dan S - can you add some notes on how to represent goal #11?) > > Bjorn: > Are there any cases in which a classfile does not represent a reference > type? > Valhalla - goal is that the classfile represents both value type and the > boxed value type > > Proposal from John/Karen: > CONSTANT_Class_info: used for both the "head" LType and the classfile - > conflate for backward compatibility > CONSTANT_Value_info: mode information and references the underlying > CONSTANT_Class_info > Parameterized type: has auxiliary info and references at least on > underlying (head) CONSTANT_Class_info > e.g. List<Foo> would reference List class, and Foo would linked to in > auxiliary info > > AI: All > Explore this potential model: > Would this make sense from a JVMS perspective? > Would this work for JVM implementations? > Would this work for bytecode generation etc? > - please check if this is feasible short-term, i.e. for EA > - also explore if we could "flop" to #1 later > > Feedback: > John: short term: Try the proposal above with CONSTANT_Value_info refering to > an underlying CONSTANT_Class_info > Spec direction is likely to be CONSTANT_Class references a Classfile > Lois: ok with verifier > Frederic: ok with bytecodes > Bjorn: prefer #3 ;Q - for MVT - it has minimal impact > ok with #2, but the change wouldn't slow us down much > Frederic: todwy - handle by using separate opcodes and all have CONSTANT_Class > (ed. note - and we haven't implemented the verifier which would like to > sanity check > that the CONSTANT_Class matches the expected type in the opcode) > > > --- > 3. Ways to phase out current classfile capabilities such as CONSTANT_Class? > Or LDC CONSTANT_Class? > Brian: jigsaw added the (not so popular) concept of runtime warnings > Maurizio - jsr/ret deprecated (John: ACC_SUPER) - not used much - javac was > primary client at the time > StackMapTable added - lots of complaints > > What if long-term we were to derive arrays using multi-level constant pool > entries > What if we were to support Q[ as well as L arrays? > - immutable, non-nullable, identityless > > John: What if we were to evolve CONSTNAT_MethodType - currently a flat string > to use tree structured approach? > > Dan H: limited numbers of places we parse descriptors > Karen: don't slow down our resolution method and field lookup > Dan H: limited to resolution time > Dan S: might be faster to look up using tree comparison vs. extra long symbols > ed. note: worth exploring - just be really sure there is no potential for > ambiguity, > i.e. at any resolution step: do you have a match for X or Y > > --- > 4. Box and value implementation relationships > goal: reduce costs when boxing/unboxing > -e.g. same layout alignment for fields > - what if we could just change 1 bit in the carrier > > --- > 5. Opcode proposal: > drop vgetfield, overload getfield instead > Bjorn: concern - not want performance impact on existing opcodes > John: propose discard the extra defined opcode and leave room for quickening > > overload: anewarray, multianewarray > > Chat room notes on details: > John: > uses of C_Class as a class-file: this_class, PType head-type (template) uses > of C_Class as a type: ldc, > ?Field/Methodref? > Dan S: > Arbitrary types allowed: anewarray, multianewarray, structural descriptor, > ldc, bootstrap argument, > verification_type_info, maybe field/method refs > Reference types allowed: checkcast, instanceofReference > class/species allowed: super_class, interfaces, new, annotation, catch_type, > Exceptions > Plain class required: this_class, InnerClasses, EnclosingMethod, maybe > field/method refs > Maurizio: > was thinking the recently that InnerClasses is probably another 'classfile' > use > John: > Agree > ldc is not arbitrary type, b/c ldc int.class not possible; ldc is L-type only > > > >
