Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Garbage Collection is Wrong

lb-stuff.com

Post reply on HN
Print view View original

91–100 of 111 posts

Re: Garbage Collection is Wrong

#91

Post by AnimalMuppet »

shmerl wrote: post #41

I surely prefer RAII to any garbage collection. It doesn't mean it's completely wrong though and has no uses at all. It's just of limited usefulness that's why languages which overuse it claiming it's always needed (like Java) are too limiting. If anything, GC should be optional, not mandatory.

Well... if C and (early) C++ showed us anything, it's that programmers aren't very good at managing memory. (It's not just leaking memory. Accessing deleted memory is much worse.)

So, what are you going to do? Just say "Most programmers are lousy, deal with it"? Introduce garbage collection, which solves 90% of the problem (memory) with no programmer intervention, but does nothing whatsoever to help the other 10% of cases (files, sockets, mutexes, etc.)? Rely on RAII, which in turn relies on programmer education and discipline? Or do you have another alternative?

Optional GC could be interesting - maybe some kind of a switch that you set at compile time that says "this program uses GC" or "this program uses destructors". But then you're essentially talking about two similar, but different languages (like, say, Java and C++).

Re: Garbage Collection is Wrong

#92

Post by AnimalMuppet »

mcphage wrote: post #89
banachtarski wrote: post #15

Earlier quoted context omitted.

Professional C++ coder here. Seeing new and delete has very heavy code smell and can be avoided 99% of the time.

What have you done to your language that the native syntax for creating and deleting objects is a code smell?!

Recognized that the average programmer can't reliably handle the tool?

Re: Garbage Collection is Wrong

#93

Post by emeraldd »

rian wrote: post #20
emeraldd wrote: post #8

In modern C++, using new or delete in your code is wrong. It's not done. Nobody writes code like that anymore in C++. It's been quite a while since I wrote any significant C++ code, but this statement seems wrong. Is this really "state of the art" for C++?

Naked New/delete have been taboo since auto_ptr hit the scene.

Interesting, I hadn't seen that before. I guess I really need to go back and relearn C++ ...

Re: Garbage Collection is Wrong

#94

Post by mcguire »

codeka wrote: post #6

When was this written? It seems to be at least half a decade out of date. Certainly nothing it espouses is actually new...

Indeed. The "garbage collection" described seems to have been state-of-the-art in the late '80's. And, of course, it's compared to features that weren't officially added to C++ until 2011.

Yes, garbage collection is inappropriate for things with finalizers---for resources other than memory. Other than that, I can't see anything useful here.

Re: Garbage Collection is Wrong

#95

Post by shmerl »

AnimalMuppet wrote: post #91
shmerl wrote: post #41

I surely prefer RAII to any garbage collection. It doesn't mean it's completely wrong though and has no uses at all. It's just of limited usefulness that's why languages which overuse it claiming it's always needed (like Java) are too limiting. If anything, GC should be optional, not mandatory.

Well... if C and (early) C++ showed us anything, it's that programmers aren't very good at managing memory. (It's not just leaking memory. Accessing deleted memory is much worse.) So, what are you going to do? Just say "Most programmers are lousy, deal with it"? Introduce garbage collection, which solves 90% of the problem (memory) with no programmer intervention, but does nothing whatsoever to help the other 10% of…

You are right, in case of C++ the language doesn't ensure safety because of RAII since one can always go back to manual new / delete and etc. But in newer languages this can be avoided.

Rust actually does that, and GC there is optional by the way.

Re: Garbage Collection is Wrong

#96

Post by dmunoz »

taybin wrote: post #50
bananaoomarang wrote: post #4

What's the catch?

You can run out of space on the stack, which has a smaller size than the heap, where new'd objects are placed. This can easily happen with large objects that own other large objects and it is difficult to debug without knowledge of the implementation of all of the child objects.

That's too strong of a critique. You can have just a handle on the stack, with the data on the heap. When the destructor of the handle is executed, it deallocates the data on the heap. This is what almost all resource holding library or user-defined types do in C++.

Re: Garbage Collection is Wrong

#97

Post by mcguire »

danbruc wrote: post #84
rian wrote: post #78

Earlier quoted context omitted.

I'm a bit skeptical of the results of that paper without the seeing the source code and in what contexts they are performing the comparison. One can always find situations where one scheme is faster than the other but I'm not totally sure if micro benchmarks are representative of the real world. In long-lived servers, ref-counting can be preferable because it avoids random pauses. Maybe it's a latency vs throughput p…

Reference counting doubles the number of memory access - you have to update the reference and the counter every time. That is a big performance hit. Reference counting may randomly halt your code, too, because you never know when you hit zero and the resource gets freed.

And you don't know how many resources will be freed when you drop the last pointer to that giant tree structure.

Of course, you could queue up and lazily delete the resources, but then you're back to nondeterministic behavior.

Re: Garbage Collection is Wrong

#98

Post by kd0amg »

mcphage wrote: post #89
banachtarski wrote: post #15

Earlier quoted context omitted.

Professional C++ coder here. Seeing new and delete has very heavy code smell and can be avoided 99% of the time.

What have you done to your language that the native syntax for creating and deleting objects is a code smell?!

Included an alternative to new/delete's form of allocation that covers a good range of its use cases and is less prone to screwup.

Re: Garbage Collection is Wrong

#99

Post by dllthomas »

danbruc wrote: post #7

Yes, in some scenarios you can associate the lifetime of a resource with the lifetime of a storage location, but this simply does not work in all cases, probably only in a small fraction of all cases. And then? How do you handle resources that have no single obvious owner? How do you determine if the resource is still in use when you are done with it in one place? You implement some kind of reference counting? You ke…

In my experience, "small fraction of all cases" is inaccurate - in my C it's probably 1/3 to 2/3 of cases, depending on how much I structure my program to allow for it. For instance, synchronous processing of messages makes it relevant in many more cases, but has obvious costs (which isn't to say they aren't sometimes worth bearing). It is still true that there is a significant fraction of coding where it does not apply, and which must be treated specially.

Re: Garbage Collection is Wrong

#100

Post by letzjuc »

danbruc wrote: post #88
letzjuc wrote: post #83

Earlier quoted context omitted.

> And reference counting also renders the point of determinism moot - now you never know if releasing a reference while trigger freeing a resource. You know that releasing the last reference will. That is why the important concept is single ownership of resources and not reference counting by itself.

But you don't know which reference is the last until you actually get there - that is why you used reference counting in the first place, because you were unable to statically determine which reference will be the last one. So every time you abandon a reference it might be the last one and you might have to spend extra cycles to free the resource. This is no more deterministic than a garbage collector.

In a non-deterministic garbage collector memory _might not_ be released when the last reference goes out of scope (and this is often the case).
Post reply on HN