Inlining

[Raffaello Giulietti]

Hi Charles,

let's pretend to have only parameterless messages. Then a message send
gets translated into something like

InvokeDynamic.<Obj>#"rich name for call_site_i"(stub_i, receiver);

The "rich name" identifies the call_site_i. For each call site there is
a specific stub_i which carries information about the most recent method
lookups in the form of (receiver class, method handle) pairs. How many
pairs are maintained in the stub depends on how polymorphic the inline
cache shall be.

The target of the call site is a method handle to a method similar to

static Obj invoke_0(Stub stub, Obj self) {
    if (self.klass == stub.klass_0)
	return stub.mh_0.<Obj>invoke(self);
    // some other similar lines, depending on how polymorphic the inline
cache shall be

    // otherwise do a slow lookup, cache the results in the stub
according to some strategy and invoke the final method
    return lookupCacheInvoke(stub, self);
}

It is true that each call site's target refers to the same method
handle, hence to the same dispatching method, i.e., invoke_0 above.
However, every call site has its own Stub instance, so every call site
caches its own information.

But you state

> It sounds like you're still dispatching through a generic piece of
> code, yes? If you have a piece of code in the call path that all calls
> pass through, you essentially defeat inlining entirely.

Why is this so? I cannot see why invoke_0 couldn't be inlined at the
invokedynamic call site. Is there a fundamental reason?


Thanks
Raffaello