OOP Basics - Mathematical and Low-Level Foundations¶

Formal notation:
  S <: T  means "S is a subtype of T"

Rules:
  Reflexivity:  T <: T  (every type is a subtype of itself)
  Transitivity: If S <: T and T <: U, then S <: U

Method signature covariance/contravariance:

Base:    T.method(ParamBase) → ReturnBase
Subtype: S.method(ParamSuper) → ReturnSub    ← valid

Where:
  ParamSuper :> ParamBase   (contravariant: accepts wider input)
  ReturnSub  <: ReturnBase  (covariant: returns narrower output)

class Animal {
    void speak() { println("..."); }    // vtable slot 0
    void eat()   { println("eating"); } // vtable slot 1
}

class Dog extends Animal {
    @Override
    void speak() { println("Woof"); }   // overrides slot 0
    void fetch() { println("fetch"); }  // vtable slot 2
}

Memory layout:

Animal object:
  ┌─────────────────┐
  │ class pointer ───┼──→ Animal vtable:
  │ (fields...)      │      [0] Animal.speak
  └─────────────────┘      [1] Animal.eat

Dog object:
  ┌─────────────────┐
  │ class pointer ───┼──→ Dog vtable:
  │ (fields...)      │      [0] Dog.speak    ← overridden!
  └─────────────────┘      [1] Animal.eat   ← inherited
                            [2] Dog.fetch    ← new method

When you call:
  Animal a = new Dog();
  a.speak();

1. Load object's class pointer
2. Look up vtable slot 0 (speak)
3. Find Dog.speak (because actual object is Dog)
4. Call Dog.speak → "Woof"

// a.speak() compiles to:
invokevirtual #2  // Method Animal.speak:()V

// JVM at runtime:
1. Get actual class of 'a' (Dog)
2. Look up Dog's vtable for speak()
3. Call Dog.speak()

Go interface value layout:

type iface struct {
    tab  *itab          // interface table (method pointers)
    data unsafe.Pointer  // pointer to actual data
}

type itab struct {
    inter *interfacetype  // interface type descriptor
    _type *_type          // concrete type descriptor
    hash  uint32          // type hash for fast type assertion
    _     [4]byte
    fun   [1]uintptr      // method function pointers (variable size)
}

Memory layout of 's':

s (interface value):
  ┌──────────────────────┐
  │ tab ──→ itab:        │
  │         inter: *Stringer interface type
  │         _type: *Dog concrete type
  │         fun[0]: Dog.String  ← method pointer
  │                              │
  │ data ──→ Dog{Name: "Rex"}   │
  └──────────────────────┘

When you call s.String():
1. Load s.tab
2. Look up fun[0] (String method)
3. Call with s.data as receiver

itab cache (global):

hash(Dog, Stringer) → itab{Dog, Stringer, [Dog.String]}
hash(Cat, Stringer) → itab{Cat, Stringer, [Cat.String]}

Subsequent interface conversions for the same pair are O(1) lookup.

type eface struct {
    _type *_type          // type descriptor only
    data  unsafe.Pointer  // pointer to data
}

// No itab needed — no methods to dispatch
var x any = 42
// x._type → *int type descriptor
// x.data  → pointer to 42

Source code → Compiler → Bytecode (.class) → ClassLoader → JVM

ClassLoader hierarchy:
  Bootstrap ClassLoader (java.lang.*)
    └── Platform ClassLoader (java.*)
          └── Application ClassLoader (classpath)
                └── Custom ClassLoaders

Loading phases:
1. Loading     — read .class file bytes
2. Linking
   a. Verification — verify bytecode integrity
   b. Preparation  — allocate memory for static fields
   c. Resolution   — resolve symbolic references
3. Initialization — execute static initializers, <clinit>

0: new           #2    // class Dog
3: dup
4: invokespecial #3    // Dog.<init>:()V  (constructor)
7: astore_1            // store in local var 1 (a)
8: aload_1             // load 'a'
9: invokevirtual #4   // Method Animal.speak:()V
                       // At runtime, JVM sees actual type is Dog
                       // → dispatches to Dog.speak()

HotSpot JVM optimizations:

1. Monomorphic call site (only one type seen):
   invokevirtual Animal.speak
   → JIT inlines Dog.speak directly (with type guard)

2. Bimorphic call site (two types seen):
   invokevirtual Animal.speak
   → JIT generates: if (type == Dog) call Dog.speak
                     else if (type == Cat) call Cat.speak
                     else deoptimize

3. Megamorphic call site (many types):
   → Falls back to full vtable lookup
   → Significant performance penalty

L[C] = C + merge(L[B1], L[B2], ..., L[Bn], [B1, B2, ..., Bn])

where C(B1, B2, ..., Bn) and L[X] is the linearization of X

merge operation:
1. Take the head of the first list
2. If the head is not in the tail of any other list:
   - Add it to the result
   - Remove it from all lists
3. Otherwise, skip to the next list and try its head
4. Repeat until all lists are empty
5. If no head can be selected → Error (inconsistent hierarchy)

Java object header (64-bit JVM with compressed oops):

┌─────────────────────────────────────┐
│ Mark Word (8 bytes)                 │  ← hash code, GC age, lock info
│ Class Pointer (4 bytes, compressed) │  ← pointer to Class metadata
│ [Array Length (4 bytes)]            │  ← only for arrays
├─────────────────────────────────────┤
│ Instance fields                     │
│ (ordered by type size, then name)   │
│ (with padding for alignment)        │
└─────────────────────────────────────┘

Example:
class Point {
    int x;    // 4 bytes
    int y;    // 4 bytes
}

Layout:
  0-7:   Mark Word (8 bytes)
  8-11:  Class pointer (4 bytes, compressed)
  12-15: x (int, 4 bytes)
  16-19: y (int, 4 bytes)
  20-23: padding (align to 8 bytes)
  Total: 24 bytes for just two ints!

// Use JOL (Java Object Layout) library to inspect:
// System.out.println(ClassLayout.parseClass(Point.class).toPrintable());

For a class C with invariant I:

∀ method m in C:
  Precondition:  I holds before m is called
  Postcondition: I holds after m returns

If constructor creates an instance:
  Postcondition: I holds after construction

This is Design by Contract (Bertrand Meyer, Eiffel language):
  {P} operation {Q}
  P = precondition, Q = postcondition
  I = class invariant (implicitly ANDed with P and Q)