A clarification below:

> On Feb 13, 2018, at 6:26 PM, Karen Kinnear <karen.kinn...@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

Reply via email to