Skip to main content

Overview

Monty supports serialization of both parsed code and execution state, enabling:
  • Code caching: Parse once, serialize, reuse later
  • Execution suspension: Pause execution, save state, resume later
  • Process migration: Move execution between processes or machines
  • Persistent workflows: Store long-running computations in databases
Serialization uses the postcard format - a compact, binary encoding designed for embedded systems.

Serializing Monty Instances

Caching Parsed Code

Parsing and compiling Python code has overhead. Serialize a Monty instance to avoid re-parsing:

What Gets Serialized

When you serialize a Monty instance, it includes:
  • Compiled bytecode for all functions
  • Interned strings (variable names, constants)
  • Namespace size and structure
  • Type checking information (if enabled)
The original source code is included in serialized data for error reporting. If your code contains sensitive information, encrypt the serialized bytes.

Serializing Execution State

When using iterative execution, you can serialize snapshots at any suspension point.

Basic Snapshot Serialization

What Gets Serialized in Snapshots

Execution snapshots include:
  • VM State: Instruction pointer, call stack, exception handlers
  • Heap: All allocated objects (strings, lists, dicts, etc.)
  • Namespaces: All variable bindings (global and local)
  • Resource Tracker: Allocation counts, memory usage, time limits
  • Compiled Code: Bytecode and interns (same as Monty instance)
Time limits are reset when deserializing execution state. The timer starts from zero after calling load().

Snapshot Types

All snapshot types support serialization:

FunctionSnapshot

Paused at external function call:

OsSnapshot

Paused at OS operation:

NameLookupSnapshot

Paused at name resolution:

Use Cases

1. Distributed Execution

Execute expensive computations across multiple workers:

2. Long-Running Workflows

Persist execution state for workflows that take hours or days:

3. Interactive Debugging

Pause execution, inspect state, then continue:

4. Code Template Caching

Pre-parse code templates and cache them:

Security Considerations

Critical: Only deserialize data from trusted sources.Deserializing malicious snapshot data can:
  • Restore arbitrary execution state
  • Execute malicious code when resumed
  • Bypass resource limits
  • Access unintended memory

Safe Deserialization

Serialization Format

Monty uses postcard - a compact, deterministic binary format:
  • No schema evolution: Deserializing with a different Monty version may fail
  • Compact: Typically 10-50% smaller than JSON
  • Fast: Zero-copy deserialization where possible
  • Deterministic: Same data always produces same bytes
For version-stable persistence, consider wrapping serialized data in a versioned container format.

Performance

Serialization Speed

  • Monty instance: ~0.1ms for typical code
  • Execution snapshot: ~0.5-5ms depending on heap size

Size Examples

Best Practices

1

Cache Parsed Code

Always serialize and cache Monty instances when executing the same code multiple times.
2

Validate Signatures

Sign serialized data with HMAC before saving to untrusted storage.
3

Version Your Data

Wrap serialized bytes in a versioned container to handle Monty version upgrades.
4

Set Expiration

Set TTL on cached snapshots to prevent unbounded storage growth.
5

Compress for Network

Use gzip/zstd compression when sending snapshots over the network.

Next Steps

Execution Modes

Learn about run() vs start()/resume() execution

Resource Limits

Configure memory, time, and recursion limits