Slot table and runtime internals

← Back to Compose

Slot Table and Runtime Internals Deep Dive

Overview

The slot table is Compose runtime's structural memory for composition groups, remembered values, and positional metadata.

Core Concepts

• group structure and anchors
• positional memoization
• remember value storage
• key-based identity adjustments

Runtime Internals

Composer writes group operations into slot table during composition. On updates, runtime reuses or edits groups instead of rebuilding the full tree.

Composition / Recomposition Flow

• traverse existing groups
• detect structural changes
• insert/move/remove group operations
• update remembered slots and apply node edits

State Management

remember correctness depends on stable call ordering and keys relative to slot positions.

Code Examples

@Composable
fun ItemRow(item: ItemUi) {
    val formatter = remember(item.id) { NumberFormat.getInstance() }
    Text(formatter.format(item.count))
}

Common Interview Questions

• Q: What breaks positional memoization? A: Answer from runtime mechanics: state ownership, recomposition triggers, effect lifecycle, and frame-time impact measured with tooling.
• Q: How are list item moves handled with and without keys? A: Answer from runtime mechanics: state ownership, recomposition triggers, effect lifecycle, and frame-time impact measured with tooling.

Production Considerations

• keep composition structure predictable
• use explicit item keys in dynamic collections
• avoid implicit identity assumptions in complex conditionals

Performance Insights

Healthy slot reuse avoids unnecessary churn in composition memory and apply work.

Senior-Level Insights

Staff-level conversations often include slot-table mental model for debugging state jump bugs and list identity issues.