minutes Valhalla EG June 07, 2017
karen.kinnear at oracle.com
Wed Jun 7 20:28:02 UTC 2017
Valhalla EG Minutes June 07, 2017
attendees: Bjorn, Dan H, Dan S, John, Vlad, Frederic, Lois, Brian, Maurizio, Karen
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.
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
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
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?
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
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)
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
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.
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.
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
(ed. note - Dan S - can you add some notes on how to represent goal #11?)
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
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
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:
uses of C_Class as a class-file: this_class, PType head-type (template) uses of C_Class as a type: ldc,
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
was thinking the recently that InnerClasses is probably another 'classfile' use
ldc is not arbitrary type, b/c ldc int.class not possible; ldc is L-type only
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the valhalla-spec-experts