This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Too much memory in chan/select2.go used
- From: Uros Bizjak <ubizjak at gmail dot com>
- To: Ian Lance Taylor <iant at google dot com>
- Cc: gcc-patches at gcc dot gnu dot org, gofrontend-dev at googlegroups dot com
- Date: Wed, 1 Feb 2012 22:59:04 +0100
- Subject: Too much memory in chan/select2.go used
On Wed, Feb 1, 2012 at 10:27 PM, Ian Lance Taylor <iant@google.com> wrote:
>> (BTW: Do you have any idea on what to do with excessive memory usage
>> in chan/select2.go? )
>
> At this point I don't. ?It's sort of peculiar. ?Sending an int on a
> channel should not use any memory. ?The test is careful to only measure
> the memory allocated for sending and receiving, and as far as I can see
> nothing else should be allocated during the test. ?You reported that the
> test was allocating 2098576 bytes. ?When I run it I see it allocating
> 1408 bytes on x86_64, 640 bytes on i386. ?2098576 is much larger than
> either number. ?What is allocating that memory?
>
> In other words, there appears to be a real bug here. ?You can probably
> track it down by setting a breakpoint on runtime_mallocgc after the line
> ? ? ? ?runtime.MemStats.Alloc = 0
> What is calling runtime_mallocgc?
The backtrace says:
After a couple of calls from __go_new_channel, __go_new,__go_alloc,
the test starts to loop with allocations from newselect:
Breakpoint 2, runtime_mallocgc (size=156, flag=0, dogc=1, zeroed=1) at
../../../gcc-svn/trunk/libgo/runtime/malloc.goc:41
41 m = runtime_m();
(gdb) bt
#0 runtime_mallocgc (size=156, flag=0, dogc=1, zeroed=1) at
../../../gcc-svn/trunk/libgo/runtime/malloc.goc:41
#1 0x0000020000510364 in runtime_mal (n=156) at
../../../gcc-svn/trunk/libgo/runtime/malloc.goc:414
#2 0x0000020000506424 in newselect (selp=<synthetic pointer>, size=2)
at ../../../gcc-svn/trunk/libgo/runtime/chan.c:644
#3 runtime.newselect (size=<optimized out>) at
../../../gcc-svn/trunk/libgo/runtime/chan.c:c630
#4 0x0000000120001634 in main.receiver (c=0xf84020e000,
dummy=0xf84020e7c0, n=100000)
at /space/uros/gcc-svn/trunk/gcc/testsuite/go.test/test/chan/select2.go:19
#5 0x0000000120001824 in main.main () at
/space/uros/gcc-svn/trunk/gcc/testsuite/go.test/test/chan/select2.go:36
I didn't check where memory gets de-allocated, but there are really a
lot of above calls.
Uros.