5 ms·

I'm not so sure there are applications which simply cannot tolerate garbage collection. Unless, you have no reasonable way of preventing allocations. Console g

I'm not so sure there are applications which simply cannot tolerate garbage collection. Unless, you have no reasonable way of preventing allocations. Console games, for instance, are often largely garbage collected, despite being hugely performance critical applications. The way this is generally achieved is by allocating 100% of the console's memory upfront as object pools. The game then utilizes domain specific collection mechanisms on those pools. Shawn Hargreaves has a good article on dealing with C#'s garbage collection in XNA games: http://blogs.msdn.com/b/shawnhar/archive/2007/07/02/twin-paths-to-garbage-collector-nirvana.aspx http://blogs.msdn.com/b/shawnhar/archive/2007/07/02/twin-pat... The problem in .NET land is that some base class library methods allocate internally, so you need to completely avoid them if you use "Path 1" (avoid collections). You wind up having to do funky things like re-implementing core methods and pre-allocating pools of strings to avoid concatenation. Presumably, a language designed to be a systems language could avoid these library problems. I don't know much about Go, but if allocations are clearly demarcated and easily avoidable when necessary, you could allocate 100% of memory up front. You could treat virtual memory as an object pool of memory pages and perform domain specific allocation on those. Alternatively, a collector with a richer interface, such as generation control, multiple heaps, etc. Would allow for "Path 2" (avoid latency) by performing very small, simple collections.

JonnieCache 15y ago
>I'm not so sure there are applications which simply cannot tolerate garbage collection. Things that need to be really seriously realtime, such as aeroplane pilot assistance AI, and medical equipment firmware, I think these cannot use stuff like GC because there is no room for the slightest deviation in performance.
- lysium 15y ago
  As snprbob86 already mentioned, you pre-allocate all the memory you will need, so GC never runs.
- masklinn 15y ago
  > Things that need to be really seriously realtime Real-time garbage collection (hard and soft) is not a work of fiction. Hell, the first papers on real-time GCs were in the 70s. > I think these cannot use stuff like GC because there is no room for the slightest deviation in performance. IBM's Metronome (Bacon & al) is a hard real-time GC.
- anamax 15y ago
  > Things that need to be really seriously realtime, such as aeroplane pilot assistance AI, and medical equipment firmware, I think these cannot use stuff like GC because there is no room for the slightest deviation in performance. Nope - real time systems have room for deviation. They "just" have different bounds. Specifically, hard real time "merely" requires guarantees that operations complete before their deadline. For example, real-time systems can have caches even though they introduce varibility in execution time. Of course, the closer one is to the edge, the less room for error or mis-allocation, aka "time fragmentation".
bxr 15y ago
I've never done this kind of programming around GC, is manual memory management in a garbage collected language any better than manual memory management in a language without GC? >I'm not so sure there are applications which simply cannot tolerate garbage collection. From your post, it sounds like "tolerating garbage collection" is the same as making sure it never ever happens. The application clearly doesn't tolerate GC, the programmer tolerates the language enough to bend over backwards to avoid one of its central features.
s_tec 15y ago
There are microcontrollers with only 128 bytes of ram and 1KB of flash. They don't have enough memory to support malloc, so there is nothing to garbage collect in the first place. There isn't enough flash to even store the garbage collector's code, even if it sits unused.
kjetil 15y ago
For what its worth, Tim Sweeney appears to endorse GC for game programming in his POPL talk: http://lambda-the-ultimate.org/node/1277 http://lambda-the-ultimate.org/node/1277

JonnieCache 15y ago

>I'm not so sure there are applications which simply cannot tolerate garbage collection. Things that need to be really seriously realtime, such as aeroplane pilot assistance AI, and medical equipment firmware, I think these cannot use stuff like GC because there is no room for the slightest deviation in performance.

lysium 15y ago
As snprbob86 already mentioned, you pre-allocate all the memory you will need, so GC never runs.
masklinn 15y ago
> Things that need to be really seriously realtime Real-time garbage collection (hard and soft) is not a work of fiction. Hell, the first papers on real-time GCs were in the 70s. > I think these cannot use stuff like GC because there is no room for the slightest deviation in performance. IBM's Metronome (Bacon & al) is a hard real-time GC.
anamax 15y ago
> Things that need to be really seriously realtime, such as aeroplane pilot assistance AI, and medical equipment firmware, I think these cannot use stuff like GC because there is no room for the slightest deviation in performance. Nope - real time systems have room for deviation. They "just" have different bounds. Specifically, hard real time "merely" requires guarantees that operations complete before their deadline. For example, real-time systems can have caches even though they introduce varibility in execution time. Of course, the closer one is to the edge, the less room for error or mis-allocation, aka "time fragmentation".

bxr 15y ago

I've never done this kind of programming around GC, is manual memory management in a garbage collected language any better than manual memory management in a language without GC? >I'm not so sure there are applications which simply cannot tolerate garbage collection. From your post, it sounds like "tolerating garbage collection" is the same as making sure it never ever happens. The application clearly doesn't tolerate GC, the programmer tolerates the language enough to bend over backwards to avoid one of its central features.

s_tec 15y ago

There are microcontrollers with only 128 bytes of ram and 1KB of flash. They don't have enough memory to support malloc, so there is nothing to garbage collect in the first place. There isn't enough flash to even store the garbage collector's code, even if it sits unused.

kjetil 15y ago

For what its worth, Tim Sweeney appears to endorse GC for game programming in his POPL talk: http://lambda-the-ultimate.org/node/1277 http://lambda-the-ultimate.org/node/1277