[gclist] GC & profiling

[Boehm, Hans]

I agree with Eliot that it would be useful to profile allocation separately.

A very partial answer to some of the detailed questions:

> There's macros ENTER_GC() and EXIT_GC(), which [in some 
> configurations]
> set/unset a volatile global variable GC_collecting -- exactly what
> we want.  Changing things so that they do that 
> unconditionally would be
> easy enough (see diff 2).  Unfortunately, the purpose of GC_collecting
> is slightly different -- it is documented as "A hint that we're in the
> collector and holding the allocation lock for an extended 
> period.", and
> ENTER_GC() doesn't seem to be called in all the places that we want it
> to be.  So I guess that is not an ideal approach.
My guess would have been that this should be pretty close, in that the flag
should be set when the collector is running for an extended period. Some of
the smaller grain overhead will be distributed to the allocation sites, but
that sounds tolerable to me.  It's precisely the large grain stuff that you
want to handle separately.  And the boundary between allocation and
collection is very fuzzy anyway.

This will charge sweeping or initial free-list construction to the GC,
unless you use thread-local allocation, in which case it will be charged to
the allocating thread.  I would gues that either solution is acceptable,
though mixing them is probably confusing.  (The reason for the difference is
that with thread-local allocation, the lock is not held during sweeping.  In
the default case it is.)

I don't know how finalization is used in Mercury, so I'm not sure whether
it's an issue.
Anytime finalization is accessible to arbitrary client code, it should
really run in a separate thread, since it is logically a separate thread,
and may need access to synchronization facilities.  If finalization is only
used in the runtime, then it should be possible to special case it
appropriately.  (The collector's default behavior of running finalizers as
part of allocation is only suitable for very simple applications.  For
anything else you should be running them explicitly.  The facilities for
doing that have been getting better.)
> 
> There's also a function GC_collection_in_progress() that looked a bit
> more promising.  This looks at the GC_mark_state variable, 
> which is set
> at various stages of the marking process.
I think this doesn't do what you want with the incremental collector.  This
returns true even if the client was running if there is a partially finished
collection going on in the background.

For profiling purposes, it might also be acceptable to run all the
collections in a separate thread, and arrange to not profile that thread.  I
don't know how feasible that is in your system.