TIB

TIB (Type Information Block)

Per-class metadata array containing vtable, IMT, constant pool references, and other type information needed for efficient runtime operations.

Overview

The Type Information Block (TIB) is a per-class Object[] array that stores all runtime type metadata for a Java class. Every Java object in JNode carries a reference to its class's TIB at offset -1 in the object header (see Object-Layout). The TIB provides a single, efficient lookup point for all type-dependent operations including virtual method dispatch, interface method lookup, GC tracing, and class identity checks.

Unlike some JVMs that use separate vtable and itable objects, JNode stores everything in a single TIB array. This design simplifies object headers (one pointer instead of two) at the cost of a larger TIB for complex classes. The TIB is constructed during class preparation (VmClassType.prepareTIB) and remains immutable thereafter.

Key Components

Class / File	Role
core/src/core/org/jnode/vm/classmgr/TIBLayout.java	Interface defining TIB array index constants (VMTYPE_INDEX, IMT_INDEX, etc.)
core/src/core/org/jnode/vm/classmgr/TIBBuilder.java	Builder class that constructs TIB arrays via inheritance-copy and method append/override
core/src/core/org/jnode/vm/classmgr/VmClassType.java	Abstract class representing class types; holds tib field, calls prepareTIB() during linking
core/src/core/org/jnode/vm/VmMagic.java	getTIB(object) helper for runtime TIB access

TIB Structure

The TIB array is organized as follows (per TIBLayout):

Index 0: VMTYPE_INDEX         → VmType (the class object itself)
Index 1: IMT_INDEX            → Object[] (Interface Method Table)
Index 2: IMTCOLLISIONS_INDEX  → boolean[] (IMT collision flags)
Index 3: COMPILED_IMT_INDEX   → Object (architecture-dependent compiled IMT)
Index 4: SUPERCLASSES_INDEX   → VmType[] (superclass chain)
Index 5+: FIRST_METHOD_INDEX  → VmInstanceMethod[] (vtable, one entry per virtual method)

The MIN_TIB_LENGTH constant is 5, meaning the vtable starts at index 5. The vtable grows by appending new methods as subclasses are loaded, with overrides replacing entries at the same index.

How It Works

TIB Construction

TIB construction happens in VmClassType.prepareTIB() (VmClassType.java:126):

1. Inheritance copy: If the class has a superclass, copy the superclass's TIB as the starting point. This copies both the fixed header entries and the existing vtable methods.
2. Method processing: Loop through the class's declared methods. For each non-static, non-special instance method:
   • Search the existing vtable for a matching name+signature via TIBBuilder.indexOf()
   • If found: check visibility rules (TIBBuilder.overrides()). Public/protected methods or same-package methods override (replace the slot); private methods append (new slot).
   • If not found: append the method as a new vtable entry.
3. Abstract method synthesis: For abstract classes, clone interface methods that lack an implementation and add them to the vtable as synthetic entries.
4. Lock: Call TIBBuilder.toArray() to finalize the TIB — it becomes immutable.

TIB Access

At runtime, the TIB is accessed via VmMagic.getTIB(object):

public static Object[] getTIB(Object object) {
    return VmMagic.getObjectTypeInfo(object);
}

The assembly-level getTIB operation simply reads the word at offset -1 from the object pointer. GC visitors (GCMarkVisitor, GCVerifyVisitor) use this to trace all live objects by following their TIB reference.

Method Dispatch

Virtual method dispatch uses the TIB as follows:

1. The object's TIB is loaded (one pointer dereference).
2. The vtable slot for the method is accessed (offset = method.getTibOffset()).
3. The method code is jumped to.

For interface dispatch, the IMT slot in the TIB (index 1) points to an IMTBuilder-constructed hash table. The IMT lookup uses selector % 64 indexing and handles collisions via a linked list. See IMT for details.

Gotchas & Non-Obvious Behavior

• TIB is class-level, not instance-level: A single TIB is shared by all instances of a class. This means TIB modifications (during class loading) must be synchronized carefully, and once a class is fully linked, the TIB is immutable.
• TIB size affects object footprint: A class with many virtual methods has a larger TIB. Every instance of the class carries only a single TIB pointer, but the TIB itself occupies memory proportional to the method count in the class hierarchy.
• vtable slot assignment is inheritance-order dependent: The order in which methods appear in the vtable depends on the order they were encountered during class loading (superclass methods first, then subclass methods in declaration order). This can be surprising when debugging dispatch behavior.
• Synthetic abstract method cloning: When a class implements an interface abstractly, the prepareTIB code clones interface methods to add them to the vtable. This clone's TibOffset is set to the slot in the abstract class's vtable, not the interface's.
• CompiledIMT is architecture-specific: The COMPILED_IMT_INDEX slot holds an architecture-dependent compiled dispatch table generated by the JIT for fast interface calls. It may be null on some platforms.
• Superclasses array for GC: The SUPERCLASSES_INDEX slot holds the superclass chain as a VmType[] array. This is used by the GC to traverse the class hierarchy for mark/sweep operations.

Related Pages

• Object-Layout — Object header structure including TIB pointer
• vtable — Virtual method table within the TIB
• IMT — Interface Method Table within the TIB
• Type-System-Internals — VmType hierarchy and class loading pipeline
• Virtual-Methods — Overview of method dispatch mechanisms
• JIT-Compilers — How JIT compilers use TIB data for dispatch