[gclist] GC & profiling

[Fergus Henderson]

On 19-Apr-2001, eliot@parcplace.com <eliot@parcplace.com> wrote:
> Fergus Henderson <fjh@cs.mu.oz.au>:
> | For accurate profiling of execution time, GC can cause some problems,
> | because GCs can occur at semi-random times, but the blame for time spent
> | in a GC should really be spread among all the routines that allocated
> | the memory, not on the routine that happened to do the final memory
> | allocation which triggered that GC.  If you don't treat GC specially,
> | then some innocuous routine can be unfairly blamed for a large proportion
> | of the execution time simply because that routine happened to be the
> | one that triggered a collection.
> 
> | On the other hand, costs of ordinary memory allocation should indeed be
> | credited to the calling routine.
> 
> I'm not sure if this is the best way iof solving it, but it is an alternative
> approach.  The VisualWorks Smalltalk profiling facilities provide both a time
> profiler and an allocation profiler.  The time profiler doesn't include
> explicit GC time.  Instead it is simply a statistical sampler of Smalltalk
> methods, so GC time is hidden.

I'm not sure what you mean by that.
Do you mean that
	- if a profiling timer tick occurs during GC, that tick is discarded?
	- if a profiling timer tick occurs during GC, that tick is credited to
	  the currently active Smalltalk method?
	  (This is what happens in the current Mercury profiler.)
	- profiling ticks can never occur during GC (e.g. because the
	  profiler actually counts number of bytecode instructions executed,
	  rather than time)?
	- something else?

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
                                    |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.