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

61–70 of 111 posts

Re: Garbage Collection is Wrong

#61

Post by letzjuc »

mikeash wrote: post #39
letzjuc wrote: post #32

Earlier quoted context omitted.

Then the lists should only have a weak_ptr to the object. Something is handling both list [1], that something could own the object, or maybe something external to that. Giving ownership of the object to both list is a design error [2]. [1] e.g. if the two list are an implementation detail of a data structure, the data-structure itself could own the objects in the lists. [2] Do non-deterministic garbage collectors tha…

Sharing immutable data between multiple places with no single master owner is a perfectly reasonable thing to do in a program.

I fail to see why you need cycles' support for that.

Re: Garbage Collection is Wrong

#62

Post by mikeash »

letzjuc wrote: post #51
ori_b wrote: post #35

Earlier quoted context omitted.

It's only a design error when you don't have a GC. Imagine you have an arbitrary long lived connected cyclic graph that can be incrementally updated from multiple short lived worker threads. With a GC, this is a no brainer: just put the objects in the graph. No workarounds, no extra tracking. Without a GC, on removing a node, you have to walk to essentially do a mark/sweep of the graph to find dead nodes that were co…

Have a vector of shared_ptr that own the objects in the graph and build a graph with weak_ptr ? Removing an object is just as easy as removing an element from the vector. (If you test the weak_ptrs on use, that's actually the only thing you would need to do).

Isn't that equivalent to using a shared_ptr directly, just unnecessarily complicated?

Reference counting works fine as long as you don't have cycles, of course.

Re: Garbage Collection is Wrong

#63

Post by letzjuc »

Guvante wrote: post #47
letzjuc wrote: post #29

Earlier quoted context omitted.

Because it is deterministic? (i'm just guessing that what you call "proper" garbage collector is non-deterministic). Furthermore, the only "advantage" I see in garbage collectors is that they can deal with cycles. I say "advantage" because i'm of the strong opinion that having a cycle in your code is a software design error.

Say you are implementing a self-tracking objects model for data management. How do you fix the reversal of control required to manage that? Specifically you need to go from the representative object to the controller to store the fact that you changed.

Could you elaborate?

Re: Garbage Collection is Wrong

#64

Post by rian »

chollida1 wrote: post #30
rian wrote: post #16

This is totally on point. Ref-counting / RAII is the only sane way to do resource management. It's super lightweight and easy to understand. The vast majority of resources are short-lived and don't create cycles. Our garbage collections "systems" should be designed for this case. Cycles are a special case required for few data structures. They are not the norm and we shouldn't ship a huge heaping mess of a garbage co…

> The vast majority of resources are short-lived and don't create cycles. Our garbage collections "systems" should be designed for this case. Many modern GC systems are tuned for exactly this. It often is called generational garbage collection and the youngest generation is tuned to quickly collect these short-lived and non cyclic objects. I used to work in this field so I've got at least a decent grasp of what moder…

My point is that, what GCs do at runtime (discover garbage) can be done statically in all of these cases. The sole reasons GCs do that work at runtime is because of cycles.

Cycles aren't common at all and the answer shouldn't be "let's create a huge complex GC that handles all cases, then down the road we'll optimize for the common case" the answer should be "let's do the sane reasonable thing that handles the common case and push the problem of cycle-management to the programmer"

Re: Garbage Collection is Wrong

#65

Post by danbruc »

rian wrote: post #55
danbruc wrote: post #34

Earlier quoted context omitted.

See mikeash's comment for a very simple situation. I mostly develop business applications with customers, products, orders, contracts, addresses and hundreds of other things connected and entangled in sometimes insane ways as dictated by the business. And at any point the user may just open another form viewing the orders of a different customer linked to the same products as in five other forms. Managing such comple…

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 trigger freeing a resource. You could of course delay offload it to a separate thread, but this makes you lose any guarantee about the time when the resource is actually freed, too.

Re: Garbage Collection is Wrong

#66

Post by mikeash »

letzjuc wrote: post #61
mikeash wrote: post #39

Earlier quoted context omitted.

Sharing immutable data between multiple places with no single master owner is a perfectly reasonable thing to do in a program.

I fail to see why you need cycles' support for that.

You asked for a situation where the lifetime of a resource can't be directly tied to the lifetime of a single storage location. Cycles are a different matter.

Re: Garbage Collection is Wrong

#67

Post by jvreeland »

mildtrepidation wrote: post #42

As someone who's not interested in following every acronym and resource allocation strategy there is... is this even remotely useful? Lately I've gotten back into Java for Android, and after a very long time with Python, it's the first exposure in over a decade I've had to this argument... ...which, for some of us, isn't an argument, as we have basically no choice in the matter. But I'm still interested to know wheth…

As someone who recently transitioned from C to C++ programming with RAII is an incredibly useful tool. In addition to making resource management easier when done properly it helps clarify your code, well worth the minor amount of time it takes to implement IMO.

Re: Garbage Collection is Wrong

#68

Post by rian »

Guvante wrote: post #47
letzjuc wrote: post #29

Earlier quoted context omitted.

Because it is deterministic? (i'm just guessing that what you call "proper" garbage collector is non-deterministic). Furthermore, the only "advantage" I see in garbage collectors is that they can deal with cycles. I say "advantage" because i'm of the strong opinion that having a cycle in your code is a software design error.

Say you are implementing a self-tracking objects model for data management. How do you fix the reversal of control required to manage that? Specifically you need to go from the representative object to the controller to store the fact that you changed.

Weak ptr/reference.

Also I would say that it's very uncommon to do/need something like this so it shouldn't be cited as an reason for cycles to be generally handled.

Re: Garbage Collection is Wrong

#69

Post by rgo »

troebr wrote: post #40

Isn't it simply a form of garbage collection? Instead of garbage collecting all the unused objects at random moments, an object is garbage collected as soon as it goes out of scope. The way I understand it, no garbage collection means you take care of cleaning after yourself, whereas garbage collectors do it for you. It sounds like what he calls resource acquisition.

No. I think cleaning up, manually or automatically, after objects go out of scope is not the same as garbage collecting. "Garbage" here implies objects that linger beyond their usage scope, from construction to destruction, and now have become garbage taking up memory that can only be reclaimed by an extraneous routine, ie the GC.

Re: Garbage Collection is Wrong

#70

Post by letzjuc »

danbruc wrote: post #49
letzjuc wrote: post #32

Earlier quoted context omitted.

Then the lists should only have a weak_ptr to the object. Something is handling both list [1], that something could own the object, or maybe something external to that. Giving ownership of the object to both list is a design error [2]. [1] e.g. if the two list are an implementation detail of a data structure, the data-structure itself could own the objects in the lists. [2] Do non-deterministic garbage collectors tha…

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 is triggered, you check the count of the shared_ptr. If it is 2 (i.e. the order and the manager), the order removes the shared_ptr.

[1] Single ownership is the key concept, not reference counting which is just an implementation detail.

Post reply on HN