[gclist] GC & profiling

eliot@parcplace.com eliot@parcplace.com
Thr, 19 Apr 2001 10:31:32 -0700


-covering message-

+-----------------------------
| Date:	Thu, 19 Apr 2001 16:17:34 +1000
| From:	Fergus Henderson <fjh@cs.mu.oz.au>
| Subject:	[gclist] GC & profiling

| 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.

| The remainder of this mail discusses some particular details of this
| problem with regard to the Mercury profiler and the Boehm (et al)
| collector.  I'm hoping, perhaps optimistically ;-), that someone will
| find this stuff interesting enough to read it and give some feedback on
| which of the different approaches is the best way of solving this problem.


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.  However, the allocation profiler assigns all
allocations to methods, resulting in a call graph annotated with the mount of
storage allocated.

Applying the allocation profiler to your context, you could make the
assumption that GC activity is as the result of allocation activity.  While
this isn't true in general, its a fair assumption in typical workloads.  Total
the GC time separately from the rest of the execution time.  Then use the
allocation profile to apportion the GC time amongst the non-GC code on the
basis of allocation rates.
---
Eliot Miranda                ,,,^..^,,,
mailto:eliot@parcplace.com
VisualWorks Engineering, Cincom    Smalltalk: scene not herd Tel +1 408 216
4581
3350 Scott Boulevard, Building 36, Santa Clara, CA 95054 USA Fax +1 408 216
4500