attendees: Tobi, Dan Smith, Dan Heidinga, Karen Kinnear

Dan S: Condy SOE circularity issue:
   - sent
  - additional feedback welcome
David Holmes: JVMTI spec updates for nestmates:
  - feedback welcome
All: please review LWorld Value Types and JVMS proposals
   note: updated versions from early reviews:

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 
       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:
   we got as far as the Nullability and migration Open Design Issues.

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 
The proposal is to have a field (or array) declaration declare if a value type 
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 

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 

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

   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,


Reply via email to