Hi Alex, On Tue, May 21, 2013 at 7:46 AM, Alexander Burger <a...@software-lab.de>wrote: > > > To make things more clear, let's consider the following situation. It is > after the program started two coroutines, and then execution continued > in the main program. The two coroutines are suspended, and the hardware > stack points into the main program's stack frame: > > +---------------+ > Stack frame #1 | | > Main program | | > | Stack | > | Area | <- SP (Stack pointer register points > here) > | | > ... > | e.g. 4 MB | > | | > | | > | | > +---------------+ > Stack frame #2 | tag | > Coroutine #1 +---------------+ > | Saved SP | +--+ This is the SP of the suspended > coroutine > +---------------+ | > | | | > | Environment | | > | | | > +---------------+ | > | | | > | | | > | Stack | | > | Area | <--+ > | | > ... > | e.g. 1 MB | > | | > | | > | | > +---------------+ > Stack frame #3 | tag | > Coroutine #2 +---------------+ > | Saved SP | +--+ This is the SP of the suspended > coroutine > +---------------+ | > | | | > | Environment | | > | | | > +---------------+ | > | | | > | | | > | | <--+ > ... > > Is that picture a single, contiguous memory region? Because then, you *could* have the first scenario I mentioned in a previous mail (unlikely, but, think of a native C code, that allocated huge structures and recursed -- it could overwrite many megabytes of stack). This would be my concern: a C library function that uses (in the above picture) more than 4 MB of memory. That is easy to imagine with modern reentrant graphics libraries. The programmer would have to have a very clear picture of the above to know to use the 'stack' function to allocate adequate stack.
Anyway, enough is *not ever* enough. I would only feel comfortable seeing at least 10MB of *non-mapped* memory between the main program's stack and each of the the co-routines' stacks. Again, generally, I would feel uncomfortable having anything "below" my stack pointer than a large region of writable memory followed by a very large region of memory that would give me a "sigsegv" if I tried to access it. If I am the application programmer, I can violate these rules, but as the "language system programmer" (i.e., you) you can never make assumptions about how that application programmer is going to use the stack. Now, if the system inspects this process (during a system call or > interrupt), it finds that - despite the fact that the process ONCE used > a large stack space - the stack pointer is now back in the upper regions > of the stack space. > > The system doesn't know about the frame structures. It will assume that > the process did a lot of pushes and/or recursive calls, but is now done > with them, and the stack is no longer needed. > > So it might decide to purge it. > > The big question is: Will the system (which system?) do that? If so, how > do other languages implement green threads, coroutines or continuations? > > Since that is read/write memory, the system won't purge it. It might be paged out (to swap), but would be transparently paged back in if/when used again. I'd never expect an OS to "know" that a region of memory is a stack. Rand