constant-dynamic specification, updated

[Paul Sandoz]

> On 5 Jul 2017, at 11:57, Brian Goetz <brian.goetz at Oracle.COM> wrote:
> 
> This is very nice.
> 
> One thing that readers will wonder (doesn't belong in JVMS, but belongs somewhere) is what suggested practice are for using invocation name / constant name.  I don't see the name widely used in indy, but I could imagine it more widely used in condy, because constants often have names (like Pi.)  For a BSM that effectively has a single String parameter, I think we'll get more compact classfiles if we use the name and a shared no-arg BootstrapMethods entry, but is that a good reason?  For example, for a primitive-class bootstrap, would this be a good use of the name?
> 

That’s how it’s applied by javac and the BSM (j.l.i.DynamicConstants.primitiveClassBootstrap) in the amber branch. For a VarHandle to a field, the name corresponds to the field name (for an array it is redundant).

(FWIW the StringConcatFactory BSM could of used the name for the recipe encoding. Arguably with condy a richer recipe description could be used as a BSM argument rather than encoding it all into a string.)


> I don't understand this sentence: "A bootstrap specifier gives a method or field descriptor, TD."
> 
> On the API:
> 
>  - The type parameter T to BCI is "dangling", in that there is nothing to constrain it.  However, IIUC, it can only be MethodType or Class.  In an ideal world, T would be bounded by the common supertype of these two things (NominalConstantRepresentingMemberDescriptor).  We generally advise against use of unconstrained tvars like this in APIs, since it provides only the illusion of type safety, though I understand why you went this way -- you can have a BSM
> 
>     Foo bsm(Lookup lookup, BootstrapCallInfo<Class> bci) { ... }
> 
> and just proceed without casting, and it's both convenient and self-documenting.
> 
> If we had a common supertype in the future, we'd not be able to add this as a bound in a binary-compatible manner, because invocationType()Object would be burned into client classfiles.  So it's kind of a dead-end.  In any case, I'd add a stronger note about the range of T here.  THere's room to put javadoc on tvars with "@param <T>"; you could say "Must be Class or MethodType."
> 
>  - In ConstantGroup, do you want to clarify that constants described by multiple CGs might be the same constant, and therefore might share the one-time transition to resolved?  Readers could think that the one-transition lifecycle is a property of "entry #3 in CG at 234098", not the constant that CG at 234098 happens to refer to in slot 3.
> 
> 
> I'd like to see some guidance about what a constant is.  Condy will happily serve up mutable objects in the guise of dynamic constants, and the VM will have no regrets.  However, this is likely to lead to pain (or security issues) for the user.  Some sort of guidance here would be good, perhaps in the package javadoc.
> 
> Also, related: what sort of facilities might we want to provide for caching/interning of equivalent constants across classes?  I could easily imagine a BSM wanting to preserve the invariant that any LDC with a given set of args from any class results in the same object.
> 

And also that the constant returned from a condy might store a ConstantGroup for later resolution of further values, namely the scope of resolution can exceed that of the BSM invocation (which is what i suspect might happen for pattern matching).

Paul.