On Thu, 1 May 2008, Tzvetan Mikov wrote:
> On May 1, 8:37 am, "Kjetil S. Matheussen" <k.s.matheus...@[EMAIL PROTECTED]
>
> wrote:
> > Exactly, thats what "snapshot" means (although only mark happens in
> > parallel, not sweep, but sweep can be interrupted and continued later
> > at next audio block exit).
> >
> > There are two reasons why this can work very well:
> >
> > 1. Realtime audio processing code is often
> > compact and doesn't require extremely large heaps (1 megabyte might
> > be enough, but larger heaps can work fine as well).
> >
> > 2. Its common to run many "instruments" simultaniously,
> > which has the advantage of making it possible to let one
> > instrument run signal processing code while all the other
> > instrumentst can do their snapshots. And when having a snapshot,
> > marking and sweeping runs in complete parallel with respect to both
> > owning and not-owning instruments.
> >
> > As I said, this is not a general technique for doing hard realtime
> > garbage collecting, it will only work for the kind of tasks which are
> > synchronized by a clock, sometimes has some time to spare doing
> > snapshots, and preferably where there are many processes running
> > simultaniously (although not necessarily concurrently) not sharing
> > heaps. Audio is one such type of task, video might be another.
>
> Thanks. I am not familiar at all with sound processing, so if you
> don't mind I would like to dig a little further. I've been looking at
> improving the interactivity of GC applications, so your GC is somewhat
> relevant, although clearly it has a different target.
>
> If the sweep doesn't run in parallel, what are the advantages compared
> to, for example, snapshot-at-beginning with Yuasa write barriers,
> which allows (mostly) incremental mark and sweep ? It seems that the
> advantages of separate heaps wold apply equally to both.
>
Sweep may run in parallel, I just chose it not too. It might
be faster to make it run in parallel, but it requires locks
around alloc() and free(), which will also slow down, so maybe not.
Benchmarking is needed to find that out. Its possible to have
two heaps though, and free in one while allocating in another,
but that will cause more memory fragmentation, plus that
all memory can't be freed anyway, which is the only real advantage
of running sweep in parallel using locks around free() (ie.
theres less chance of running out of memory and therefore the heap size
can be decreased), so there's probably not really much advantage
in having two heaps either.
The advantage of not having write barriers is obvious: write barriers
are complicated and the code having to deal with them will
use more cpu.
> Is the idea that atomic copying of the heap is cheaper than "atomic
> marking of the roots + plus write barriers" which is otherwise
> required?
Don't know. Probably. The point about this garbage collector
is that its very simple to plug into most garbage producing
high level languages which uses mark and sweep collectors.
I don't know what you are trying to achieve, but if its only
better interactivity you're after, generational garbage collectors
seems to do a pretty good job.
|
