Building a Copying GC for the Plush Programming Language

Indie dev’s Plush gets an auto-cleaner; comments explode over memory and manners

TLDR: Plush’s creator is building a simple “auto-cleaner” that copies message data between its worker threads. Commenters split: one camp demands a smarter, generational approach to avoid re-copying old data; another cheers the simplicity. Bonus drama: a grammar cop insists acronyms be spelled out first.

The creator of Plush, a playful, JavaScript-like language built for graphics and sound, just unveiled plans for a copying garbage collector — think an automatic cleaner that duplicates stuff when messages move between little worker “actors.” Plush uses two memory stashes per worker: a fast private one and a “mailbox” for incoming packages. The dev wants simple: send a message, the system copies the whole bundle for you, no freezing objects or global cleanup pauses. Straightforward… until the comments rolled in.

The loudest take came from user trashburger, who slammed the design for having no generations — translation: old stuff sticks around, so why keep re-copying grandpa every time he visits? They also grilled how the two memory piles play together, asking if Plush’s heap is “regional” or one big soup. Meanwhile, Bad_Initialism went full grammar police: spell out your acronyms first (“garbage collector (GC)”) or face the wrath of the bad initialism GC.

So yes, Plush’s copying cleaner sparked a split: performance purists want generational smarts, simplicity fans love the “just send it, it gets copied” vibe, and the thread devolved into jokes about mailbox spam and a GC about the GC. More Plush, inspired by Lox and JavaScript, less chill

Key Points

  • Plush is a dynamically-typed language inspired by Lox and JavaScript, aimed at experimentation with sound and graphics.
  • The Plush VM uses actor-based parallelism and avoids a global VM lock; actors synchronize only on message passing.
  • To reduce complexity and avoid global GC coordination, Plush copies entire object subgraphs when sending messages between actors.
  • Each actor has two allocators: a lock-free private allocator and a mailbox allocator for incoming messages.
  • The runtime adopts a bump allocator with a copying garbage collector to keep allocations fast, despite the implementation challenges of building a GC.

Hottest takes

“No generations means copying long-lived objects needlessly” — trashburger
“Is the heap non-regional, or separate regions?” — trashburger
“Spell out initialisms... Sincerely, your bad initialism GC” — Bad_Initialism
Made with <3 by @siedrix and @shesho from CDMX. Powered by Forge&Hive.