On Wed, Apr 27, 2005 at 03:43:32PM -0400, Dan Sugalski wrote: > At 5:40 PM +0200 4/27/05, Robin Redeker wrote: > >Just for the curious me: What was the design decision behind the GC > >solution? Was refcounting that bad? Refcounting gives a more global > >speed hit indeed, but it's more deterministic and you wont run into > >(probably) long halts during GC. (Java programs often suffer from this, > >and it results in bad latency). > > I'll answer this one, since I'm the one responsible for it. > > Refcounting has three big issues: > > 1) It's expensive > 2) It's error-prone > 3) It misses circular garbage > [...] > > The expense is non-trivial as well. Yeah, it's all little tiny bits > of time, but that adds up. It's all overhead, and useless overhead > for the most part.
Yes, but do we know whether refcounting is really slower than a garbage collector in the end? > > The circular garbage thing's also an issue. Yes, there are > interesting hacks around it (python has one -- clever, but definitely > a hack) that essentially involves writing a separate mark&sweep > garbage collector. I don't think circular references are used that much. This is maybe something a programmer still has to think a little bit about. And if it means, that timely destruction maybe becomes slow only for the sake of collecting circular references... don't know if thats a big feature. Are cicrular references such a big issue in perl5? I heard that the buildin GC in perl5 only runs at program end and captures the circular references, what sometimes causes a segfault (as a friend of mine experienced). > > The thing is, there aren't any languages we care about that require > true instant destruction -- the ones that care (or, rather, perl. > Python and Ruby don't care) only guarantee block boundary collection, > and in most cases (heck, in a near-overwhelming number of cases) > timely destruction is utterly irrelevant to the code being run. Yeah, > you *want* timely destruction, but you neither need nor notice it in > most program runs, since there's nothing that will notice. In many programruns you wont notice the overhead of refcounting too. And in scripts, that only run up to (max) a minute, you won't even notice if the memory isn't managed at all. And timely destruction is still a feature thats used much more than collection of circular references would be (IMHO) > > Having been too deep into the guts of perl, and having written more > extensions in C than I care to admit to, I wanted refcounting *dead*. > It's just spread across far too much code, tracking down errors is a > massive pain, and, well, yech. Yes, non-refcounting GC systems are a > bit more complex, but the complexity is well-contained and > manageable. (I wrote the first cut of the GC system in an afternoon > sitting in my local public library) There's also the added bonus that > you can swap in all sorts of different GC schemes without disturbing > 99% of the code base. Just because refcounting is error-prone it doesn't mean that a garbage collector is better (and less error-prone). I agree, the code is more localized. But i guess that memory leaks (and resource leaks) that are caused by a bug in a garbage collector aren't that easy to find and fix also. And there are many other things that are error-prone: - a jit is error-prone - optimizations are error-prone - register allocation is error-prone - parsers/lexers/* is error-prone But i understand your argument and see that it's maybe better to localize the complex memory management stuff. > [.snipped interesting technical stuff about optimizing GC.] > I guess we will see what we get, and if GC turns out to deal with all the issues (timely destruction etc.) well and is the perfect solution, thats great! I don't have the ability to look into the future, but Java has still (after so many years) quite some GC issues (my freenet process seems to leak like hell, and the gc runs are causing full stops for 0.6s, what causes heavy latency). But i don't say (nor i know) that parrot will have these problems. I was just afraid that GC won't be faster and less overhead than a refcounted solution, and we end up with a laggy parrot ;) But many people here are convinced that the GC solution will be faster and easier, and as parrot is still in developmen, i guess there will be profiles and benchmarks in future. > I really need to go profile perl 5 some time to get some real stats, > but I think it's likely that most programs (well, most programs I run > at least) have less than 0.1% of the variables with destructors, and > maybe one or two variables *total* that have a need for timely > destruction. (And most of the time they get cleaned up by global > destruction, which makes 'em not actually timely cleaned up) IMHO timely destruction is not that useless. The alternative would be to free resources and close files explicit, like one has to do in Java. And doing resource freeing explicit doesn't feel very Perl*-ish to me. > >You said, that most languages will have refcount semantics, just sounds > >funny for me to implement a GC then. > > Actually most languages won't have refcount semantics. Perl 5's the > only one that really guarantees that sort of thing now, though I > think it's in there for perl 6. I doubt the python, ruby, Lisp, or > Tcl compilers will emit the cleanup-at-block-boundary sweep code. Well, python doesn't gurantee it. But i heard some people rely on that feature as the implementation does provide it. But ok, as you have to manage resources manually in Lisp and Ruby anyway, the compilers won't output the boundary-sweep. It's there for Perl6, right, and i thought that parrot is in first place there for Perl6. And there maybe will be new and other languages that rely at least on timely destruction. cya, robin -- [EMAIL PROTECTED] / [EMAIL PROTECTED] Robin Redeker
