www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Segmented stack

reply "Shucai" <yao2001626 gmail.com> writes:
I am doing research on segmented stack mechanisms, and in 
addition to academic papers, I am surveying whether segmented 
stack mechanism is still useful on 64-bit machines. On 64 bit 
machines, why  they don’t just use a big enough stack, for 
example, 1GB or even larger?  Are segmented stacks only useful 
for 32 bit machines?  Are there other reasons for segmented 
stacks on 64 bit machines?

Any response is appreciated, thanks, Shucai
Oct 16 2014
next sibling parent reply "Brad Anderson" <eco gnuk.net> writes:
On Thursday, 16 October 2014 at 19:46:42 UTC, Shucai wrote:

 I am doing research on segmented stack mechanisms, and in 
 addition to academic papers, I am surveying whether segmented 
 stack mechanism is still useful on 64-bit machines. On 64 bit 
 machines, why  they don’t just use a big enough stack, for 
 example, 1GB or even larger?  Are segmented stacks only useful 
 for 32 bit machines?  Are there other reasons for segmented 
 stacks on 64 bit machines?

 Any response is appreciated, thanks, Shucai


You might want to try asking the Go and Rust mailing lists since 
they have a lot of experience with segmented stacks.

Rust abandoned them for a few reasons you can read about here[1]. 
The announcement specifically mentions they believe the MMU can 
take care of the stack on 64-bits.

1. 
https://mail.mozilla.org/pipermail/rust-dev/2013-November/006314.html
Oct 16 2014
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 16 October 2014 at 22:20:34 UTC, Brad Anderson wrote:

 You might want to try asking the Go and Rust mailing lists 
 since they have a lot of experience with segmented stacks.


But note that Go has a different problem since they want high 
concurrency, so stacks have to stay small (and be able to 
shrink). I believe they copy stacks and rewrite pointers… (ugh)


 Rust abandoned them for a few reasons you can read about 
 here[1]. The announcement specifically mentions they believe 
 the MMU can take care of the stack on 64-bits.


They don't have much of a choice since AMD64 does not provide a 
segmented memory model.

Why they chose the flat model I cannot say, but I believe it has 
to do with the x86 memory architecture and how 32-bit x86 
implements segments as a separate layer from page tables with 
segments pointing to address ranges rather than a page table 
slot. If segment registers were more abstract (with no notion of 
physical memory addresses) then it would make sense to have it 
IMO.

Many-core probably make the 32-bit x86 model expensive to 
implement with little gain, so the FS and GS registers have been 
repurposed for other things instead.
Oct 16 2014
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 17 October 2014 at 04:23:40 UTC, Ola Fosheim Grøstad 
wrote:

 They don't have much of a choice since AMD64 does not provide a 
 segmented memory model.


Ack, I misinterpreted. The OP probably talks about 
"split-stacks", stacks a linked list of memory segments. I 
thought it was about trapping out-of-stack situations.

A historical note: I think Simula, Beta, Self and maybe early 
versions of Java allocated activation records on the gc-heap 
rather than using a stack. Allowing for high levels of 
concurrency with little wasted memory, but I have no references 
at hand…
Oct 17 2014
prev sibling parent "thedeemon" <dlang thedeemon.com> writes:
On Thursday, 16 October 2014 at 22:20:34 UTC, Brad Anderson wrote:

 On Thursday, 16 October 2014 at 19:46:42 UTC, Shucai wrote:

 I am doing research on segmented stack mechanisms, and in 
 addition to academic papers, I am surveying whether segmented 
 stack mechanism is still useful on 64-bit machines. On 64 bit 
 machines, why  they don’t just use a big enough stack, for 
 example, 1GB or even larger?  Are segmented stacks only useful 
 for 32 bit machines?  Are there other reasons for segmented 
 stacks on 64 bit machines?

 Any response is appreciated, thanks, Shucai


 You might want to try asking the Go and Rust mailing lists 
 since they have a lot of experience with segmented stacks.


"Go 1.3 has changed the implementation of goroutine stacks away 
from the old, "segmented" model to a contiguous model. When a 
goroutine needs more stack than is available, its stack is 
transferred to a larger single block of memory. "
https://golang.org/doc/go1.3

So I guess both of them abandoned segmented stacks.
Oct 16 2014
prev sibling parent "Chris Williams" <yoreanon-chrisw yahoo.co.jp> writes:
On Thursday, 16 October 2014 at 19:46:42 UTC, Shucai wrote:

 I am doing research on segmented stack mechanisms, and in 
 addition to academic papers, I am surveying whether segmented 
 stack mechanism is still useful on 64-bit machines. On 64 bit 
 machines, why  they don’t just use a big enough stack, for 
 example, 1GB or even larger?  Are segmented stacks only useful 
 for 32 bit machines?  Are there other reasons for segmented 
 stacks on 64 bit machines?

 Any response is appreciated, thanks, Shucai


While the implementation isn't guaranteed, I think that Java 
mandates that the VM behave like every function receives a fresh 
stack. I imagine that the advantage of this was that it allows 
the VM to supply only the minimal necessary memory for a function 
to operate, at any given time. On small devices, it can swap the 
stack out to disk. On large devices, it can just keep everything 
in memory. Optimization for size/speed is handled for you, making 
your code more portable. (Theoretically.)

Another possibility is that, while I can't think of the 
application, being able to preserve discarded chunks of the stack 
might be useful in some way. In a traditional stack arrangement, 
a new function entry will generally cause the data from the 
previous function entry to be overwritten. If you're allocating 
each new entry as its own thing, then all of the old functions 
continue to sit around to be processed by another thread, until 
you're ready to completely get rid of them.
Oct 17 2014