I know a thing or two about VMs. Reading this post, I thought to myself "No way it was this easy. No performance hit in the single threaded case? No way".

I was right. Buried in the middle of the post is this tidbit:

> v1 collects synchronous and stop-the-world

Ah, there it is! I knew it!

Parallel garbage collection is a very hard problem. Years of experience and subtle implementation are required to get something like ZGC. A stop-the-world garbage collector will kill tail latency in many use-cases, especially for large programs. I'd say a good GC is the hardest part of a modern VM, even harder than a good JIT: not that a JIT is easy.

Show me multi-threaded JS with generational mark, sweep, compaction, etc. running in parallel with the mutator and I'll be impressed. (The smart thing would be to base it on the JVM or CLR. Doesn't count though.)

It's all so exhausting, this current programmer culture of doing the easy part of a system thing X and presenting your work, without qualifiers, as a complete and modern X.

Sure, sure, we can have memory safe C (just don't have any data races!). Sure, we can have an AI C compiler (just don't expect type checking). Sure, we can port SQLite to Rust (but don't expect it to be fast). Sure, you can one shot a Slack clone (just don't expect performance or security). Doing the easy part of a thing is not doing the thing! You can't trust a README's feature list these days.

To be fair, given that the README is obviously unedited LLM output, the authors might not have realized that their agents cheated and made threading easy by pessimizing the GC. The LLM certainly did though.

Now, maybe the JSC really is adaptable to a multi-threaded mutator world. If it is, great. But over and over, I've seen AI say "I will defer and charter $HARD_THING" and mean "I have no idea how to do $HARD_THING, so I'm creatively reinterpreting your request to make it easy". You have to be endlessly vigilant for LLMs subtly twisting your tasks into easy versions that might technically meet the requirements but they are less complete than you intend.

▲

hedgehog an hour ago | parent | next [-]

I sometimes wonder if full GC is really worth it. For a lot of applications some compile time analysis + refcounting is close enough, and for some others arenas (per frame rendered, per request served, etc) are as fast as a GC to allocate and faster than malloc to free. Could we make the rest a compile error and save most people most of the time a lot of pain?

	▲	quotemstr 24 minutes ago \| parent [-]
		GC is worth it. What you're proposing is a false economy. In addition to lifetime management, GC gives you compaction, pointer compression, and fast bump-pointer allocation that doesn't depend on being able to represent your lifetimes as nested arenas. Modern GC is excellent. Replacing it with manual allocation isn't better, even with guardrails: reference counting is expensive, atomic reference counting doubly so, and free() itself is very far from free. Sure, you can restrict lifetime shapes, but when you do that, people switch to allocating out of arrays and using indices as pointers, so you're right back where you started with respect to lifetime management. So what are you saving? You're just replacing the high-performance concurrent mark/sweep microsecond-pause GC someone has written and debugged for you for free with custom convoluted logic that'll probably leak and run slower besides. Why would anyone want this trade? The elevation of manual memory management to standard performance practice is a generational mistake this industry is making.

▲

12_throw_away 3 hours ago | parent | prev [-]

In contrast, I don't know that much about VMs.

But if you're making a big fundamental change to a system, I do know that it shouldn't start with a single "+279,276 -4,272" PR. It starts with a small patch with the core of the change so that everyone can understand what it does and how it works. (I mean, ideally, a change like this starts with documentation, discussion, diagrams, surveys of existing implementations, etc, before you start writing code)

You don't cram everything into a single 270K line PR, even (especially) with an LLM, unless you specifically don't want anyone else to look too closely at what you did.