All~
I don't like the idea of having to dig down through the entire return chain promoting these guys. Is there a reason not to use DOD/GC to recycle continuations?
Yes. Speed.
While you can skip some of the digging (since you can stop at the first promoted one) the reality is that 90%+ of the return continuations will *never* need promoting. Not bothering to make the return continuations true full continuations until they're actually needed as one lets us immediately recycle return continuations as soon as they're used in the near-overwhelming majority of the cases -- that is, when nothing can possibly have a hold of 'em. That leaves a lot fewer objects for the DOD to sweep through, as well as speeding up allocation (since we're more likely to have ones at hand, and likely in cache too) of the things in the first place.
On Tue, 2 Nov 2004 14:10:09 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:> fetching.At 6:51 PM +0100 11/2/04, Leopold Toetsch wrote:
>* The stack frame caching is back, hopefully now implemented correctly: > 1) when a return continuation is invoked the stack frame is recycled > 2) when a continuation is created, all the return continuations up the > call chain are converted to real continuations by changing the > vtable. This prevents 1) from happening. > 3) cloning a return continuation yields a true continuation > >* When you need the return continuation of the current call (and >reuse it later) use this sequence: > > .include "interpinfo.pasm" > $P1 = interpinfo .INTERPINFO_CURRENT_CONT > $P1 = clone $P1 > >I'm still inclined to make this sequence an opcode, though. The >cloning is still necessary, as the return continuation is returned.
Hrm. I think the returned continuation should be usable without cloning. If we need to clone it it should be part of the continuation
-- Dan
--------------------------------------it's like this-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
