Dan Sugalski <[EMAIL PROTECTED]> wrote: > Since this has gotten to be an issue...
> Making a continuation conceptually has three steps. One must: > 1) Copy the current environment contents to the continuation > 2) Note the bytecode address at which the continuation should run > 3) Mark the stacks as COW > Step 3 is universally required *however* we can skip it *if* we > mandate that return continuations can't be used for anything other > than returning. I'm not sure that's a good idea, but we can do it. We > can also do it transparently if it turns out that it's a bad idea. That is a RetContinuation. It has only pointers of the context inside. > Allocating continuations quickly is important enough that I think > they warrant a separate arena with specifically sized PMCs. (with > each allocatable item being sizeof(PMC)+sizeof(environment) What about other sub PMCs: Sub, Closure, Coroutine, Exception_Handler? > there's no need for memory allocation at continuation allocation > time) Creating a continuation, if step 3 above is skipped, then has > the cost of a single PMC allocation from a free list and a memcpy of > the environment chunk of the interpreter structure. Should be faster by some yes. [ single items stack ] > ... and make 'em PMCs to boot. That > is, rather than having the stack allocated in chunks that can hold > multiple pushes, we make each push to the stack live in its own > independent structure that's linked to the previous top-of-stack > element. If we make these PMCs as well then we get it all nicely > DOD-able and GC-able without any (well, much) special code. The "this > is a buffer of PObj pointers" flag will work nicely for this too, as > it'll mean we won't even need to bother with a separate scanning code > path for this stuff. Making it a PMC just for marking is suboptimal. Special handling of PObj_is_buffer_of_pobjs can be inserted in mark_special(). The current Stack_Chunk_t has a C<limit> member to protect against to many pushes and C<name> for displaying error messages. leo
