On Thu, Feb 9, 2012 at 7:43 AM, Ian Lance Taylor i...@google.com wrote:
Uros Bizjak ubiz...@gmail.com writes:
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
Uros Bizjak ubiz...@gmail.com writes:
BTW: I'd like to point out that we can use go-execute-xfail in this
case, so the case is compiled but is known to fail execution for some
reason.
Thanks, I didn't know about that one.
I think I'll leave it as is for now because I'm treating stack.go the
Uros Bizjak ubiz...@gmail.com writes:
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:
Thanks for tracking this down.
So, short of XFAILing the
On Wed, Feb 1, 2012 at 10:59 PM, Uros Bizjak ubiz...@gmail.com wrote:
On Wed, Feb 1, 2012 at 10:27 PM, Ian Lance Taylor i...@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
On Wed, Feb 1, 2012 at 10:27 PM, Ian Lance Taylor i...@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
