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

381–390 of 460 posts

Re: For Better Computing, Liberate CPUs from Garbage Collection

#381

Post by Arelius »

SilasX wrote: post #379
simias wrote: post #267

Earlier quoted context omitted.

I don't see your point. Of course sometimes the lifetime of an object is not tied to code scope but actually to something dynamic. Let's say for instance when you close a tab in your browser you expect the resources to be freed (ignoring caching to simplify the argument). Clearly somewhere in your code you have to explicitly handle tab closing and break the references to allow the GC to do its job. Why not free the r…

>I find RAII a lot easier to model and think about than "you drop this reference and one day maybe your object is destroyed, but don't really rely on that" Heh, I just realized this is what we depend on to remove commits from Github. "Uh, just delete any branches that contain it, and, uh, it'll get removed ... like, eventually." (of course you have to assume any secret data is compromised)

This is a fundamental git model. see `git help gc`

Re: For Better Computing, Liberate CPUs from Garbage Collection

#382

Post by kilon »

The irony of the thing is that in manual memory management languages you end up doing your own garbage collectors and in garbage collector languages you end up doing your own manual management. Unfortunately if you look in a language to solve such complex problems you are heading straight to severe disappointment land. Same shit different package. I still prefer dynamic languages by a long margin because of their ability to do decent metaprogramming and reflection which is essential for managing any form of data. Pick your poison and enjoy the hype while it lasts.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#383

Post by altfredd »

lodi wrote: post #339
titzer wrote: post #180

Earlier quoted context omitted.

IMO manual memory management is the epitome of sunk cost fallacy. Sixty years of good programmer effort thrown at a bad idea that has produced an endless stream of security bugs and performance problems that have only hidden the cost of memory management behind non-obvious barriers and done severe violence to systems languages with an absurd obsession with custom allocators and baked ownership into otherwise straight…

How is that not how garbage collectors work? You start at a gc root and chase pointers all through memory. Then do the same thing again and again. (I'm assuming we're talking about a standard, generational mark-and-sweep gc.)

>> we have a giant for loop that iterates over all of memory over and over and over

> How is that not how garbage collectors work?... I'm assuming we're talking about a standard, generational mark-and-sweep gc

GCs do not scan "all memory", but small fraction of memory. In case of generational GC the scanned fraction of memory is (usually) limited to single generation. Even without generational approach scanning heap itself is frequently avoided in favor of scanning separate data structure with highly compressed representation of object set.

GCs do not generally iterate over memory just because they can. They either reclaim space for new allocations, move things around to reduce fragmentation or fire periodically in response to increased allocation rate. If your program does not make allocations, it may never incur a GC at all.

The grandparent comment makes it sound like garbage collection is a simple effort, conducted solely by distinct GC code ("giant for loop"). This is often not the case: for example, JVM may generate additional memory barriers in any code, that uses references (exact nature and purpose of memory barriers depends on GC being used [1]). Augmenting the code with those barriers allows GC to operate more efficiently and quickly: achieve smaller pauses, scan less memory, collect memory for some threads without disturbing others.

[1]: https://shipilev.net/jvm/diy-gc/#_barriers

Re: For Better Computing, Liberate CPUs from Garbage Collection

#384

Post by mar77i »

kazinator wrote: post #347

I'm skeptical; GC is closely tied to programming language run-times. How is some accelerator going to know which pointers in an object are references to other GC objects and which are non-GC-domain pointers (like handles to foreign objects and whatnot)? How does the accelerator handle weak references and finalization? People aren't going to massively rewrite their language run-times to target a boutique GC accelerato…

I remember ruby had some approach with reusing previously allocated yet out of scope objects. I can very well imagine taking this concept above and beyond, and having virtually separated stacks for each type...

Re: For Better Computing, Liberate CPUs from Garbage Collection

#385

Post by SilasX »

Arelius wrote: post #381
SilasX wrote: post #379

Earlier quoted context omitted.

>I find RAII a lot easier to model and think about than "you drop this reference and one day maybe your object is destroyed, but don't really rely on that" Heh, I just realized this is what we depend on to remove commits from Github. "Uh, just delete any branches that contain it, and, uh, it'll get removed ... like, eventually." (of course you have to assume any secret data is compromised)

This is a fundamental git model. see `git help gc`

I know I can clean up locally, I meant deleting the commits on the github server/repo.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#386

Post by mcguire »

steveklabnik wrote: post #346
mcguire wrote: post #344

Earlier quoted context omitted.

? C++ and Objective C inherited C's memory model and thus don't have a good memory management option. Rust is explicitly a systems language, meaning stronger memory models are out of scope, and then inherited most of C++'s idioms. Other than those, what popular languages are specifically choosing reference counting as a primary GC method?

Swift.

Which inherits its memory management from Objective C.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#387

Post by dullgiulio »

tempguy9999 wrote: post #228
fnord123 wrote: post #178

Earlier quoted context omitted.

>it causes a lot of updates at each pointer 'take' even if it's a read only This isn't required in the read-only case. If you're only borrowing the value, for example, taking a const& in C++ and not holding onto it, then you can cast to the underlying type and use the reference. In Rust you can also just borrow: https://play.integer32.com/?version=stable&mode=debug&editio... >trashing caches ARC is usually atomic ref…

> This isn't required in the read-only case which is why I carefully used the word Naive, however I had little time to expand on it so I can't blame anyone for overlooking that. > If you're only borrowing the value... Then you give examples of manually offloading memory management to the programmer. It should be done, and I believe the book I reference covers it (can't find it now, sorry), but definitely not by the p…

In regards to memory fragmentation, you probably think of GC with compaction. Not all GCs are like that, but that is a plus for GCs if use the heap a lot and need cache friendliness.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#388

Post by kbenson »

kazinator wrote: post #365
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…

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 s…

> when we push down a "bump" of complexity in one place, seventeen bumps at least as large can crop up elsewhere.

I think you've taken the metaphor about a waterbed and design advice a bit too literally. :)

When you push complexity down in one area and it pops up in another, there's no guarantee that it's of the same overall magnitude, as it would be in a real waterbed. Sometimes it's larger, and sometimes it's smaller.

The same idea applies to whether we should all write assembly or use a higher level language to accomplish our computing needs. We push down the complexity of knowing exactly what the processor is doing at any one moment for a easier to manage overall view of what we want to accomplish. Overall, the net effect is a lessening of complexity for most people, but for those that want or need to know exactly what is going on, there more complexity. Still, overall I think the net effect is less complexity for most people, vastly outweighing the time and effort a few put into figuring out why something isn't as expected.

On the other end of the spectrum, using a dynamically typed scripting language might save people a lot of time initially, or when prototyping, or on smaller programs, but as those programs become larger, the lack of constraints (which provide a small but immediate complexity hurdle) can build up and overwhelm a large project that might otherwise had an easier time if some more constraints were required along the way.

No one tool or paradigm is perfect for every task, and we should not expect one to be. We don't usually commute in dump trucks, and we don't usually haul lots of debris in compact cars. I see no reason why it should be any different for programming languages. Sometimes all you need is a 10 line bash script, and given that information, I doubt there's a huge level of complexity that's going to rear its head later because I didn't write it in some lower level language.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#389

Post by MaxBarraclough »

xxs wrote: post #98
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…

Garbage collection is godsend when it comes to concurrency algorithms. Determine liveness is hard on its own, ABA issues are totally eliminated by GC enabled setups. As for energy costs, I'd bet generation/copy collectors are cheaper than malloc/free. They are way cheaper than ref. counting which requires deeper pipelines + branch predictor extra load; ref. counting with concurrency requires atomics, cache coherency…

> ABA issues are totally eliminated by GC enabled setups

Doesn't the same approach work with a thread-safe reference-counting approach to memory-management?

The big difference between tracing GC, and reference-counting, is the ability to handle reference-cycles. Is that relevant here?

Post reply on HN