[gclist] GC in a Windows NT/95 threaded environment

[Hans Boehm]

Charles wrote:

> We've had very bad luck with write barrier based gc as far as
> efficiency is conserned. The exception is C++ pointer wrappers
> where the write barrier is simply on the pointer. Our best luck
> has been with gcAttemptCollection( userIdleDetectFunction ); That
> is calling for a collection but trashing it if interaction is
> required. In real world applications this works very well.
> 

Is this referring specifically to win32?  If not, then it only partially
agrees with my experience.  With my collector, there is clearly an additional
overhead for the VM-based write-barrier.  I know of no cases where it pays
for itself without paging.  On the other hand, in my experience with Cedar,
it's essential if your application is paging.  (But buying more memory is
a much better solution.)  It's also important if you expect to get interactive
response from a process that's running a large compute-bound task in
another thread.  I agree that if you have enough idle time and no paging,
abortable collections make more sense.

The cost of VM-protection based write barriers varies temendously based
on the system and exactly how the write-barriers are implemented.  For
example, the version that shipped with 4.10 and earlier of our collector
is quite slow under Irix.  The 4.11alpha versions have a simple workaround
that reduces the faulting/mprotect cost by something like a factor of 10.
Win32 provides particularly clumsy hooks for this sort of thing.

My impression (based on limited experience in a different context) is that
C++ pointer wrappers work well if you don't access the wrapped pointers
very often.  But they can be quite expensive if you do.

Hans


Hans-Juergen Boehm
boehm@mti.sgi.com