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 # ... > > It is based on the fact that 90% of the time (or more), all objects > needing timely destruction will be found live. It uses a priority > method to try to find these objects quickly, and ceases if it does. > This behavior is only carried out if the DOD was invoked by C<sweep 0>. > > There is an external list of objects needing timely destruction, which > is not walked by DOD. Each object has a DOD_high_priority_FLAG. Each > time an impatient object is created, its high_priority_FLAG is set. > > As everything is walked, if an object with this flag set is encountered, > whichever thing referenced it also gets the flag set[1]. > > The DOD queue has two segments: high_priority and low_priority. > high_priority is always drained and processed first. When this portion > of the queue is completely drained, the external list of impatient > objects is checked. If every object has been marked live, DOD > terminates (and GC is not allowed to run, because that would result in a > lot of wrongly murdered objects). If there are dead objects in that > list, DOD continues and does a full sweep. > > When an impatient object is destructed, it might be good to reset all > high_priority_FLAGs, except for other impatient objects, so there is > nothing being walked at high priority that doesn't deserve it. > > That's it. The first few times C<sweep 0> is run, it will take just as > long as C<sweep 1>, but the priorities will propogate down to things in > the root set, and it will begin to speed up. And the algorithmic > complexity never exceeds that of a regular sweep[2]. > > Luke > > [1] This probably has to be done when the object is enqueued, not > dequeued. I don't know whether this impacts performance significantly. > See [2]. > > [2] Although a single cycle of the algorithm becomes more complex, so it > will slow things down a little when it's not doing any good. But at the > expense of a little templating, these checks could be eliminated when > the sweep wasn't triggered by C<sweep 0>. -- print+qq&$}$"$/$s$,[EMAIL PROTECTED],$:$.$q$^$,[EMAIL PROTECTED];$.$q$m&if+map{m,^\d{0\,},,${$::{$'}}=chr($"+=$&||1)}q&10m22,42}6:[EMAIL PROTECTED];^2$g3q/s"&=~m*\d\*.*g