Inspired in part by a recent exchange between Remi and Charlie[1],
I've been thinking recently, again, about binding Java APIs to indy.


I think I have a way to make it work, and (what is more)
I think the end result looks pretty good.  Even better,
along the way we can create a mechanism for naturally
constant-folding selected method calls (like List.of)
at link-time.  (Library defined constants ahead!)

There are two things which make all this hard.
First, indy calls its BSM at link time (for the particular
indy instruction, since the JVM is lazily linked),
but the Java language does not expose link-time operations,
except very indirectly (in <clinit> code, for example).

Second, many good indy use cases are at least partly
signature-polymorphic, just like method handles. 
But the Java language does not allow you to generify over
method type signatures (e.g., argument types of (), (int),
(int,int), (String), (String,int), etc., all in one API point).
Even Valhalla only lets you generify over one value at
a time.  (One step at a time!)

Note that these two hard points might occur at the same
time, since some interesting BSMs are in fact signature
polymorphic.  (Well, at least they are varargs methods,
and varargs is an OK substitute for S-P, at link time.)

OK, so we are reduced to baking special handling for those
sorts of things into the language (as MethodHandle and
VarHandle do), or passing some sort of smoke signal
through the language and reweaving the bytecodes
(as Remi is so good at).

How would we signal a BSM call, though Java, in a way
that a bytecode reweaver could recognize it?

Here's an answer, maybe the simplest answer:  Mark
some API points as BSMs (in disguise; don't let javac
know!).  When the reweaver encounters a BSM call in
bytecode, it has to collect all the operands and ensure
that they are constants.  If they are constants, then
the reweaver collects the whole call, and sticks it
into an auxiliary static method (or pattern-matches
the whole call into an indy bootstrap specifier, if
possible).  If they are not constants, it is a reweaving

class IndyTrickster {
   enum StringIndexerKind { LENGTH, HASHCODE, CHAR0, PARSEINT };
   static ToIntFunction<String> indexString(StringIndexerKind k) { … }

class IndyTrickUser {
   int foo(String s) {
     return indexString(LENGTH).applyAsInt(s);  // returns s.length()
   int bad(String s, StringIndexerKind k) {
     return indexString(k).applyAsInt(s);  // ERROR in reweaver?

This is really just a mechanism for materializing link-time constants,
which all by itself is pretty interesting.

I've chosen enums here, because (a) they are constants, but
(b) they cannot be directly supported (today) as indy static
arguments.  So the reweaver has to dump some code in an
auxiliary method somewhere, at least to materialize the enum.

(And see JDK-8161256, "general data in constant pools", for
a better way forward.)

We can stop here and use this trick to create APIs that materialize
constant values of type List, Map, etc.  Put the AtLinkTime
annotation on List.of, for example, et voila.

This raises the question, what happens if an operand fails to be
a link-time constant?  Should the reweaver silently keep the
call as-is, so that it runs every time, instead of just once at
link time?  Probably yes, but what happens when somebody
is expecting link-time folding, and wants to hear if it fails?

One answer:  An optional argument to the AtLinkTime annotation,
to determine what to do if the folding fails (error/warn/allow).
The List.of guys would just silently allow the non-folding uses,
since that is what they are used for now.

It would seem that link-time constants can only be produced by
static methods, but that would be wrong:  You can have link-time
computations that call non-static methods also, as long as the
receiver of each such method is itself a link-time constant.

(All of this suggests that the Java language should just have
a first-class notion of link-time constant, as it already has
compile-time constants.  But as we all know, Java grows
slowly and deliberately.  Experimenting first outside the JLS,
such as suggested here with reweavers, is a great way to
add weight to the case for change.)

What's next?  Well, so far the thing returned from the
constant-producing BSM has a type fully determined
by the static declaration of the BSM method.

You could grab some S-P magic from MethodHandles
to follow the BSM call by an S-P call, like this:

class IndyTrickster {
   static MethodHandle doubler(Class<?> type) {
      return makeDoublerMH(type);
   static MethodHandle makeDoublerMH(Class<?> type) {
      … // returns (type x) -> (String) Arrays.asList(x, x).toString()

class IndyTrickUser {
   String foo1(String s) {
     return (String) doubler(String.class).invoke(s);
   String foo2(int n) {
     return (String) doubler(int.class).invoke(n);

Here the reweaver doesn't have to do anything special with
the MH.invoke.  But of course the BSM static argument
needs to be inferred; that's one of the things a BSM can
do which a mere constant-linker doesn't need to do.

So what sort of smoke-signal can we send to the reweaver
to tell it how to thread the necessary type information into
the BSM call?

Well, we can use more annotations to mark the "special"
BSM arguments that are filled in silently.  There are three
of them:  The Lookup, the method name, and the method
type.  In this case, we want to pass the method type,
which will be (in the previous examples) something like
(String)String or (int)String.

class IndyTrickster {
   static MethodHandle doubler(
        @IndyTricks.MethodTypeArg MethodType mtype) {
      Class<?> type = mtype.parameterType(0);
      … // as before, using type
   // fake generic entry point for javac to hit:
   static MethodHandle doubler() {
      return doubler(methodType(String.class, Object.class));

class IndyTrickUser {
   String foo1(String s) {
     return (String) doubler().invoke(s);
   String foo2(int n) {
     return (String) doubler().invoke(n);

What's the rule here?  Well, the reweaver looks for a
method call (of a normal method) immediately
on the result of the constant expression (a link-time
method call or chain of them).  It says to itself, "Hmm, if this
were an indy call, what would be the first three BSM
arguments?"  And if the actual link-time method
asks for one of those arguments, it will happily
supply it.  You ask for a method type argument
by annotating it as @MethodTypeArg, and similarly
for method name and lookup.

There needs to a pair of associated API points
here, one for javac to compile to, and one for
the reweaver to feed the extra argument to.
For now, let's just allow them to be overloadings
of the same name; we'll suggest something more
explicit later.

Let's try that with formatting, which uses varargs:

class IndyTrickster {
   static MethodHandle formatterMH(
        @IndyTricks.MethodTypeArg MethodType mtype,
        String format) {
      Formatter.checkFormatArgTypes(format, mtype.parameterList());
   // fake generic entry point for javac to hit:
   static MethodHandle formatterMH(String format) {
      … return something that doesn't check errors and accepts (Object...)

class IndyTrickUser {
   String numberedLine(int lineno, String line) {
      return (String) formatterMH("%4d %s").invoke(lineno, line);
   String bad(int lineno, String line) {
      return (String) formatterMH("%4d %s").invoke(line, lineno); // ERROR at 

Now the non-annotated BSM arguments look lonely.
Maybe there's another annotation, @LinkTimeArg,
for the other BSM static arguments.  Of course,
all arguments to an @AtLinkTime method are
link time arguments, aren't they?  Maybe not.

That leads to an extremely interesting question:
What would it mean to equip a link-time method
with a *mix* of link-time and run-time arguments?
This leads away from reweavers into language
design, but let's go there just for a second.

class IndyTrickster {
   // P-E-able version of String.matches:
   static String stringMatches(
        String string,
        static String regex) {  // IGNORE THIS BIKESHED
     // compile the regex, once at link time:
     Pattern p = Pattern.compile(regex);
     // link-time operations are all finished now!
     return p.matcher(string).matches();
   // we'd want to do format like this, if we had Formatter.compile
   static String stringFormat(
        static String format,
        Object... args) { … }

class IndyTrickUser {
   boolean hasFoo(String s) {
     return stringMatches(s, "foo");
     // static arg is SECOND
   String numberedLine(int lineno, String line) {
      return stringFormat("%4d %s", lineno, line);
     // static arg is FIRST

Note that the stringMatches method wants to be split in half,
with the first half run (once) at link time, and the second run
(one or more times) each time the call to stringMatches is
executed.  Doing that for real will require some serious
cooperation with the JVM and JLS.  But can we fake it?

Yes it can be faked if we allow these tricky API points
to be associated together somehow (another annotation convention),
so that one API point accepts both static and regular arguments,
and the reweaver goes and finds the associated API point
(which the user doesn't call directly) that handles the
static arguments, and a third which handles the final call.

Like this:

class IndyTrickster {
   @IndyTricks.AtLinkTime(nonConstant=ALLOW, mixedArgs=true)
   static String stringMatches(
       @IndyTricks.RunTimeArg String string,
       @IndyTricks.LinkTimeArg String regex) {
     Pattern p = stringMatchesLinker(regex);
     return stringMatchesRunner(p, string);
   static Pattern stringMatchesLinker(String regex) {
     return Pattern.compile(regex);
   static Pattern stringMatchesRunner(
       @IndyTricks.LinkTimeArg Pattern p,
       String string) {
     return p.matcher(string).matches();

The rule is that the reweaver splits the nominal
call to stringMatches into a link-time call and
a run-time call.  The runtime takes one link-time
argument, the result (non-void) from the link-time
call.  That is simply a link-time constant, no different
from a constant list; in this case it is a compiled
regular expression pattern, but as we have seen
it can also be method handle.

(The "mixedArgs" argument isn't strictly necessary,
since the annotated arguments are obviously mixed.)

That works pretty well, except for the exposure of messy
extra API points.  But (and this part is pretty fun) those
extra API points can be made non-public, if we want.
After all, if the reweaver succeeds in converting the
call to indy, all it needs to link the instruction is a suitable
BSM.  That BSM needs some sort of handshake with
the defining class of stringMatches to produce the
method handles for the auxiliary functions.

(The method handles must be produced by privileged
code, but that privileged code can enforce rules
which prevent security holes.  For example,
methods outside of a class cannot nominate
themselves as helpers to a link-time function.
Or the link-time function can go the other way
and nominate its helpers directly, thereby
delegating their access to its clients.
I like the balanced look of the annotations
when the helper nominate themselves,
but it's a matter of taste.)

All right, so we can, with some setup work,
create API points which access a hybrid of
link-time and run-time processing.  What's
left?  The signature polymorphism, of course.

We already exhibited use of an S-P method
with this link-time APIs; it was MH.invoke.
Our options are limited here; the language
only recognizes a handful of methods for
this special treatment, and we don't want to
see their names scattered all over our code.

(At this point, I'd like to point out that, in theory,
*almost all* Java API points could be treated as
signature-polymorphic, as long as there were
for the JVM's link-resolver to do two things:
Record the exact intended method descriptor
to call, and arrange to adjust the caller's
descriptor to match the callee's.  Today
this is done by javac, which puts boxing,
unboxing, casting, and varargs instructions
around the call.  Tomorrow it could an indy
instruction which defers all the work to an
asType call at link time.)

Anyway, a reweaver can simulate the presence
of additional signature-polymorphic entry points
by *undoing* the argument matching code inserted
by javac, and passing the originally typed arguments
to an indy call, with a BSM which includes enough
smarts to identify the correct receiver (a MH constant
in the constant pool) and apply asType to that MH
constant to match to the caller's invocation type.

There's a difficulty here:  The reweaver can only
guess whether a given call to (say) Integer.valueOf
was really written by the user, or was inserted by
javac for autoboxing.  I think (but don't know)
that it is harmless to assume that they are all
"noise" calls that can be removed safely.

So, for the final act of this annotation extravaganza,
let's suppose there is an annotation which says
"do not change the original type of this argument".
This annotation would apply to return values
as well.  When applied to a varargs argument,
it would mean "don't make a varargs array,
just pass the original arguments, unchanged".
We will annotate such an argument as

(Such tricks are pointless unless there is
a way to replace the now-useless loosely typed
call by a method handle that accepts the exact
changed call type.  So we need another smoke
signal which tells the reweaver to completely
replace the original run-time call with a method
handle invocation.  We'll do this with an option
on the AtLinkTime annotations.)

Again, we need helpers.  Here's the doubler
example reworked with helpers and polymorphic

class IndyTrickster {
   // fake generic entry point for javac to hit:
   static String doubler(
        @IndyTricks.RuntimeArg(polymorphic=true) Object x) {
      return (String) doublerLinker(methodType(String.class, Object.class), 
   // it has help:
   static MethodHandle doublerLinker(
        @IndyTricks.MethodTypeArg MethodType mtype) {
      return makeDoublerMH(mtype.parameterType(0));
   // there is no @AtRunTime; link time result is invoked

class IndyTrickUser {
   String foo1(String s) {
     return doubler(s);  // makes a constant MH, invokes it exactly
   String foo2(int n) {
     return doubler(n);  // makes a constant MH, invokes it exactly

Let's put it all together with a formatter example.

class IndyTrickster {
   static String format(
        @IndyTricks.LinkTimeArg String format,
        @IndyTricks.RuntimeArg(polymorphic=true) Object... args) {
      return (String) formatLinker(genericMethodType(args.length).String.class, 
Object.class), x).invoke(x);

   static String formatLinker(
        @IndyTricks.MethodTypeArg MethodType mtype,
        @IndyTricks.LinkTimeArg String format) {
      return buildCustomFormatMH(format, mtype.parameterList());

class IndyTrickUser {
   String numberedLine(int lineno, String line) {
      return format("%4d %s", lineno, line); // link-time optimized MH does 
   String bad(int lineno, String line) {
      return format("%4d %s", line, lineno); // ERROR at link!

(The annotation argument which says "just invoke
the result" is actually superfluous.  That is not
because the link-time helper returns a method
handle, since maybe the user is expecting a
method handle as a plain constant.  But the presence
of polymorphic arguments in the original method
that was replaced forces a method handle invocation.
If we can agree that this move is unavoidable,
we can omit the silly-looking annotation argument.)

OK, enough examples.

Are the annotations designed right?  Probably not.
Right now the Lumper in me is stronger than the
Splitter, so I'd say we could do nicely with one
annotation to mark methods as participating
in link-time processing (whether they are
helpers or not, and even if they are run-time
helpers), and one parameter annotation which
includes options for all the above degrees of
freedom.  Maybe @LinkConstant and
@LinkParameter.  (Visions of bikeshed

The net result is that we can treat tasks like
regular expression compilation and format string
verification as link-time operations, with the possibility
of optimizing the exact use case.  This works well
for some existing uses of invokedynamic, for
lambda creation and (more recently) string
concatenation.  Formatting can be viewed as
the next step beyond string concatenation.

As we use invokedynamic more and more,
we push more and more useful work into the
link phase.  This makes both source code and
bytecode very compact, but forces the JIT to
optimize only after link processing has performed
its magic.  This conflicts with ahead-of-time
compilation, which needs to see the results
of link processing before it generates code,
but doesn't have a running JVM to run the
linkage logic.  We will need to do further work
to create rules and frameworks for isolated
execution of link-time logic apart from the
actual application, before it runs.  Marking
some of our methods as @AtLinkTime is
a first step in that direction.

One more observation:  We haven't used any
call sites here.  Where are the call sites?  Users
need mutable call sites to build inline caches.
Of course, a mutable call site is just another kind
of constant.  (Well, it's a mutable constant, which
is odd.)  All the observations about creating constants
at link time apply to inline caches.  We want an
error signaled if the reweaver can't fold an inline cache,
so the annotation should say "nonConstant=ERROR".

In the above reweaver tricks, the handle returned for
a call site can just be the CallSite.dynamicInvoker,
and you are done.  It would be even more graceful
for the reweaver to accept a CallSite (or subtype
thereof) wherever a MethodHandle is sought,
and just do the right thing with it.

I guess that's enough to keep us busy for a while.
Anybody want to take a whack at it?

— John

mlvm-dev mailing list

Reply via email to