Happy New Year! Attendees: Remi, Dan H, Tobi, Dan S, John, Karen
AIs: All - review nestmates JVMS invokeinterface selection changes All - review Dan’s proposal for constant pool structural descriptors Remi - proposal for T-Types - simpler approach to generic specialization I. Nestmates 1. JVMTI -agreed to modify JVMTI specification to disallow modifying NestHost or NestMembers attributes as part of class redefinition. 2. InvokeInterface selected method discussion - Karen sent an email http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2017-December/000486.html <http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2017-December/000486.html> with an attached .pdf that essentially described the invokeinterface selection changes from pre-nestmates. (oops - .pdf was stripped) Need to revisit from further investigation - I will send a separate email. II. Constant Pool future changes Dan followed-up with an email: http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2017-December/000490.html <http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2017-December/000490.html> Dan S discussed a proposal to evolve Descriptors in the Constant Pool from strings to structured, in part motivated by template specialization. Today we use name mangling for arrays and for the Minimal Value Types prototype. Proposal is to have a Descriptor refer to a set of other Constant Pool entries which describe types, e.g. CONSTANT_ArrayType_info - would point to the type of its element e.g. CONSTANT_PrimitiveType_info - would have a byte which says which primitive e.g. CONSTANT_ParametersAndReturn_info - CP indices for return and parameters Goals: Dan H: request fixed length constant pool entries -> leading to proposal to contain the parameters and return value in an attribute rather than in the CONSTANT_ParametersAndReturn_info directly. Karen: ability for implementation to continue to use a String - so as to allow fast method lookup searches and reduce API changes, without having to do lots of constant pool resolution/class loading Karen: need ability to incorporate live types with different class loaders - this is a new challenge Remi: Already have L/D/I/F Would the new version be e.g. int.class? Today you can’t store an int in an object, but we can store a value type with an int - is it possible we don’t need the new primitives - or at least too soon to know? Is it possible JIT can do most of the specialization and we won’t need this? Dan S: other motivations John: wants this for template classes Remi: What if instead of template classes we had a T-Type descriptor - which is less powerful than template holes - substitution fills the CP holes AI: Remi - write a proposal - we would like to see how that might work Dan S: Cycle handling Array types can have cycles - rather than relying on ordering - perhaps tell tree depth - e.g. component type & dimensions - all in the CP John: perhaps modify to include the depth indicators in an attribute (separate proof of acyclicity) Remi: but if you insert a condy … John: would need to discard the attribute Dan H: concern about a constant array for each dimension ? maybe some adhoc compression techniques Remi: why do you want to be cycle free? Dan S: hard to verify if types cyclical? Remi: why do you need to check in the verifier? John: maybe a structural constraint? Remi: if value - ok, but not for an array of values? e.g. Object[] with first entity as itself Dan: want array type convertible to finite string, benefit of attribute not tied to construct is it can evolve Dan H: Concerns about attributes - will this be as hard to maintain for e.g. class redefiners/bytecode generators as stackmaptables? No - you have to keep the CP indices in sync, but stackmaptables required abstract interpretation - transformer did not have the type information, and the compression mechanism was harder to implement and these would just require bumping indices. III LWorld Value Types - Remi Issue 1: Can Object[] store an array of VT? Dan S: NOT allow as part of subtyping Karen: missed that - Brian asked if X <: Object is X[] <: Object[] e.g. if X is a Value Type Why would this not be true? Dan S: performance concerns? (ed. note - I need to understand this better) Issue 2: putfield semantics aaload/aastore can do the same thing for value types and references if field is a ValueType can’t put a reference type in it Karen: for an array of VT - must have a VT to store in it for an object container that has a value type field - you can write a different value type in the field the restriction is on updating a field in an immutable value type itself Remi: when can the VM store a VT as an Object (ed. note: I presume he meant indirectly vs. flattened) Note: VM chooses when to do flattening - need to clarify in spec The author does NOT know if a value type has been flattened in a given container - reference, value type, array thanks, Karen
