[perl #27904] [PATCH] stack items 2
Leopold Toetsch
# Please include the string: [perl #27904]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=27904 >
Here is the next attempt, diffstat against CVS is below:
- has now freelist handling
- doesn't use managed memory anymore
User, control and pad stack are still handled in stack_common.c. This is
easily changable, *if* we finally know, how these stacks should look like.
Test imcc/t/syn/pcc_16 is failing due to a DOD bug that got exposed by
these changes. This test uses lexicals a coroutine and exceptions.
Somewhere the interpreter context is messed up, so that it contains
illegal PMC pointers.
leo
$ diffstat -w 70 stack-items-2.patch
classes/closure.pmc | 3
classes/coroutine.pmc | 2
imcc/pcc.c | 8 -
include/parrot/interpreter.h | 1
include/parrot/register.h | 2
include/parrot/stacks.h | 18 +-
src/debug.c | 24 +--
src/dod.c | 1
src/register.c | 62 +++-------
src/stack_common.c | 201 ++++++++++++++-------------------
src/stacks.c | 78 ++++--------
src/sub.c | 46 +++----
t/op/stacks.t | 4
t/pmc/eval.t | 4
14 files changed, 184 insertions(+), 270 deletions(-)
Dan Sugalski
>Here is the next attempt, diffstat against CVS is below:
>
>- has now freelist handling
>- doesn't use managed memory anymore
>
>User, control and pad stack are still handled in stack_common.c. This is
>easily changable, *if* we finally know, how these stacks should look like.
I tried this out, and it's mildly faster, except where it isn't. I'm
comfortable with this going in, and we can refine it afterwards.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Leopold Toetsch
> At 5:02 AM -0800 3/24/04, Leopold Toetsch (via RT) wrote:
>>
>>User, control and pad stack are still handled in stack_common.c. This is
>>easily changable, *if* we finally know, how these stacks should look like.
> I tried this out, and it's mildly faster, except where it isn't.
*g* --pushing a lot onto user stack?
> I'm
> comfortable with this going in, and we can refine it afterwards.
I'll commit it in a minute
Thanks for looking through it,
leo
Dan Sugalski
>Dan Sugalski <d...@sidhe.org> wrote:
>> At 5:02 AM -0800 3/24/04, Leopold Toetsch (via RT) wrote:
>>>
>>>User, control and pad stack are still handled in stack_common.c. This is
>>>easily changable, *if* we finally know, how these stacks should look like.
>
>> I tried this out, and it's mildly faster, except where it isn't.
>
>*g* --pushing a lot onto user stack?
Yeah, going with single-element things for the user stack's going to
hurt. I'm tempted to make those entries just PMCs--there's enough
stuff in the PMC to make it a viable singly-linked-list element with
payload.
Leopold Toetsch
> - doesn't use managed memory anymore
> - has now freelist handling
Thinking more about all these stacks, I think we got a problem.
Let's assume this code snippet with this call trace:
.sub _main
newsub eh, .Exception_Handler, catch # or .Continuation
set_eh eh # or pass on continuation
# (1)
_func1() # (2)
.sub _func1
...
_func2() # (3)
...
.sub _func2
...
throw exception # (4) or invoke Continuation PMC
catch: # (1')
The PMC register frame stack looks like (assuming a function call does
C<pushtopp>):
(1) <top>
(2) P16...P31
(3) P16...P31
(4) --> (1')
Now when the Continuation (or Exception) is invoked in (4) all the
context of (1) is restored into the interpreter's context. Program flow
continues in main but all stack changes (on all stacks) are effectively
discarded--the whole context is reset to main's context.
That means currently: we are leaking PMC register frames (2) and (3) in
this example. But we could leak other register stack frames and user or
pad stack entries too:
.sub func2
new_pad 3
save 10
...
throw
I can seen two ways to get around that:
1) use (again) managed (i.e. Buffer) memory for *all* stacks.
Discarding the stacks is cleaned up by the next DOD+GC run.
2) on invoke()ing a Continuation unwind *all* stacks, that is:
while (interp->ctx.<stack> != continuation->ctx.<stack>)
POP(interp->ctx.<stack>
During popping off all intermediate entries until the original state is
reached, these stack entries are put onto the stacks freelist and aren't
lost.
3) I'm missing something and can't count
*But* there are coroutines too, which have additional complications,
like their own register frame stacks.
leo
Dan Sugalski
>That means currently: we are leaking PMC register frames (2) and (3) in
>this example. But we could leak other register stack frames and user or
>pad stack entries too:
Right. That's why the stack frames have to be garbage collected--only
the DOD knows when one's truly not used any more.
Jonathan Worthington
> + switch (STACK_ITEMSIZE(chunk)) {
> + case sizeof(struct IRegFrame):
> + s = 0;
> + break;
> + case sizeof(struct NRegFrame):
> + s = 1;
> + break;
This is a no-go for places where sizeof(INTVAL) is the same as
sizeof(FLOATVAL). As is the case on certain cygwin setups, and I'd guess on
some other 64-bit platforms.
Jonathan
Leopold Toetsch
> Hi,
> This is a no-go for places where sizeof(INTVAL) is the same as
> sizeof(FLOATVAL).
I know. It'll be replaced RSN.
> Jonathan
leo
Leopold Toetsch
> Right. That's why the stack frames have to be garbage collected--only
> the DOD knows when one's truly not used any more.
Done (again).
leo