Dan, I was going to ask you if there were changes you would find more supportable than others.
So the current RI for retransform classes today supports: ADD and DELETE for PRIVATE && (FINAL || STATIC) methods (We are still investigating history) > On Feb 21, 2018, at 1:51 PM, Daniel Heidinga <daniel_heidi...@ca.ibm.com> > wrote: > > Thanks Karen for the link to the bug. > > By "private methods" does that imply both static and instance methods? I > hope not. > > With NestMates, the JVMS has been updated with the (non-normative) text: > --- > Because private methods may now be invoked from a nestmate class, it is no > longer recommended to compile their invocation to invokespecial. > (invokespecial may only be used for methods declared in the current class or > a superclass.) A standard usage of invokevirtual or invokeinterface works > just fine instead, with no special discussion necessary. > --- > implies that private instance methods will have vtable slots and adding a new > private instance method will be a heavy weight operation due to modifying a > vtable(!). I’m glad we are having this conversation. Just to clarify - we have been able to invoke private methods via invokevirtual for years, so that capability is not new. So I do not see how nestmates JVMS changes make any changes to invokevirtual. Totally agree with the goal of not allowing modification of a vtable (and all tables inherited from it), due to heavy operational costs. With the more detailed restrictions above - does that make it more possible to support private instance method addition/deletion - i.e. if the instance methods have to be final and private? > > Adding static methods, private or not, is less problematic apart from > interfaces due to the knock-on effects to iTables. Agree that static methods are easier. Not to go into implementation details, but I don’t understand a relationship between static methods and itables since static methods are not inherited. > > We can live with the later (static) though we'd like to avoid the former > (instance). thanks, Karen > > --Dan > > ----- Original message ----- > From: Karen Kinnear <karen.kinn...@oracle.com> > Sent by: "valhalla-spec-experts" > <valhalla-spec-experts-boun...@openjdk.java.net> > To: valhalla-spec-experts <valhalla-spec-experts@openjdk.java.net> > Cc: > Subject: Re: Valhalla EG minutes Feb 14, 2018 > Date: Wed, Feb 21, 2018 12:52 PM > > JVMTI RedefineClasses spec handling of private methods is being tracked via: > https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8192936&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=LBQnmyrHQkEBElM8bAxhzfwLG2HbsYDdzEznFrQoob4&m=KyGIkr3_m7an4VEDrmlaWzy_eUhQvpypda7FucEbf-M&s=PAZDayMHueNWfP6wI6s3I-XfDpiobFf3OPhEerTcI7s&e= > > <https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8192936&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=LBQnmyrHQkEBElM8bAxhzfwLG2HbsYDdzEznFrQoob4&m=KyGIkr3_m7an4VEDrmlaWzy_eUhQvpypda7FucEbf-M&s=PAZDayMHueNWfP6wI6s3I-XfDpiobFf3OPhEerTcI7s&e=> > > 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 > > > > https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.openjdk.java.net_pipermail_valhalla-2Dspec-2Dexperts_2018-2DFebruary_000560.html&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=LBQnmyrHQkEBElM8bAxhzfwLG2HbsYDdzEznFrQoob4&m=KyGIkr3_m7an4VEDrmlaWzy_eUhQvpypda7FucEbf-M&s=wjLLp1GHaRDE0Jpm_PQVRmoCst7uwiVJ7luwjBu_E7c&e= > > > > <https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.openjdk.java.net_pipermail_valhalla-2Dspec-2Dexperts_2018-2DFebruary_000560.html&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=LBQnmyrHQkEBElM8bAxhzfwLG2HbsYDdzEznFrQoob4&m=KyGIkr3_m7an4VEDrmlaWzy_eUhQvpypda7FucEbf-M&s=wjLLp1GHaRDE0Jpm_PQVRmoCst7uwiVJ7luwjBu_E7c&e=> > > > > 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: > > https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.openjdk.java.net_pipermail_valhalla-2Dspec-2Dexperts_2018-2DFebruary_000570.html&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=LBQnmyrHQkEBElM8bAxhzfwLG2HbsYDdzEznFrQoob4&m=KyGIkr3_m7an4VEDrmlaWzy_eUhQvpypda7FucEbf-M&s=64MFsDQjWyxhx3hjvJwpEU1DNm9KwcaP1QH0InfASu8&e= > > > > <https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.openjdk.java.net_pipermail_valhalla-2Dspec-2Dexperts_2018-2DFebruary_000570.html&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=LBQnmyrHQkEBElM8bAxhzfwLG2HbsYDdzEznFrQoob4&m=KyGIkr3_m7an4VEDrmlaWzy_eUhQvpypda7FucEbf-M&s=64MFsDQjWyxhx3hjvJwpEU1DNm9KwcaP1QH0InfASu8&e=> > > > > 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: > > https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.openjdk.java.net_pipermail_valhalla-2Dspec-2Dexperts_2018-2DFebruary_000567.html&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=LBQnmyrHQkEBElM8bAxhzfwLG2HbsYDdzEznFrQoob4&m=KyGIkr3_m7an4VEDrmlaWzy_eUhQvpypda7FucEbf-M&s=-fdQS3jfPiI_HfNasVUIBYyqRqmyOYMMHwPH89N2DjE&e= > > > > <https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.openjdk.java.net_pipermail_valhalla-2Dspec-2Dexperts_2018-2DFebruary_000567.html&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=LBQnmyrHQkEBElM8bAxhzfwLG2HbsYDdzEznFrQoob4&m=KyGIkr3_m7an4VEDrmlaWzy_eUhQvpypda7FucEbf-M&s=-fdQS3jfPiI_HfNasVUIBYyqRqmyOYMMHwPH89N2DjE&e=> > > > > 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 > > https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.openjdk.java.net_pipermail_valhalla-2Dspec-2Dexperts_2018-2DFebruary_000541.html&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=LBQnmyrHQkEBElM8bAxhzfwLG2HbsYDdzEznFrQoob4&m=KyGIkr3_m7an4VEDrmlaWzy_eUhQvpypda7FucEbf-M&s=EuwhQi4t5_6WZczp-jStDfWc5jIRMy1mVR-8yQOJWko&e= > > > > <https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.openjdk.java.net_pipermail_valhalla-2Dspec-2Dexperts_2018-2DFebruary_000541.html&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=LBQnmyrHQkEBElM8bAxhzfwLG2HbsYDdzEznFrQoob4&m=KyGIkr3_m7an4VEDrmlaWzy_eUhQvpypda7FucEbf-M&s=EuwhQi4t5_6WZczp-jStDfWc5jIRMy1mVR-8yQOJWko&e=> > > > > 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: > > https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Eacorn_LWorldValueTypesFeb13.pdf&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=LBQnmyrHQkEBElM8bAxhzfwLG2HbsYDdzEznFrQoob4&m=KyGIkr3_m7an4VEDrmlaWzy_eUhQvpypda7FucEbf-M&s=wwzmVDbZdp90GAS939tSP6TLrYuRPlO3OrwVvZYOYBg&e= > > > > <https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Eacorn_LWorldValueTypesFeb13.pdf&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=LBQnmyrHQkEBElM8bAxhzfwLG2HbsYDdzEznFrQoob4&m=KyGIkr3_m7an4VEDrmlaWzy_eUhQvpypda7FucEbf-M&s=wwzmVDbZdp90GAS939tSP6TLrYuRPlO3OrwVvZYOYBg&e=> > > Latest rough draft JVMS: > > https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Efparain_L-2Dworld_L-2DWorld-2DJVMS-2D4b.pdf&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=LBQnmyrHQkEBElM8bAxhzfwLG2HbsYDdzEznFrQoob4&m=KyGIkr3_m7an4VEDrmlaWzy_eUhQvpypda7FucEbf-M&s=98mDp23fCot9T029MVb6vUgw9TsU_Dr42EDx_FnnBrw&e= > > > > <https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Efparain_L-2Dworld_L-2DWorld-2DJVMS-2D4b.pdf&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=LBQnmyrHQkEBElM8bAxhzfwLG2HbsYDdzEznFrQoob4&m=KyGIkr3_m7an4VEDrmlaWzy_eUhQvpypda7FucEbf-M&s=98mDp23fCot9T029MVb6vUgw9TsU_Dr42EDx_FnnBrw&e=> > > > > 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 > > > > > > > > > > > > > > > > > > > > >
