Valhalla EG minutes Dec 20, 2017

[Karen Kinnear]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/attachments/20180103/68b15027/attachment.html>