Minutes Valhalla EG Oct 11 2017

[Martijn Verburg]

Hi John,

Just for my reading benefit :-), did you mean:

"Format should be self-explanatory.  My new text is in yellow, stuff of
Dan's *is green*, *stuff* I deleted is in crossed-out *red*."?

Cheers,
Martijn

On 27 October 2017 at 03:11, John Rose <john.r.rose at oracle.com> wrote:

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