Walking the stack is where you look at the systems call stack searching
for valid pointers. The valid pointers are used to make sure that all
memory that is in use does not get freed during GC.
Depending on the architecture, valid pointers might have to be 1, 2, or
4 byte aligned so you have to check differently for each architecture.
Some architectures might have a stack that grows downwards, others
upwards. So this is the sort of thing that is heavily platform dependent.
Matt
The system stack is where parameters and automatic (non-static) C
variables are stored. For a long time, there was a problem with Parrot
where something like this would happen:
STRING * foo=string_new(...);
some_operation_that_does_gc();
do_something(foo); /* ! */
The line marked with an exclamation point was a big problem, because foo
might have been GCed by accident. This is called the "infant mortality"
problem, because brand-new things that hadn't been put somewhere yet
were killed. It could also be a lot more insidious--for example, if you
were in the middle of allocating a PerlHash and the PerlHash allocated
some extra memory for itself, it might clobber itself in the process.
Which is a Bad Thing, obviously.
A bunch of schemes were proposed to fix this, usually involving a
special stack and some extra macros or function calls, but all of them
were prone to breakage--someone might forget to mark something as an
infant and thus shoot himself in the foot. Finally, we implemented
system stack walking to take care of the problem for us--and to my
knowledge, it hasn't been a problem since.
--Brent Dax <bren...@cpan.org>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
>How do you "test" this 'God' to "prove" it is who it says it is?
"If you're God, you know exactly what it would take to convince me. Do
that."
--Marc Fleury on alt.atheism