[gclist] GC & profiling
Mon, 23 Apr 2001 00:11:54 +1000
On 19-Apr-2001, email@example.com <firstname.lastname@example.org> wrote:
> Fergus Henderson <email@example.com>:
> | 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 <firstname.lastname@example.org> | "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.