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