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.kinn...@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 > > > > > > > > >
