This is the mail archive of the
mailing list for the GCC project.
Re: 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: Thu, 2 Feb 2012 18:34:38 +0100
- Subject: Re: Too much memory in chan/select2.go used
- References: <CAFULd4ai=gXSxCYXjAf24GQ-=6rYUi5eXTYvJzk2wH_Ef4ZQ_Q@mail.gmail.com>
On Wed, Feb 1, 2012 at 10:59 PM, Uros Bizjak <email@example.com> wrote:
> On Wed, Feb 1, 2012 at 10:27 PM, Ian Lance Taylor <firstname.lastname@example.org> 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?
Some more debugging reveal the difference between alpha and x86_64.
Alpha does not implement split stacks, so soon after
"runtime.MemStats.Alloc = 0" line, we allocate exactly 2MB fake stack
Breakpoint 5, runtime_mallocgc (size=2097152, flag=6, dogc=0,
zeroed=0) at ../../../gcc-svn/trunk/libgo/runtime/malloc.goc:41
41 m = runtime_m();
#0 runtime_mallocgc (size=2097152, flag=6, dogc=0, zeroed=0) at
#1 0x000002000050d4b0 in runtime_malg (stacksize=<optimized out>,
#2 0x000002000050e3b8 in __go_go (fn=0x1200016b0 <main.$thunk1>,
arg=0xf8400001f0) at ../../../gcc-svn/trunk/libgo/runtime/proc.c:1218
#3 0x0000000120001968 in main.main () at select2.go:46
#4 0x000002000050e800 in runtime_main () at
So, short of XFAILing the test on non-split stack targets, I have no
other idea how to handle this testcase failure.