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
