Hacker News Reader

Comment by a_imho | Hacker News Reader

Combining these two functions, it is possible to take control of the GC to make sure it runs only when it is acceptable to do so.

I'm conflicted on this. My gut tells me if I'm going to manually take control over the garbage collector I should reconsider my design decisions.

Disclaimer, I don't know the first thing about PyPy or Gambit Research, so probably this is the right approach for them?

View on HN

It's explained in the article that this is to solve one specific issue that Gambit Research had: in some parts of their code they need to take action with very low latencies (<10ms) and hence they can't wait for the GC. This way they manually execute the GC in other sections of the code were timing requirements are relaxed.

It's a fairly common thing to do for e.g. games as well. Disable the GC during all your code, and then run it manually at the end of your frame. All you're doing is moving the gc runs to predictable points. You could even skip a collection if you've got a slow to render frame or two, evening out the spikes in framerate.

The advantages of a typical GC are that it avoids the development costs of manual memory management, and it allows high throughput. The main disadvantage is usually latency spikes. Using this feature decreases maximum latency spikes by orders of magnitude, with only a small cost in cognitive burden and throughput. If without this feature GC might have been a good tradeoff if not for latency, there is only a sliver of design space in which using this feature would push the throughput out of acceptable bounds. (And cognitive burden is still way lower than any other form of memory management.)

Reply on news.ycombinator.com