Valhalla EG minutes Feb 14, 2018

Thu Feb 22 00:54:56 UTC 2018

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_Heidinga at 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.kinnear at oracle.com>
> Sent by: "valhalla-spec-experts" <valhalla-spec-experts-bounces at openjdk.java.net>
> To: valhalla-spec-experts <valhalla-spec-experts at 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.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
> >
> > 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
> >
> >
> >
> >
> >
> >
> >
> >
> > 
>  
>  
> 