Hacker News Reader

Comment by gdwatson | Hacker News Reader

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

View on HN

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