Hacker News Reader

Comment by p_l | Hacker News Reader

We wrote latency-sensitive and high-performance code in GCed languages back in 1980s - avoiding pauses or having predictable latencies (in fact, more predictable than usual manual memory management!) are more of "we don't teach people how to program" rather than issue with GC.

As for energy savings, many garbage collectors have amortized energy use lower than malloc/free. Even pretty simple ones (some of the simplest I've seen beat it so hard it's not competition, but they are specific to their application)

View on HN

”As for energy savings, many garbage collectors have amortized energy use lower than malloc/free”

For those wondering: that’s because malloc/free ‘visits’ every dead object, while garbage collection visits the live ones (another way to say that: free collects garbage, the moment it is created, GC collects non-garbage, periodically) and there typically is way more garbage than non-garbage.

I haven’t seen energy usage comparisons that include extra energy use due to GC’s higher memory usage, though. That possibly is because it is hard to quantify. On current technology, you pay for your RAM’s energy usage the moment you power it on, whether you need it or not)

Could you explain further or give links to more information? I'd love to read about old-timey techniques for programming in GCed languages.

His point is it's not rocket science. Preallocate and pool what you might need, don't call new in your tight loop. Change the GC algorithm to something that never runs unexpectedly. If you're still allocating such that you need GC eventually, manually GC at an appropriate time like a load screen.

> Preallocate and pool what you might need, don't call new in your tight loop.

This piece of advice is also valid in languages without GC. In C++ it's well known one should avoid allocating memory in tight loops, and it's strongly advised to call e.g. `reserve` on vectors to avoid allocating.

The point is that you lose not only in tight loops. (Tight loop allocating with good GC is actually well known good [1] case, it's deallocation that is PITA).

free() as well as malloc() and related have significantly complex algorithms behind them, unless one can simplify base memory management in certain ways - and those ways tend to also allow region-enabled GC to outperform them anyway.

[1] Allocating memory in many Garbage Collected systems can be down to one instruction, and if using per-thread heap, it can be atomic add without CAS

A good "keyword" to search is "non-consing code", from lisp lore meaning it doesn't construct (allocate) new space.

As sibling comment says, it often involved object caches and static allocations.

Interestingly enough, similar rules are necessary with malloc()/free where dynamic allocation is often forbidden for latency critical code (or safety critical one)

Also - I really, really recommend reading the classic GC book ( http://gchandbook.org/) and related sources.

I stopped complaining too much about developers when I noticed pretty much Noone gets taught how memory management works - either manual or GC

Reply on news.ycombinator.com