Let’s run Julia everywhere from mobile to web
Anticipated questions about SubsetJuliaVM (sjulia), with answers grounded in the actual implementation. Also: a short Q&A on the Jacobian-conjecture demo (Symbolics.jl).
sjulia)?A. A clean-room implementation of a subset of the Julia language, written in Rust — built to run Julia code where the official runtime cannot go.
source → CST → Core IR → bytecode). All code generation stays in data (bytecode), so it runs on iOS (W^X), Android, WASM, and desktop.sjulia CLI, an iOS/iPadOS App Store app, an Android (Flutter) app, and a browser playground — plus juliars, an experimental Julia→Rust AoT transpiler.A. An interpreter that executes bytecode using an operand stack instead of registers.
1 + 2 * 3 compile (before optimization) to instructions such as PushI64(1), PushI64(2), PushI64(3), MulI64, AddI64 — each operation pops its operands from the stack and pushes the result.code[ip], match on the opcode, execute, advance ip (plus fast paths: pre-decoded straight-line blocks and specialized call sites bypass the generic loop).enum Instr) has 400+ opcodes: typed arithmetic (AddI64, MulF64), dynamic fallbacks (DynamicAdd), control flow (Jump, JumpIfZero), calls, array ops, etc.Frame (locals, captured variables, entry stack height) onto a call-frame stack.println(1 + 2 * 3) actually run? (1/2)A. Everything up to bytecode happens before execution:
1. Parse — the pure-Rust parser builds a CST; precedence makes * bind tighter than +:
call println( binary+ ( 1, binary* (2, 3) ) )2. Lower — CST → Core IR: Call("println", [BinaryOp(+, 1, BinaryOp(*, 2, 3))])
3. Compile — for this literal expression, constant propagation already finishes the math at compile time. The actual emitted bytecode (sjulia --dump-bytecode):
PushI64(7) PrintI64NoNewline PrintNewlineThe VM never multiplies — and println of an inferred Int64 compiles to specialized print opcodes, not even a function call.
println(1 + 2 * 3) actually run? (2/2)A. To watch the stack machine work, hide the constants behind an argument. f(x::Int64) = println(1 + x * 3) compiles to (verified with --dump-bytecode):
| step | instruction | operand stack after (x = 2) |
|---|---|---|
| 1 | PushI64(1) |
[1] |
| 2 | LoadSlotI64(0) |
[1, 2] — load x from its typed slot |
| 3 | PushI64(3) |
[1, 2, 3] |
| 4 | MulI64 |
[1, 6] — pops 2 and 3, pushes 6 |
| 5 | AddI64 |
[7] — pops 1 and 6, pushes 7 |
| 6 | PrintI64NoNewline |
[] — pops 7, prints 7 |
| 7 | PrintNewline |
[] |
code[ip] → match on the opcode → push/pop the stack (optimized straight-line blocks can bypass this generic loop).MulI64 is plain Rust: pop two i64s, multiply, push — no type check, no boxing.A. Three classic interpreter designs:
| Design | How it works | Trade-off |
|---|---|---|
| Tree-walking | Recursively evaluate the AST | Simplest, slowest |
| Stack VM (sjulia today) | Linear bytecode + operand stack | Compact bytecode, simple compiler; CPython/older JVMs work this way |
| Register VM | Bytecode operates on virtual registers | Fewer instructions dispatched; Lua-style |
A. A stack VM today; a register VM is being evaluated.
eval of Expr values).A. Data are nouns, stages are arrows:
Source ─[parse]→ CST ─[lower]→ Core IR ─[compile]→ Bytecode ─[VM interprets]→ resultwasm32-unknown-unknown.A. A layered Cargo workspace: one core pipeline, thin per-platform bindings.
flowchart LR
SRC["Julia<br/>source"] --> PARSER
subgraph CORE["Core pipeline crates"]
direction LR
PARSER["parser<br/>→ CST"] --> LOWER["lowering<br/>→ Core IR"] --> COMPILE["compile<br/>inference · opt"] --> BC["bytecode"] --> VM["vm<br/>(stack VM)"]
end
style CORE fill:#2b2b2b,stroke:#777,color:#ddd
parser / lowering / compile / bytecode / vm — each stage is a separate crate with its own tests and a well-defined output (CST / Core IR / bytecode).
A. Thin per-platform bindings around the same core:
flowchart LR FE["front end<br/>parser → lowering → Core IR"] --> VM["bytecode compiler<br/>+ stack VM"] FE --> AOT["aot: juliars<br/>Core IR → Rust source + runtime crate"] VM --> FFI["ffi<br/>hand-written C ABI"] VM --> WEB["web<br/>wasm-bindgen"] FFI --> MOB["iOS (Swift)<br/>Android (Flutter)"] WEB --> JS["Browser<br/>playground (JS)"]
A. The tree-shaped intermediate representation at the center of the pipeline — “Julia after desugaring.”
CST ─[lowering]→ Core IR ─[bytecode compiler]→ bytecode → stack VM
└────[aot: juliars]─────→ Rust sourceAssign, For/ForEach, While, Literal, Var, BinaryOp, Call, ArrayLiteral, … E.g. println(1 + x * 3) becomes Call("println", [BinaryOp(+, 1, BinaryOp(*, Var(x), 3))]).@code_lowered) — but still a tree, not SSA; SSA appears later, inside the compiler’s optimizer.Span for precise error locations; hot identifier positions are interned; Call carries kwargs and splat masks, so Julia’s calling convention survives lowering.sjulia --compile f.jl -o f.sjir saves it, --run-ir executes it, and juliars accepts it directly — the shared input of both back ends.A. Code generation happens up front — and anything generated later is still only bytecode.
CallSpecialize) only emits more bytecode — data, not machine code.A. Portability and predictability:
A. Method tables + two-level dispatch:
MethodTable of signatures (Tuple{argtypes...}, incl. where params).CallSpecialize compiles a per-type-signature specialized bytecode version of the callee on first use and caches it).Any-typed call sites use dynamic dispatch opcodes with a most-specific-match search, accelerated by dispatch caches (including negative caching) and a first-argument-type index (for primitive first arguments) — the interpreter analogue of inline caches.A. A hybrid scheme, tuned for a single-threaded, no-JIT VM:
Value enum; strings and other shared immutable data use Rust reference counting (Rc — cloning is a refcount bump, not a copy).Vec<StructInstance>), referenced by index.A. That is the price of “no JIT”:
juliars (AoT → Rust) removes interpretation entirely and matches official Julia.A. sjulia claws a lot back before execution, at compile time:
AddI64, LoadSlotF64) instead of boxed generic opsA. The phenomena all exist — but for these measured workloads they are far lighter than in official Julia, because the first-use work is bytecode compilation, not the second-scale native-compilation latency associated with Julia TTFP workloads.
sjulia -e 'println(1)' finishes in ~0.1 s total.using. Measured (total process time, baseline 0.05 s): using Plots 0.29 s, OrdinaryDiffEq 0.16 s, AbstractAlgebra 0.59 s, Distributions 0.72 s. Lazy per-signature bytecode specialization adds a minor first-call warmup on top.using Plots, the incremental first plot(...) call measures only ~3 ms (subsequent calls ~1 ms) — plotting just builds a Plot value and emits Plotly JSON, with no native-code generation.using Plots; plot(sin) once during startup, before the Run button is enabled.A. Two cache layers exist — complete for Base, shallower than pkgimages for packages:
Module is cached on disk, keyed by source hash + metadata-schema fingerprint + OS/arch; the files are even named in homage to Julia’s .ji (Distributions.<hash>.ji.json, under a temp cache dir; disabled on iOS/WASM).using. Measured accordingly: using Distributions cold 0.72 s vs. warm 0.71 s — parse+lower savings only.A. Yes — CPython compiles to bytecode and interprets it on an operand stack, same family as sjulia.
.py → .pyc bytecode → the eval loop interprets it. Same architecture “family”.A. Typed instructions vs. generic instructions.
BINARY_OP; every execution inspects the operand types to decide what “+” means (3.11+ adaptive specialization rewrites hot sites — but still at run time).AddI64, MulF64, LoadSlotF64 — no type checks, no boxing in hot loops.A. Wrapping a raw machine value in a heap object so it can be handled generically.
Int64 is just 8 bytes — it fits in a CPU register or on the stack.Any boundaries); sjulia does it by inferring types ahead of execution and keeping scalars inline in its Value enum (I64(i64), F64(f64)) and in typed local slots.A. Unboxed enum variants vs. everything-is-a-PyObject.
PyObject; 1 + 2 involves pointer dereferences and refcount traffic.Value is a Rust enum — I64(i64), F64(f64) are stored inline, unboxed; type-stable locals live in typed slots.Rc for immutable values and a mark & compact pass that runs only at safe points — hot loops pay no per-assignment bookkeeping.A. Multiple dispatch vs. single dispatch.
obj.method(...)).CallSpecialize).using Plots download the real Plots.jl?A. No — nothing is ever downloaded (also an App Store requirement).
include_str! and loaded from virtual paths, since iOS/WASM have no package filesystem.base/ + 10 stdlib modules — mirroring official Julia’s layout.A. Plots.jl output renders as Plotly JSON on every host.
Plot value; the VM serializes it to an artifact with MIME application/vnd.plotly+json.plotly.min.js viewer — same interactive plots on every platform, including offline.@animate/@gif (Plotly frames). A second artifact type, JSXGraph JSON, serves interactive geometry.A. Parity with official Julia 1.12 is enforced mechanically:
1e-10); a separate parity sweep runs eligible fixtures under both real julia and sjulia and compares.eval/Expr, BigInt/BigFloat/Rational/Complex, Tasks & Channels (via VM-level continuations).@inbounds, @inline), and Dict-heavy hot loops are unoptimized.A. No. Julia has no complete, normative, implementation-independent language specification — so “fully Julia-compatible” can only be defined operationally, not as conformance to a standard.
julia and sjulia, demand identical output, and pin a concrete version (Julia 1.12) as the target.A. The everyday core of the language (every item on these two slides was verified by running it on the sjulia binary):
if/elseif/else, for (ranges, in over iterables, tuple destructuring), while, break/continue, try/catch/finally, &&/|| short-circuits, ternary ?:, let (even official Julia’s soft-scope rules for top-level loops are reproduced)function/short-form/anonymous (x -> x^2), recursion, do blocks, keyword arguments, varargs & splat (f(args...), ; kwargs...), return-type annotations, first-class functions and higher-order functionsmodule/baremodule, using/import (incl. using M: f), qualified calls M.f, exportim (Complex), // (Rational), BigInt/BigFloat, string interpolation "$(x)", raw/regex/byte string macros, juxtaposition (2x, 3.0im)A. Including the parts that make Julia Julia:
struct / mutable struct, inner constructors, parametric types (Point{T}, where clauses, Type{T} dispatch), abstract types, Union types, multiple dispatch with most-specific selectionx .+ y, f.(xs)), views/SubArray (a representative subset), the full iterate protocolDict, Set, tuples, named tuples, ranges; string operations and PCRE-style regexmacro with hygiene and esc(), quote/$ interpolation, Expr/QuoteNode, eval, macroexpand; built-ins like @test/@testset, @time, @show, @assert, @enum, @kwdefStatistics, Random, Dates, Test, Printf, Iterators, LinearAlgebra (partial), and moredocs/vm/UNIMPLEMENTED.md — see also the next slideA. Everything that would break the sandboxed, offline, no-downloaded-code model:
Pkg.add, no registry, no downloads. using X only reaches the ~34 packages bundled into the binary (App Store apps may not download code, and the design is offline-first).download.pwd, mkdir, rm, stat, …) are unimplemented; iOS/WASM have no free filesystem, so include resolves through virtual embedded paths instead.run(cmd), environment control, or signals.@ccall/@cfunction/pointer/unsafe_*: arbitrary native code would defeat the whole sandbox/no-JIT story.Threads API exists as stubs, Tasks/Channels are cooperative continuations, no Distributed.@code_llvm/@code_native (there is no LLVM); use --dump-bytecode instead.A. One core, three thin bindings — iOS and Android share a versioned hand-written C ABI; Web has its own wasm-bindgen API:
cargo build --target aarch64-apple-ios → static lib → SubsetJuliaVM.xcframework; SwiftUI calls compile_and_run_detailed, repl_session_eval, etc. directly.cargo-ndk for each ABI, loaded from a Flutter app through dart:ffi.wasm-bindgen crate built with wasm-pack (size-optimized profile: opt-level="s", LTO); JS calls run_from_source(code, seed).juliars (AoT) work, and why no libjulia?A. It transpiles the Core IR to Rust source, then rustc compiles it:
rustc -O.Value, dispatch helpers) — never on Julia’s C runtime, because the whole toolchain is pure Rust.--pure-rust) compile to standalone binaries; scalar entry points can be exported as a C ABI.A. Memory pages that can be both written to and executed — the thing a JIT needs.
A. Runtime code generation is reserved for Apple; interpreting data is not.
mmap with MAP_JIT) requires an entitlement that ordinary distributed apps cannot obtain — Apple reserves it for its own apps like Safari’s JS engine (exceptions: approved alternative browser engines, debugger-attached dev builds).A. The constraints rule out the usual options:
libjulia is not built for iOS targets.A. Roughly 570k lines of Rust (src/ code, excluding tests), plus a large pure-Julia layer:
juliars) is ~53k lines — roughly 9–10% of the Rust code.base/, plus 10 stdlib modules), and ~34 bundled packages (Plots, Distributions, AbstractAlgebra, …).julia.A.
wasm32-unknown-unknown support with no C toolchain involved was decisive (it is also why the parser was rewritten from tree-sitter’s generated C into pure Rust).enum + match fit a bytecode interpreter naturally (tagged Value, exhaustive opcode dispatch).