[bitc-dev] Pools in lieu of GC

Jonathan S. Shapiro shap at eros-os.com
Wed Mar 4 22:37:17 EST 2009


On Wed, Mar 4, 2009 at 9:56 PM, Rick R <rick.richardson at gmail.com> wrote:
> I have read about a generational garbage collector that operated approx. 20%
> faster than hand coded memory over the lifetime of a non-trivial, real world
> application. The downside is that it required 3x the available heap space of
> the hand coded one. At 2x the available memory, it operated at approx. 90%
> of the hand standard.

This has been historically typical, but it is a misleading analysis.
The reason for the 2x overhead is that the underlying OS does not
provide support. The non-current generation does not need to be backed
by real memory most of the time, so that real memory overhead can, in
principle, be shared across a large number of programs. Current
implementations don't tend to do that.

> e7 Lisp was built explicitly for live sound processing applications and
> mixers. It features an incremental red/gray/black GC suitable for "hard
> realtime". To my knowledge it achieves that goal (it's written in C++, but
> may be worth borrowing)

Hmm. Tried to go look at it. Either the site is temporarily down or
it's dead. Do you know which?


shap


More information about the bitc-dev mailing list