Valhalla EG minutes Jan 31, 3018
karen.kinnear at oracle.com
Tue Feb 13 23:26:31 UTC 2018
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
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
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.
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
- 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
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
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
More information about the valhalla-spec-experts