FRESH

Hacker News

V8 Garbage Collector

113 points by swah

by ZeroConcerns

2 subcomments

Interesting article! One thing that made me literally LOL was the fact that several exploits were enabled via a Google "style recommendation" that caused on-heap length fields to be signed and thus subject to sign-extension attacks.
The conversation-leading-up-to-that played out a bit like this in my head:
Google Engineer #1: Hey, shouldn't that length field be unsigned? Not like a negative value ever makes sense there?
GE#2: Style guide says no
GE#1: Yeah, but that could easily be exploited, right?
GE#2: Maybe, but at least I won't get dinged on code review: my metrics are already really lagging this quarter
GE#1: Good point! In fact, I'll pre-prepare an emergency patch for that whole thing, as my team lead indicated I've been a bit slow on the turnaround lately...

by Benjamin_Dobell

1 subcomments

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.

by whizzter

1 subcomments

I don't envy these engineers having to trace through corruptions and other issues related to moving GC's, just keeping a simple regular toy GC from blowing up can be hard enough sometimes (Maybe they have some better tools, but memory corruptions are inherently prickly to debug).

by NeutralForest

0 subcomment

It's an interesting article because tech articles rarely revisit the past for what kind of decisions were made and why. Thanks! Also always cool to see a Wingo article because I get exposed to a field I know very little about (how garbage collection works).

by wffurr

0 subcomment

The fact that they are working so hard to retrofit a GC into the V8 C++ code IMO calls into question their premise for not using Rust, namely that the majority of V8 security flaws are in the JIT generated code, not V8 itself. That always seemed to be a flimsy excuse to keep using an insecure language for what is supposed to be a very secure language runtime for untrusted code, but now it’s laughable on its face.

by maartin0

4 subcomments

What does FTE stand for?:
> From what I can tell, there have been about 4 FTE from Google over this period