Execution Model

Metered ticking

The VM executes at most 5,000 instructions per game tick (~100,000/second) and then yields until the next tick. An infinite loop is therefore harmless — it just runs slowly and never blocks the server. Consequences:

• A tight while true { } with no sleep burns the whole budget every tick and starves nothing but itself.
• Timing-sensitive code should use sleep, which parks the VM at zero cost.

Blocking calls

Three builtins can park the VM. While parked it consumes no budget; the scheduler resumes it.

Call	Wakes when
sleep(ticks)	the given number of game ticks have elapsed
read()	a line is typed into the terminal
recv() / recv(timeout)	a message arrives, or the timeout expires (returning nil)

sleep(0) (or any non-positive value) returns immediately without parking.

Lifecycle and persistence

• run (or Save & Run) compiles the source. Compile errors print as [compile error] and nothing runs.
• A finished program prints [program finished]; a runtime error prints [error] line N: ... and stops.
• The program source, hostname, console scrollback, disk contents and redstone output levels are all saved with the block. Break the pot and they are gone — there is no item persistence.
• If a program was running when the chunk unloaded, it restarts from the beginning when the chunk reloads. VM state (variables, position in the program) is not saved — use the disk to keep anything that must survive a reload.

Runtime limits

Limit	Value
Instructions per tick	5,000
Value stack	1,024 slots
Call frames	64
Locals per function	256
Parameters / arguments	16
List literal elements	1,024
Longest string	50,000 chars
Longest list	10,000 elements
Program source	100,000 chars
Console scrollback	200 lines, 256 cols
Mailbox	64 messages
Terminal input queue	16 lines
Disk	256 keys, 64-char keys, 4,096-char values

Exceeding a runtime limit raises a normal script error (string too long, list too long, stack overflow, …).

---

See also: Standard Library · Errors & Gotchas · Wiki Home