A shared view written to stdout or stderr went out in 64 KiB pieces through
scr_stdio_write, so a replaced process.stdout.write received the first
piece alone, and a false return, which only reports backpressure, ended the
loop: a view larger than 64 KiB lost the rest. With a write hook, the view
is now copied whole and passed in one call, as Node passes it; the bounded
pieces go to the stream itself through scr_stdio_write_raw, which never
stops early.
tests/corpus/shared-bytes-stdio-write.ts replaces process.stdout.write with
a function that records each chunk's length and returns false, and writes a
150,000-byte shared view through it.
Three runtime changes that lower peak memory without changing behavior:
- In programs with workers, process.stdout.write and process.stderr.write
of a view into a SharedArrayBuffer read it through a 64 KiB buffer
instead of copying the whole view first, so writing a 32 MB shared view
no longer holds a second 32 MB. Programs without workers keep the direct
write.
- The one-slot string spare keeps freed blocks of 512 bytes to 1 MiB only.
A larger block stayed resident until a string of about its size came
along, which a program that replaces its input with an edited copy never
does.
- The main thread trims its arena when its event loop waits with nothing
ready, once it has carved 16 MB more since its last trim, as a parking
thread does: pages that hold only free blocks go back to the system while
the program waits on its workers.
Chris Tate