For Better Computing, Liberate CPUs from Garbage Collection • Hacker News Board

Re: For Better Computing, Liberate CPUs from Garbage Collection

#311

Post by norswap » Thu, May 09, 2019, 4:00 PM UTC

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.

I've always seen automatic reference counting classified as GC.

e.g. https://users.cecs.anu.edu.au/~steveb/pubs/papers/rc-ismm-20...

> Reference counting and tracing are the two fundamental approaches that have underpinned garbage collection since 1960.

https://www.cs.virginia.edu/~cs415/reading/bacon-garbage.pdf

> Tracing and reference counting are uniformly viewed as being fundamentally different approaches to garbage collection that possess very distinct performance properties.

This last one is great if you want to understand GC tradeoffs btw, highly recommend it.

---

And as the first paper implies, refcounting is often slower (because it trashes caches). The issue is having to propagate the diminution of refcounts amongst a graph of references. This also creates de facto "pauses", much like tracing GC (although arguably more predictable!).

And this "propagation of diminished refcount" is very much a memory traversal — (probably) smaller in scope than (non-incremental) tracing, but also much less local.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#312

Post by simias » Thu, May 09, 2019, 4:00 PM UTC

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…

>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.

This is like bizarro world to me. I genuinely can't comprehend that.

Here's how memory management looks like to me, using concrete examples in languages featuring RAII like C++ or Rust:

- I have a function that needs to compute a hash so I need to allocate a hash context for it. If it's small I'll put it on the stack, otherwise it'll go on the heap. In either case when the function returns the destructor is automatically called.

- I have a function that takes the name of a file as parameter and returns its contents in a buffer. Clearly the buffer needs to be allocated on the heap, so I allocate a large enough vector or string read into it and return that. The caller will then either use it and drop it immediately or store it somewhere to be dropped later, either on its own or as part of the structure it belongs to. In either case the destructor will be called automatically and the memory will be freed.

That's easily 99.9% of what memory management looks like in the programs that I write. I have absolutely no idea what using a GC would change at any point here. Note that while this is technically "manual" memory management I never have to explicitly free anything and in the vast majority of cases I don't even have to bother implementing the destructor myself (I basically only need to implement them if I need to release external resources like, for instance, raw OpenGL handles, file descriptors and the like. The GC wouldn't help either here).

It's genuinely a non-issue as far as I'm concerned. I literally never think "uh, I have no idea when this object won't be used anymore, I wish I had a GC to figure it out". I can't even imagine when such a scenario would crop up.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#313

Post by cblades » Thu, May 09, 2019, 4:03 PM UTC

dleslie wrote: post #309

cblades wrote: post #302

Earlier quoted context omitted.

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

For 95% of the code you write it's not a concern; that last 5% sure can eat up time if your software has any concern about performance.

Totally agree. I don't think that tradeoff is particularly out-balanced by the time it takes to do manual memory management.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#314

Post by dleslie » Thu, May 09, 2019, 4:04 PM UTC

norswap wrote: post #311

dleslie wrote: post #307

Earlier quoted context omitted.

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.

I've always seen automatic reference counting classified as GC. e.g. https://users.cecs.anu.edu.au/~steveb/pubs/papers/rc-ismm-20... > Reference counting and tracing are the two fundamental approaches that have underpinned garbage collection since 1960. https://www.cs.virginia.edu/~cs415/reading/bacon-garbage.pdf > Tracing and reference counting are uniformly viewed as being fundamentally different approaches to garb…

Interesting! I'll be reading that today.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#315

Post by exabrial » Thu, May 09, 2019, 4:04 PM UTC

p_l wrote: post #129

exabrial wrote: post #9

Azul Systems has asked Intel to do this once... but instead created their own processors with interesting memory barrier properties for awhile that greatly sped up JVMs beyond what was capable (at the time) on x86-32/ppc/sparc. Eventually they gave up and became a purely software company, but their "Java Mainframe" product was many times faster than the Intels of the age executing the same code despite much slower CP…

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?

Re: For Better Computing, Liberate CPUs from Garbage Collection

#316

Post by cblades » Thu, May 09, 2019, 4:04 PM UTC

simias wrote: post #312

cblades wrote: post #302

Earlier quoted context omitted.

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

>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. This is like bizarro world to me. I genuinely can't comprehend that. Here's how memory management looks like to me, using concrete examples in languages featuring RAII like C++ or Rust:…

>he caller will then either use it and drop it immediately or store it somewhere to be dropped later, either on its own or as part of the structure it belongs to.

You're glossing over a lot of complexity there. That's the entire point of GC, you don't have to think about when it's dropped.

Also, I wasn't arguing for the blanket necessity of GC in all contexts and for all problems.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#317

Post by andreareina » Thu, May 09, 2019, 4:05 PM UTC

daemin wrote: post #170

One talking point I'd like to ask is: For small short lived scripts and applications, do we even need to free any memory these days? For example you write a script which takes several seconds to execute, moves files, computes stuff with strings, etc. Should we really invest time and effort in the script interpreter to free the memory, where instead we can just exit normally and let the OS handle the clean up. I would…

Git reportedly[1] doesn't much bother with free()

[1] https://www.youtube.com/watch?v=dBSHLb1B8sw&t=115

Re: For Better Computing, Liberate CPUs from Garbage Collection

#318

Post by norswap » Thu, May 09, 2019, 4:07 PM UTC

simias wrote: post #267

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…

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 mostly agree with your point on RAII.

But I don't think OP was advocating RAII.

The typical argument for GC is that it is less error-prone than even RAII. And I agree with that point. It's a trade-off on which you have to decide on. I think the tiny perf penalty is often worth it.

You can still retain stale data under a GC, but real leaks (unreachable allocated memory) are precluded — which is usually considered (not unreasonably) to be the more common and serious problem.

I think GC is a sane default because it's less error prone, and god knows the average developer will make enough errors as it is. I'd trust myself with manual memory management, but not a random group of developers I don't know. What about you?

Re: For Better Computing, Liberate CPUs from Garbage Collection

#319

Post by kllrnohj » Thu, May 09, 2019, 4:07 PM UTC

vlovich123 wrote: post #65

kllrnohj wrote: post #50

Earlier quoted context omitted.

It's not at all zero CPU overhead, not even close. retain & release are thread-safe, meaning atomic ref count. Very comparable in cost to std::shared_ptr or Rust's Arc . Both of which also automatically insert the calls to inc & dec ref counts. It's cool that you don't need to bother with specifying the type as being std::shared_ptr or Arc , but it's not particularly novel, either. It's "just" syntax sugar (or lack o…

Almost but not quite. Clang has very special rules around ARC that allow it to perform additional optimizations that would otherwise be illegal [1]. [1] https://clang.llvm.org/docs/AutomaticReferenceCounting.html#...

That just lets it release earlier, not retain/release less often.

ARC can't do anything magic here vs. something like really careful use of std::move & const references.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#320

Post by c-smile » Thu, May 09, 2019, 4:09 PM UTC

simias wrote: post #267

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…

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…

> GCs should be an opt-in niche tool used to solve specific problems.

That is true. Sciter (https://sciter.com) contains implementation of DOM(tree), CSS and script.

DOM is a regular tree structure - each element of the tree has strictly one parent and no cycles on the tree in principle. It does not need GC at all and is not using it for DOM tree management.

CSS is a collection of collections of name/value pairs. No loops. It does not need GC at all.

And only script uses GC for the simple reason: in UI, ownership graph of script objects frequently contains loops. Yet lifespan of objects is unknown at compile time - depends on user interactions.

Even purely native GUI application benefits from GC when that GC is used in places where it is needed. GC is just one way (of many) of doing memory management.

Ideally it should be a multi-paradigm programming language and environment that allows to use as explicit memory management (and so RAII, memory pools, etc) as a GC.

    int *ptr = …;
    gcable int* gptr = …;

But unfortunately such dualism is hard to achieve.