Page History

Patch name: inti.patch
Description: inti.txt

Implementation Notes

See InterfaceCalls for a discussion of how interface call sites work.

Each klass structure already includes (allocated inline) a 2-dimensional ragged table of its statically defined interfaces. The spine of the table has pairs, <oop iklass, offset_t itable>. The spine is terminated by a tuple <NULL, 0>.. The itable offsets are relative to the enclosing klass (the receiver type).

Each itable is an array of the form {{methodOop target\[N]}}, where {{N}} is the number of methods in the interface.

Interface dispatch (for polymorphic call sites) searches the spine of the table, and dips into the matching itable, picking out the target method corresponding to the index (in 0..N-1) of the abstract method in the interface.

...

In order to pack these dynamic itables, MethodHandles must be lowered to methodOops. For the special case of direct method handles, the original methodOop can be reused. For other (adapted or bound) method handles, a new methodOop must be created to wrap the method handle. This is a dark and dirty secret that nobody but the JVM will know about. (See the auto-generation of invoke methods in methodOop.cpp of meth.patch.)

A wrapper methodOop for a method handle mh of type R(A...) could look like bytecodes for this pseudocode:

  static final MethodHandle MH = mh; // stored directly in m's constant pool
  static R m(A... a...) {
    // ldc #MH
    // push l0; push l1; ... for all A
    // invokevirtual MethodHandle.invoke(A...)R
    return MH.<R>invoke(a);
    // return
  }

The meth.patch code already uses the oop-in-a-constant-pool technique for autogenerated MethodHandle.invoke methods (of which there is an infinite variety).

...