Valhalla EG minutes Jan 31, 3018

[Karen Kinnear]

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
      - 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