Re: My arguments

On 08/13/03 Fergus Henderson wrote:
> > If we're not going to achieve that, we might as well just keep using
> > libgc.
> 
> I don't agree.  For many applications we ought to be able to get
> significantly better performance than libgc using a good copying or
> mark/compact garbage collector.  Also, there are advantages to using a
> type-accurate collector rather than a conservative collector (e.g. more
> predictable memory usage) which are desirable for some applications.
> So type-accurate copying or compacting collection is desirable even
> if it is not incremental.
[...]
> In the short to medium term, I think implementing a type-accurate
> collector and integrating it with the rest of the Mono implementation
> is already a complex task, so I think we should start off simple,

I agree with Fergus here. Just doing a precise collector is hard,
specially when considering that in the CLR managed<->unmanaged
transitions are quite common and need to be handled correctly.
Moving the objects around could be considered just a way to test
the pointer-tracking implementation more than anything else;-)
Tracking the pointers in the heap is very easy: the issue is with
tracking them on the stack/registers. There are papers, though, about
scanning stack/regs conservatively and avoiding copies of objects
that could be referenced from there: this might be a possible convenient
compromise.
I would also like to point out some features required by the CLR
that need to be taken into account when designing a replacement for
libgc:
*) pinning (an object may be marked as non-moving for some periods of time)
*) weak references
*) finalization issues

lupus

-- 
-----------------------------------------------------------------
[email protected]                                     debian/rules
[email protected]                             Monkeys do it better
_______________________________________________
Mono-gc-list maillist  -  [email protected]
http://lists.ximian.com/mailman/listinfo/mono-gc-list