Minutes Valhalla EG Oct 11 2017

[John Rose]

FTR, Dan's draft is posted at:
  http://cr.openjdk.java.net/~dlsmith/constant-dynamic.html

One thing I like very much about Dan's work is the refactoring of
information that used to be co-located with invokedynamic-specific
sections of the spec, into their own sections, where indy and condy
can refer to them in common.

I did some more clarification and refactoring here:
  http://cr.openjdk.java.net/~jrose/jvm/constant-dynamic-jrose.html

Format should be self-explanatory.  My new text is in yellow, stuff of
Dan's I deleted is in crossed-out green.
 
The clarifications in my draft are about errors thrown around edge cases,
such as circular dependencies, and about permitted implementation options
(the "as if" rules).  The new processing step *after* the BSM invocation
collects a nice bundle of information about edge cases pertaining
to the result of the invocation, IMO.

The refactoring is around the treatment of arguments and return values to the
BSM. By shifting the BSM call specification to use invokeWithArguments,
non-essential arity restrictions are incidentally lifted, which was difficult to
do in the previous treatment.  Also, an intermediate fictitious descriptor
(which implies a fictitious MethodType) is no longer extracted from descriptor
fragments collected from the BSM argument constants; this IMO is a helpful
simplification.

Cheers,
— John

On Oct 13, 2017, at 3:26 AM, Karen Kinnear <karen.kinnear at oracle.com> wrote:
> 
> 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.
> 
> 2. InvokeWithArguments
> 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
> for that.
> 
> 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.
> 
> 3. Renaming
> Constant_Dynamic
> 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.
> 
> 5. ldc_w
> 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?
> 
> John: intention
>  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.