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 <[email protected]> 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 <[email protected]> > 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. > >
