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.
Yes, I know that. I'm not 100% sure it's safe. Or, rather, I'm sure its safe if it's only used as a return continuation, as any full-fledged continuation will mark everything COW so it'll be fine. I'm just not sure we're going to be able to guarantee that a return continuation won't be used in other ways.
I suppose we could have an upgrade op that upgraded this to a full continuation, which'd just involve a COW stack walk.
D'oh! (I should edit this all out but, well...) If we go with a one frame stack chunk then we don't have to bother with COW-ing *anything* with the stack. Which makes the differentiation between a return continuation and a regular continuation irrelevant, as they'd be identical.
> Allocating continuations quickly is important enough that I thinkthey 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?
Dunno if they're allocated often enough to warrant any extra work. Maybe exception handlers.
[ 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.
Maybe, but I'm not sure of that. It's not the reason for going for a one frame stack chunk, but if we're going to we might as well just make it a PMC, or a PObj, or whatever. Reduce the number of special cases for the moment.
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.
Yes, I know. I want to skip the multiple frames per stack chunk thing entirely. One element per chunk and that's it.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
