Valhalla EG minutes Jan 31, 3018

[Karen Kinnear]

A clarification below:

> On Feb 13, 2018, at 6:26 PM, Karen Kinnear <karen.kinnear at oracle.com> wrote:
> 
> attendees: Tobi, Dan Smith, Dan Heidinga, Karen Kinnear
> 
> AIs:
> Dan S: Condy SOE circularity issue:
>   - sent http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2018-January/000526.html
>  - additional feedback welcome
> David Holmes: JVMTI spec updates for nestmates:
>   http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2018-February/000541.html
>  - feedback welcome
> All: please review LWorld Value Types and JVMS proposals
>   note: updated versions from early reviews: http://cr.openjdk.java.net/~acorn/LWorldValueTypesFeb13.pdf
>   http://cr.openjdk.java.net/~fparain/L-world/L-World-JVMS-4b.pdf
> 
> I. Condy:
>  JVMS in finali stages - any open issues?
>  Dan H - not seeing any major issues
>  Dan S - Alex Buckley is reviewing prior to incorporating into JVMS
>       revising circularity detection - currently flexibility is a bit too nondeterministic
>       clarifying when StackOverflowError happens - backedge of cycle,
>       i.e. static arguments are resolved before SOE
> 
>  Nested BSM invocations on a single thread - the deepest one wins
> 
> II. Nestmates
>  JVMS review?
>  Dan H: looks reasonable, including IAE change for invokeinterface non-public/non-private method
>  Question about whether we have explicitly shared javac changes for inner/outer classes with Eclipse/IntelliJ
>      - note: javac did not add nestmate changes for multiple top level classes in the same source
Q: Is there a nestmate relationship between top level classes that share the same source file?
A: No. Being defined in the same source file is not sufficient to have a nestmate relationship.
>      - feel free to share, or to invite a contact to track the spec-observers, or to contact us directly
> 
> 
> III. Value Types - LWorld
>   Karen walked through beginning of proposal: http://cr.openjdk.java.net/~acorn/LWorldValueTypesjan31.pdf
>   we got as far as the Nullability and migration Open Design Issues.
> 
> Summary:
> 1. java.lang.Object as root
> 2. value types have no identity, ever, there are no boxes and no implicit conversions ever
> 3. common bytecodes between object class (ID class?) and value class
> 	except for new  vs. defaultvalue/withfield
> 3. migration ok object class -> value class, but not the reverse
> 4. to maximize ability to support existing code for
>    a) methods and fields that refer to Objects or Object[] which now will also see value classes
>    b) migration of value-based-classes to value types with e.g. caller/callee unchanged - to continue working
> 
> we are proposing handling nullability by allowing value types to be nullable in general.
> The proposal is to have a field (or array) declaration declare if a value type is ACC_FLATTENABLE - i.e.
> if it is non-nullable, then it may be flattenable if the JVM chooses to.
> 
> This proposal allows removing all Q-descriptors.
> 
> Note that with a caller/callee/actual class separate compilation/migration challenge - only the actual
> class knows whether it is a value type or not.
> 
> Open question for prototyping: can we get the JIT performance optimizations we need?
> 
> Discussion:
> Dan S - how hard would it be to add Q’s to descriptors?
> Frederic - we have proposed a way to handle Q descriptors for fields and methods
>    - we need to deal with signature mismatch between
>    caller/callee (accessor/declarer) and the actual class that is loaded
>    so internally the JVM would need to store both an all-L “canonical” signature for handling signature searches
>    as well as inheritance/overriding, as well as reflection, jvmti, etc. 
>    - and then would need to consult the Q-descriptor to see what was claimed
>    - and then would have to consult the actual loaded class to see whether we actually have a Qtype
>    - and if so far we only have null e.g. as a method argument, we may not yet have loaded the class, …
>    - note: there are NO conversions (implicit or explicit) - in an actual runtime, Foo is always actually
>      either a value type or an object type 
>    - so without the Q descriptor - this is simpler - there is only one namespace
> 
> Dan S: 
>  - what about using Q-signature to mean flattenable/non-nullability?
> Frederic: yes - if we had a fresh implementation that would work well, with the migration it does not
>      note: no heisenboxes, no accidental identity
>      method call: sig L: do not know L vs. Q until we load the type
> 
>      the intentional model here is that most bytecodes do not care - they work either way
>         except for new and defaultvalue/withfield
>         note: other bytecodes have different behaviors - e.g. putfield can not write to a value type immutable instance field
> 
> Dan H: What about JIT performance?
> Frederic: for the hotspot JIT, we have loaded the signature types before we compile
> Dan H: what about needing different paths for L vs. Q?
> Frederic: also if you have an Object or Interface, the subtype may be a value class or object class
>  - yes we do need to determine if we can get the JIT performance we need 
> 
> Dan S:
>   does defaultvalue give a null for LType? 
>   defaultvalue only works on a value type, and gives a fully initialized instance
> 
>   note: anewarray/multianewarray - preload type of component
> 
> Dan S:
>   If you want non-nullable/flattenable
>   today: if you have a value -> might flatten, populate with default values
>              objectArray - populate with null references
> 
> with this proposal:
>   field: reference - initializes to null - which is a general default for a reference (which has no type)
>    explicitly flattenable - pre-load class and initialize to default value for that type
> 
> Corrections welcome,
> thanks,
> Karen
> 
> 
> 
>