Re: performance of multithreading gets gradually worse under gdb

["Ulrich Weigand" <uweigand at de dot ibm dot com>]

Tom Tromey wrote:
> >>>>> "Markus" == Markus Alber <markus@hyperion-imrt.org> writes:
> 
> Markus> See the attached file. It shows a similar behaviour, although it only
> Markus> allocates 8kB per iteration.
> Markus> You have to wait some time before this happens.
> 
> Thanks.
> 
> I changed 1<<24 to 1<<15, to spare my underpowered machine, and ran gdb
> under massif.
> 
> This part is interesting:
> 
> ->20.78% (2,954,016B) 0x8253683: regcache_xmalloc_1 (regcache.c:232)
> | ->20.78% (2,954,016B) 0x8253F85: get_thread_arch_regcache (regcache.c:463)
> |   ->20.78% (2,954,016B) 0x82540B5: get_thread_regcache (regcache.c:488)
> |     ->20.78% (2,954,016B) 0x81D1579: i386_linux_resume (i386-linux-nat.c:861)
> |     | ->20.78% (2,954,016B) 0x81D7D32: linux_nat_resume (linux-nat.c:1983)
> 
> 
> I debugged gdb a little and it does indeed seem to be leaking here.
> 
> I don't understand why registers_changed_ptid unconditionally clears
> current_regcache.  I suspect that may be the source of the problem.
> 
> Perhaps someone who knows this code better could take a look.

It seems this leak was introduced by Pedro's patch here:
http://sourceware.org/ml/gdb-patches/2010-04/msg00960.html

The function used to free all regcaches in the list and then
reset current_regcache.  The new code now takes care to selectively
free only a subset of regcaches -- and then resets current_regcache
anyway ...

I guess we should just remove the current_regcache = NULL line now.

(Actually, now that every thread always has a thread_info, the
best thing would probably be anyway to hang each thread's regcaches
off the thread_info, and do away with the global list completely.)

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com