Valhalla EG minutes Feb 14, 2018

[Karen Kinnear]

JVMTI RedefineClasses spec handling of private methods is being tracked via: 
https://bugs.openjdk.java.net/browse/JDK-8192936

thanks,
Karen

> On Feb 20, 2018, at 10:52 AM, Karen Kinnear <karen.kinnear at oracle.com> wrote:
> 
> 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
> 
> 
> 
> 
> 
> 
> 
> 
>