MMTk Bindings

MMTk Bindings

Memory Management Toolkit VM interface for GC implementation.

Overview

MMTk (Memory Management Toolkit) is a flexible garbage collection framework that provides a clean separation between GC algorithm design and VM implementation. JNode integrates MMTk through a VM-specific binding layer under core/src/mmtk-vm/, allowing the use of sophisticated GC strategies while remaining tightly coupled to JNode's VM implementation.

The MMTk bindings provide three primary interfaces: the VM interface (core MMTk classes adapted for JNode), Plan implementations (GC algorithms like MarkSweep, GenRC, NoGC), and Space management (heap region allocation and layout). This integration allows JNode to leverage MMTk's mature GC algorithms while maintaining the low-level control required for an OS-level Java VM.

Key Components

Class / File	Role
core/src/mmtk-vm/org/mmtk/vm/Plan.java	Stub replaced at build time with actual GC plan
core/src/mmtk-vm/org/mmtk/vm/Memory.java	VM interface for heap region queries (HEAP_START, HEAP_END, AVAILABLE_START, AVAILABLE_END)
core/src/mmtk-vm/org/mmtk/vm/Collection.java	VM interface for triggering GC collection cycles
core/src/mmtk-vm/org/jnode/vm/memmgr/mmtk/ms/Plan.java	MarkSweep GC plan implementation, extends MarkSweep base class
core/src/mmtk-vm/org/jnode/vm/memmgr/mmtk/genrc/Plan.java	Generational RC (Reference Counting) plan implementation
core/src/mmtk-vm/org/jnode/vm/memmgr/mmtk/nogc/Plan.java	NoGC plan for debugging/tracing
core/src/mmtk-vm/org/jnode/vm/memmgr/mmtk/BaseMmtkHeapManager.java	Heap manager base class bridging JNode's VM to MMTk
core/src/mmtk-vm/org/jnode/vm/memmgr/mmtk/BaseMmtkGCStatistics.java	GC statistics collection

How It Works

Build-Time Plan Selection

JNode's build process replaces the stub org.mmtk.vm.Plan with the actual GC plan implementation (e.g., org.jnode.vm.memmgr.mmtk.ms.Plan for MarkSweep). This allows the same MMTk API to be used with different GC strategies without source code changes.

Heap Memory Interface

The org.mmtk.vm.Memory class provides the bridge between MMTk and JNode's virtual memory layout:

// Query heap boundaries from VM architecture
public static Address HEAP_START() {
    return VmUtils.getVm().getArch().getStart(VirtualMemoryRegion.HEAP);
}

public static Address AVAILABLE_START() {
    return VmUtils.getVm().getArch().getStart(VirtualMemoryRegion.AVAILABLE);
}

// Get VM space (boot image space)
public static ImmortalSpace getVMSpace() {
    // Reserved for boot image, must be initialized first
}

Plan Instance Management

Each processor has its own plan instance accessed via Plan.getInstance():

public static Plan getInstance() {
    return (Plan) VmProcessor.current().getHeapData();
}

The plan provides getHeapHelper() to access JNode's heap management facilities.

Heap Manager Integration

BaseMmtkHeapManager extends VmHeapManager and implements the core GC integration points:

• Object header management (flags offset, TIB offset, header size)
• Memory resource allocation for heap regions
• GC trigger points and collection coordination
• Object layout integration (uses ObjectLayout for header calculations)

GC Plan Implementations

MarkSweep (ms/Plan.java): A simple mark-sweep collector that traces all reachable objects and frees unreachable ones. Extends MMTk's MarkSweep base class.

GenRC (genrc/Plan.java): A generational collector with reference counting, designed for better throughput on workloads with many short-lived objects.

NoGC (nogc/Plan.java): A no-op collector used for debugging and tracing, useful for understanding allocation patterns without GC overhead.

Gotchas & Non-Obvious Behavior

• Build-time stub replacement: The org.mmtk.vm.Plan stub is replaced during build. The actual plan class is selected based on build configuration, not source code imports.

• Boot image space reservation: Memory.getVMSpace() must be called first during heap initialization, as it reserves the lowest virtual addresses for the boot image. Other space allocations fail if called before this.

• Per-processor plan instances: Each VmProcessor has its own plan instance. GC operations are coordinated across processors but the plan is processor-local.

• Object header dependency: The heap manager requires exact knowledge of object header layout (flags offset, TIB offset) which must match JNode's ObjectLayout implementation.

• GCSpy disabled: All plan implementations have WITH_GCSPY = false, meaning GC visualization/debugging features are compiled out in JNode.

Related Pages

• Memory-Management — Higher-level memory management overview
• Boot-Sequence — Boot image space initialization
• Paging-Implementation — Virtual memory regions used for heap
• Object-Layout — Object header structure that GC depends on