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

81–90 of 111 posts

Re: Garbage Collection is Wrong

#81

Post by danbruc »

sanderjd wrote: post #74
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…

> You implement some kind of reference counting? Yep! Or, ideally, you use one of the good reference counting libraries that your language almost certainly ships with if it is one which encourages RAII.

Reference counting is just one form of garbage collection, the other main alternative is a collecting garbage collector. And comparisons showed - I know that they tried both for .NET - that a collecting GC outperforms a reference counting GC. Yes, you will have to take a performance hit when you perform garbage collection in cases where it would not be necessary but the convince of not having to care far outweighs this because program correctness is important and development time expensive, computing power is cheap and does not matter. At least in my field, mainly business applications.

Re: Garbage Collection is Wrong

#82

Post by danbruc »

letzjuc wrote: post #70
danbruc wrote: post #49

Earlier quoted context omitted.

I am mostly developing business applications. The user decided to view a couple of orders, orders reference products and some of the orders reference the same product. Who owns the product? Definitely non of the orders and neither the form showing the order. Well, I could attach them to the main form, but now they stay in scope until you close the application. This is not what we wanted. I could implement referencing…

It's simple. The key is that something has to have _ownership_ of the products. [1] User decides to view a couple of orders. Orders reference products. Those products are managed by something (e.g. an unordered_map of shared_ptr). The order can check, is my product there? If so, i'll copy the shared_ptr to it. Otherwise, I create a shared_ptr for a product and store a copy in the manager. When the order's destructor…

https://news.ycombinator.com/item?id=7315392

https://news.ycombinator.com/item?id=7315575

(Don't want to duplicate the comment once again.)

Re: Garbage Collection is Wrong

#83

Post by letzjuc »

danbruc wrote: post #65
rian wrote: post #55

Earlier quoted context omitted.

Yes I think you would use a ref counted resource in that case. For your tangled mess of database connections I can't imagine ref counting not being adequate in those scenarios as well.

And now we are back at garbage collection - the two main options are reference counting GCs and collecting GCs. I know it for the .NET GC, they tried a reference counting GC and it performed worse than a collecting GC and not to forget the trouble with cycles when implementing a reference counting GC. And reference counting also renders the point of determinism moot - now you never know if releasing a reference while…

> 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.

Re: Garbage Collection is Wrong

#84

Post by danbruc »

rian wrote: post #78
pcwalton wrote: post #31

Earlier quoted context omitted.

> If you consider it a GC then it's the fastest GC. It's also deterministic and does not pause. No, it's not, not unless you use a lot of cleverness. "We find that an existing modern implementation of reference counting has an average 30% overhead compared to tracing…" (They did perform a lot of optimizations to get it up to speed with tracing garbage collection... however, these are far beyond what shared_ptr does.)…

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.

Re: Garbage Collection is Wrong

#85

Post by sanderjd »

danbruc wrote: post #81
sanderjd wrote: post #74

Earlier quoted context omitted.

> You implement some kind of reference counting? Yep! Or, ideally, you use one of the good reference counting libraries that your language almost certainly ships with if it is one which encourages RAII.

Reference counting is just one form of garbage collection, the other main alternative is a collecting garbage collector. And comparisons showed - I know that they tried both for .NET - that a collecting GC outperforms a reference counting GC. Yes, you will have to take a performance hit when you perform garbage collection in cases where it would not be necessary but the convince of not having to care far outweighs th…

Well, reference counting is definitely a way to collect garbage, but when people say X language used a reference counting GC versus a collecting GC, they typically mean that X language was using that GC for all objects. I'm guessing that the .NET experiment you're thinking of used the terminology in that way, and if so, I don't think it's particularly surprising that reference counting was slower. But using a reference counting library only in cases where you find that you need multiple references to a single object is a very different animal. Most programs don't actually need much shared data, even without any design contortions.

Re: Garbage Collection is Wrong

#86

Post by letzjuc »

to3m wrote: post #58
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++?

You can get surprisingly far without using new or delete. std::vector, std::list and std::string are good replacements for many uses, you can of course create objects on the stack, and if your objects are stateless then they can maybe be const globals - and that can often save you a big pile of bother. Though while new and delete are best avoided where possible, it's hardly the end of the world if you do use them. An…

Why use new/delete when you have make_shared and make_unique?

Like 99.99999999% of the time you can use those. Like the only situation where I think they might be not enough is for some weird uses of placement new.

Re: Garbage Collection is Wrong

#87

Post by danbruc »

rian wrote: post #80
danbruc wrote: post #65

Earlier quoted context omitted.

And now we are back at garbage collection - the two main options are reference counting GCs and collecting GCs. I know it for the .NET GC, they tried a reference counting GC and it performed worse than a collecting GC and not to forget the trouble with cycles when implementing a reference counting GC. And reference counting also renders the point of determinism moot - now you never know if releasing a reference while…

Ah, I don't think ref counting is generally considered GC. It's more like RAII and used in C++ elsewhere via shared_ptr.

It is a mechanism to figure out if a resource is no longer in use and can be released - that sounds like the very definition of garbage collection.

Re: Garbage Collection is Wrong

#88

Post by danbruc »

letzjuc wrote: post #83
danbruc wrote: post #65

Earlier quoted context omitted.

And now we are back at garbage collection - the two main options are reference counting GCs and collecting GCs. I know it for the .NET GC, they tried a reference counting GC and it performed worse than a collecting GC and not to forget the trouble with cycles when implementing a reference counting GC. And reference counting also renders the point of determinism moot - now you never know if releasing a reference while…

> 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.

Re: Garbage Collection is Wrong

#89

Post by mcphage »

banachtarski wrote: post #15
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++?

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?!

Re: Garbage Collection is Wrong

#90

Post by danbruc »

sanderjd wrote: post #85
danbruc wrote: post #81

Earlier quoted context omitted.

Reference counting is just one form of garbage collection, the other main alternative is a collecting garbage collector. And comparisons showed - I know that they tried both for .NET - that a collecting GC outperforms a reference counting GC. Yes, you will have to take a performance hit when you perform garbage collection in cases where it would not be necessary but the convince of not having to care far outweighs th…

Well, reference counting is definitely a way to collect garbage, but when people say X language used a reference counting GC versus a collecting GC, they typically mean that X language was using that GC for all objects. I'm guessing that the .NET experiment you're thinking of used the terminology in that way, and if so, I don't think it's particularly surprising that reference counting was slower. But using a referen…

Of course, you are right, I did not want to imply that we should call C++ a garbage collecting language just because it has shared_ptr. And you are right that you can achieve more optimal code if you can use you knowledge to decide when reference counting is necessary and when not. But there is just an enormous spectrum of cases where the convenience of a garbage collector - which gives you less (but not zero) opportunities for memory leaks and speeds up development - far outweighs the performance hit. And the performance hit is really not large, modern garbage collectors are highly tuned pieces of software. Obviously you probably don't want a GC run when you are in the middle of some timing critical driver code, but I never wanted to imply a black/white world where garbage collectors are the silver bullet. But the article is definitely wrong - garbage collection is not wrong (in all scenarios).
Post reply on HN