[Benjamin_Dobell]

I've recently become the maintainer of https://github.com/godotjs/GodotJS (TypeScript bindings + JS runtime for Godot). GodotJS supports numerous runtimes, but V8 is the most well supported. Unfortunately, I have been noticing V8's GC a bit more than I would like recently.

Don't get me wrong, I'm aware V8 wasn't designed with games in mind. QuickJS (which is also supported by GodotJS) is probably the safer bet. Or you know, not JavaScript at all. However, I'm building tooling specifically for kids to make games, and TypeScript is leagues ahead in terms of usability:

https://breaka.club/blog/why-were-building-clubs-for-kids

Before I make the swap to QuickJS out of necessity, I was hoping to try my hand at tuning V8's GC for my use case. I wasn't expecting this to be easy, but the article doesn't exactly instill me with confidence:

> Simply tuning the system appears to involve a dose of science, a dose of flailing around and trying things, and a whole cauldron of witchcraft. There appears to be one person whose full-time job it is to implement and monitor metrics on V8 memory performance and implement appropriate tweaks. Good grief!

If anyone reading this has experience with tuning V8's GC to minimize stop-the-world GC duration (at the cost of overall memory use, or runtime performance etc.) I'd greatly appreciate any advice that can be offered.

[pantsforbirds]

Have you explored using Apple's javascript core engine at all? I know bun was built on it, but I don't know much else about it.

[Benjamin_Dobell]

Not really. I've written a bunch of code to try maintain the limited support for it that already exists in GodotJS, but I've never really tried it. Main reason I haven't is I'm dependent on Web Worker(-like) APIs in GodotJS, and they're currently missing for JavaScript Core. But since I actually wrote some of those APIs, that's not really an excuse, I can port them easily enough.

So, yeah, I should really give it a shot. Thanks for the reminder.