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

401–410 of 460 posts

Re: For Better Computing, Liberate CPUs from Garbage Collection

#401

Post by Shikadi »

rayiner wrote: post #326
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…

> When you say "manual memory management" if you're thinking C-style malloc-free then you have a point, it's very easy to forget a free() somewhere. But any language with destructors can handle these situations without much more overhead than GC-based approaches. What happens when that object is shared and still referenced from somewhere else? Now you have a use after free error waiting to happen.

That's what smart pointers/ref counting is for

Re: For Better Computing, Liberate CPUs from Garbage Collection

#402

Post by crimsonalucard »

norswap wrote: post #250
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…

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…

Any lifetime that depends on an io loop or user input cannot be determined within the loop Period. Even if you have an asic designed for garbage collection. It cannot even be dynamic.

Basically in these cases you have to extend the lifetime to beyond the point of indeterminism into the point of determinism or in other words move the life time outside of the loop.

Worst case scenario you move the lifetime to right before termination of the program.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#403

Post by kazinator »

Shikadi wrote: post #399
kazinator wrote: post #354

Earlier quoted context omitted.

> Why not free the resources here while you're at it? Because you do not have an exclusive reference to all of them; we could be freeing something that is still in use somewhere. So why not reference-count? Because reference counting is slow, and must be meticulously maintained (here, languages help with constructs like smart pointers), and doesn't handle cycles in the object structure. > I find RAII a lot easier to…

RAII has nothing to do with reference counting, it stands for resource acquisition is initialization. In C++ that means the lifetime of a resource is tied to the creation and destruction of an object. Often when people talk about RAII and C++ they are also referring to destructors being called when an object goes out of scope, so if an object that contains an object containing some allocated resource goes out of scop…

RAII is commonly used for representing smart pointers that manage references to objects that themselves have otherwise pervasive lifetimes.

RAII not managing any shared resources is trivial and uninteresting. The lifecycle of an object that is confined to a single lexical scope can be handled manually and verified by visual inspection (though of course it is more reliable to automate that with RAII or macros, not to mention less verbose).

Re: For Better Computing, Liberate CPUs from Garbage Collection

#404

Post by tptacek »

Shikadi wrote: post #401
rayiner wrote: post #326

Earlier quoted context omitted.

> When you say "manual memory management" if you're thinking C-style malloc-free then you have a point, it's very easy to forget a free() somewhere. But any language with destructors can handle these situations without much more overhead than GC-based approaches. What happens when that object is shared and still referenced from somewhere else? Now you have a use after free error waiting to happen.

That's what smart pointers/ref counting is for

C++ is the flagship language for smart pointers and UAF memory corruption flaws are endemic to it.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#405

Post by kazinator »

kbenson wrote: post #388
kazinator wrote: post #365

Earlier quoted context omitted.

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

The waterbed theory in fact explicitly states that the amount of complexity is preserved no matter how it is distributed. The Wikipedia definition of it explicitly talks about how the volume of water remains constant due to its incompressibility.

If that isn't taken literally, it informs of nothing we don't already suspect. It tells us that for each functional requirement, there is at least one piece of code in the system somewhere. If we remove these lines of code from one place, or places, something has to be added elsewhere (possibly way more lines, or way fewer) so that the requirement remains implemented.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#406

Post by [deleted] »

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.

[deleted]

Re: For Better Computing, Liberate CPUs from Garbage Collection

#407

Post by irq11 »

cblades wrote: post #302
irq11 wrote: post #292

Earlier quoted context omitted.

Having spent years writing code in both GC’ed and non-GC’ed languages, it’s pretty clear that it programmers spend about the same amount of time worrying about memory management with either paradigm. The main differences are that people using GC systems spend their time doing magical incantations to manage the GC wizard, and they’re a lot more smug about the goodness of their system.

>programmers spend about the same amount of time worrying about memory management with either paradigm I have no idea how you've come to that conclusion. For the vast majority of memory allocation in any GC'd language I can think of, you spend zero time thinking about memory management 98% of the time. whereas in a manual language, you must consider it every time you allocate memory . That's not a bad thing, it's oft…

”I have no idea how you've come to that conclusion.”

30 years of experience.

”For the vast majority of memory allocation in any GC'd language I can think of, you spend zero time thinking about memory management 98% of the time.”

No, you think about 98% of the code 0% of the time. The remaining 2% ends up causing so many problems that your amortized time spent on memory management is the same.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#408

Post by McWobbleston »

mafribe wrote: post #115
reitzensteinm wrote: post #92

Earlier quoted context omitted.

In my opinion, shared memory mutability is the actual bad idea that's going to eventually die. It's not just error prone, it doesn't scale; try mutating the same cache line from two threads on an Intel desktop chip and see how that goes. Let alone across mesh buses, chiplets, dual sockets or (God forbid) the network. Garbage collection on immutable data is vastly easier; it's intrinsically non blocking, concurrent an…

Au contraire , as memory, and hence workloads, get bigger, the cost of copying increases, and copying rather than sharing becomes ever more expensive. I just spoke with a physicist who told me that his current experiment produces 200 Gigabytes of data per second! Copying that amount of data around for immutability is inconceivable. Indeed the single biggest factor for performance for such workloads is minimising the…

Usually when working with immutable data you don't need to copy it around, you can just pass it around via reference, and the data structure will support cheap "updates". You can see this in F# and Clojure where immutable maps are supported by tree structures, and operations like add/remove return a new reference without touching the original while being reasonably performant.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#409

Post by irq11 »

cblades wrote: post #341
simias wrote: post #332

Earlier quoted context omitted.

Can you point out a specific example then? I'm genuinely not trying to play dumb. I very honestly not see that complexity that should be obvious to me given that I spend most of my time writing code in non-GC languages. Maybe it's just Stockholm syndrome and I'm so used to working that way that I don't even see the problem anymore but there are now a long string of replies talking abstractly about the overhead of pro…

>store it somewhere to be dropped later, either on its own or as part of the structure it belongs to. Wherever you're storing the reference, you have to eventually free the memory. That propagates memory-management code throughout your codebase, and is error-prone. I totally agree that if you're allocating on the stack it's a non-issue. If you're returning a reference and always freeing in the caller, that's pretty e…

”If you're storing a reference on the heap somewhere, you suddenly have dynamic lifetimes with indeterminate reference counts, and it gets quite hard to 1) correctly manage memory and 2) verify that you're correctly managing memory.”

It is axiomatic that GC programs leak memory. I’ve never encountered one that didn’t. The difference is that it’s harder to see, and most programmers who have grown up with GC systems don’t know how to fix it.

”The alternative is that in all three instances in a GC language, I don't have to care about memory management.”

Again, no. The alternative is thar you aren’t paying attention, and don’t see the leaks until they become fatal. Just like cockroaches, you have them, somewhere.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#410

Post by garmaine »

stcredzero wrote: post #371
garmaine wrote: post #47

Earlier quoted context omitted.

Many ARM chips have this.

Any useful links? What are the terms I should search for?

It’s called a “weak ordering memory model.” Synchronization requires explicit memory fence instructions.

RISC-V, btw, supports both weak and strong memory models as an implementation choice.

Post reply on HN