FAQ
Thank you, Ian this clears up most of my confusion on the subject. I do
have a couple more points I hope you can clear up for me.
On Thursday, 20 February 2014 14:36:40 UTC-8, Ian Lance Taylor wrote:
On Thu, Feb 20, 2014 at 1:51 PM, Rob Thornton wrote:

When a Go program starts, it's my understanding that the OS allocates an
amount of stack space (between 1-8mb, typically, depending on the
OS/architecture). In a single thread if a program requests more stack space
but the frame pointer would exceed the stack segment then the result would
be a stack overflow. However, in Go a new stack would be created on the heap
to prevent this from happening. If you continually straddle this boundary
between the heap allocated stack and the "true" system allocated stack, it
would be called stack splitting?
The "stack splitting" is the allocation of the stack on the heap.
When that happens, the stack has been split. This does not happen in
a conventional C program.

Note that Go normally does not run on the system allocated thread
stack, but always runs on its own heap allocated stacks. Note also
that for 1.3 we are likely to switch to growable stacks, in which the
stack is grown as needed but not normally split except perhaps in some
special cases.
Regarding Go normally only using the heap allocated stack, do you mind my
asking why you wouldn't utilize any of the thread based stack? I am
assuming you're making a trade off between wasting said memory and
complexity?

I have read http://golang.org/doc/faq#goroutines but it's not clear
specifically what is meant by a segmented stack. Is a segmented stack having
one or more heap allocated stacks on top of the system allocated stack or is
it how goroutines have their own mini-stack segments?
Goroutines always use heap allocated stacks.

I'm very (emphasis on VERY) new to assembly but my understanding is that the
stack pointer is an internal CPU register. When a stack overflow would occur
and the program responds by requesting more stack space from the heap, must
the stack pointer now be maintained by the Go program rather than a CPU
register? This would be an assembly based stack data structure (linked
list)? Or I am I way off base now?
The stack pointer is a register. When a goroutine splits the stack,
it updates the stack pointer. So, yes, the stack pointer is
maintained by the Go program, and, yes, the stack pointer is a CPU
register. The two statements are not incompatible.
After reading your answer I felt quite foolish because the answer should
have been clear.

Ian
--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 3 of 8 | next ›
Discussion Overview
groupgolang-nuts @
categoriesgo
postedFeb 20, '14 at 9:51p
activeFeb 21, '14 at 6:38p
posts8
users4
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase