探索メモ: MoonBit の Workers 用アダプターを磨く #

MoonBit 側 #

• **wasm-gc の出力にも線形メモリがある。** moon build --output-wat で見ると (memory $moonbit.memory 1) があり、何も読み書きしていない（i32.load / i32.store が 1 つもない）。link 設定の "export-memory-name": "memory" で export できる。
• **inline wasm で線形メモリを読み書きできる。** extern "wasm" fn store8(addr : Int, v : Int) = #|(func (param i32) (param i32) (i32.store8 (local.get 0) (local.get 1))) のように書くと、wasm-gc でも i32.load8_u、i32.store16、memory.size、memory.grow が使えた。ただし、moon が将来この 1 ページを自分で使い始めたら壊れる（今は使っていない、というだけ）。
• **method は予約語。** Site::render に method~ という引数を足すと reserved_keyword の警告が出る（「将来のために予約」）。spike では verb~ にした。
• **wasm-gc の link 設定には imported-string-constants がある**（package の設定）。use-js-builtin-string の文字列定数を import する名前空間で、既定は "_"。"wasm:js/string-constants" にすると、workerd のフラグが決め打ちしている名前空間に合わせられる。
• **builtin string にすると、埋め込んだ文章が文字列定数の import 名になる。** 案 E の Wasm は import が 221 個（wasm:js/string-constants が 215、wasm:js-string の length、charCodeAt、equals、concat、fromCodePoint、fromCharCodeArray）で、いちばん長い import 名は 23,369 文字。それでも Wasm は 24 KB ほど小さくなる。

JS / Workers 側 #

• **memory.grow のあと、前の memory.buffer は detach される。** new Uint8Array(memory.buffer, 0, serve(n)) と書くと、引数の評価順で memory.buffer を先に読むので、serve の中でメモリが増えると TypeError: Cannot perform Construct on a detached ArrayBuffer になる。serve の戻り値を先に変数に取る。いちばん大きいページ（53,784 B）は初期の 1 ページ（64 KiB）に収まるので、Wasm がメモリを多めに確保するまでこの誤りに気づかなかった。
• **Workers では、どの案でも本文は chunked で返る。** wrangler dev では、本文を文字列で渡しても Uint8Array で渡しても Transfer-Encoding: chunked になり、Content-Length は付かない。Go 版のサーバーは Content-Length: 1877 を付ける。make compare はこれを比べないので一致する。本番の Cloudflare の前段で変わるかは見ていない。
• **HEAD**: wrangler dev では、どの案でも HEAD に本文が付かない。Go 版と同じく Content-Type が付く。
• **メソッド**: 今の Worker は POST にも 200 で同じページを返す。Go 版は GET と HEAD 以外に 404 の「Page not found.」を返す。メソッドを Wasm に渡す案（C、D、D'、E）は、本文まで Go 版と一致した。
• **壊れた % エスケープ**: /%E0%A4%A はどちらも 400（本文は違う。Go 版は 400 Bad Request、Worker は Bad request: malformed path）。**/%FF は Go 版が 404、Worker は 400。** %FF は形の上では正しいエスケープだが UTF-8 として不正なので、decodeURIComponent が投げる。全案に共通の違いで、make compare の既定のパスには入っていない。その後、案 H で直した。
• **workerd による URL の正規化**（/docs/ja/../TODO が届く前に /docs/TODO になる）は、どの案でも変わらない。アダプターの側では直せない。
• wrangler dev の往復時間は、どの案も / が約 1.1 ms、いちばん大きいページが 1.5〜1.8 ms で、案の差（0.3 ms 程度）はばらつきに埋もれる。案の比較は Node で行った。
• Node の Request / Response を作って本文を読むだけの Worker（Wasm を呼ばない）は、1,732 文字の本文で 6 µs、36,670 文字で 22 µs かかる。以下の Node の数字にはこれが含まれる。

測り直して分かったこと #

• **いちばん大きいページの render は、Wasm の中だけで約 345 µs かかる**（Markdown の解析を含む）。前の調査の /big（80 µs 前後）は段落を並べただけの合成ページだったので、実際のページはそれより重い。受け渡しを速くすると、残りのほとんどは render になる。
• / の render は約 10 µs。

C、D、D' に共通の形 #

• 入力は 1 つの文字列 BASE_URL\nmethod\nquery\npath にして、JS がメモリの先頭に書き、serve(長さ) を呼ぶ。パスは最後に置くので、デコードした結果に改行が入っても困らない（最初の 3 つの改行だけで区切る）。クエリーは url.search のままなので改行を含まない。
• 出力は status\nname\tvalue\n...\n\n と本文を、同じ場所に上書きする。serve は長さを返す。ヘッダーの名前と値は改行を含まない。
• BASE_URL を毎回渡すので、set_base_url と、JS 側の「前に渡した値」の状態がいらない。Wasm は前の値と違うときだけ Site を作り直す。
• メモリが足りなければ、入力は JS が memory.grow、出力は Wasm が memory.grow する。
• D と D' は本文を Uint8Array のまま Response に渡すので、JS の文字列を作らない。ヘッダーの部分だけ TextDecoder で文字列にする。

E（builtin string）について #

• **workerd の PR #7685（2026-10-12 マージ）で、互換性フラグ wasm_esm_integration_builtins が入った。** import した Wasm を new WebAssembly.Module(src, { builtins: ['js-string'], importedStringConstants: 'wasm:js/string-constants' }) と同じ設定でコンパイルする。提案がまだ実装段階なので、有効になる日付はなく、明示的に付ける必要がある（compatibility-date.capnp には $experimental の印はなかった）。調査メモの「Workers ではコンパイルのオプションが効かない」は、このフラグで変わる可能性がある。
• 文字列定数の名前空間は wasm:js/string-constants に決め打ちなので、MoonBit 側で "imported-string-constants": "wasm:js/string-constants" を指定した。
• Node で同じオプションを付けてコンパイルすると、35 パスの出力が案 A と一致した。
• 遅い理由: builtin string にすると、MoonBit の文字列の操作が JS の関数の呼び出しになるので、render そのものが約 345 µs から約 409 µs に遅くなる。さらに、StringBuilder の to_string と本文の連結で文字列を作り直す。
• 利点: アダプターがいちばん単純になり（inline wasm も線形メモリもいらない）、Wasm もいちばん小さい。

試していない案 #

• **H（パスのデコードを Wasm で）**: その後、取り込んだ（「取り込み（案 H）」の節）。
• **I（応答のキャッシュ）**: その後、取り込んだ（「取り込み（案 I）」の節）。Cache API（caches.default）を使う形は試していない。
• **J（js バックエンド）**: Workers 用の MoonBit ライブラリとして mizchi/cloudflare（mooncakes.io の mizchi/cloudflare 0.1.13、KV、D1、R2 などのバインディング）が見つかった。前の調査では見つからなかったもの。ただし moon.mod は preferred_target = "js"、各パッケージは supported_targets = "js" で、mizchi/js_* に依存する **JS にコンパイルするためのライブラリ**であり、Wasm では使えない。このブログは Wasm で動かすこと自体が目的（ロマン）なので、対象外とする。Wasm 向けで Workers に使える MoonBit のライブラリは、今回も見つからなかった（mooncakes.io の一覧 3,029 件を cloudflare、workers、workerd で検索した）。

Node での処理時間 #

worker-<案>.mjs の fetch に Request を渡し、Response の本文を読み終えるまで。各案を 1,000 回 × 5 回測った中央値を、2 回実行した範囲で書く。どの案も、35 パス（/、/docs/ からたどれる記事と文書とその .md 版、/favicon.svg、/site.css、存在しないパスなど）で、ステータス、ヘッダー、本文が案 A と一致することを先に確かめた。

• 受け渡しにかかる時間（全体 −render − Node の Response の約 20 µs）は、A が約 390 µs、B が約 280 µs、C が約 100〜140 µs、D' が約 30〜70 µs。
• B のように 1 回の呼び出しで運ぶ量を増やしても、呼び出しの回数が 1/8 になるほどには速くならない。JS の配列に積んで String.fromCharCode する部分が残る。

サイズ #

• アダプターの違いによるサイズの差は 1 KB 前後で、ほとんどが埋め込んだ文章。サイズを決めるのは -Oz と、文章を Wasm の外に出す TODO のほう。
• moon-wasm-opt に渡す機能の指定は、前の調査と同じく -all だと V8 で読めない（invalid heap type 'exact'）。--enable-gc --enable-reference-types --enable-bulk-memory --enable-sign-ext --enable-nontrapping-float-to-int --enable-mutable-globals --enable-multivalue で通る。E には --enable-strings も足した。
• zsh では、この機能の一覧を変数に入れて $OPT $FEAT と渡すと、単語に分割されずに 1 つの引数になる（Unknown option）。bash -c で実行した。

Go 版との比較 #

C、D、A のそれぞれを wrangler dev で動かし、ローカルの Go 版（-base-url https://blog.podhmo.workers.dev）と make compare で比べた。既定の 6 パスと、上の 35 パスに //posts/../、/docs?x=1、/site.css?v=... などを足した 41 パスが、3 つとも一致した。D' と E はこのときは wrangler dev で比べておらず、Node での案 A との一致だけを確かめた（D' は D と JS が同じで、Wasm の UTF-8 の書き方だけが違う）。案 E は 2026-10-22 に wrangler dev と本番で比べた（「追試」の節）。

確かめたこと #

• make check が通る（62 テスト）。
• make dev と、ローカルの Go 版（-base-url https://blog.podhmo.workers.dev）を make compare で比べた。既定の 6 パス、/ と /docs/ からたどれる記事と文書（このメモを含む）とその .md 版、/favicon.svg、/site.css（?v= 付きと無し）、/docs、/docs?x=1、//posts/../、/_livereload.js、存在しないパスの 42 パス、日本語を含むパスとリダイレクト 4 つが、すべて一致した。
• POST の /posts/hello と /docs は、Go 版と同じく 404 で、本文も一致した。
• make deploy で blog にデプロイし、公開中の https://blog.podhmo.workers.dev と Go 版を 43 パスで比べて、すべて一致した。POST は 404 になった。

比べた数字 #

比べる相手は、同じ文書（このメモを含む）を埋め込み、worker と worker.mjs だけを main のものに戻したビルド。Site::render は両方とも verb~ を足したもの。

• Node の数字は、1,000 回 × 5 回の中央値を 2 回実行した範囲。最初は別の作業でマシンの負荷が高く（load average 41）、同じ測り方で main が 1.3〜1.7 ms、取り込んだ版が 0.6〜1.0 ms と大きくぶれた。負荷が下がってから測り直した値を載せた。負荷の高いときの数字は使わない。
• 起動時間は ms 単位でしか出ないので、差は見えない。
• Wasm は、UTF-8 の読み書きのぶん 1.3 KB 大きくなった。

Go 版との比較 #

44 パスに、変なエスケープを含む 14 パス（/%FF、/posts/%FF、/docs/%FF、/posts/%FF.md、/%FF/、/%FF//、/a%00b、/%C3%28、/%ED%A0%80、/%E0%A4%A、/%zz、/docs%2F、/a%2Fb、/posts/hello%3F）を足した 58 パスで比べた。

• **/%FF// は残る。** Go 版は /%FF/ にリダイレクトするが、Wasm は U+FFFD に置き換えた後のパスを書くので /%EF%BF%BD/ になる。MoonBit の String は不正な UTF-8 を持てないので、合わせるには、置き換えずに元のバイトを覚えておく仕組み（例えば Python の surrogateescape のように、バイト b を孤立したサロゲート U+DC00+b にして、リダイレクトの escape で %XX に戻す）が要る。UTF-8 でないパスが、さらに正規化されていない場合だけの違いなので、入れていない。
• **本番では、/a%00b と /%zz は Worker に届かない。** Cloudflare の前段が、HTML の 400 Bad Request ページ（server: cloudflare、content-type: text/html）を返す。wrangler dev では Worker に届き、Go 版と一致する。/%E0%A4%A と /% は本番でも Worker に届き、Go 版と同じ本文を返す。どのエスケープを前段が止めるのかの規則は調べていない。
• デプロイした版の Total Upload は 273.08 KiB（gzip 後 86.86 KiB）、Worker Startup Time は 2 ms。

数字 #

• キャッシュに当たったときの 33 µs は、ほぼ Node が 53,784 B の本文の Response を作って読む時間。最初のリクエストは今までと同じ時間がかかる。
• 本番で、どれくらいの割合のリクエストが同じ isolate に当たるかは分からない（isolate はデータセンターごとにあり、いつ捨てられるかも決まっていない）。本番での CPU 時間の変化も測っていない。
• make dev とローカルの Go 版を、44 パス + 変なエスケープの 14 パス + /posts/hell%6F と /site.css?v=other の 60 パスで、続けて 3 回比べた。2 回目と 3 回目はキャッシュから返る。どの回も、一致しないのは案 H の節の /%FF// だけだった。デプロイした blog でも同じく 3 回比べ、一致しないのは案 H の節の 3 パスだけだった。
• デプロイした版の Total Upload は 276.63 KiB（gzip 後 88.03 KiB。文書がこのメモの分だけ増えた）、Worker Startup Time は 2 ms。

wrangler dev #

moonbit/experiments/adapter-abi の make build で spike を作り、workers/wrangler-jsstr.jsonc と worker-jsstr.mjs を wrangler dev で動かした。-Oz の jsstr-Oz.wasm も、main だけ worker-jsstroz.mjs にした設定を一時的に作って試した。フラグは通り、Ready on http://localhost:8787 になった。

Go 版（-debug、-base-url https://blog.podhmo.workers.dev）と 84 パスを make compare で比べた。

• 通常の 70 パス（/、/docs/、記事と文書とその .md、/favicon.svg、/site.css、リダイレクト、存在しないパス）は、-Oz の有無にかかわらず、すべて status・Content-Type・本文が一致した。
• 変なエスケープの 14 パスのうち、10 パスが一致しなかった（/%FF、/posts/%FF、/docs/%FF、/posts/%FF.md、/%FF/、/%FF//、/%C3%28、/%ED%A0%80、/%E0%A4%A、/%zz）。これはフラグのせいではなく、案 E の worker.mjs が decodeURIComponent でパスを JS 側でデコードするため。Go 版は UTF-8 でないバイトを U+FFFD にして 404 を返すが、decodeURIComponent は例外を投げるので 400 になる。/%zz と /%E0%A4%A はどちらも 400 だが、Content-Type（text/plain;charset=UTF-8 と text/plain; charset=utf-8）と本文が違う。
• 残りの 4 パス（/a%00b、/docs%2F、/a%2Fb、/posts/hello%3F）は一致した。
• エスケープしたパスをそのまま serve に渡す（デコードしない）版も試したが、/%FF//、/%E0%A4%A、/%zz、/docs%2F の 4 パスが違った。案 H と同じデコードを再現するには、案 E の serve にパスのデコードを足すか、Worker 側に Go と同じデコーダーが要る。
• POST /posts/hello と POST /docs は 404 で本文まで一致した。HEAD / は 200 と Content-Type が一致した（wrangler dev は HEAD に Content-Length を返さないが、make compare は見ていない）。

本番 #

wrangler deploy でもフラグは通り、確認用の Worker を 2 つデプロイできた。

• spike-jsstr（-Oz なし）: https://spike-jsstr.podhmo.workers.dev （確認後に削除）、Total Upload 462.18 KiB（gzip 160.81 KiB）、Worker Startup Time 4 ms。
• spike-jsstroz（-Oz）: https://spike-jsstroz.podhmo.workers.dev （確認後に削除）、441.17 KiB（gzip 153.01 KiB）、4 ms。
• デプロイした spike-jsstr とローカルの Go 版を 84 パスで比べると、11 パスが違った。上の 10 パスに /a%00b が加わる。/a%00b と /%zz は Cloudflare の前段が HTML の 400 を返す（案 H の節と同じ）。通常の 70 パスはすべて一致した。
• 確認用の 2 つは確認後に wrangler delete で削除した。

サイズと速さ #

-Oz は、案 E の jsstr.wasm に --enable-strings を足してかけた。文書がこのメモの分だけ増えたので、前の節の絶対値とは比べられない。

• 案 D' は今回デプロイしていない。Total Upload は wrangler deploy --dry-run、起動時間は前回の値。
• 案 E + -Oz は案 D' より Wasm が 78,050 B（14.8%）小さく、gzip 後も 3,280 B 小さい。Total Upload も gzip 後で 4.08 KiB 小さい。
• ただし、-Oz なしの案 E は gzip 後で案 D' より大きい（162,910 B 対 158,090 B）。案 E のサイズは -Oz とセットで見る。

Node の bench.mjs で 2,000 回 × 5 回を 2 回測った、中央値の範囲:

• / は案 E のほうが速い。いちばん大きいページは案 E が案 D' より約 13% 遅く、-Oz でも約 7% 遅い。前の節の「約 540 µs」は文書が 53,784 B のときの値で、今は 67,918 B なので絶対値は比べられない。速い順は案 D'、案 E + -Oz、案 E。
• これは Node で new WebAssembly.Module(..., { builtins: ["js-string"] }) を使った値。本番の CPU 時間は測っていない。

まとめ #

• フラグは wrangler dev でも本番でも使える（2026-10-22 時点）。案 E の Wasm は -Oz でいちばん小さく、起動時間も 4 ms で、通常のページは Go 版と一致する。
• それでも今の案 D' を置き換える理由にはならない。いちばん大きいページは案 D' より遅く、案 H のパスのデコードを再現できない。案 E を使うなら、パスのデコードを Wasm に移す設計が要る。
• フラグ自体は、将来ほかの ABI を試すときに使える。

案 D' #

worker_utf8d/moon.pkg:

import {
  "podhmo/blog/site",
  "moonbitlang/core/encoding/utf8",
}

supported_targets = "+wasm-gc"

options(
  link: {
    "wasm-gc": {
      "exports": [ "serve" ],
      "export-memory-name": "memory",
    },
  },
)

MoonBit（load、answer は、BASE_URL が変わったら Site を作り直すことと、render の結果を status\nname\tvalue\n...\n\n と本文に分けることだけをする）:

///|
extern "wasm" fn load8(addr : Int) -> Int =
  #|(func (param i32) (result i32) (i32.load8_u (local.get 0)))

///|
extern "wasm" fn store8(addr : Int, v : Int) =
  #|(func (param i32) (param i32) (i32.store8 (local.get 0) (local.get 1)))

///|
extern "wasm" fn memory_size() -> Int =
  #|(func (result i32) (memory.size))

///|
extern "wasm" fn memory_grow(pages : Int) -> Int =
  #|(func (param i32) (result i32) (memory.grow (local.get 0)))

///|
/// reserve grows the memory to hold at least n bytes.
fn reserve(n : Int) -> Unit {
  let more = (n + 65535) / 65536 - memory_size()
  if more > 0 {
    ignore(memory_grow(more))
  }
}

///|
/// write8 encodes s in UTF-8 at address at, and returns the end.
fn write8(at : Int, s : String) -> Int {
  reserve(at + s.length() * 3)
  let mut p = at
  let n = s.length()
  let mut i = 0
  while i < n {
    let mut c = s.code_unit_at(i).to_int()
    i += 1
    if c >= 0xD800 && c < 0xDC00 && i < n {
      let d = s.code_unit_at(i).to_int()
      if d >= 0xDC00 && d < 0xE000 {
        c = 0x10000 + ((c - 0xD800) << 10) + (d - 0xDC00)
        i += 1
      }
    }
    if c < 0x80 {
      store8(p, c)
      p += 1
    } else if c < 0x800 {
      store8(p, 0xC0 | (c >> 6))
      store8(p + 1, 0x80 | (c & 0x3F))
      p += 2
    } else if c < 0x10000 {
      store8(p, 0xE0 | (c >> 12))
      store8(p + 1, 0x80 | ((c >> 6) & 0x3F))
      store8(p + 2, 0x80 | (c & 0x3F))
      p += 3
    } else {
      store8(p, 0xF0 | (c >> 18))
      store8(p + 1, 0x80 | ((c >> 12) & 0x3F))
      store8(p + 2, 0x80 | ((c >> 6) & 0x3F))
      store8(p + 3, 0x80 | (c & 0x3F))
      p += 4
    }
  }
  p
}

///|
/// serve reads the request, n UTF-8 bytes at address 0, and writes the
/// response there in UTF-8, returning its length in bytes.
pub fn serve(n : Int) -> Int {
  let req = @utf8.decode(Bytes::makei(n, i => load8(i).to_byte())) catch {
    _ => ""
  }
  let (head, body) = answer(req)
  write8(write8(0, head), body)
}

worker.mjs:

import wasm from "./build/app.wasm";

const { memory, serve } = new WebAssembly.Instance(wasm).exports;
const encoder = new TextEncoder();
const decoder = new TextDecoder();

export default {
  async fetch(request, env) {
    const url = new URL(request.url);
    let path;
    try {
      path = decodeURIComponent(url.pathname);
    } catch {
      return new Response("Bad request: malformed path\n", { status: 400 });
    }
    const req = `${env.BASE_URL ?? ""}\n${request.method}\n${url.search.slice(1)}\n${path}`;
    const more = Math.ceil((req.length * 3) / 65536) - memory.buffer.byteLength / 65536;
    if (more > 0) memory.grow(more);
    const { written } = encoder.encodeInto(req, new Uint8Array(memory.buffer));
    // serve may grow the memory, which detaches the old memory.buffer.
    const n = serve(written);
    const out = new Uint8Array(memory.buffer, 0, n);
    let end = out.indexOf(10);
    while (out[end + 1] !== 10) end = out.indexOf(10, end + 1);
    const [status, ...headers] = decoder.decode(out.subarray(0, end)).split("\n");
    return new Response(out.slice(end + 2), { status: +status, headers: headers.map((h) => h.split("\t")) });
  },
};

案 E #

moon.pkg の link 設定:

options(
  link: {
    "wasm-gc": {
      "exports": [ "serve" ],
      "use-js-builtin-string": true,
      "imported-string-constants": "wasm:js/string-constants",
    },
  },
)

MoonBit の入り口は pub fn serve(base : String, verb : String, path : String, query : String) -> String で、status\nname\tvalue\n...\n\n と本文をつないだ文字列を返す。wrangler.jsonc に "compatibility_flags": ["wasm_esm_integration_builtins"] を足し、worker.mjs は次のとおり。

import wasm from "./build/app.wasm";

const { serve } = new WebAssembly.Instance(wasm).exports;

export default {
  async fetch(request, env) {
    const url = new URL(request.url);
    let path;
    try {
      path = decodeURIComponent(url.pathname);
    } catch {
      return new Response("Bad request: malformed path\n", { status: 400 });
    }
    const out = serve(env.BASE_URL ?? "", request.method, path, url.search.slice(1));
    const end = out.indexOf("\n\n");
    const [status, ...headers] = out.slice(0, end).split("\n");
    return new Response(out.slice(end + 2), { status: +status, headers: headers.map((h) => h.split("\t")) });
  },
};