Minutes Valhalla EG Oct 11 2017
karen.kinnear at oracle.com
Fri Oct 13 10:26:02 UTC 2017
AI: David Holmes - Proposal for reflection APIs for nestmates ( thanks David for volunteering)
AI: Dan Smith - updated Condy JVMS
AI: Karen Kinnear - for nestmates - transitive overriding example email
Attendees: Bjorn, David Simms, Dan H, Frederic, Lois, John, Karen
I. Nestmates JVMS comments: (Thanks to David Holmes)
1. IAE due to issues with nestmates
such as - NCDFE or not listed in nest host member list or other resolution error
We all agreed we want to report more information than just an IAE
- add a cause
- additional information in the message
- possibly subclass of IAE for nestmates?
(ed. note - while access checking is likely to be the place where lazy nest host resolution occurs,
it might also happen due to a reflection request)
2. InvokeInterface change to support local private method invocation - proposal is to make that
independent of class file version.
Change in behavior: old ICCE will now succeed.
No issues with mix-n-match class file versions. All will support local and old versions won’t have
Dan H pointed out that we have reserved the right to go from an error to a success case.
Summary: EG was good with change. This will be a strict subset of the new behavior for old classifies.
Need a specific API proposal for when we get nest host resolution errors or there is a mismatch
in nest membership. For each API - do we return e.g. null or a failure or a subset of members?
If I ask for all my nest mates - do we need to eagerly resolve them?
No to returning string names of nest mates
John Rose: what if we were able to return the upcoming ClassRef, i.e. an unresolved reference which
could then later be resolved which could get an appropriate resolution error at that time?
— if this is going to ship in the same timeframe as support for Constable - maybe this is a better
approach going forward.
4. Preparation vs. Selection
Dan H said that Karen’s proposal made sense to him (yay! and many thanks) and clarified some
of the intended loader constraint handling. So we are ok with the preparation changes to the JVMS
if Dan S agrees with Karen’s description as well - i.e. we think they match :-)
Karen owes brief summary of transitive overriding including some examples - to double-check the
No other nest mate JVMS issues were raised.
II. Release timing:
Intention is that 18.3 contain ConstantDynamic with class file version update. No other class file changes
Nestmates are targeted for early in the 18.9 cycle so it gets bake time.
Other language changes in 18.3 - LVTI
III. Condy JVMS
Dan Smith is working through some improvements - in internal review. Should be available soon.
1. 5.4.3 Clarification of pre-condy expected behavior:
Indy - if resolution fails with a LinkageException for s given BCI, we need to record the exception and rethrow.
Successes for a given BCI also need to be cached and return the same result.
(Oracle is currently fixing a bug with that).
If a VM error pass through unchanged, else wrap in BSME.
Handling for megaarguments - e.g. removing the limits and turning the tail into varargs.
This matches what we do i source code.
goal: scale BSM (8 bit limitation today)
treat BSM as if method descriptor from constant pool
- all Object except for boxing
note: no method descriptor in constant pool call matches > 256 args on stack - and we do not want to change the JVMS
So - looking to find a short simple way to allow this in the specification without having to precisely restrict
implementation. In future we plan to clean this up with the BsCI mechanism.
Constant_DynamicCallSite (yes - renaming indy as well)
4. Implementation clarification
For non-ConstantCallSite - if setTarget is called - what is the expected behavior?
If SetTarget is called - the JVM MUST notice this and
- replace any caching, deopt/recompile etc.
- it is not valid to setTarget to null - it must be a non-null MethodHandle and the proper type
The Callsite returned must be the same for the same BCI for indy, but the target itself is changeable.
Just ensuring we all are expecting that ldc_w condy works for double and wide
6. Consider using a MethdHandle for ldc rather than a field descriptor?
condy is to indy as get static is to invoke static
indy uses a name&type for a method type and condy uses a name&type for a field type
building on the existing JVM language split between methods and fields
in future - may use MethodTypeRef and ClassRef
goal is to benefits from combinators, and languages that want very untyped BSM args.
Concern is a bootstrap attribute index which is shared between indy and condy. It has to be an indy BSM -
super type of both is java.lang.Object today.
More information about the valhalla-spec-observers