[perl #27904] [PATCH] stack items 2

0 views
Skip to first unread message

Leopold Toetsch

unread,
Mar 24, 2004, 8:02:08 AM3/24/04
to bugs-bi...@rt.perl.org
# New Ticket Created by 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(-)

stack-items-2.patch

Dan Sugalski

unread,
Mar 24, 2004, 11:32:58 AM3/24/04
to perl6-i...@perl.org, bugs-bi...@rt.perl.org
At 5:02 AM -0800 3/24/04, Leopold Toetsch (via RT) wrote:
>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

unread,
Mar 24, 2004, 11:52:48 AM3/24/04
to Dan Sugalski, perl6-i...@perl.org
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?

> 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

unread,
Mar 24, 2004, 12:10:04 PM3/24/04
to l...@toetsch.at, perl6-i...@perl.org
At 5:52 PM +0100 3/24/04, Leopold Toetsch wrote:
>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

unread,
Mar 24, 2004, 3:46:31 PM3/24/04
to perl6-i...@perl.org
Leopold Toetsch <bugs-...@netlabs.develooper.com> wrote:

> - 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

unread,
Mar 24, 2004, 4:18:34 PM3/24/04
to l...@toetsch.at, perl6-i...@perl.org
At 9:46 PM +0100 3/24/04, Leopold Toetsch wrote:
>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

unread,
Mar 24, 2004, 5:41:18 PM3/24/04
to perl6-i...@perl.org, bugs-bi...@rt.perl.org
Hi,

> + 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

unread,
Mar 25, 2004, 2:53:40 AM3/25/04
to Jonathan Worthington, perl6-i...@perl.org
Jonathan Worthington <jona...@jwcs.net> wrote:
> 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

unread,
Mar 25, 2004, 4:28:22 AM3/25/04
to Dan Sugalski, perl6-i...@perl.org
Dan Sugalski <d...@sidhe.org> wrote:

> 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

Reply all
Reply to author
Forward
0 new messages