Dave Mitchell wrote:
>
> On Wed, Aug 20, 2003 at 06:40:51PM -0400, Benjamin Goldberg wrote:
> > Dave Mitchell wrote:
> > >
> > > On Sun, Aug 17, 2003 at 05:48:14AM -0600, Luke Palmer wrote:
> > > > Here comes that ever-reincarnating thread again, sorry.
> > > >
> > > > This is a proposal for an efficient solution to the timely
> > > > destruction problem, which doesn't use refcounting, and fits in to
> > > > the current scheme pretty well.
> > >
> > > I don't quite follow all the below (probably mainly due to my
> > > infamiliarity with parrot's DOD/GC stuff).
> > >
> > > Would it be possible to illuminate it by explaining how the
> > > following Perl5 code (presumably being executed by Ponie/Parrot)
> > > would ensure that the two destructors are called at the places
> > > marked:
> > >
> > > {
> > > my $ref;
> > > {
> > > my $obj1 = Foo->new(...);
> > > my $obj2 = Foo->new(...);
> > > $ref = $obj1;
> > > } # $obj2->DESTROY called here
> > > # ...
> > > } # $obj1->DESTROY called here
> > > # ...
> >
> > At each of the two end-of-scope braces, a "sweep 0" instruction would
> > be emmited. This performs Dead Object Detection, which at the first
> > "}" detects that $obj2 is dead, and at the second "}" detects that
> > $obj1 is unreachable.
>
> Yeah, I understood that bit. It was all the stuff about lists of
> high-priority and low-priority objects etc that I got lost in.
(For the sake of my fingers, please read any "ntd" as "needing timely
destruction", and "owntd" below as "object which needs timely
destruction.")
Well, *most* of the time, when we reach a "}", *nothing* has gone out of
scope. Or at least, no owntds have gone out of scope.
Thus, on *those* occasions (when nothing ntd has gone out of scope), we
want the "sweep 0" instruction to execute really really fast, not
slowing our interpreter down at all.
When we normally do dead object detection, when we discover an object
which is reachable, which we hadn't previously marked as reachable, we
would just add it to a simple queue -- a linked list. I forget if this
list is a fifo or stack, but it doesn't really matter... the point is,
the order we scan our objects depends soley on the order in which we see
them.
Luke's proposal is that we change to *two* queues -- one queue
containing objects which are believed to be able to reach owntds (this
is the high priority queue), and a second queue for objects which we
don't think are able to reach any owntds (this is the low priority
queue).
*Assuming* that no owntds have gone out of scope, then by scanning the
high priority queue first, we *should* (we hope) be able to (quickly)
mark all of the owntds as being alive (just by scanning the high
priority queue), and then quickly abort the DOD.
> In particular how does it detect that $obj2 should be kept alive at the
> end of the inner block withoput doing a *full* DoD sweep?
ITYM, s/kept alive/destructed/.
Alas, in those situations when an owntd goes out of scope, a full DoD
sweep will be needed.
After sweeping the high priority queue, and discovering there are some
owntds not yet marked as alive, we continue with the low priority queue,
and if they're *still* not all marked as alive, we continue with garbage
collection and firing off of destructors.
But this situation *isn't* the majority case.
> Since I presume that's what the proposal was intended to avoid.
It's intended to speed up the majority case, when no owntds have gone
out of scope, and thus no destructors need be called.
--
$a=24;split//,240513;s/\B/ => /for@@=qw(ac ab bc ba cb ca
);{push(@b,$a),($a-=6)^=1 for 2..$a/6x--$|;print "[EMAIL PROTECTED]
]\n";((6<=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))&&redo;}
