[gclist] zillion objects

[Nick Barnes]

At 2001-08-24 16:25:59+0000, Charles Fiterman writes:
> Some odd observations here.
> 
> First while Nick Barnes likes copying collectors I prefer the non copying
> varity as large applications in the real world pass objects back and forth
> to application written in lots of languages like C. Moving objects makes
> this very hard.

Charles is largely right.  Many objects in many applications are not
suited to moving collection.  But some objects in some applications
are not suited to collection at all, and that doesn't mean we don't
use collection where appropriate.  The same goes for moving
collectors.

Moving or mostly-moving collectors have considerable value in some
applications, and a collector which might even occasionally move an
object can't use the weak tri-colour invariant for that object.
That's why I generally disregard it when discussing incremental
collection.  Another reason is that incremental GC is complex enough
already without using the (IMO) fancier barrier methods implied by the
weak invariant (see Pekka's paper for the details).

In any case, it is extraordinarily hard to make incremental collection
work as a drop-in solution for existing large applications in C and
(especially) C++ without recompilation.  Too many uncontrollable
factors (mostly third-party libraries, but also language runtime code,
e.g. RTTI) interfere with the memory barriers.  Geodesic's Great
Circle is a great drop-in GC product, but even they prefer their
pseudo-incremental mode to true incremental.

> We have a lot of good luck with pseudo incremental collection.
> Incrementality is so expensive that its worth while trying to avoid it. The
> pseudo incremental collector starts normal collection and asks "Am I idle?"
> If there is anything that needs the system it aborts the collection losing
> all the work and returns control. Our experience is this is rare once and
> never happens twice in a row.

This is an excellent solution for many applications, especially those
seeking a drop-in collector, but you may find that it's not acceptable
for the multi-gigabyte heaps which Ji-Yong D. Chung was asking about.
I certainly agree that anyone who thinks they need an incremental
solution should try pseudo-incremental.  They should also try
non-incremental; an optimized scanner can through a lot of objects in
a very short time.

Nick B