Valhalla EG minutes Feb 14, 2018
karen.kinnear at oracle.com
Tue Feb 20 15:52:51 UTC 2018
attendees: Tobi, Mr Simms, Dan H, Dan S, Frederic, Remi, Karen
1. Condy reference implementation was pushed last week into JDK 11.
2. StackOverFlow handling/future LDC early cycle detection
Dan S walked us through his StackOverFlow JVMS clarification for condy, specifically the ordering of resolution
prior to throwing StackOverFlowError for JDK11 initial Condy release
AI: implementors - check if this clarification matches implementable behavior
Dan: also described an incremental ldc early detection circularity proposal
- not requiring candy’s to refer to entries earlier in the classfile
- not depending on an attribute to keep current during retransformation
- assume earlier references are the common case, so that is fastest
- still work if not in order - need to do static cycle tracking - so slower
question for ASM users - e.g. JRuby, Groovy - as they add Condy support - how
often do they need forward references?
AI: all - double-check implementation implications
Dan S - if you want to ask Charlie Nutter to let us know for JRuby going forward ...
post-meeting Update from Dan Smith:
AI: All - check if works for ASM and implementors
3. Planned uses for condy in jdk?
- Nothing in imminent plans
- expect longer term constant Lambdas to use condy - lightweight
- future: still exploring APIs for constants, switch, pattern match, …
Remi: Python, JRuby - all lambdas are constant
Remi: wants support in javac behind a flag
Dan S: it is in Amber
Remi: wants a binary :-) - Dan S will pass on that message
1. Lookup handling
AI: Karen to send email with details
- here it is: http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2018-February/000567.html
Note: javac will not be generating bridges for private members when nestmate support goes into JDK 11 (soon)
protected members will still require bridges
2. Spec updates to JVM Ti, JDWP, JDI, java.lang.instrument
Request to update JVMTI retransformation to describe ability to add private methods. Recognize this
is independent of Nestmates, but perhaps overdue if we intend this to be supported behavior.
AI: Karen - review with past owners of JVMTI specification changes.
III. Value Types
Latest LWorld Value Types proposal: http://cr.openjdk.java.net/~acorn/LWorldValueTypesFeb13.pdf
Latest rough draft JVMS: http://cr.openjdk.java.net/~fparain/L-world/L-World-JVMS-4b.pdf
1. creation of a new value type - Remi
- why not vnew ? why default/withfield/withfield/withfield?
- transformations - e.g. Byteman - easier if arguments are on the stack
Frederic: First proposal had a factory bytecode, returning a single fully constructed value type
rejected: concern: cost of pushing all arguments, method signature and attribute to how signature maps to fields
Dan S: declared fields do not have an inherit ordering, so e.g. attribute to identify order
- expected usage: factory method in the value class itself
Dan: also want withfield exposed at the language level to allow tweaking one thing
Karen: would be helpful to have a single way to create a value type or an object to allow more shared code
- model is to move all toward a factory mechanism
- inside factory - it is not the same bytecodes for value type and object type creation
- note: withfield returns a new value type - it does not have the same stack behavior as putfield
Dan H: factory proposal is better than defaultvalue/withfield
- less throwing away extra created value types for the interpreter
Needs more discussion
2. what does verifier / class file format checker need to do in JVMS?
from LWorld Value Type pdf
Can verifier check bytecode validity? No - we do not want to eagerly load class files, so it doesn’t know if
a bytecode is being applied to a value type or an object identity type
AI: Karen - make sure the “what can javac do for you?” static verification is added to static checking, probably
3. withfield handling
Remi: why withfield?
Frederic: goal is to allow loop iteration with low cost
Remi: why restrict to within the value class itself?
Karen: concern: this creates a new value type, think of it as CopyOnWrite, it does NOT go through final
and update an existing value type. So this is heavyweight
Remi: could we have the language decide restrictions on its usage rather than the JVMS?
Dan S: future - if we want a general purpose withfield - we may want to put that in with extended
field access controls - e.g. separate read vs. write. At that time you could use withfield if the field were
- e.g. with Records - may expose readability, not availability
Frederic: concern about confusing people - withfield with an immutable object
Dan S: language could make this clearer that this is not an assignment, but is a “new”
We need a new bytecode to create a flattenable/non-nullable array
existing bytecodes do not create flattenable arrays with the new model of container marking flattenable
rather than by type
note: if a field is marked as ACC_FLATTENABLE and you load the field and it is not a value type -> ICCE
Dan S: initial value could indicate if this is flattenable or not
Remi: C++ does this - it is not a good thing
Karen: we do not want to have to pre-load the type to determine if it is flattenable, we require the field access flag
in order to require pre-loading
5. Arrays and nullability
Question: can you pass a VT where an Object is expected?
Yes you can pass the argument, and sub typing works.
Frederic: If you have an Object, if you have non-flattenable values then elements are nullable, if you have flattenable values, then elements are not nullable
5. Generics and nullability
Dan S: With generics, value types will work as is.
In future, if we were to change a field to be non-nullable, then we could get NullPointerExceptions
Karen: if we were to change a field to be non-nullable, then if we wanted to we could support a different layout,
and that would require specialization if the field were non-nullable depending on the parameter type.
This is a current open challenge - how to handle migration to non-nullable fields and arrays
Note that in future we might want non-nullable identity objects as well as value types.
To help migration, Brian would like us to find a way so that javac would detect a mismatch in expectations of nullability,
so we catch them at compile time.
More information about the valhalla-spec-experts