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.
Is the idea that atomic copying of the heap is cheaper than "atomic
marking of the roots + plus write barriers" which is otherwise
required?
regards,
Tzvetan
|
