Minutes Valhalla EG Oct 11 2017
martijnverburg at gmail.com
Fri Oct 27 14:57:37 UTC 2017
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*."?
On 27 October 2017 at 03:11, John Rose <john.r.rose at oracle.com> wrote:
> FTR, Dan's draft is posted at:
> 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:
> 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
> 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
> fragments collected from the BSM argument constants; this IMO is a helpful
> — John
> On Oct 13, 2017, at 3:26 AM, Karen Kinnear <karen.kinnear at oracle.com>
> > 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
> > (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
> > 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
> > 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
> > 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.
More information about the valhalla-spec-observers