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

181–190 of 460 posts

Re: For Better Computing, Liberate CPUs from Garbage Collection

#181

Post by geocar »

barrkel wrote: post #151
geocar wrote: post #113

Earlier quoted context omitted.

> But all of these are much cheaper than developer labour and reputation damage caused by leaky/crashy software. And that's why so much effort has gone into making it fast and low latency, but it was a false dichotomy: We can have memory safety without garbage collection. - Automatic reference counting: Most people know about Objective-C's efforts in this space, but it's admittedly less automatic than programmers wou…

Reference counting is garbage collection. It's part of the mix of potential strategies for automatic collection of memory. As is static analysis of data flow, fwiw.

In taxonomy, I say we have "automatic memory management" when we have some kind of `malloc()` type device and no need to `free()` it.

Garbage collection is about visiting live objects to figure out what's alive and ignoring the dead stuff. Every theory about why GC can work (or be useful) is predicated on the idea that there is more garbage than live objects so you're touching less stuff.

If all you do is mark/sweep, you're visiting the garbage as well, so GC research has led neatly into moving collectors (which don't ever touch the garbage). That's a win, and that's why GC is worth study.

There are other kinds of "automatic memory management" though: reference counting, arena allocators (at a stretch), and object memory (I've only seen this on mainframes), and they're all worth some attention.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#182

Post by pron »

eru wrote: post #175
pron wrote: post #104

Earlier quoted context omitted.

I think that garbage collection has proven to be the best idea in programming languages in the past decades, and probably the only one that has made an impact at all. It's getting so good these days that few are willing to consider "moving on." In terms of throughput, it beats manual memory management (in fact, in principle, the cost of GC can be made arbitrarily low; a famous Andrew Appel paper shows how it can be c…

> I think that garbage collection has proven to be the best idea in programming languages in the past decades, and probably the only one that has made an impact at all. Depends on how you set your thresholds. Paying more attention to side-effects / purity / const has been pretty useful, too. And so have mainstream languages adopting first class functions. And making it easy to compose data structures. (Compare eg how…

> Paying more attention to side-effects / purity / const has been pretty useful, too...

I don't know. Studies haven't been able to find any big effects, and the industry isn't seeing them, either. You may like those things, but unlike GCs, it doesn't seem like they've made a real impact.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#183

Post by eternalban »

arcticbull wrote: post #80

IMO garbage collection is the epitome of sunk cost fallacy. Thirty years of good research thrown at a bad idea. The reality is we as developers choose not to give languages enough context to accurately infer the lifetime of objects. Instead of doing so we develop borderline self-aware programs to guess when we're done with objects. It wastes time, it wastes space, it wastes energy. If we'd spent that time developing…

> we have a giant for loop that iterates over all of memory over and over and over to guess when we're done with things. What a mess!

Yeah, that's like having dedicated busboys clean up customers mess and clear tables when they are done in a restaurant. Why can't the customers get up and remove dishes as courses are served? Or the waiter could do it. Why does the poor busboy have to ask "are you done with this?" Now this article is proposing busboys on powered skateboards. What a mess!

Counter-point, for you.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#184

Post by barrkel »

geocar wrote: post #181
barrkel wrote: post #151

Earlier quoted context omitted.

Reference counting is garbage collection. It's part of the mix of potential strategies for automatic collection of memory. As is static analysis of data flow, fwiw.

In taxonomy, I say we have "automatic memory management" when we have some kind of `malloc()` type device and no need to `free()` it. Garbage collection is about visiting live objects to figure out what's alive and ignoring the dead stuff. Every theory about why GC can work (or be useful) is predicated on the idea that there is more garbage than live objects so you're touching less stuff. If all you do is mark/sweep,…

> Garbage collection is about visiting live objects to figure out what's alive and ignoring the dead stuff

That's a description of tracing GC, not a definition of GC.

GC is whatever technology that enables what you've called automatic memory management: a kind of illusion that there is infinite memory, from the programmer's perspective.

That might involve some mix of reference counting (Python is probably the biggest example), tracing (what you seem to think is all of GC), data flow analysis (e.g. escape analysis in some Java GC / JIT integration), etc.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#185

Post by Confusion »

arcticbull wrote: post #80

IMO garbage collection is the epitome of sunk cost fallacy. Thirty years of good research thrown at a bad idea. The reality is we as developers choose not to give languages enough context to accurately infer the lifetime of objects. Instead of doing so we develop borderline self-aware programs to guess when we're done with objects. It wastes time, it wastes space, it wastes energy. If we'd spent that time developing…

  The reality is we as developers choose not to give languages 
  enough context to accurately infer the lifetime of objects.
The reality is we as developers choose not to give languages enough context to just do what I mean.

  instead of finding a way of expressing when we're done with instances
So, when are you done with an instance? How to enumerate all possible situations and devise a comprehensible encoding for them? Without requiring developers to keep a lookup table of lifetime declarations or other non-local reasoning in mind? Concurrency. Laziness. Runtime code replacement.

You're handwaving over fundamental research problems here. You don't know this is even possible in a way that doesn't completely hose the comprehensibility of a language.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#186

Post by stephc_int13 »

I never understood the need for Garbage Collectors. In my opinion, the difficulties of memory management are extremely overrated. I write code in C/C++ for almost 20 years and I never encountered a difficult bug that would have been avoided with a Garbage Collector.

If a coder really has a hard time with manual memory management it means he can't really code, this is a beginner problem...

Re: For Better Computing, Liberate CPUs from Garbage Collection

#187

Post by basetop »

arcticbull wrote: post #80

IMO garbage collection is the epitome of sunk cost fallacy. Thirty years of good research thrown at a bad idea. The reality is we as developers choose not to give languages enough context to accurately infer the lifetime of objects. Instead of doing so we develop borderline self-aware programs to guess when we're done with objects. It wastes time, it wastes space, it wastes energy. If we'd spent that time developing…

It wastes time, space and energy, but it also lowers the bar for programming ( don't have to know or care much about memory ) and removes the potential for errors. It's like programming on training wheels. Sure it, there are costs upfront, but it also saves costs down the line.

Also, garbage collection doesn't iterate over all memory. There are lists, structures and variables that the runtime/GC manages.

And we already have languages that doesn't use GC and give us ways of "releasing memory" - C being one of the most famous ones. But C also has its share of problems.

The more control you give to the programmer, the lower the footprint but the higher the learning curve and the costs of bugs. The more control you give to the runtime, the higher the bloat and lower the learning curve, but lower the cost of bugs. The GC exists because it removes a class of bugs that human programmer seem prone to write and it theoretically allows programmers to work on more business/productive aspects of software development.

Software development is such a vast space that I think there will be room for GC and non-GC. And as you said, sunk costs ( on both sides ) almost dictate they both be around for a very long time.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#188

Post by seanmcdirmid »

barrkel wrote: post #184
geocar wrote: post #181

Earlier quoted context omitted.

In taxonomy, I say we have "automatic memory management" when we have some kind of `malloc()` type device and no need to `free()` it. Garbage collection is about visiting live objects to figure out what's alive and ignoring the dead stuff. Every theory about why GC can work (or be useful) is predicated on the idea that there is more garbage than live objects so you're touching less stuff. If all you do is mark/sweep,…

> Garbage collection is about visiting live objects to figure out what's alive and ignoring the dead stuff That's a description of tracing GC, not a definition of GC. GC is whatever technology that enables what you've called automatic memory management: a kind of illusion that there is infinite memory, from the programmer's perspective. That might involve some mix of reference counting (Python is probably the biggest…

GC has always meant tracing GC while reference counting (ever since McCarthy invented it) was considered another form of automatic memory management (like using arenas, doing escape analysis, etc...). Only recently in hacker news have they become all merged into the same word, for some reason.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#189

Post by simias »

eru wrote: post #168
Patient0 wrote: post #136

Earlier quoted context omitted.

In the ~15 years I spent building software in C++ I don't recall a single time that I wished for garbage collection. By using RAII techniques, it was always possible (nay, easy!) to write code that cleaned up after itself automatically. I always found it easier to reason about and debug programs because I knew when something was supposed to be freed, and in which thread. The only time that use of simple reference cou…

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, poorly architectured code where you have a mess of a data-dependency graph and nobody knows who owns what and when things need to be deleted, so you let the GC (hopefully) figure it out. In my experience this leads to all sorts of issues independently of memory management, such as having obsolete data lingering in certain parts of the program because it's not expunged properly.

IMO GC or not having clear ownership semantics are necessary to properly architecture anything more complicated than a script. And if you have ownership semantics then why do you need a GC anyway?

Re: For Better Computing, Liberate CPUs from Garbage Collection

#190

Post by seanmcdirmid »

Patient0 wrote: post #149
apta wrote: post #140

Earlier quoted context omitted.

While RAII is a very good technique, it is not the solution to all issues here. I read that some concurrent datastructure implementations would not be possible without a GC. Furthermore, when a project reaches a certain level of complexity, it ends up implementing GC anyway (see Unreal engine).

I agree that RAII does not solve everything - in particular, issues with memory fragmentation. However, I prefer the direction being taken by Rust and suggested by the top level poster: rather than having to run a separate thread which tries to infer which resources are no longer needed, with potentially large runtime costs, instead augment the language semantics with a clear ownership model, and thereby give the com…

That reminds me of the VILW argument: we will make languages really expressive and compilers really smart, then we can get rid of fancy CPU hardware that do instruction scheduling dynamically.

It doesn’t always work. A dynamic tracing GC (or reference counting or using arenas) can be more efficient in ways that static approaches probably won’t be able to effectively emulate. Rust is a great experiment for seeing how far we can go in this area, so we will see.

Post reply on HN