Valhalla EG minutes Feb 14, 2018

[Karen Kinnear]

attendees: Tobi, Mr Simms, Dan H, Dan S, Frederic, Remi, Karen

I. Condy

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

http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2018-February/000560.html

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:
http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2018-February/000570.html

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


II. Nestmates

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
http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2018-February/000541.html

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

Feedback/Q&A:

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

Frederic:
   - 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 
ClassFileFormatError

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
accessible. 
  - 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”

Opinions?

4. arrays
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.

Corrections welcome,
thanks,
Karen