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

41–50 of 460 posts

Re: For Better Computing, Liberate CPUs from Garbage Collection

#41

Post by AnimalMuppet »

gizmo686 wrote: post #34
AnimalMuppet wrote: post #28

Earlier quoted context omitted.

But hardware that has to interface with the main memory can't be fundamentally parallel, because of memory bandwidth limitations. If you want to make this part of the memory , then my objection does not apply. But if it's an external chip to the memory, you still are fundamentally serial.

How much does it need to interface with main memory? If the external chip has its own memory then it can maintain its own view of the object graph. The software can update it when references are made/deleted and query it when an allocation needs to be made. There is still the overhead of communicating when references are made/deleted, but you need that anyway, as something that only looks at memory doesn't know what…

I'm presuming some kind of a heap. That heap has something like a list of free blocks. Who keeps that list - the main memory, or this other chip? If the main memory does, then when you garbage collect blocks you have to change the main memory. If the chip keeps the list, then yes, the chip can do it all internally. But...

What about multitasking? If there are N programs running, and each has their own heap, the chip has to be able to keep track of each of them. Or it has to be able to keep track of one monster heap that uses almost all of the available memory, even if it's occupied by a bunch of small allocations. All this without using any (main) memory itself. This chip would have to have a large amount of onboard memory itself to pull that off. The very worst scenario would be to be a long way into a run of a program that thrashed the heap, and then the GC chip ran out of slots. You can't (easily) go back and re-do the heap to have the heap control in the main memory, and you can't continue with the chip managing the heap.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#42

Post by aidenn0 »

xenadu02 wrote: post #33
aidenn0 wrote: post #24

Earlier quoted context omitted.

That would seem to eliminate all moving GC algorithms though.

Not really though you may want to. The main CPU could compact memory if it felt fragmentation was high enough to warrant it. By its nature the traffic is asynchronous so the CPU won't do a perfect compaction (it won't have processed all the inbound messages to mark garbage as free) but it would probably be close enough. The big win here is making it all async. No need to stop the world, issue write barriers to applic…

Compacting without tracing can't really be done, and not all moving algorithms are collect and compact (though collect and compact seems to have won over other moving algorithms in the SMP erra)

Re: For Better Computing, Liberate CPUs from Garbage Collection

#43

Post by Simple_Guy »

CoolGuySteve wrote: post #8

From an environmental perspective, I wonder how much energy is consumed (and emissions generated) for garbage collection and interpreters. These things exist to make programming easier but are then duplicated across thousands of servers. If everyone used some compiled language that was just a little simpler, a little safer, had just a little better memory management/tooling, or like here, had better hardware support,…

If you want to reduce emission it is more effective to look at big things like car usage and space heating rather than interpreter use.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#44

Post by kev009 »

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…

IBM POWER, Z, and Oracle SPARC silicon have instructions designed explicitly for GC and other common managed runtime tasks.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#45

Post by mailslot »

ygra wrote: post #40
mailslot wrote: post #32

Earlier quoted context omitted.

Sure, if you’re using pre-1990’s memory management. Best practices have evolved far beyond the explicit use of malloc & free and unsafe string handling. Most popular dynamic languages don’t use garbage collection under the hood anyway. In Python and many other runtimes, it’s primarily reference counted.

Python still uses mark and sweep occasionally to clean up structures where reference counting fails.

It has optional cycle detection, yep. But... you could also just spend a couple of minutes to not have cyclic references.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#46

Post by kllrnohj »

mailslot wrote: post #32
SmooL wrote: post #20

Earlier quoted context omitted.

Which has been shown time and time again to be the source of many serious software bugs and exploits

Sure, if you’re using pre-1990’s memory management. Best practices have evolved far beyond the explicit use of malloc & free and unsafe string handling. Most popular dynamic languages don’t use garbage collection under the hood anyway. In Python and many other runtimes, it’s primarily reference counted.

Python largely only gets away with ref counting because it doesn't support concurrent access. The GIL means it's basically single-threaded ref counting, which is much cheaper than an actual atomic ref count (like std::shared_ptr)

Scattering atomic ref counts everywhere gets extremely expensive very quickly.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#49

Post by didibus »

Maybe I'm naive, but with multi-core CPUs, and parallel GCs, isn't it somehow the same? One core is mostly only used for GC, while the others do other things?

Edit: I guess they mention their chip itself can do it at a high level of parallelism, so that's probably one more advantage. But CPUs with additional slower cores and a lot more cores are in the works as well.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#50

Post by kllrnohj »

Eric_WVGG wrote: post #16
mailslot wrote: post #13

Seems like we could just as easily stop using garbage collection. ... or even go back to reference counting / smart pointers and just live with the “limitation” that we can’t have circular references.

doesn’t seem cool to admire Apple technologies, but ARC seems to work amazingly well with zero CPU overhead

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 of syntax sugar I guess?)

Post reply on HN