Our JS engine recompiles from source on every request so the committed heap never holds code. What did we give up?
Building a JavaScript engine (V9) as part of a from-scratch browser in Rust, and one design decision keeps getting questioned, so I'd like this sub's read on it.
The engine is a bytecode VM over a bounded, serializable heap. Scripts are scanned, parsed and compiled to stack bytecode on every request. Code is identified by its byte offset in the page, so the committed state never carries executable code: a closure names a code site, and when the state is loaded again it is validated against freshly compiled sources. Frames are explicit heap data rather than a native stack, so a generator or an async function suspends into the heap and resumes in a later request after a serialize round trip. An await on a fetch continues when the host delivers the response, possibly seconds later.
The reasons: the host (the browser) wants to snapshot a page's script state, hand it between processes, and never trust a blob that could contain code. Every bound (objects, properties, environments, string units, call depth, operations) applies to live values, a precise stop-the-world collector runs between instructions so garbage never counts, and a bound crossed stops the script with a limit error the script cannot catch. There is no JIT. V8's tiering hints evaluate to undefined, which is how V8 itself behaves without an optimizer, so its mjsunit suite runs unchanged.
What we pay: compile cost on every request, and a heap representation that has to be stable enough to round-trip, which rules out a lot of pointer tricks.
Questions for people who have built interpreters or VMs:
1. Caching bytecode keyed by a source hash seems like the obvious next step. Is there a reason not to, if the invariant is only "no code in the committed state" rather than "no code cache anywhere"?
2. Has anyone else made frames heap data so that suspended code survives a serialize round trip, and what did it cost you in call performance? We accepted the hit without measuring the alternative.
3. Precise stop-the-world collection between instructions is simple and makes the bounds exact. Where does it break down in practice? I would rather hear it here than find out.
Source if anyone wants to read it: the mars/crates/v9 folder of github.com/OyadotAI/oya-browser, README first. It is source-available under a sustainable use license, not an OSI license, saying so up front.
2 comments
What a from-scratch browser actually trusts: webpki-roots, exact pins, and the eMudhra week
We're writing a browser from scratch in Rust. It's called Mars: own HTML parser and layout engine, own JS engine, own HTTP framing on top of rustls, native macOS shell. When you own the network stack you also own the question Apple is getting shouted at about this week: which certificate authorities does the thing trust, and who updates that list?
How Mars gets its roots
Our network crate, Relay, builds a rustls RootCertStore from webpki_roots::TLS_SERVER_ROOTS once at startup and keeps it in a OnceLock. That's it. No OS keychain, no /etc/ssl/cert.pem, no runtime download. The trust anchors are whatever the webpki-roots crate contained the day the lockfile was written. That's a normal choice for rustls users, and it has one property worth saying out loud: the trust store ships inside the binary, so it only changes when you rebuild.
What I found today
The eMudhra / emSign compromise is around ten days old. Mozilla, Google, Microsoft and most Linux distros dropped the roots within days. Apple blocked the certificates in Safari and Mail but left the macOS command line tools reading a cert.pem that still trusts them, which is why Hacker News is on fire.
In that thread someone asked whether there's a Rust crate that compiles root certs into binaries. There is, and we use it. So I checked. Both crates that do TLS in Mars pinned webpki-roots = "=1.0.9", released July 18. Grepping src/lib.rs in each release:
- 1.0.9 (Jul 18): emSign Root CA - G1, emSign Root CA - C1, emSign ECC Root CA - G3, emSign ECC Root CA - C3
- 1.0.10 (Oct 19): removed emSign ECC Root CA - G3
- 1.0.11 (Oct 23): removed emSign Root CA - C1 and emSign ECC Root CA - C3, tracking the CCADB removals
So Mars, as of this morning, had the same hole as /usr/bin/curl on a Mac. Nothing at runtime would have told us. rustls does no revocation checking unless you hand it CRLs, and we don't. There is no blocklist. The bundle is the whole story.
The fix and the lesson
The fix took four minutes: bump both pins to =1.0.11, cargo update -p webpki-roots, cargo check. It compiles and it's in the tree.
The lesson is the uncomfortable one. Mars pins dependencies to exact versions, and an exact pin on a root bundle is a decision to stop receiving CA removals. It means someone has to watch that crate's releases the way an OS vendor watches the CCADB. For a browser that isn't optional, so it goes on the release checklist. I'd like to know how other rustls users handle it: Dependabot on that one crate, a CI job that diffs root names between versions, or just reading the release notes.
Repo: OyadotAI/oya-browser, folder mars/. Source-available under a Sustainable Use License, SDK and CLI MIT.
Mars - A browser written from scratch in Rust (own HTML/layout engine, own JS engine, own HTTP stack), made for a person and an AI agent to share
I’m hiring Sr product engineers and Sr Software engineers… our product is oyabrowser.com an AI Native browser check it out and check our GH OyadotAI/oya-browser
Remote first, competitive compensation and we’re VC backed.
Interview process:
- Clone the source code
- Find a of bug or enhancement
- Create a PR
- DM me with your resume and the PR link.
This is a Sr role so you must have at least 5 years of experience
21 likes · 149,485 views
Mentions
Our JS engine recompiles from source on every request so the committed heap never holds code. What did we give up? Building a JavaScript engine (V9) as part of a from-scratch browser in Rust, and one design decision keeps getting questioned, so I'd like this sub's read on it. The engine is a bytecode VM over a bounded, serializable heap. Scripts are scanned, parsed and compiled to stack bytecode on every request. Code is identified by its byte offset in the page, so the committed state never carries executable code: a closure names a code site, and when the state is loaded again it is validated against freshly compiled sources. Frames are explicit heap data rather than a native stack, so a generator or an async function suspends into the heap and resumes in a later request after a serialize round trip. An await on a fetch continues when the host delivers the response, possibly seconds later. The reasons: the host (the browser) wants to snapshot a page's script state, hand it between processes, and never trust a blob that could contain code. Every bound (objects, properties, environments, string units, call depth, operations) applies to live values, a precise stop-the-world collector runs between instructions so garbage never counts, and a bound crossed stops the script with a limit error the script cannot catch. There is no JIT. V8's tiering hints evaluate to undefined, which is how V8 itself behaves without an optimizer, so its mjsunit suite runs unchanged. What we pay: compile cost on every request, and a heap representation that has to be stable enough to round-trip, which rules out a lot of pointer tricks. Questions for people who have built interpreters or VMs: 1. Caching bytecode keyed by a source hash seems like the obvious next step. Is there a reason not to, if the invariant is only "no code in the committed state" rather than "no code cache anywhere"? 2. Has anyone else made frames heap data so that suspended code survives a serialize round trip, and what did it cost you in call performance? We accepted the hit without measuring the alternative. 3. Precise stop-the-world collection between instructions is simple and makes the bounds exact. Where does it break down in practice? I would rather hear it here than find out. Source if anyone wants to read it: the mars/crates/v9 folder of github.com/OyadotAI/oya-browser, README first. It is source-available under a sustainable use license, not an OSI license, saying so up front.
What a from-scratch browser actually trusts: webpki-roots, exact pins, and the eMudhra week We're writing a browser from scratch in Rust. It's called Mars: own HTML parser and layout engine, own JS engine, own HTTP framing on top of rustls, native macOS shell. When you own the network stack you also own the question Apple is getting shouted at about this week: which certificate authorities does the thing trust, and who updates that list? How Mars gets its roots Our network crate, Relay, builds a rustls RootCertStore from webpki_roots::TLS_SERVER_ROOTS once at startup and keeps it in a OnceLock. That's it. No OS keychain, no /etc/ssl/cert.pem, no runtime download. The trust anchors are whatever the webpki-roots crate contained the day the lockfile was written. That's a normal choice for rustls users, and it has one property worth saying out loud: the trust store ships inside the binary, so it only changes when you rebuild. What I found today The eMudhra / emSign compromise is around ten days old. Mozilla, Google, Microsoft and most Linux distros dropped the roots within days. Apple blocked the certificates in Safari and Mail but left the macOS command line tools reading a cert.pem that still trusts them, which is why Hacker News is on fire. In that thread someone asked whether there's a Rust crate that compiles root certs into binaries. There is, and we use it. So I checked. Both crates that do TLS in Mars pinned webpki-roots = "=1.0.9", released July 18. Grepping src/lib.rs in each release: - 1.0.9 (Jul 18): emSign Root CA - G1, emSign Root CA - C1, emSign ECC Root CA - G3, emSign ECC Root CA - C3 - 1.0.10 (Oct 19): removed emSign ECC Root CA - G3 - 1.0.11 (Oct 23): removed emSign Root CA - C1 and emSign ECC Root CA - C3, tracking the CCADB removals So Mars, as of this morning, had the same hole as /usr/bin/curl on a Mac. Nothing at runtime would have told us. rustls does no revocation checking unless you hand it CRLs, and we don't. There is no blocklist. The bundle is the whole story. The fix and the lesson The fix took four minutes: bump both pins to =1.0.11, cargo update -p webpki-roots, cargo check. It compiles and it's in the tree. The lesson is the uncomfortable one. Mars pins dependencies to exact versions, and an exact pin on a root bundle is a decision to stop receiving CA removals. It means someone has to watch that crate's releases the way an OS vendor watches the CCADB. For a browser that isn't optional, so it goes on the release checklist. I'd like to know how other rustls users handle it: Dependabot on that one crate, a CI job that diffs root names between versions, or just reading the release notes. Repo: OyadotAI/oya-browser, folder mars/. Source-available under a Sustainable Use License, SDK and CLI MIT.
Mars - A browser written from scratch in Rust (own HTML/layout engine, own JS engine, own HTTP stack), made for a person and an AI agent to share
I’m hiring Sr product engineers and Sr Software engineers… our product is oyabrowser.com an AI Native browser check it out and check our GH OyadotAI/oya-browser Remote first, competitive compensation and we’re VC backed. Interview process: - Clone the source code - Find a of bug or enhancement - Create a PR - DM me with your resume and the PR link. This is a Sr role so you must have at least 5 years of experience