Steve Fink wrote:
To anyone out there who is thinking of a Grand Unified Infant
Mortality Solution, here's another thing that vastly complicates
things, and that we don't yet have a workable solution for yet: prompt
finalization.
my %x;
{ # start scope
my $timer1 = Timer->new();
my $timer2 = Timer->new();
$x{timer} = $timer2;
...
} # $timer1->DESTROY should be called
# $timer2->DESTROY should NOT be called
Right now, the only correct implementation of this that has been
proposed is to do a full DOD run at the end of every single scope.
Active destroying (did I say: "We don't need it" ;-)
The question is: does the HL know, that $timer1 needs to be destroyed, while $timer2 is still refererenced outside the current scope?
... We can do minor optimizations of that, by for example suppressing the DOD if no object that implements a DESTROY method is live, but that's it.
Or a more specific destroy flag or a separate object list for objects, which are not allowed to live beyond the end of a scope?
At the moment, this threatens to make perl6 the *slowest* language
hosted by Parrot! (Since we haven't implemented any other languages
yet that need this.)
Doing a full DOD run at the end of a scope is not an option.
... It is possible that this problem will be fixed by weakening the finalization guarantees in the language definition, but it's definitely something to worry about.
Weakening guarantees is probably not an option: file handles have the same problem - they should AFAIK be closed, when going out of scope.
... which seems to indicate, that stack/register walking is unusable for such obbjects, which are not allowed to be live.The connection to the infant mortality problem is just that some solutions might make this easier. Or harder. For example, the current conservative stackwalk breaks even the painfully slow solution: there might be a stale pointer somewhere on the C stack (or in a register, or a saved register window) that keeps the DESTROYable object alive unnaturally.
leo
