Valhalla EG minutes Jan 31, 3018
karen.kinnear at oracle.com
Wed Feb 14 14:33:16 UTC 2018
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
> 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:
> - 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
> 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.
> 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?
> 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,
More information about the valhalla-spec-experts