# wingolog A mostly dorky weblog by Andy Wingo This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## wastrel milestone: full hoot support, with generational gc as a treat DevFeed: [wastrel milestone: full hoot support, with generational gc as a treat]() Original publisher: [Read original article]() Author: Andy Wingo Published: 2026-04-09T13:48:04Z Content type: article Language: en Sources: [wingolog]() Topics: [WebAssembly](), [scheme](), [toolchain](), [gcc]() Tags: [binaries](), [garbage-collection](), [gc](), [gcc](), [hoot](), [optimization](), [repl](), [scheme](), [spidermonkey](), [toolchain](), [treats](), [v8](), [wasm](), [wastrel](), [web](), [webassembly]() ### AI overview The article describes a Wastrel milestone: compiling WebAssembly files produced by the Hoot Scheme toolchain into native binaries, including a console-based read-eval-print loop. It covers the build process, runtime modules, binary size, dependencies, and initial performance observations. ### Source excerpt Hear ye, hear ye: Wastrel and Hoot means REPL! Which is to say, Wastrel can now make native binaries out of WebAssembly files as produced by the Hoot Scheme toolchain, up to and including a full read-eval-print loop. Like the REPL on the Hoot web page, but instead of requiring a browser, you can just run it on your console. Amazing stuff! try it at home First, we need the latest Hoot. Build it from source, then compile a simple REPL: echo '(import (hoot repl)) (spawn-repl)' > repl.scm ./pre-inst-env hoot compile -fruntime-modules -o repl.wasm repl.scm This takes about a minute. The resulting wasm file has a pretty full standard library including a full macro expander and evaluator. Normally Hoot would do some aggressive tree-shaking to discard any definitions not used by the program, but with a REPL we don't know what we might need. So, we pass -fruntime-modules to instruct Hoot to record all modules and their bindings in a central registry, so they can be looked up at run-time. This results in a 6.6 MB Wasm file; with tree-shaking we would have been at 1.2 MB. Next, build Wastrel from source, and compile our new repl.wasm: wastrel compile -o repl repl.wasm This takes about 5 minutes on my machine: about 3 minutes to generate all the C, about 6.6MLOC all in all, split into a couple hundred files of about 30KLOC each, and then 2 minutes to compile with GCC and link-time optimization (parallelised over 32 cores in my case). I have some ideas to golf the first part down a bit, but the the GCC side will resist improvements. Finally, the moment of truth: $ ./repl Hoot 0.8.0 Enter `,help' for help. (hoot user)> "hello, world!" => "hello, world!" (hoot user)> statics When I first got the REPL working last week, I gasped out loud: it's alive, it's alive!!! Now that some days have passed, I am finally able to look a bit more dispassionately at where we're at. Firstly, let's look at the compiled binary itself. By default, Wastrel passes the -g flag to GCC, which results in bi ## WebAssembly interpreter performance depends on the runtime, not just the code pattern DevFeed: [WebAssembly interpreter performance depends on the runtime, not just the code pattern]() Original publisher: [Read original article]() Author: Andy Wingo Published: 2026-04-07T12:49:39Z Content type: article Language: en Sources: [wingolog]() Topics: [Rust](), [WebAssembly](), [Assembly](), [toolchain](), [V8](), [Chrome](), [Firefox]() Tags: [assembler](), [assembly](), [chrome](), [firefox](), [oracles](), [performance](), [performance-oracles](), [raven](), [rust](), [tail-calls](), [toolchain](), [wasm](), [wasmtime](), [wastrel](), [webassembly]() ### AI overview The article revisits a comparison of switch-based and tail-calling bytecode interpreters. Its measurements confirm earlier native and Wasmtime results but report that Wastrel substantially reduces the apparent WebAssembly penalty, suggesting that the poor performance is runtime-specific rather than inherent to WebAssembly. ### Source excerpt Over on his excellent blog, Matt Keeter posts some results from having ported a bytecode virtual machine to tail-calling style. He finds that his tail-calling interpreter written in Rust beats his switch-based interpreter, and even beats hand-coded assembly on some platforms. He also compares tail-calling versus switch-based interpreters on WebAssembly, and concludes that performance of tail-calling interpreters in Wasm is terrible: 1.2x slower on Firefox, 3.7x slower on Chrome, and 4.6x slower in wasmtime. I guess patterns which generate good assembly don't map well to the WASM stack machine, and the JITs aren't smart enough to lower it to optimal machine code. In this article, I would like to argue the opposite: patterns that generate good assembly map just fine to the Wasm stack machine, and the underperformance of V8, SpiderMonkey, and Wasmtime is an accident. some numbers I re-ran Matt's experiment locally on my x86-64 machine (AMD Ryzen Threadripper PRO 5955WX). I tested three toolchains: Compiled natively via cargo / rustc Compiled to WebAssembly, then run with Wasmtime Compiled to WebAssembly, then run with Wastrel For each of these toolchains, I tested Raven as implemented in Rust in both "switch-based" and "tail-calling" modes. Additionally, Matt has a Raven implementation written directly in assembly; I test this as well, for the native toolchain. All results use nightly/git toolchains from 7 April 2026. My results confirm Matt's for the native and wasmtime toolchains, but wastrel puts them in context: We can read this chart from left to right: a switch-based interpreter written in Rust is 1.5x slower than a tail-calling interpreter, and the tail-calling interpreter just about reaches the speed of hand-written assembler. (Testing on AArch64, Matt even sees the tail-calling interpreter beating his hand-written assembler.) Then moving to WebAssembly run using Wasmtime, we see that Wasmtime takes 4.3x as much time to run the switch-based interpreter, compare ## Wastrel Compiles Hoot Scheme-to-WebAssembly Output DevFeed: [Wastrel Compiles Hoot Scheme-to-WebAssembly Output]() Original publisher: [Read original article]() Author: Andy Wingo Published: 2026-03-31T20:34:23Z Content type: article Language: en Sources: [wingolog]() Topics: [WebAssembly](), [Compiler](), [scheme]() Tags: [accidentally-quadratic](), [aot](), [bigint](), [bignums](), [compiler](), [compilers](), [exception-handling](), [exceptions](), [gc](), [gcc](), [gmp](), [hoot](), [igalia](), [library](), [maps](), [precision](), [scheme](), [standard](), [tail-calls](), [wasm](), [wastrel](), [webassembly](), [whippet]() ### AI overview The article describes recent work on Wastrel, an ahead-of-time WebAssembly compiler, including compiling output from the Hoot Scheme-to-Wasm compiler. It covers implementing bignum operations with mini-gmp and updating Hoot to use standardized WebAssembly exception handling. ### Source excerpt Good day! Today (tonight), some notes on the last couple months of Wastrel, my ahead-of-time WebAssembly compiler. Back in the beginning of February, I showed Wastrel running programs that use garbage collection, using an embedded copy of the Whippet collector, specialized to the types present in the Wasm program. But, the two synthetic GC-using programs I tested on were just ported microbenchmarks, and didn't reflect the output of any real toolchain. In this cycle I worked on compiling the output from the Hoot Scheme-to-Wasm compiler. There were some interesting challenges! bignums When I originally wrote the Hoot compiler, it targetted the browser, which already has a bignum implementation in the form of BigInt, which I worked on back in the day. Hoot-generated Wasm files use host bigints via externref (though wrapped in structs to allow for hashing and identity). In Wastrel, then, I implemented the imports that implement bignum operations: addition, multiplication, and so on. I did so using mini-gmp, a stripped-down implementation of the workhorse GNU multi-precision library. At some point if bignums become important, this gives me the option to link to the full GMP instead. Bignums were the first managed data type in Wastrel that wasn't defined as part of the Wasm module itself, instead hiding behind externref, so I had to add a facility to allocate type codes to these "host" data types. More types will come in time: weak maps, ephemerons, and so on. I think bignums would be a great proposal for the Wasm standard, similar to stringref ideally (sniff!), possibly in an attenuated form. exception handling Hoot used to emit a pre-standardization form of exception handling, and hadn't gotten around to updating to the newer version that was standardized last July. I updated Hoot to emit the newer kind of exceptions, as it was easier to implement them in Wastrel that way. Some of the problems Chris Fallin contended with in Wasmtime don't apply in the Wastrel case: sinc ## nominal types in webassembly DevFeed: [nominal types in webassembly]() Original publisher: [Read original article]() Author: Andy Wingo Published: 2026-03-10T08:19:34Z Content type: article Language: en Sources: [wingolog]() Topics: [WebAssembly](), [wasm]() Tags: [exceptions](), [hoot](), [igalia](), [isorecursive-types](), [nominal-types](), [structural-types](), [type-equality](), [types](), [wasm](), [wastrel](), [webassembly]() ### AI overview This article explains WebAssembly's structural type equality, how recursive type groups approximate nominal typing within a module, and how the nominal typing proposal adds nominal types for stronger separation between types across modules. ### Source excerpt Before the managed data types extension to WebAssembly was incorporated in the standard, there was a huge debate about type equality. The end result is that if you have two types in a Wasm module that look the same, like this: (type $t (struct i32)) (type $u (struct i32)) Then they are for all intents and purposes equivalent. When a Wasm implementation loads up a module, it has to partition the module's types into equivalence classes. When the Wasm program references a given type by name, as in (struct.get $t 0) which would get the first field of type $t, it maps $t to the equivalence class containing $t and $u. See the spec, for more details. This is a form of structural type equality. Sometimes this is what you want. But not always! Sometimes you want nominal types, in which no type declaration is equivalent to any other. WebAssembly doesn't have that, but it has something close: recursive type groups. In fact, the type declarations above are equivalent to these: (rec (type $t (struct i32))) (rec (type $u (struct i32))) Which is to say, each type is in a group containing just itself. One thing that this allows is self-recursion, as in: (type $succ (struct (ref null $succ))) Here the struct's field is itself a reference to a $succ struct, or null (because it's ref null and not just ref). To allow for mutual recursion between types, you put them in the same rec group, instead of each having its own: (rec (type $t (struct i32)) (type $u (struct i32))) Between $t and $u we don't have mutual recursion though, so why bother? Well rec groups have another role, which is that they are the unit of structural type equivalence. In this case, types $t and $u are not in the same equivalence class, because they are part of the same rec group. Again, see the spec. Within a Wasm module, rec gives you an approximation of nominal typing. But what about between modules? Let's imagine that $t carries important capabilities, and you don't want another module to be able to forge those c ## two mechanisms for dynamic type checks DevFeed: [two mechanisms for dynamic type checks]() Original publisher: [Read original article]() Author: Andy Wingo Published: 2026-02-18T16:21:10Z Content type: tutorial Language: en Sources: [wingolog]() Topics: [virtual machines](), [Inheritance](), [WebAssembly](), [JIT](), [Polymorphism]() Tags: [cardelli](), [cohen](), [dfs](), [display-hack](), [dybvig](), [scheme](), [vitek](), [wasm](), [webassembly]() ### AI overview This technical note explains two mechanisms for dynamic instance type checks in virtual machines with single inheritance. It describes DFS numbering when the type set is fixed and the display hack, based on per-type supertype arrays, when types can be added at run time. ### Source excerpt Today, a very quick note on dynamic instance type checks in virtual machines with single inheritance. The problem is that given an object o whose type is t, you want to check if o actually is of some more specific type u. To my knowledge, there are two sensible ways to implement these type checks. if the set of types is fixed: dfs numbering Consider a set of types T := {t, u, ...} and a set of edges S := {, ...} indicating that t is the direct supertype of u, or ε if u is a top type. S should not contain cycles and is thus a direct acyclic graph rooted at ε. First, compute a pre-order and post-order numbering for each t in the graph by doing a depth-first search over S from ε. Something like this: def visit(t, counter): t.pre_order = counter counter = counter + 1 for u in S[t]: counter = visit(u, counter) t.post_order = counter return counter Then at run-time, when making an object of type t, you arrange to store the type's pre-order number (its tag) in the object itself. To test if the object is of type u, you extract the tag from the object and check if tag-u.pre_order mod 2n < u.post_order-u.pre_order. Two notes, probably obvious but anyway: one, you know the numbering for u at compile-time and so can embed those variables as immediates. Also, if the type has no subtypes, it can be a simple equality check. Note that this approach applies only if the set of types T is fixed. This is the case when statically compiling a WebAssembly module in a system that doesn't allow modules to be instantiated at run-time, like Wastrel. Interestingly, it can also be the case in JIT compilers, when modeling types inside the optimizer. if the set of types is unbounded: the display hack If types may be added to a system at run-time, maintaining a sorted set of type tags may be too much to ask. In that case, the standard solution is something I learned of as the display hack, but whose name is apparently ungooglable. It is described in a 4-page technical note by Norman H. Coh