Re: Garbage collection (was Re: JWZ on s/Java/Perl/)
James Mastros [EMAIL PROTECTED] wrote:
The idea is [for Larry] to declare "no, it isn't". Otherwise, you have to
do refcounting (or somthing like it) for DESTROY to get called at the right
time if the class (or any superclass) has an AUTOLOAD, which is expensive.
I'm coming in halfway through a thread, which is always dangerous, but...
the above seems to imply a discussion that you only need to do expensive
ref-counting (or whatever) on objects which have a DESTROY method.
However, since you dont know in advance what class(es), if any, a thinngy
will be blessed as, you always have to ref-count (or whatever technique is
chosen) just to be sure:
my $h = {}; $ref1 = \$h; $ref2= \$h; ...
# we havent been ref-counting because $h is isnt an object.
bless $h, some_class_with_a_destroy_method;
# whoops, $h now needs to be properly managed. Anyone remember
# what's pointed at it ???
Re: Garbage collection (was Re: JWZ on s/Java/Perl/)
David Mitchell wrote: James Mastros [EMAIL PROTECTED] wrote: ... do refcounting (or somthing like it) for DESTROY to get called at the right time if the class (or any superclass) has an AUTOLOAD, which is expensive. ... the above seems to imply a discussion that you only need to do expensive ref-counting (or whatever) on objects which have a DESTROY method. However, since you dont know in advance what class(es), if any, a thinngy will be blessed as, you always have to ref-count (or whatever technique is chosen) just to be sure: I agree. Mixing ref-counting and whatever won't work (or will work and will be worse than only ref-counting). Either we stick with ref-counting (and maybe add something for breaking circular references) or we forget about this fallacy of having DESTROY called at a predictable time. Afterall, why do we need DESTROY to get called at the right time? Afterall, Java does live without it, and if Perl is supposed to run on the JVM, we won't have it there anyway! I think with .NET (Microsoft's C# VM) the situation is the same. If resource exhaustion is the problem, I think we can deal with that when we try to allocate a resource and we get an error, then we call the GC explicitly (one or more times if needed) to see if we can free some resources with it. Resource exhaustion would be a rare situation (I think), and doing some expensive treatment when it happens is OK for me. Anyway, that data flow analysis that was being proposed could well be used to `avoid' or `delay' resource exhaustion in some cases. But I don't think any guarantees should be given about when the DESTROY method of an object would be called. Also, I think it would be valid for the programmer to explicitly say ``I would like to DESTROY this object now'', and have the DESTROY method called in that time, even if the memory would be reclaimed only later. The problem I see with this is what if a programmer calls DESTROY on an object that was being used by others. The way I suggest to deal with this is set a flag if the object was already DESTROYed. Then if any other tries to use it, it raises an exception (dies) with a message about ``This object was already DESTROYed.''. This flag could be used also to signal to the GC system that the object already got its DESTROY method called, and it shouldn't be called again. Just an idea, but... - Branden
Re: Garbage collection (was Re: JWZ on s/Java/Perl/)
On Wed, Feb 14, 2001 at 10:12:36AM -0300, Branden wrote: David Mitchell wrote: ... the above seems to imply a discussion that you only need to do expensive ref-counting (or whatever) on objects which have a DESTROY method. However, since you dont know in advance what class(es), if any, a thinngy will be blessed as, you always have to ref-count (or whatever technique is Blast. You are absolutly right, Dave. [snip about DESTORY predictablity not being neccessary] You're probably right about that, Branden. Quite nice, but not neccessary. Also, I think it would be valid for the programmer to explicitly say ``I would like to DESTROY this object now'', I'd think that an extension to delete is in order here. Basicly, delete should DESTROY the arg, change it's value to undef, and trigger a GC that will get rid of the arg. If the arg is a ref, it is /not/ derefed, so you'd oft want to use delete $$foo. being used by others. The way I suggest to deal with this is set a flag if the object was already DESTROYed. Then if any other tries to use it, it raises an exception (dies) with a message about ``This object was already DESTROYed.''. I think an ordinary "attempt to dereference undef" will work. -=- James Mastros -- "All I really want is somebody to curl up with and pretend the world is a safe place." AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
Re: Garbage collection (was Re: JWZ on s/Java/Perl/)
James Mastros wrote: I'd think that an extension to delete is in order here. Basicly, delete should DESTROY the arg, change it's value to undef,... Huh? What delete are you thinking of? This is Perl, not C++. ...and trigger a GC that will get rid of the arg. No. Perl decides for itself when to do GC. -- John Porter You can't keep Perl6 Perl5.
Re: Garbage collection (was Re: JWZ on s/Java/Perl/)
On Wed, Feb 14, 2001 at 09:59:31AM -0500, John Porter wrote: James Mastros wrote: I'd think that an extension to delete is in order here. Basicly, delete should DESTROY the arg, change it's value to undef,... Huh? What delete are you thinking of? This is Perl, not C++. Umm, perldoc -f delete? Come to think of it, this doesn't mesh purticularly well with the current meaning of delete. It does, however, with undef. In fact, it /is/ the current meaning of undef, except for the GC part. And perhaps the GC should be explicit or automatic, but not implicit. ...and trigger a GC that will get rid of the arg. No. Perl decides for itself when to do GC. That's almost certianly a mistake. The programmer often /does/ know the expectations of the end-user better then the interpreter. If the programmer can GC when /he/ wants to, he can do so when the pause will have the least effect. Think of a program that you want to run near-realtime most of the time, but where you have a bit of downtime every now and again. A game comes immedetly to mind. Or, for that matter, a program that spawns an external process that might take a lot of memory, so does a GC before spawning it. (Because otherwise the OS will happily page out your garbage, resulting in massive amounts of unneeded IO.) -=- James Mastros -- "All I really want is somebody to curl up with and pretend the world is a safe place." AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
Re: Garbage collection (was Re: JWZ on s/Java/Perl/)
James Mastros [EMAIL PROTECTED] wrote: [snip about DESTORY predictablity not being neccessary] You're probably right about that, Branden. Quite nice, but not neccessary. Hmm, I'd have to say that predictability is very, *very* nice, and we shouldnt ditch it unless we *really* have to. [ lots of examples of freeing up database connections, locked files etc, not included here because it would involve too much typing :-) ] Dave M.
Re: Garbage collection (was Re: JWZ on s/Java/Perl/)
James Mastros wrote: On Wed, Feb 14, 2001 at 10:12:36AM -0300, Branden wrote: Also, I think it would be valid for the programmer to explicitly say ``I would like to DESTROY this object now'', I'd think that an extension to delete is in order here. Basicly, delete should DESTROY the arg, change it's value to undef, and trigger a GC that will get rid of the arg. Actually, DESTROY has nothing to do with delete or setting a value to undef. Well, yes, they are related, but if that was all that matters, every object could be deleted when I assign a variable to other thing. Delete/set to undef sets the value of a variable, and DESTROY is called when no more variables reference that object. The problem is when objects are shared by many variables. For example: $a = new Object(); $b = $a; ... destroy $a; ## would call $a-DESTROY() ... $b-doSomething();## should die. Note that $b is not undef The problem is that $b has a reference to an object that was already destroyed, right? It has nothing to do with `undef', since $b cannot be undef'ed when I call destroy $a, the object knows nothing about $b, right? And there would be another problem when the GC tries to collect the memory used by the object, because it usually calls DESTROY on collected objects. Calling it for this object would mean calling it twice, what is probably a very wrong thing to do. - Branden
Re: Garbage collection (was Re: JWZ on s/Java/Perl/)
John Porter wrote: James Mastros wrote: I'd think that an extension to delete is in order here. Basicly, delete should DESTROY the arg, change it's value to undef,... Huh? What delete are you thinking of? This is Perl, not C++. Agreed, definitely Perl is not C++. ...and trigger a GC that will get rid of the arg. No. Perl decides for itself when to do GC. Please read the original message I wrote. The reply had only some off-the-context snippets of the original idea. The idea is to *allow* a programmer to explicitly destroy an object, for better (and sooner) resource disposal. The programmer wouldn't have to do it (and wouldn't do it most the time), but if he knows he uses many resources and he would like to be nice, he *could* do it (not meaning he would have to do it either...). - Branden
Re: Garbage collection (was Re: JWZ on s/Java/Perl/)
James Mastros wrote: On Wed, Feb 14, 2001 at 09:59:31AM -0500, John Porter wrote: Huh? What delete are you thinking of? This is Perl, not C++. Umm, perldoc -f delete? Come to think of it, this doesn't mesh purticularly well with the current meaning of delete. It does, however, with undef. In fact, it /is/ the current meaning of undef, except for the GC part. And perhaps the GC should be explicit or automatic, but not implicit. As I wrote in the last post, this isn't what I'm talking about. I'm talking about destroying the object before the GC does. ...and trigger a GC that will get rid of the arg. No. Perl decides for itself when to do GC. That's almost certianly a mistake. Yeah, what about a nasty module that decides not to call the GC and blow your memory??? That's IMO the best thing about programming in Perl compared to C: not having to keep track of the memory!!! RFC 28!!! The programmer often /does/ know the expectations of the end-user better then the interpreter. We must not count on the programmer for almost nothing. Most (Perl) programmers want to forget about housekeeping details and expect Perl to do the magic for them. And I think they're right! If Perl can do it, why would they bother? Why write more code to do things Perl can do for you? Why write C if you can write Perl? If the programmer can GC when /he/ wants to, he can do so when the pause will have the least effect. I agree the programmer should have how to explicitly call the GC, but that wouldn't be required from him. Think of a program that you want to run near-realtime most of the time, Write C. With no GC below it. Probably, with no OS (or a realtime one) below it. but where you have a bit of downtime every now and again. A game comes immedetly to mind. Even if you want to write games in Perl (I would definitely want to), you should use C extensions to do the screen update (at least for speed...), and those would definitely not be constrained to GC pauses. Or, for that matter, a program that spawns an external process that might take a lot of memory, so does a GC before spawning it. (Because otherwise the OS will happily page out your garbage, resulting in massive amounts of unneeded IO.) Call the GC explicitly before, no need to control when *not* to call it for this, as you were suggesting. Serious, man. Not having a implicit GC is not having GC at all! And as Perl should be Perl, it should keep collecting our garbage as we produce it! -=- James Mastros -- "All I really want is somebody to curl up with and pretend the world is a safe place." AIM: theorbtwo homepage: http://www.rtweb.net/theorb/ - Branden
Re: Garbage collection (was Re: JWZ on s/Java/Perl/)
[[ reply to this goes only to -internals ]] Dan Sugalski wrote: *) People like it Well, if people liking it is the only reason (either is the only on or appears 3 times in a 5 item list, what is pretty much the same to me ;-) [... the only reason] to add a feature to Perl, we'll probably end much more bloated than we're now, IMHO. *) Scarce external resources (files, DB handles, whatever) don't get unnecessarily used Unless there's a way to do it predictably without impacting programs that don't depend so much on quick freeing of external resources, I don't believe it's worth. *) Saves having to write explicit cleanup code yourself You wouldn't have to, you only would be able to, if you like it. If you're writing an application that would possibly open too many files, you'd probably want to destroy their handles ASAP. OTOH, if you're writing an application that only opens one file and does a lot of processing over it, you simply wouldn't care and let it be freed whenever the GC collects its memory. At 10:12 AM 2/14/2001 -0300, Branden wrote: If resource exhaustion is the problem, I think we can deal with that when we try to allocate a resource and we get an error, then we call the GC explicitly (one or more times if needed) to see if we can free some resources with it. Resource exhaustion would be a rare situation (I think), and doing some expensive treatment when it happens is OK for me. The point of DESROY isn't resource exhaustion per se, at least not anything the garbage collector will care about, since it only cares about memory. Well, I thought DESTROY frees open files, database connections, OS locks, etc. Aren't those what cause resource exhaustion? Also, I think it would be valid for the programmer to explicitly say ``I would like to DESTROY this object now'', and have the DESTROY method called in that time, even if the memory would be reclaimed only later. So you undef your object reference. If the object doesn't go away, it means that something else probably still has a handle on it somewhere. I thought that was the whole problem with ``not predictable stuff'': undefing the variable, no other variable references the object, and it's still there, it doesn't get destroyed. Plus there's nothing stopping you from having $obj-DESTROY in your own code, though it may be inadvisable. It is (mainly) inadvisable because: 1. GC will call DESTROY when it collects the memory, so DESTROY would get called twice, which is VERY BAD. 2. If I call DESTROY on an object, it would still be a (valid) object after the call, so that if I call some other method, it will succeed. But that shouldn't happen, since the object was DESTROYed, right? That's exactly what I propose. Having something that, when called with an object as parameter, would call the object's DESTROY, and would flag the object someway so that GC doesn't call DESTROY on it when collecting the memory and that every other attempt to call a method on the object raises an exception that makes it clear what happened (ie. ``Method call on already destroyed object''), so that debugging is `possible' in this semantic. - Branden
Re: Garbage collection (was Re: JWZ on s/Java/Perl/)
On Wed, Feb 14, 2001 at 01:43:22PM -0300, Branden wrote: As I wrote in the last post, this isn't what I'm talking about. I'm talking about destroying the object before the GC does. Yah, so am I. I'm just saying that after the object is destroyed, don't keep it around. Yeah, what about a nasty module that decides not to call the GC and blow your memory??? That's IMO the best thing about programming in Perl compared to C: not having to keep track of the memory!!! RFC 28!!! Whoh! I never meant to say that Perl shouldn't automaticly do GC as it feels like it. Simply that you should be able to explicitly garbage-collect if you want to. (It's arguable that you should be able to disable automatic GC. In any case, it should be tunable, so disabling it is just an _extreme_ tune.) We must not count on the programmer for almost nothing. Watch your double-negitives. Writing calmly helps. If the programmer can GC when /he/ wants to, he can do so when the pause will have the least effect. I agree the programmer should have how to explicitly call the GC, but that wouldn't be required from him. OK then, we're all in agreement. Think of a program that you want to run near-realtime most of the time, Write C. With no GC below it. Probably, with no OS (or a realtime one) below it. Sorry. Near-realtime is apparently a much more restrictive word then I wanted. but where you have a bit of downtime every now and again. A game comes immedetly to mind. Even if you want to write games in Perl (I would definitely want to), you should use C extensions to do the screen update (at least for speed...), and those would definitely not be constrained to GC pauses. True, but I probably wouldn't for the event loop, and certianly not for the tick function. (At least some of the tick functions.) Call the GC explicitly before, no need to control when *not* to call it for this, as you were suggesting. Serious, man. Not having a implicit GC is not having GC at all! And as Perl should be Perl, it should keep collecting our garbage as we produce it! Sorry. I should have explained my wording more carefuly. I see three different types of triggers: 1) Explicit -- A call to garbage::collect or somesuch. 2) Implicit -- Certian program-execution events implicitly do a GC run when encountered. For example, you could say we do this now -- we garbage-collect every time a scope exits. What I was suggesting above is that when a 1-arg undef is encountered, implicitly GC. 3) Automatic -- Certian runtime events, not directly (or obviously) related to the flow of execution, like when the number of SVs created or the amount of memory allocated since the last GC run exced a certian critical value. (I /think/ a dictionary would agree with me, but I'm not about to get pissy and look them up.) I was saying that we should do 1 and 3, but not 2. -=- James Mastros
Re: Garbage collection (was Re: JWZ on s/Java/Perl/)
On Wed, Feb 14, 2001 at 01:25:26PM -0300, Branden wrote: The problem is when objects are shared by many variables. For example: $a = new Object(); $b = $a; ... destroy $a; ## would call $a-DESTROY() ... $b-doSomething();## should die. Note that $b is not undef Hmm? (Assuming destroy() autoderefs.) destory $a would call %$a-DESTORY (assumption of hash for example), and remove %$a from the symbol-table/otherwise make it nonexistant. Then $b-doSomthing() will fail because it's a ref to undef. And there would be another problem when the GC tries to collect the memory used by the object, because it usually calls DESTROY on collected objects. Calling it for this object would mean calling it twice, what is probably a very wrong thing to do. Oh, I rather assumed that there would be a "invalid" marker of some sort. It's neccessary (I think) for a pool, which I assumed. Bad James, bad. -=- James Mastros -- "All I really want is somebody to curl up with and pretend the world is a safe place." AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
Re: Garbage collection (was Re: JWZ on s/Java/Perl/)
Branden wrote: John Porter wrote: ...and trigger a GC that will get rid of the arg. No. Perl decides for itself when to do GC. The idea is to *allow* a programmer to explicitly destroy an object, for better (and sooner) resource disposal. The programmer wouldn't have to do it (and wouldn't do it most the time), but if he knows he uses many resources and he would like to be nice, he *could* do it (not meaning he would have to do it either...). Obviously "freeing" an object marks it as GC'able. It should *NOT* "trigger" a GC. If the user wants to explicitly cause GC (and the language allows), then she can put that in too. Freeing should NOT trigger a GC; although of course it's a logical point at which perl may decide to do a GC anyway. -- John Porter
Re: Garbage collection (was Re: JWZ on s/Java/Perl/)
On Wed, Feb 14, 2001 at 01:30:03PM -0300, Branden wrote: John Porter wrote: James Mastros wrote: I'd think that an extension to delete is in order here. Basicly, delete should DESTROY the arg, change it's value to undef,... Huh? What delete are you thinking of? This is Perl, not C++. Agreed, definitely Perl is not C++. ...and trigger a GC that will get rid of the arg. No. Perl decides for itself when to do GC. Please read the original message I wrote. The reply had only some off-the-context snippets of the original idea. The idea is to *allow* a programmer to explicitly destroy an object, for better (and sooner) resource disposal. The programmer wouldn't have to do it (and wouldn't do it most the time), but if he knows he uses many resources and he would like to be nice, he *could* do it (not meaning he would have to do it either...). There is no need to add that to Perl, as Perl already has a function for that: Cundef $obj;. Naturally, that won't cause DESTROY to be run if there are other references to it, but then, I don't see what an "object destruction" is supposed to do if there are still references to the object left. Nor is this wanted behaviour. All the programmer needs to do for sooner resource disposal it to let his references go out of scope when no longer needed. Abigail
Re: Garbage collection (was Re: JWZ on s/Java/Perl/)
On Wed, Feb 14, 2001 at 02:10:59PM -0300, Branden wrote: Dan Sugalski wrote: Plus there's nothing stopping you from having $obj-DESTROY in your own code, though it may be inadvisable. It is (mainly) inadvisable because: 1. GC will call DESTROY when it collects the memory, so DESTROY would get called twice, which is VERY BAD. *blink* It is? Why? I grant you it isn't the clearest way of programming, but "VERY BAD"? 2. If I call DESTROY on an object, it would still be a (valid) object after the call, so that if I call some other method, it will succeed. But that shouldn't happen, since the object was DESTROYed, right? Eh, you don't understand DESTROY. DESTROY doesn't destroy an object. Perl, the language, does not have the concept of destroying objects. DESTROY is just a call back from perl, the binary, that everyone is done with the object, and it's about to go away. DESTROY might be called around the same time its memory is being reclaimed, but from a language perspective, all this memory dealing is non-existant. DESTROY is a language thing, garbage collection an implementation detail of the run-time, purely necessary because of the limited physical model of the abstract machine Perl is supposed to run on. Their perceived relation is merely a coincidence. Even if you have a bucket load of memory and there was a way of telling Perl not to bother with garbage collection, DESTROY should still be called. Being able to separate DESTROY and garbage collection is a feature. ;-) Abigail
Re: Garbage collection (was Re: JWZ on s/Java/Perl/)
At 07:44 PM 2/14/2001 +, Simon Cozens wrote:
On Wed, Feb 14, 2001 at 08:32:41PM +0100, [EMAIL PROTECTED] wrote:
DESTROY would get called twice, which is VERY BAD.
*blink*
It is? Why?
I grant you it isn't the clearest way of programming, but "VERY BAD"?
package NuclearReactor::CoolingRod;
sub new {
Reactor-decrease_core_temperature();
bless {}, shift
}
sub DESTROY {
Reactor-increase_core_temperature();
}
Time to snag some bits from the Java license agreement.
"...this software is not meant for...aircraft control...nuclear
reactors...medical equipment..."
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Garbage collection (was Re: JWZ on s/Java/Perl/)
On Tue, Feb 13, 2001 at 10:32:26AM -0800, Peter Scott wrote:
At 01:16 PM 2/13/01 -0500, James Mastros wrote:
On Tue, Feb 13, 2001 at 01:09:11PM -0500, John Porter wrote:
Certainly AUTOLOAD gets
called if DESTROY is called but not defined ... just
like any other method.
The idea is [for Larry] to declare "no, it isn't". Otherwise, you have to
do refcounting (or somthing like it) for DESTROY to get called at the right
time if the class (or any superclass) has an AUTOLOAD, which is expensive.
Perhaps you could declare, but not define, DESTROY to have AUTOLOAD called
for DESTROY, and have DESTROY called as soon as the last ref goes out of
scope. (IE have a sub DESTROY; line.)
I like this idea, and would have suggested it except that James Mastros got
there first. It is a special case "no AUTOLOAD of DESTROY by default"
but it might be quite a win.
This may be a naive question, but what is the benefit - aside from
consistency, and we don't need to rehash the litany on that - to AUTOLOAD
getting called for DESTROY? I've never actually seen any code that makes
use of it. I have grown somewhat tired of writing, and teaching, "return
if $AUTOLOAD =~ /:DESTROY$/", however.
Doesn't
sub DESTROY {}
have the same effect but with less typing?
Nicholas Clark
Re: Garbage collection (was Re: JWZ on s/Java/Perl/)
At 10:32 AM 2/13/2001 -0800, Peter Scott wrote: At 01:16 PM 2/13/01 -0500, James Mastros wrote: On Tue, Feb 13, 2001 at 01:09:11PM -0500, John Porter wrote: Certainly AUTOLOAD gets called if DESTROY is called but not defined ... just like any other method. The idea is [for Larry] to declare "no, it isn't". Otherwise, you have to do refcounting (or somthing like it) for DESTROY to get called at the right time if the class (or any superclass) has an AUTOLOAD, which is expensive. Perhaps you could declare, but not define, DESTROY to have AUTOLOAD called for DESTROY, and have DESTROY called as soon as the last ref goes out of scope. (IE have a sub DESTROY; line.) This may be a naive question, but what is the benefit - aside from consistency, and we don't need to rehash the litany on that - to AUTOLOAD getting called for DESTROY? I've never actually seen any code that makes use of it. I have grown somewhat tired of writing, and teaching, "return if $AUTOLOAD =~ /:DESTROY$/", however. I have no idea. It's legal, though, so unless it's declared illegal (which is fine with me) it needs to be supported. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Garbage collection (was Re: JWZ on s/Java/Perl/)
Sam Tregar wrote:
On Mon, 12 Feb 2001, Dan Sugalski wrote:
Also, the vast majority of perl variables have no finalization
attached to them.
That's true, but without static typing don't you have to treat them as if
they did? At the very least you need to do a "is it an object with a
DESTROY" check at block boundaries.
Only because the type is static, I don't think they wouldn't be references.
my $foo = new Baz();
{
my Baz $bar = $foo;
};
# DESTROY should be called on the object ref'd by $bar ?
# It's still ref'd on $foo !!!
- Branden
Re: Garbage collection (was Re: JWZ on s/Java/Perl/)
At 10:38 AM 2/12/2001 -0500, Sam Tregar wrote: On Mon, 12 Feb 2001, Dan Sugalski wrote: Perl needs some level of tracking for objects with finalization attached to them. Full refcounting isn't required, however. I think I've heard you state that before. Can you be more specific? What alternate system do you have in mind? Is this just wishful thinking? This isn't just wishful thinking, no. Also, the vast majority of perl variables have no finalization attached to them. That's true, but without static typing don't you have to treat them as if they did? At the very least you need to do a "is it an object with a DESTROY" check at block boundaries. Code flow analysis can get an awful lot. Some help from the runtime will get the rest. It's reasonably obvious (which is to say "cheap") which variables aren't involved with anything finalizable. I do wish people would get garbage collection and finalization split in their minds. They are two separate things which can, and will, be dealt with separately. 2x the penalty, right? Instead of a speed increase we carry the burden of ref-counting in addition to the overhead of an alternate system. Nowhere near double the penalty. We only need to deal with refcounts when references are actually taken, assigned, or destroyed. That's a rare occurrence, relatively speaking. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Garbage collection (was Re: JWZ on s/Java/Perl/)
On Mon, 12 Feb 2001, Dan Sugalski wrote: I think I've heard you state that before. Can you be more specific? What alternate system do you have in mind? Is this just wishful thinking? This isn't just wishful thinking, no. You picked the easy one. Maybe you can get back to the other two when you have more time? Code flow analysis can get an awful lot. Some help from the runtime will get the rest. Do you mean that you can tell from a compile-time flow-control graph exactly when DESTROY needs to be called for every object? What kind of help from the runtime? Reference counting help? It's reasonably obvious (which is to say "cheap") which variables aren't involved with anything finalizable. Probably a simple bit check and branch. Is that cheap? I guess it must be. Nowhere near double the penalty. We only need to deal with refcounts when references are actually taken, assigned, or destroyed. That's a rare occurrence, relatively speaking. Perhaps. It's not rare in OO Perl which is coincidentally one area in serious need of a speedup. I suppose I'm warped by my own experience - all the code I see every day is filled with references and objects. That's probably not the average case Perl usage. -sam
Re: Garbage collection (was Re: JWZ on s/Java/Perl/)
On Mon, 12 Feb 2001 13:29:21 -0500, Dan Sugalski [EMAIL PROTECTED] wrote: At 10:38 AM 2/12/2001 -0500, Sam Tregar wrote: On Mon, 12 Feb 2001, Dan Sugalski wrote: Perl needs some level of tracking for objects with finalization attached to them. Full refcounting isn't required, however. I think I've heard you state that before. Can you be more specific? What alternate system do you have in mind? Is this just wishful thinking? This isn't just wishful thinking, no. You've been asked multiple times to share how this is supposed to work. Is there a specific reason you don't want to talk about it? As far as I can see, there is only *one* reason to go to partial refcounting: it saves some memory. But beyond that, it is slower, more complicated and shares all the disadvantages of refcounting. Why don't you want to just keep the current scheme and avoid having to think about mark-and-sweep altogether if you agree that at least partial refcounting will still be needed? -Jan
Re: Garbage collection (was Re: JWZ on s/Java/Perl/)
On Mon, Feb 12, 2001 at 01:33:52PM -0500, Sam Tregar wrote: Perhaps. It's not rare in OO Perl which is coincidentally one area in serious need of a speedup. I suppose I'm warped by my own experience - all the code I see every day is filled with references and objects. That's probably not the average case Perl usage. Possibly not. People keep saying that OO is slow, but there are no good examples of OO code to benchmark. perl5-porters would happily receive sample code that hammers perl5 so that it can be profiled to find where in the perl5 source the bottleneck is I suspect that perlbench would also not object to OO code for benchmarking. Nicholas Clark
Re: Garbage collection (was Re: JWZ on s/Java/Perl/)
On Mon, 12 Feb 2001 13:33:52 -0500 (EST), Sam Tregar [EMAIL PROTECTED] wrote: It's reasonably obvious (which is to say "cheap") which variables aren't involved with anything finalizable. Probably a simple bit check and branch. Is that cheap? I guess it must be. Yes, but incrementing the reference count is a single inc instruction too, and todays CPUs are optimized to do those fast too. I doubt a memory fetch, bit test and jump instruction is much fast than an memory increment. Nowhere near double the penalty. We only need to deal with refcounts when references are actually taken, assigned, or destroyed. That's a rare occurrence, relatively speaking. Perhaps. It's not rare in OO Perl which is coincidentally one area in serious need of a speedup. I suppose I'm warped by my own experience - all the code I see every day is filled with references and objects. That's probably not the average case Perl usage. I don't think so. Most Perl code nowadays makes heavy use of modules and man modules are written in OO fashion. But reference counting is *not* what makes Perl method calls so slow. -Jan
Re: Garbage collection (was Re: JWZ on s/Java/Perl/)
At 01:33 PM 2/12/2001 -0500, Sam Tregar wrote:
On Mon, 12 Feb 2001, Dan Sugalski wrote:
I think I've heard you state that before. Can you be more specific? What
alternate system do you have in mind? Is this just wishful thinking?
This isn't just wishful thinking, no.
You picked the easy one. Maybe you can get back to the other two when you
have more time?
That is the plan, yes.
Code flow analysis can get an awful lot. Some help from the runtime will
get the rest.
Do you mean that you can tell from a compile-time flow-control graph
exactly when DESTROY needs to be called for every object? What kind of
help from the runtime? Reference counting help?
Every object? No. Most objects? Yes. For this code:
{
my $foo = new Some::Thing;
$foo-whatever;
}
it's pretty obvious in many cases where $foo needs finalization. (Those
cases where it isn't include the ones where the whatever method gets
redefined at runtime, or where there's an eval/do/require without a "static
assumptions OK" flag set somewhere)
Runtime support for this would include things like the assign vtable method
for blessed references to finalizable things adding an entry to the "check
me for cleanup or hoist me out" list for the home block of the variable
getting the reference assigned to.
It's reasonably obvious (which is to say "cheap") which variables aren't
involved with anything finalizable.
Probably a simple bit check and branch. Is that cheap? I guess it must
be.
Nowhere near double the penalty. We only need to deal with refcounts when
references are actually taken, assigned, or destroyed. That's a rare
occurrence, relatively speaking.
Perhaps. It's not rare in OO Perl which is coincidentally one area in
serious need of a speedup. I suppose I'm warped by my own experience -
all the code I see every day is filled with references and objects.
That's probably not the average case Perl usage.
It *is* rare in OO perl, though. How many of the variables you use are
really, truly in need of finalization? .1 percent? .01 percent? Less? Don't
forget that you need to count every scalar in every array or hash, and
every iteration over a block with my declarations. Perl churns through a
*lot* of SV pointers in its average run, and most of them aren't in need of
finalization.
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Garbage collection (was Re: JWZ on s/Java/Perl/)
Dan Sugalski [EMAIL PROTECTED] writes: At 10:38 AM 2/12/2001 -0500, Sam Tregar wrote: On Mon, 12 Feb 2001, Dan Sugalski wrote: Perl needs some level of tracking for objects with finalization attached to them. Full refcounting isn't required, however. I think I've heard you state that before. Can you be more specific? What alternate system do you have in mind? Is this just wishful thinking? This isn't just wishful thinking, no. Also, the vast majority of perl variables have no finalization attached to them. That's true, but without static typing don't you have to treat them as if they did? At the very least you need to do a "is it an object with a DESTROY" check at block boundaries. Code flow analysis can get an awful lot. Some help from the runtime will get the rest. It's reasonably obvious (which is to say "cheap") which variables aren't involved with anything finalizable. Remember too that right now we don't properly finalize everything as quickly as we should in the cases where stuff is caught up in circular references. We don't need to be perfect, but we do need to be predictable. -- Piers
Re: Garbage collection (was Re: JWZ on s/Java/Perl/)
At 09:08 PM 2/12/2001 +, Piers Cawley wrote: Dan Sugalski [EMAIL PROTECTED] writes: At 10:38 AM 2/12/2001 -0500, Sam Tregar wrote: On Mon, 12 Feb 2001, Dan Sugalski wrote: Perl needs some level of tracking for objects with finalization attached to them. Full refcounting isn't required, however. I think I've heard you state that before. Can you be more specific? What alternate system do you have in mind? Is this just wishful thinking? This isn't just wishful thinking, no. Also, the vast majority of perl variables have no finalization attached to them. That's true, but without static typing don't you have to treat them as if they did? At the very least you need to do a "is it an object with a DESTROY" check at block boundaries. Code flow analysis can get an awful lot. Some help from the runtime will get the rest. It's reasonably obvious (which is to say "cheap") which variables aren't involved with anything finalizable. Remember too that right now we don't properly finalize everything as quickly as we should in the cases where stuff is caught up in circular references. We don't need to be perfect, but we do need to be predictable. Yep, that's another issue, and one I keep forgetting about, though the fact that we don't do predictable finalization on some objects isn't a good reason to not do it for any of them. I really don't want to guarantee predictable end-of-block cleanup, though, since that means a potentially expensive GC run more often than we might otherwise do. One more thing for the GC PDD, I think. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Garbage collection (was Re: JWZ on s/Java/Perl/)
On Mon, 12 Feb 2001 16:28:00 -0500, Dan Sugalski [EMAIL PROTECTED] wrote: Yep, that's another issue, and one I keep forgetting about, though the fact that we don't do predictable finalization on some objects isn't a good Yes, I know I promised to shut up until you come up with a spec, but there is one thing that irritates me: Could you guys please use "destruction" or "cleanup" as the term for the end-of-scope processing (see e.g. C++). Finalization is used everywhere else to mean: called by GC before the memory is released (see e.g Java/C#). Thanks, -Jan
Re: Garbage collection (was Re: JWZ on s/Java/Perl/)
At 01:44 PM 2/12/2001 -0800, Jan Dubois wrote: On Mon, 12 Feb 2001 16:28:00 -0500, Dan Sugalski [EMAIL PROTECTED] wrote: Yep, that's another issue, and one I keep forgetting about, though the fact that we don't do predictable finalization on some objects isn't a good Yes, I know I promised to shut up until you come up with a spec, but there is one thing that irritates me: Could you guys please use "destruction" or "cleanup" as the term for the end-of-scope processing (see e.g. C++). Finalization is used everywhere else to mean: called by GC before the memory is released (see e.g Java/C#). Correct terminology's important. Destruction it is. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Garbage collection (was Re: JWZ on s/Java/Perl/)
At 10:46 AM 2/12/2001 -0800, Jan Dubois wrote: On Mon, 12 Feb 2001 13:29:21 -0500, Dan Sugalski [EMAIL PROTECTED] wrote: At 10:38 AM 2/12/2001 -0500, Sam Tregar wrote: On Mon, 12 Feb 2001, Dan Sugalski wrote: Perl needs some level of tracking for objects with finalization attached to them. Full refcounting isn't required, however. I think I've heard you state that before. Can you be more specific? What alternate system do you have in mind? Is this just wishful thinking? This isn't just wishful thinking, no. You've been asked multiple times to share how this is supposed to work. Is there a specific reason you don't want to talk about it? I do want to talk about it. It just hasn't been at the top of the heap of things that need discussing, and I don't really have time right now, unfortunately. It's also an internals issue, not a language issue. (I've set followups appropriately) The only thing that language really cares about is deterministic destruction, and it's arguable whether that's a language issue. (And no, I'm not going to argue it. I don't really care one way or the other at the moment) As far as I can see, there is only *one* reason to go to partial refcounting: it saves some memory. But beyond that, it is slower, more complicated and shares all the disadvantages of refcounting. Why don't you want to just keep the current scheme and avoid having to think about mark-and-sweep altogether if you agree that at least partial refcounting will still be needed? If you haven't already gone and read up on various garbage collectors, I'd recommend you do. Folks more clever than I am have already dealt with this--refcounting in general isn't necessary, and in those cases where it is needed, it doesn't have to be full refcounting. Bottom line is that most variables in perl don't need any finalization at all, and those that do don't necessarily need refcounting. (Though I'll grant that the alternatives I can think of may be more expensive than refcounting, but I've not put much thought into it) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Garbage collection (was Re: JWZ on s/Java/Perl/)
At 15:37 12/02/2001 -0500, Dan Sugalski wrote: It *is* rare in OO perl, though. How many of the variables you use are really, truly in need of finalization? .1 percent? .01 percent? Less? Don't forget that you need to count every scalar in every array or hash, and every iteration over a block with my declarations. Perl churns through a *lot* of SV pointers in its average run, and most of them aren't in need of finalization. Couldn't we simply (for non-implementer values of simply) provide a way for people to ask for finalization on an object ? Given that most of the time it isn't needed, it wouldn't be too much of a burden for programmers to have to write i_want_some_finalization($object, [finalization params]) ? That would avoid burdening Perl with more dwimity. Dwimity's cool but it usually has consequences and costs, and those ought to be balanced against what it costs not to have it. just my E0.02, -- robin b. There's too much blood in my caffeine system.
Re: Garbage collection (was Re: JWZ on s/Java/Perl/)
At 11:28 PM 2/12/2001 +0100, Robin Berjon wrote: At 15:37 12/02/2001 -0500, Dan Sugalski wrote: It *is* rare in OO perl, though. How many of the variables you use are really, truly in need of finalization? .1 percent? .01 percent? Less? Don't forget that you need to count every scalar in every array or hash, and every iteration over a block with my declarations. Perl churns through a *lot* of SV pointers in its average run, and most of them aren't in need of finalization. Couldn't we simply (for non-implementer values of simply) provide a way for people to ask for finalization on an object ? Given that most of the time it isn't needed, it wouldn't be too much of a burden for programmers to have to write i_want_some_finalization($object, [finalization params]) ? Sure. Y'know, maybe we could even have a sub with a special name! Maybe... DESTROY? :) Seriously, I presume Larry will want perl 6 to follow perl 5's lead and use the DESTROY sub to indicate that an object should be actively (rather than passively) trashed when the interpreter is sure the object is unused. Adding something like: package foo; use attrs qw(cleanup_sub); would be nice, but I don't know that he'll go for it. (Though it's the only way I can think of to avoid AUTOLOAD being considered a potential destructor) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Garbage collection (was Re: JWZ on s/Java/Perl/)
At 17:33 12/02/2001 -0500, Dan Sugalski wrote: At 11:28 PM 2/12/2001 +0100, Robin Berjon wrote: Couldn't we simply (for non-implementer values of simply) provide a way for people to ask for finalization on an object ? Given that most of the time it isn't needed, it wouldn't be too much of a burden for programmers to have to write i_want_some_finalization($object, [finalization params]) ? Sure. Y'know, maybe we could even have a sub with a special name! Maybe... DESTROY? :) Yes, I'm vaguely aware of that possibility :) I believe I misexpressed myself. What I meant was re non-refcount GC and predictability of destruction. If the author wanted refcount triggered destruction for a given object he'd say so explicitly. That would make it easy to separate the objects that require deterministic destruction from those that can be left to the more sophisticated GC. Adding something like: package foo; use attrs qw(cleanup_sub); would be nice, but I don't know that he'll go for it. (Though it's the only way I can think of to avoid AUTOLOAD being considered a potential destructor) Yes that would be nice indeed. -- robin b. You can tune a piano, but you can't tuna fish.
Re: Garbage collection (was Re: JWZ on s/Java/Perl/)
On Mon, Feb 12, 2001 at 05:33:05PM -0500, Dan Sugalski wrote: package foo; use attrs qw(cleanup_sub); would be nice, but I don't know that he'll go for it. (Though it's the only way I can think of to avoid AUTOLOAD being considered a potential destructor) Fiat? It's pretty hard (for me) to think of when you'd want an AUTOLOADed DESTROY, since if you create /any/ objects of the class, DESTROY will be called. "It isn't possible to AUTOLOAD DESTROY." --perlmem(6) -=- James Mastros -- "All I really want is somebody to curl up with and pretend the world is a safe place." AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
Re: Garbage collection (was Re: JWZ on s/Java/Perl/)
On Fri, 09 Feb 2001 13:19:36 -0500, Dan Sugalski [EMAIL PROTECTED] wrote:
Almost all refcounting schemes are messy. That's one of its problems. A
mark and sweep GC system tends to be less prone to leaks because of program
bugs, and when it *does* leak, the leaks tend to be large. Plus the code to
do the GC work is very localized, which tends not to be the case in
refcounting schemes.
Going to a more advanced garbage collection scheme certainly isn't a
universal panacea--mark and sweep in perl 6 will *not* bring about world
peace or anything. It will (hopefully) make our lives easier, though.
I currently don't have much time to follow the perl6 discussions, so I
might have missed this, but I have some questions about abandoning
reference counts for Perl internals. When I reimplemented some of the
Perl guts in C# last year for the 'Perl for .NET" research project, I
tried to get rid of reference counting because the runtime already
provides a generational garbage collection scheme.
However, I couldn't solve the problem of "deterministic destruction
behavior": Currently Perl will call DESTROY on any object as soon as the
last reference to it goes out of scope. This becomes important if the
object own scarce external resources (e.g. file handles or database
connections) that are only freed during DESTROY. Postponing DESTROY until
an indeterminate time in the future can lead to program failures due to
resource exhaustion.
The second problem is destruction order: With reference counts you can
have a dependency graph between objects. Without them destruction can
only appear in random order, which sometimes is a problem: You may have a
database connection and a recordset. The recordset may need to be
DESTROYed first because it may contain unsaved data that still needs to be
written back to the database.
I've been discussing this with Sarathy multiple times over the last year,
and he insists that relying on DESTROY for resource cleanup is bad style
and shouldn't be done anyways. But always explicitly calling e.g. Close()
or whatever is pretty messy at the application level: you have to use
eval{} blocks all over the place to guarantee calling Close() even when
something else blows up.
As an implementer I most definitely see the advantages of giving up
deterministic destruction behavior to random sequences of finalizer calls.
But as a Perl programmer I loathe the additional complexity for my Perl
programs to make them robust. There is a reason memory allocation isn't
exposed to the user either. :-)
Have these issues been discussed somewhere for Perl6? If yes, could you
point me to that discussion?
-Jan
Re: Garbage collection (was Re: JWZ on s/Java/Perl/)
On Sunday 11 February 2001 19:08, Jan Dubois wrote: However, I couldn't solve the problem of "deterministic destruction behavior": Currently Perl will call DESTROY on any object as soon as the last reference to it goes out of scope. This becomes important if the object own scarce external resources (e.g. file handles or database connections) that are only freed during DESTROY. Postponing DESTROY until an indeterminate time in the future can lead to program failures due to resource exhaustion. But doesn't resource exhaustion usually trigger garbage collection and resource reallocation? (Not that this addresses the remainder of your post.) -- Bryan C. Warnock bwarnock@(gtemail.net|capita.com)
Re: Garbage collection (was Re: JWZ on s/Java/Perl/)
On Sun, 11 Feb 2001 21:11:09 -0500, "Bryan C. Warnock" [EMAIL PROTECTED] wrote: On Sunday 11 February 2001 19:08, Jan Dubois wrote: However, I couldn't solve the problem of "deterministic destruction behavior": Currently Perl will call DESTROY on any object as soon as the last reference to it goes out of scope. This becomes important if the object own scarce external resources (e.g. file handles or database connections) that are only freed during DESTROY. Postponing DESTROY until an indeterminate time in the future can lead to program failures due to resource exhaustion. But doesn't resource exhaustion usually trigger garbage collection and resource reallocation? (Not that this addresses the remainder of your post.) Not necessarily; you would have to implement it that way: When you try to open a file and you don't succeed, you run the garbage collector and try again. But what happens in the case of XS code: some external library tries to open a file and gets a failure. How would it trigger a GC in the Perl internals? It wouldn't know a thing that it had been embedded in a Perl app. This scheme would only work if *all* resources including memory and garbage collection are handled by the OS (or at least by a virtual machine like JVM or .NET runtime). But this still doesn't solve the destruction order problem. -Jan
Garbage collection (was Re: JWZ on s/Java/Perl/)
At 12:06 PM 2/9/2001 -0500, Ken Fox wrote:
Branden wrote:
I actually don't understand how traversing a graph can be faster than
incrementing/decrementing/testing for zero on a refcount.
There are two main reasons advanced garbage collectors are fast:
1. Cheap allocations. Most fast collectors have a one or two
instruction malloc. In C it looks like this:
void *malloc(size) { void *obj = heap; heap += size; return obj; }
It's easier to do alignments in a macro layer above the allocator
so the allocator doesn't have to constantly re-align to address
boundaries. There is basically no difference between the performance
of heap and stack allocations with a good collector.
This is definitely very true. It cuts out the overhead of free as well,
since you don't have to free any data (perl pays this with realloc a lot,
since realloc's a malloc, copy, and free). Plus there's no need to mess
with any sort of 'allocated memory' list, which malloc and free currently
need to keep so they don't leak memory.
2. Work proportional to live data, not total data. This is hard to
believe for a C programmer, but good garbage collectors don't have
to "free" every allocation -- they just have to preserve the live,
or reachable, data. Some researchers have estimated that 90% or
more of all allocated data dies (becomes unreachable) before the
next collection. A ref count system has to work on every object,
but smarter collectors only work on 10% of the objects.
As is this. (Perl can generate a lot of garbage if you're messing around
with strings and arrays a lot)
Also, one thing people forget is that manipulating reference counts can get
expensive. It doesn't seem like much--an integer increment or decrement
here or there. No big deal, right? Well, that cost tends to add up after a
while. Its paid in lots of tiny little pieces rather than in a few big
chunks, but the total time taken by it is larger.
It's also possible that by tossing refcounts we can shrink down the size of
a perl variable structure (though I know it's not that way now) or at least
move the GC field to the end, where it's less likely to be loaded. Most
fast processors these days fetch data into cache in 8 or 16 byte chunks, so
moving the GC field outside of the active chunk area means we won't be
loading in dead data (okay, it's only resting!) every time we access a
variable. There's no point in doing this with perl 5, since it's not dead
data, but with a non-refcount GC scheme it'll be accessed much less.
Finally, all you really need to do is read the last day or so of p5p where
Alan's trying to plug a batch of perl memory leaks to see how well the
refcount scheme seems to be working now...
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Garbage collection (was Re: JWZ on s/Java/Perl/)
Dan Sugalski wrote: At 12:06 PM 2/9/2001 -0500, Ken Fox wrote: 2. Work proportional to live data, not total data. This is hard to believe for a C programmer, but good garbage collectors don't have to "free" every allocation -- they just have to preserve the live, or reachable, data. Some researchers have estimated that 90% or more of all allocated data dies (becomes unreachable) before the next collection. A ref count system has to work on every object, but smarter collectors only work on 10% of the objects. As is this. (Perl can generate a lot of garbage if you're messing around with strings and arrays a lot) Let me see if I got that right. If I change the way some objects are used so that I tend to create other objects instead of reusing the old ones, I'm actually not degrading GC performance, since its work is proportional to live data. Right? This increases memory usage, though, right? Would this cause some thrashing if the excessive memory usage causes degrading to virtual memory? (I guess not, since live data would probably be accessed, and dead data would probably be discarded somehow before going to virtual memory, right?). What are actually the consequences of generating more or less garbage by reusing/not reusing structures, under this advanced GC model? Finally, all you really need to do is read the last day or so of p5p where Alan's trying to plug a batch of perl memory leaks to see how well the refcount scheme seems to be working now... Yeah, I know that... But I actually think this is because Perl 5's implementation of refcounting is quite messy, specially when weakrefs are in the game. - Branden
Re: Garbage collection (was Re: JWZ on s/Java/Perl/)
At 06:30 PM 2/9/2001 +, Nicholas Clark wrote: On Fri, Feb 09, 2001 at 01:19:36PM -0500, Dan Sugalski wrote: The less memory you chew through the faster your code will probably be (or at least you'll have less overhead). Reuse is generally faster and less resource-intensive than recycling. What's true for tin cans is true for memory. reduce, reuse, recycle. The first R might also be important :-) Oh, no doubt. Everything's got tradeoffs, the question is always "what's most important". In perl's case, it's speed, and memory usage is of secondary importance unless it impacts the speed of the program. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Garbage collection (was Re: JWZ on s/Java/Perl/)
Dan Sugalski wrote: At 04:09 PM 2/9/2001 -0200, Branden wrote: If I change the way some objects are used so that I tend to create other objects instead of reusing the old ones, I'm actually not degrading GC performance, since its work is proportional to live data. Right? Correct. Whether reuse is a win overall is a separate question. It's totally dependent upon hardware. From a software big-O type of analysis, creating new objects is never slower than reusing objects. The problems come about if (a) memory is low and the OS decides to page without telling the application to prepare for paging or (b) if all memory isn't the same speed, e.g. caches are faster than main memory. This increases memory usage, though, right? Would this cause some thrashing if the excessive memory usage causes degrading to virtual memory? ... It depends on whether the old structures are really unused. If they are, one of the GC passes will reclaim the space they're taking. It also depends on locality of reference. Semi-space-based collectors are not bad at preserving locality -- mark-sweep and malloc-like allocators are terrible. The weird thing is that a collector can actually *improve* locality by moving objects "close" to the things they refer to. In perl's case, the collector could move the underlying value representation close to the PMC that refers to it. (But we may want to pin a PMC so that foreign code can keep references to it. Argh.) (It's safe to assume that if perl 6's garbage collector causes otherwise small programs to swap then it's busted and needs fixing) If you mean small as in "tight loop" then I agree. If you mean small as in a "quick one liner" then I'm not sure. The quick one liners run quickly and speeding memory management up/down by 100% might not even be noticeable. The less memory you chew through the faster your code will probably be (or at least you'll have less overhead). Reuse is generally faster and less resource-intensive than recycling. What's true for tin cans is true for memory. The electrons are re-used whether you allocate a new object or not... ;) Going to a more advanced garbage collection scheme certainly isn't a universal panacea--mark and sweep in perl 6 will *not* bring about world peace or anything. It will (hopefully) make our lives easier, though. Mark-sweep doesn't have a cheap allocator or good locality. At this point in history, I think if we don't go with a more advanced system we're not learning. - Ken
