[Gc] Re: Understanding why GC'ing increases to the double in time?
hans.boehm at hp.com
Tue Jan 31 10:45:25 PST 2006
> From: Martin Egholm Nielsen
> But the time spent here [root scanning] is covered within the /small/
> times (the 200ms), right?!
Yes, at least it should be. The kinds of things I'm worried about are:
- It might be done more than once in the slow GCs, due to a GC bug.
- I assume there is no paging on your platform? Since there are 3 MB
of roots, these all have to be main memory accesses, and they should
continue to take the same amount of time? Is there any other reason
memory access times could change?
- Might there be something running concurrently with the later GCs?
> > If you have some way of getting an execution profile for the time
> > spent in the "long" GCs that might help to track things down.
> Sure - never tried though (besides profiling a kernel
> module). Does this
> require special treatment at compiletime? And no binary
> stripping? Doing this will require something from the
> profiler: I need being able
> to reset the profiling data until ready for measuring a
> sweep. I guess
> there must be profilers that can be controlled using socket
I'm not sure what tools work well in your environment. Sometimes,
without dynamic libraries, and if you care about only one thread, it
be easiest just to use the "profil" system call directly, and interpret
results afterwards with the aid of "nm" output or a debugger. See
for some (really simple) sample code.
More information about the Gc