[benjaminshawki]

Stacked on #45 (core/module-writer, which has #47's change in it): the kernel lets go of memory inside an application that goes on, not only when one ends. With it, Ray writes the kernel's module in one run: kernel.ray reads kernel.ts, wasm.ray writes it, no parts.

Before, what an application made was let go of when it returned. The one run build is one application that never returns until the end, so it grew about 20 MB a minute and ran out of memory at about 72 minutes.

What changes (kernel.ts, language.ts):

• Between a block's lines, once what it made since is more than 32 MB (SAFE_MIN) and more than it kept last time, what it made is moved together (evacuate), the rest let go of. What it made before that point is held where it is and read as roots.
• A level remembers the run of chunks it began in (T_RUN), not the end of its chunk: a chunk taken right after the last one is the same run (what was left of the last one is written as a filler), so moving still walks one run in order.
• What is kept for all (a rule's reads, tables made larger, T_BODIES, the host's file texts and names) comes from memory set apart for it (global 512, 64 MB more each time it is used up), so a thread's chunks stay one after another. START moves to 528.
• The log of writes into older memory, when full, has the outermost levels give theirs up, so those within go on.
• T_LEXV, T_REFF, T_WRITTEN_IN are kept only where what they name is kept, and a frame does not keep what called it alive.
• An application done: a take of its frame that read a value (not a place) no longer keeps where it was written and what read it (T_APPLIED).
• x = v in a rule: the frame it closes over is a copy with that value alone in it.
• A rule defined again in a node made before the file being read is defined again in place, so a name given a new value again and again does not grow a chain of rules.
• The newest memo table at its most gives up a slot it looked at instead of growing.
• A thread alone in its memory gets room to move 2M objects (shared threads keep 256K, as they never move).

Checks:

• Library tests (-t over the bootstrap): the same results as feature: wasm.ray, Ray writes the kernel's JMP as a wasm module #45, line for line (480 errors, 1076 passed on both; addresses in "made, at" differ, as memory set apart moves them).
• One run build: env RAY_BUDGET=100000000 RAY_NOTESTS=1 RAY_NOCACHE=1 RAY_STATEMENT_MB=1900 node --import tsx src/language.ts --threads 1 --write=kernel.wasm '--value=wasm.module(32768)' ../ray/bootstrap/.entrypoint.ray3 <file including src/wasm.ray, src/kernel.ray and kernel.ts in Kernel_js> finishes (about 100 minutes, 1.2 GB at most), and node --import tsx scripts/kernel-wasm.mts --check kernel.wasm --pages 32768 answers the same: 379351 bytes.