The CallInfo structure is used to return a multi-component result from a request for method linkage, via the LinkResolver API.

For example, the result of resolving an invokevirtual call placed (as needed) a v-table index into the CallInfo, so that the caller could "see" how to make the call. Meanwhile, an invokespecial resolution would put a neutral (negative) v-table index in, to ensure that callers would not mistake this for a virtual call.

Th CallInfo structure has always suffered from a slight defect, in that it did not record the i-table index for an interface call. But that was reasonable given the fact that interfaces could not accept "special" or "static" calls. So it was correct when downstream code from a CallInfo would notice an interface and then compute the i-table index.

JVM support for concrete interface methods was added in JDK-8006267. Now interfaces and classes are more similar (to the JVM) than they are different, and it is necessary to distinction static from virtual from special calls to interface methods, just as for class methods.

This means that CallInfo needs not only a _vtable_index member but also a _itable_index member, which needs to be filled it (or left negative) as appropriate, in substantially the same way that _vtable index is processed.

(Note that the two members cannot be merged into a single index, because interface calls can degrade to virtual or even special calls. This is a little-known corner case in the JVM which must be supported.)

The is_statically_bound query needs to check both of the index members for negative sentinel values.

There are a few places where logic post-processes the result of a LinkResolver call (which produces a CallInfo) in the case of an interface. The post processing calls klassItable::compute_itable_index to supply data missing from the CallInfo result. Notably, there is such code at the end of InterpreterRuntime::resolve_invoke, where the complexity is directly due to the original flaw in CallInfo. This logic needs to be consolidated into LinkResolver, so that there is one place where all such queries are computed. There is also duplicate logic in methodHandles.cpp which needs a similar cleanup.

This post-processing of interfaces is error-prone, since it distributes the interface-related special cases among clients of the LinkResolver API, instead of inside LinkResolver. This has led directly to complexity and bugs. For example, in methodHandles.cpp, the client code attempts to perform classification that should have been completed by LinkResolver, and gets it wrong (in a way hard to locate and debug) in the case of new method types inside interfaces.

Finally, certain LinkResolver queries which are used only from the compiler interface (e.g., resolve_virtual_vtable_index) need to be recast to use the CallInfo mechanism to report results, again so that there is just one place for queries and no risk of duplicate logic.