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

For Better Computing, Liberate CPUs from Garbage Collection

spectrum.ieee.org

Post reply on HN
Print view View original

361–370 of 460 posts

Re: For Better Computing, Liberate CPUs from Garbage Collection

#361

Post by arcticbull »

m0th87 wrote: post #262
cyphar wrote: post #255

Earlier quoted context omitted.

> (1) Automatic Reference Counting doesn't work; its equivalent in interpreted languages is, well, reference counting, which can be optimized quite a lot (though has some issues with multithreading), but cannot collect cycles. This is what weakrefs (or better data structures) are for. The Linux kernel uses reference counting incredibly effectively for almost every structure. I think that pretty much discounts any arg…

The point with weakrefs, though, is that they still require developer intervention. Also, you can use most memory management facilities in Rust (including reference counting) without `unsafe`.

Correct, leaks are considered "safe" -- it's premature deallocations that are considered unsafe.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#362

Post by simonask »

viraptor wrote: post #233
tempguy9999 wrote: post #135

Earlier quoted context omitted.

You say > but it was a false dichotomy: We can have memory safety without garbage collection. but then say > Automatic reference counting (ARC henceforth). Naive ARC is AFAIK very expensive as it causes a lot of updates at each pointer 'take' even if it's a read only (chasing pointers), trashing caches. Poss. even worse if multithreading is used as a memory barrier may have to be issued. Also it does not collect cycl…

> Naive ARC is AFAIK very expensive as it causes a lot of updates It also means you can't really rely on CoW after fork(). After a while your whole heap will be duplicated in every process because of the RC updates.

Lots of things that people do don't work after `fork()`, though, to the point where `fork()` has become largely irrelevant in new code. For example, threads are not generally compatible. You can also easily run into issues with open files, file locks, etc.

Of course, your point might still be relevant in "legacy" environments with poor threading support anyway. I would argue that those are gradually going away, as even interpreted languages without exposed threading support are increasingly using threads or adopting threads to accommodate performance needs.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#363

Post by nickpsecurity »

dleslie wrote: post #307
norswap wrote: post #250

Earlier quoted context omitted.

Ridiculous. The problem is not that you don't know when/where the lifetime will end — that can usually be characterized by a terse "English" description. The problem is that this lifetime is dynamic in nature. The end of the lifetime of an object may coincide with some user input, for instance. At this point, either you go back to manual management, with the potential for errors (and for what it's worth, I think manu…

If the lifetime can be expressed with a state machine then it needn't be garbage collected so long as the language is sufficiently expressive. Reference counting isn't garbage collection, as most people consider it. There is no need to sweep or otherwise traverse memory to discover objects that are not referenced. Claiming that ref counting is gc is a bit like claiming malloc/free is gc.

"If the lifetime can be expressed with a state machine then it needn't be garbage collected so long as the language is sufficiently expressive."

One programmer here told me he does that in Ada and/or SPARK Ada using enumerated types encoding states. Now there's two of you. Most stuff I see like this are linear/affine/dependent types or separation logic. I rarely see people talking about simple solutions like this. Do you have any links that go in-depth on it with examples? It would be good to have something to pass along to people interested in this.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#364

Post by c-cube »

simias wrote: post #189
eru wrote: post #168

Earlier quoted context omitted.

C++ code is full of use after free problems. You can avoid those with garbage collection.

If you have a use-after-free it means that you made a wrong assumption in your code about the lifetime of the object. A GC would hide the issue and potentially lessen the gravity of the bug but it doesn't resolve the core issue which is that you probably have a fundamental logical problem in your code. I'm a bit "GC hater" so obviously I'm heavily biased but to me it just means that GC make it easier to write sloppy,…

What if your domain problem (say, compilers, symbolic algorithms) doesn't have a clear notion of ownership because everything is a shared DAG that may survive for arbitrarily long? Not every problem has clear ownership imho (and tools in C or C++ in these domains resort to their own refcount/custom GC implementation anyway).

Re: For Better Computing, Liberate CPUs from Garbage Collection

#365

Post by kazinator »

kbenson wrote: post #321
simias wrote: post #303

Earlier quoted context omitted.

My point is that you need a "destructor" even with a GC. Continuing with my example you need to pop your tab from the data structure containing your tabs and you have to make sure that all references are dropped so that the GC will do its work. When I write Rust code I basically never have to explicitly free anything outside of FFI code dealing with C pointer or the like. The most straightforward way to allocate anyt…

> it's also important to recognize when something can't be pushed under the rug. If you haven't heard of it, you might be interested in the Waterbed Theory of Complexity[1]. The idea behind it is that it's not that you can't push down complexity in an area, but often that complexity just pops up in a different area. For example, you can do away with the vast majority of allocating and freeing memory, but the complexi…

The Waterbed theory is stupid, because a given requirement can be handled in one place in the system, or it can proliferate into every module, giving rise to a more complexity to achieve the same functionality.

So that is to say, when we push down a "bump" of complexity in one place, seventeen bumps at least as large can crop up elsewhere. Moreover, that seventeen is just today; we might have paved the way for more such bumps now being necessary going forward as functionality is added, whereas if we kept the original bump, it would stay the same. Water is not a good model for complexity because it is incompressible for all practical purposes; if we push down a liter of water here, the places where it pops up add up to just a liter.

For exmaple, virtual memory is considerably simpler than individual modules of a program implementing a scheme for swapping code and data to disk and back.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#366

Post by kazinator »

arcticbull wrote: post #358
kbenson wrote: post #321

Earlier quoted context omitted.

> it's also important to recognize when something can't be pushed under the rug. If you haven't heard of it, you might be interested in the Waterbed Theory of Complexity[1]. The idea behind it is that it's not that you can't push down complexity in an area, but often that complexity just pops up in a different area. For example, you can do away with the vast majority of allocating and freeing memory, but the complexi…

I like the waterbed theory, thanks, I hadn't heard of it before. You're absolutely right, in the GC context you: (1) Have to manually reference count / manage external resources like sockets and files because you can't count on the destructor to ever run. (2) Lose determinism and then have to spend huge amounts of effort tweaking GC parameters to fix your issue, but to your point, it becomes a Jenga tower where you t…

In what memory management paradigm can you free the object in a long-lived dictionary without removing it from that dictionary, and do you advocate this paradigm?

Re: For Better Computing, Liberate CPUs from Garbage Collection

#367

Post by mcguire »

arcticbull wrote: post #83
davedx wrote: post #82

Earlier quoted context omitted.

> It wastes time, it wastes space, it wastes energy. But all of these are much cheaper than developer labour and reputation damage caused by leaky/crashy software. The economics make sense. Anecdotally, I spent the first ~6 years of my career working with C++, and when I started using languages that did have GC, it made my job simpler and easier. I'm more productive and less stressed due to garbage collection. It's o…

> But all of these are much cheaper than developer labour and reputation damage caused by leaky/crashy software. The economics make sense. Of course, with traditional languages, that's the trade-off we're being asked to make. That's my point! We need to develop languages that accurately encapsulate lifetimes statically so that we can express that to the compiler. If we do, the compiler can just make instances disappe…

In Rust, does the standard way of implementing a graph structure still use a vector of nodes and indices for edges?

I think I saw a Rust implementation of an arena. Is it working?

Re: For Better Computing, Liberate CPUs from Garbage Collection

#368

Post by mcguire »

maxxxxx wrote: post #226
davedx wrote: post #82

Earlier quoted context omitted.

> It wastes time, it wastes space, it wastes energy. But all of these are much cheaper than developer labour and reputation damage caused by leaky/crashy software. The economics make sense. Anecdotally, I spent the first ~6 years of my career working with C++, and when I started using languages that did have GC, it made my job simpler and easier. I'm more productive and less stressed due to garbage collection. It's o…

I think C++ could get most GC usability benefits if there was a better/simpler syntax for shared_ptr and unique_ptr. I have written code with extensive shared_ptr usage and it was quite pleasant if you ignore the ugly syntax. On the other hand even after years of C# I still miss deterministic destructors.

One downside of reference counting is the long delete delay you get when you remove the last reference to a large data structure. That's pretty easy to fix, but then you lose deterministic destructors.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#369

Post by holy_city »

c-cube wrote: post #364
simias wrote: post #189

Earlier quoted context omitted.

If you have a use-after-free it means that you made a wrong assumption in your code about the lifetime of the object. A GC would hide the issue and potentially lessen the gravity of the bug but it doesn't resolve the core issue which is that you probably have a fundamental logical problem in your code. I'm a bit "GC hater" so obviously I'm heavily biased but to me it just means that GC make it easier to write sloppy,…

What if your domain problem (say, compilers, symbolic algorithms) doesn't have a clear notion of ownership because everything is a shared DAG that may survive for arbitrarily long? Not every problem has clear ownership imho (and tools in C or C++ in these domains resort to their own refcount/custom GC implementation anyway).

imo you solve these problems by segregating the ownership logic and relationship logic of the data structure.

In other words the DAG would never be traversed to allocate or free memory, each vertex would be held by a vector or other container and the edges represented by an adjacency list/matrix.

It's faster and safer than pointer chasing.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#370

Post by nickpsecurity »

exabrial wrote: post #315
p_l wrote: post #129

Earlier quoted context omitted.

Azul essentially provided tagged architecture AND I think forwarding pointers. The former gave you precise GC for free, the latter allowed concurrent GC to move data around without pauses.

I can't seem to find anything on the Vega processor other than "874 cores"... any links?

If it's old news, it often helps to just type the URL into Wayback Machine and click back a few years. I do it all the time. That got us this:

https://web.archive.org/web/20160310165634/https://www.azul....

Post reply on HN