constant-dynamic specification, updated

[Brian Goetz]

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?

I don't understand this sentence: "A bootstrap specifier gives a method 
or fielddescriptor,/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.


On 6/24/2017 7:52 PM, John Rose wrote:
> I have updated the javadoc API that is relevant to the proposed
> JVM features for dynamic constants and more powerful bootstrap
> methods.
>
> http://cr.openjdk.java.net/~jrose/jvm/condy-jvms-2017-0620.html
>
> Here is a rough draft of the corresponding JVMS changes:
>
> http://cr.openjdk.java.net/~jrose/jvm/specdiff-condy-2017-0624.zip
>
> Please enjoy and comment.
>
> — John