A clarification below:
> On Feb 13, 2018, at 6:26 PM, Karen Kinnear 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:
