Questions on Template Classes proposal

Karen Kinnear karen.kinnear at oracle.com
Wed Mar 13 17:41:28 UTC 2019


John,

Lois and I have been studying the Template Classes in the VM proposal:
http://cr.openjdk.java.net/~jrose/values/template-classes.html

We had some questions we were hoping you could either answer in email or in the next draft.

thanks,
Karen
Where in the template class file are holes allowed? "almost anywhere in the constant pool"
Type parameters today are allowed in ClassFile, field_info and method_info for class, interface, constructor, method or field who declarations use type variables or parameterized types (JVMS 4.7.9)
Add at use sites for field and method descriptors. Assume this applies both to the reference class and the parameters/return types
Add at use sites for CONSTANT_Class_info:
 e.g. superclass 
comment about other languages wanting to assign different superclasses for species
What about the user mode assumption that: if Foo extends Bar, Foo<Point> is a subclass of Bar<Point>
 superinterfaces
Add for annotations for field and method descriptors
other attributes?
Where are holes allowed in specialized class files?
"API types, class instances and method invocations never have holes"
Assume add "field descriptors"
"Because of overloading the type part of a method needs to be spelled with non-class holes intact, since that is how the API element seems to be distinguished from its peers. This seems to be a necessary exception to the rule that constants with holes cannot participate in resolution."
bytecodes can not be type-checked until all CP entries are complete
potential w/partial verification/2 pass - but that is an implementation optimization, not semantic
is the key point here that verifier can not see any holes, but e.g. attributes only viewed by e.g. reflection may see holes which are not caught by verification? 
clearer if "no holes in specialized class file", verification only extends as far as it does today
Is it the case that a specialization could always have two segments
There is a requirement that only the root segment can be shared
Could we therefore have two segments for a given specialization - a common root segment and a per-species segment and not need multiple segments in the specialized class file
and then, from an implementation standpoint, we could have a common root for all the raw types
Could we see more complex examples
more than one parameter type
segments that depends on multiple parameter types
template classfile and specialized result "reduction"
JVMS level
does the specialization  including the root segment
does verification verify the root segment
note: implementation may be able to optimize
e.g. implementation may be able to verify the root segment and separately verify specialization relative to the root segment
Why extend super-interfaces to Constant_Dynamic? When would the BSM be invoked? Is the intent here to allow superinterfaces with holes - couldn't that be handled via a template type species? 
Relationship between: raw type, template class, erased species
proposal is that the erased species has exact match of members as template class
proposal is that the template class is not instantiable
challenge is: older class files with instantiated raw type "new Foo" class file: new LFoo; – requires instantiation
one proposal: re-translate the bytecode into new LFoo<erased>;
and keep a non-instantiable template class, and keep the statics in java.lang.Class as they are today
TODO: walk examples of raw type bytecodes and BC
Clarifications/explorations on relationship of template class
potential for multiple inheritance
Concern about the requirement for ordering of holes - must depend on an earlier one, also the requirement to point to the "last" hole in a segment
does this cause problems for Lookup.defineClass with re-use of byte[] and constant pool extension mechanisms?
does this cause problems for bytecode instrumentors, redefinclasses  - what if they want to add an additional hole in a segment - do they need to need to change all references to the "last" hole in a segment?
Could we explore having two segments in the template classfile, one root and one specializable, and each entry you could trace dependencies instead of requiring ordered segments?
Request from vm runtime
in the specialized class file, we need both the name/UTF8 string AND the Constant_Class to have a place to store the passed-in resolved type parameter
It would be valuable to be able to share any resolved classes to achieve "same resolution" results going forward
Redefineclasses will need to have a way to indentify types resolved externally and passed in as live-types, so they are NOT re-reresolvable
Detail: How are Template Attributes used e.g. by Class, method, field? What does it mean to have a template attribute on a static field? Is that a way of clarifying which conditional species it belongs to?
Template Attribute and TemplateParameter dependency relationship?
Later email: not clear why a BSM-based template expansion logic would not use existing class loaders, system dictionary and loader constraints


More information about the valhalla-spec-observers mailing list