For Better Computing, Liberate CPUs from Garbage Collection
spectrum.ieee.org
For Better Computing, Liberate CPUs from Garbage Collection
1–10 of 460 posts
Re: For Better Computing, Liberate CPUs from Garbage Collection
#2Readable copy of the paper at Berkeley:
https://people.eecs.berkeley.edu/~krste/papers/maas-isca18-h...
ETA: this doesn't seem to be quite the paper that the story refers to, but undoubtedly describes the same work in enough detail for people to get the gist of it. Darn paywalls.
Re: For Better Computing, Liberate CPUs from Garbage Collection
#3I’m probably wrong, but didn’t the Symbolics LISP machines have some kind of hardware support for GC?
I think for platforms like Android this makes a lot of sense. Should help quite a bit with battery consumption and responsiveness. Also makes sense for server loads in Java or Go.
Re: For Better Computing, Liberate CPUs from Garbage Collection
#4I’m probably wrong, but didn’t the Symbolics LISP machines have some kind of hardware support for GC? I think for platforms like Android this makes a lot of sense. Should help quite a bit with battery consumption and responsiveness. Also makes sense for server loads in Java or Go.
It did.
Re: For Better Computing, Liberate CPUs from Garbage Collection
#5It does seem like just doing it in hardware may be a linear gain but isn't a fundamentally better algorithm. There's a proof that you do need to pause your program eventually, if you want to be sure you get all the garbage.
Re: For Better Computing, Liberate CPUs from Garbage Collection
#6I’m probably wrong, but didn’t the Symbolics LISP machines have some kind of hardware support for GC? I think for platforms like Android this makes a lot of sense. Should help quite a bit with battery consumption and responsiveness. Also makes sense for server loads in Java or Go.
A https://en.wikipedia.org/wiki/Tagged_architecture yes. Tags make life a bit easier for the CPU when it accesses objects and is deciding what to do with them, but the CPU is still doing all the work and walk the RAM to do the GC. (I vaguely recall stories about Lisp machine users who would turn off GC while working, and then let it run when they left work and returned the next day.) The idea here seems to be to have an entire separate chip, a specialized CPU, which walks RAM independently of the 'main' CPUs, whose only task is freeing up memory.
Re: For Better Computing, Liberate CPUs from Garbage Collection
#7While we're at it, how about we liberate CPUs and caches from communication between threads and cores?
Re: For Better Computing, Liberate CPUs from Garbage Collection
#8From 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, how much would that reduce global emissions caused by data centers?
Re: For Better Computing, Liberate CPUs from Garbage Collection
#9Azul 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 CPUs. Died a quick life despite the cool factor.
Re: For Better Computing, Liberate CPUs from Garbage Collection
#10It does seem like just doing it in hardware may be a linear gain but isn't a fundamentally better algorithm. There's a proof that you do need to pause your program eventually, if you want to be sure you get all the garbage.
Hardware is fundamentally parallel, CPUs are fundamentally serial; it is possible for a hardware solution to have a super-linear speedup in time.
As a simple example, what is the time complexity of zeroing out n bytes of memory. With a CPU, this is O(n). However, with proper hardware support, this can be done in O(1) time.
For a simple garbage collecting example (no idea how their chip does it), consider a simple mark and sweep algorithm. Assume the chip has an internal object graph. At the begining of GC, only root nodes are tagged. At each step, the neighboor of every tagged node is tagged. With a CPU, this step takes at least Ω(n) time, where n is the number of tagged nodes. However, if this is done entirely by hardware, then (depending on how the hardware is designed) each node can independently look at its neighboors and complete a single step in just O(1) time.
Moving stuff to hardware gives you a set of primitives that is asymptotically different than the primitives you have on a general purpose CPU.