Michael G Schwern wrote:
[snip stuff, including a mention of refcounting and it's
(dis)advantages]
> So Parrot is going with something else. Don't ask me what it is, I
> don't know.
Parrot will do it like Java -- a mark-and-sweep garbage collector --
with the difference that garbage collection will generally happen more
often.
In Java, it happens when you run out of memory, or when someone does
"java.lang.Runtime.getRuntime().gc()". There's no timely destruction,
be cause you'd need to be psychic to know ahead of time when you're
going to run out of memory. And, since gc() isn't especially fast,
calling it often would slow your program down unnecessarily.
In Parrot, it happens when you run out of memory, or any time that a
"sweep" opcode is called. And "sweep" might be called at the end of
every scope, and maybe whenever you undef() a variable, and sometimes
even more often. Thus, chances to clean up objects in Parrot are almost
as frequent as they are in perl5.
> With this other garbage collecting technique its more involved than ref
> counting
Whether it's more involved or less involved depends on from whose point
of view you're looking.
>From the POV of the person implementing the garbage collector, it's more
involved.
>From the POV of the program using the system, it's less involved.
> to guarantee timely destruction as we desire in Perl. Apparently
> someone's figured a way to do it and do it efficiently.
Well... mostly.
As a memory manager, it's certainly more efficient. That is, if you
only call it when you need to free up memory, then on average, it uses
less time than refcounting does.
However, regarding the timely destruction part... this could use some
improvement.
Every time we come to a scope end, we do a garbage collection run. This
is often inefficient. We can sometimes statically determine that no
objects needing timely destruction could possibly have gone out of
scope, and leav out the "sweep" code.
But this still isn't enough.
What we'd like is a way (and there've been a couple proposed) to make it
so that the sweep at the end of scope can *quickly* determine that all
objects needing timely destruction are still alive/reachabe/in-scope,
and abort early (and thus use less time).
--
$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;}
