[CVS ci] indirect register frames 14 - cache the register frame
Leopold Toetsch
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.
This might still change, so best is probably to hide this sequence
behind a macro.
leo
Dan Sugalski
>* 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
fetching.
--
Dan
--------------------------------------it's like this-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Dan Sugalski
>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 <d...@sidhe.org> wrote:
>> 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.
>>
Piers Cawley
> At 2:30 PM -0500 11/2/04, Matt Fowles wrote:
>>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.
And, dammit, making a full continuation isn't something a programmer
should do lightly.
Leopold Toetsch
> And, dammit, making a full continuation isn't something a programmer
> should do lightly.
BTW I had to change your example code (you remember it for sure, it's in
t/op/gc_13 inv CVS)
(define (choose . all-choices)
(let ((old-fail fail))
(call-with-current-continuation
...
I had to use a distinct second "choose" closure to make that code
working again during changes for the indirect reegister addressing.
# XXX need this these closures have different state
newsub choose, .Closure, _choose
y = choose(arr2)
I presume it's technically correct, as these two closures have different
"choices" arrays in their lexical pads.
leo
Leopold Toetsch
>> $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
> fetching.
Probably yes[1]. Eventually we can get rid of the return continuation
object. But that's not easy as we have "invoke sub_obj" too, which uses
an existing continuation in P1. Additionally there's already a lot of
code around that just does "invoke P1".
To disambiguate call and return for the case "plain subroutine", we
would need a "returncc" opcode, that use the information in the context
to return as we now do with P1.
A sequence:
invokecc
...
returncc
doesn't need a P1 object, it just needs a pointer in the Sub context to
the caller's context.
[1] There'is the case of pure introspection, where cloning isn't needed,
*if* the return continuation isn't abused. Could be dangerous, though.
leo