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@234098", not
the constant that CG@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
