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