Re: Too much memory in chan/select2.go used

[Uros Bizjak <ubizjak at gmail dot com>]

On Wed, Feb 1, 2012 at 10:59 PM, Uros Bizjak <ubizjak@gmail.com> wrote:
> 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?

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
via:

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();
(gdb) bt
#0  runtime_mallocgc (size=2097152, flag=6, dogc=0, zeroed=0) at
../../../gcc-svn/trunk/libgo/runtime/malloc.goc:41
#1  0x000002000050d4b0 in runtime_malg (stacksize=<optimized out>,
ret_stack=0xf840205f70, ret_stacksize=0xf840205f68)
    at ../../../gcc-svn/trunk/libgo/runtime/proc.c:1166
#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
../../../gcc-svn/trunk/libgo/runtime/proc.c:371

So, short of XFAILing the test on non-split stack targets, I have no
other idea how to handle this testcase failure.

Uros.