<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
</head>
<body class='hmmessage'>
> that alloca doesn't do any error checking<br><br><br>No. There is also native exception handling to consider.<br>NT essentially does error checking in both.<br><br><br>> thousands, tens of thousands, millions of threads<br><br> - 64bit address spaces<br> - multiple machines ("cloud")<br> <br><br> > Won't work. alloca releases memory at the }.<br> <br> <br> Only sort of.<br> You can still return that point and still use the memory.<br> You do risk, e.g. if you make any function calls, then the<br> alloca memory and the function parameters might overlap.<br> You could..platform-dependent..probably skip the first<br> "few" bytes of the alloca memory.<br><br><br> > Note that in my design, the stacks are all contiguous---but overlapping!<br> <br> Are your stacks also traversing heap and what-not,<br> or are you just chopping up the current stack into lots<br> of smaller stacks?<br> <br> i.e. alloca stack size times n and then create n threads?<br> That's less bad.<br> <br> I had the impression you were skipping over other memory.<br> <br> You know, like, malloc your stack, and then alloca to get<br> the stack pointer to hit the malloced memory.<br><br> > What would avoid it is generating the call to alloca in the front end.<br> <br>We could w/o much difficulty provide alloca in the frontend.<br>Probably limit it to unsafe modules.<br>At least to support your experimenting and somewhat platform-dependent code.<br><br> > in the 1970s..<br> <br> <br>I think the right place to experiment with this stuff is at a lower level.<br>Or with more complete control of the system.<br>ie. in the kernel, or on only one specific kernel, that you<br>build/modify/write-from-scratch yourself.<br><br><br>Gotta go,<br> - Jay<br><br><br><br><br><br><br>> To: jay.krell@cornell.edu<br>> Date: Wed, 23 Feb 2011 12:39:50 -0800<br>> From: mika@async.caltech.edu<br>> CC: m3devel@elegosoft.com<br>> Subject: Re: [M3devel] Avoding thread-stack overflow, proof of concept of "leapfrog stacks"<br>> <br>> Jay K writes:<br>> >--_60ddb4ae-bef3-432c-a5fd-a46c878ce951_<br>> >Content-Type: text/plain; charset="iso-8859-1"<br>> >Content-Transfer-Encoding: quoted-printable<br>> ><br>> ><br>> >Stack must be contiguous on NT.<br>> >Some platforms -- NT -- actually know how big the current stack is -- and w=<br>> >on't let you<br>> >alloca past it. Best way to let the target handle making stacks is with Pos=<br>> >ix makecontext=2C<br>> >for the many-but-not-all platforms that have it=2C or CreateFiber on NT.<br>> >(OpenBSD and I think Darwin/amd64 lack makecontext. It is in Posix=2C but d=<br>> >eprecated=3B<br>> >heck Darwin doesn't even have Posix semaphores seemingly..)<br>> <br>> The problem with making stacks with makecontext, etc., to me seems<br>> to be: what do you do when you want to return to the original stack.<br>> Can it be made to "just work"?<br>> <br>> Note that in my design, the stacks are all contiguous---but overlapping!<br>> There are no "new" stacks and no switching of stacks. You just pretend<br>> you have a huge data structure sitting where the other guys' stacks<br>> (and data, etc.) are.<br>> <br>> Cleanup is also easy, it's handled by the ordinary GC.<br>> <br>> ><br>> >To avoid the assembly you could use a hack like:<br>> >void* Unsafe__alloca(size_t n) { return alloca(n)=3B }<br>> <br>> Won't work. alloca releases memory at the }.<br>> <br>> What would avoid it is generating the call to alloca in the front end.<br>> <br>> ><br>> >Beware.<br>> >Dangerous platform/compiler-specific stuff here.<br>> <br>> Not really that specific. It relies on precisely one special property<br>> of the underlying system: that alloca doesn't do any error checking.<br>> <br>> The only changes that need to be made to CM3 are coming up with a<br>> mechanism for detecting the need for expanding the stack (could be done by<br>> bumping the redzone before winding the stack and handling this in a SEGV<br>> handler) and modifying the garbage collector to understand the scheme.<br>> I suggest adding a back pointer at the beginning of the newly allocated<br>> area that would let the GC go back to the previous one while scanning<br>> (or however it works).<br>> <br>> Users/platforms that don't need or can't support "leapfrog stacks"<br>> would not change except that their garbage collectors would have some<br>> code that's never executed...<br>> <br>> I've discussed the above with people who've been doing concurrent<br>> programming since before the glaciers came thru (implementations of<br>> Concurrent Pascal in the 1970s) and they said that they used linked<br>> (noncontiguous) stacks in those days. The state of the art of 2011<br>> seems rather unimpressive...<br>> <br>> My feeling is that the stack overflow issue is one of the things hindering<br>> the acceptance of truly multi-threaded programming (thousands, tens of<br>> thousands, millions of threads).<br>> <br>> Mika<br>> <br> </body>
</html>