View Binding

The view binding system is the core innovation enabling zero-allocation memory access. Instead of creating new objects for each memory view, references are shared.

MemoryView

A lightweight data container holding positioning information:

public class MemoryView {
    MemorySegment segment;  // The underlying memory segment
    long start;             // Starting offset within segment
    long length;            // Length of data in bytes  
    Memory source;          // Optional reference for lifecycle
}

Design principles:

• Just 4 fields - minimal overhead

• Mutable fields for reuse

• No ownership - views don't own memory

• Pre-allocated once, reused via binding

BoundView

The binding implementation that enables zero-allocation views:

public class BoundView implements BindableView {
    protected final MemoryView mappedView = new MemoryView();  // Pre-allocated!
    protected MemoryView view;       // Current active view
    protected Memory boundSource;    // Reference to bound memory
}

The Two Binding Paths

Path 1: Direct Binding (offset=0)

When binding to the entire memory region, share the source's view directly:

public void bind(Memory memory) {
    unbind();
    this.view = memory.view();     // Direct reference - 1 assignment
    this.boundSource = memory;     // Reference tracking - 1 assignment
    onBind();
}

Memory layout:

BoundView                Memory (FixedMemory/ScopedMemory)
┌─────────────┐          ┌─────────────────────────────┐
│ view ───────┼─────────►│ memView                     │
│             │          │   ├── segment ──► Native    │
│ boundSource─┼─────────►│   ├── start: 0              │
│             │          │   └── length: 1024          │
│ mappedView  │          └─────────────────────────────┘
│ (unused)    │
└─────────────┘

Cost: 2 field assignments
Allocations: ZERO

Path 2: Mapped Binding (offset > 0)

When binding with offset, use the pre-allocated mappedView:

public void bind(Memory memory, long offset, long length) {
    unbind();
    
    // Use pre-allocated mappedView - NO allocation!
    mappedView.segment = memory.segment();
    mappedView.start = memory.start() + offset;
    mappedView.length = length;
    mappedView.source = memory;
    
    this.view = mappedView;
    this.boundSource = memory;
    onBind();
}

Memory layout:

BoundView                Memory
┌─────────────┐          ┌─────────────────────────────┐
│ view ───────┼──┐       │ memView                     │
│             │  │       │   ├── segment ──► Native    │
│ boundSource─┼──┼──────►│   ├── start: 0              │
│             │  │       │   └── length: 1024          │
│ mappedView ◄┼──┘       └─────────────────────────────┘
│  ├─segment──┼──────────────────────► Native
│  ├─start: 64           (same segment, different bounds)
│  └─length: 128
└─────────────┘

Cost: 5 field assignments
Allocations: ZERO (mappedView pre-allocated at construction)

View Propagation

The key insight: views share references. When underlying memory changes, all views see it immediately.

// Packet with ScopedMemory (zero-copy capture)
Packet packet = pool.allocate();  // Has ScopedMemory inside

// Header bound to packet's memory
Ethernet eth = new Ethernet();
eth.bind(packet.memory());  // Direct binding - shares view reference

// Native packet arrives
packet.memory().bind(nativeSegment, 0, 1500);
// This updates: packet.memory().memView.segment = nativeSegment

// eth.view points to same memView - sees change instantly!
// NO additional updates needed for eth to access the data

Propagation diagram:

Before native bind:
    eth.view ──► packet.memory().memView ──► null

Native packet arrives:
    packet.memory().bind(nativeSegment)
        ↓
    packet.memory().memView.segment = nativeSegment  ← Update here

After:
    eth.view ──► packet.memory().memView ──► nativeSegment
                                              ↑
                        eth sees new data immediately!

Comparison to Standard Java

Aspect	Our Design	Java Standard
Slice creation	Pre-allocated mappedView	segment.asSlice() allocates
View sharing	Direct reference when possible	Always creates new object
JIT dependency	Works without JIT	Relies on escape analysis
Allocation	Zero	Object per slice
Predictable	Yes - fixed cost	Varies with JIT warmup

Protocol Header Binding

Headers extend BoundView to inherit zero-allocation binding:

public class Ethernet extends BoundView {
    // Inherits: mappedView, view, boundSource
    
    public int etherType() {
        return segment().get(ValueLayout.JAVA_SHORT, start() + 12) & 0xFFFF;
    }
    
    public void bind(Packet packet) {
        bind(packet.memory());  // Direct binding - 2 assignments
    }
    
    public void bind(Packet packet, long offset) {
        bind(packet.memory(), offset, 14);  // Mapped binding - 5 assignments
    }
}

Performance Summary

Operation	Assignments	Allocations
Direct bind	2	0
Mapped bind	5	0
Unbind	1-4	0
View propagation	0	0

The entire binding system operates with zero allocations in hot paths.