4 ms·

As glad as I am to see someone mention all this great old technology, I feel compelled to point out that the GC on the MIT Scheme chip was not pauseless. It wa

As glad as I am to see someone mention all this great old technology, I feel compelled to point out that the GC on the MIT Scheme chip was not pauseless. It was a fairly simple mark-sweep collector.

nickpsecurity 11y ago
I'm talking about this one (see Storage Management on p17): http://repository.readscheme.org/ftp/papers/ai-lab-pubs/AIM-514.pdf http://repository.readscheme.org/ftp/papers/ai-lab-pubs/AIM-... They had to leave it out of the first prototype due to space constraints but describe the approach. They build a second, state machine into storage interface that continuously looks for stuff it can reclaim. The idea was clearly to make it concurrent and use dedicated circuits. An enterprising reader of old wisdom would combine this with any number of parallel/concurrent algorithms in literature to achieve GC w/ predictable, performance impact. That work was later referenced in a 1976 treatment of the subject that worked out foundational issues for concurrent collection: http://repository.tudelft.nl/assets/uuid:8b7d64a2-e9a7-4b04-93fe-1845088e5d58/P_1866_1258.pdf http://repository.tudelft.nl/assets/uuid:8b7d64a2-e9a7-4b04-... Most work in GC from them on focused on software implementations. Did find a hardware implementation in embedded space with some interesting choices: http://www.ece.iastate.edu/~morris/papers/IEEE_TMC_03.pdf http://www.ece.iastate.edu/~morris/papers/IEEE_TMC_03.pdf So, the original LISP machines and many later used mark-and-sweep often around or during a heap exhaustion. There were concurrent ones, with most using software. The Steele chip describes a concurrent design w/ straightforward implementation in hardware. That combined with literature gave people more than enough to acceptably solve this problem.

4 ms·

As glad as I am to see someone mention all this great old technology, I feel compelled to point out that the GC on the MIT Scheme chip was not pauseless. It wa

by ScottBurson 11y ago

As glad as I am to see someone mention all this great old technology, I feel compelled to point out that the GC on the MIT Scheme chip was not pauseless. It was a fairly simple mark-sweep collector.

nickpsecurity 11y ago
I'm talking about this one (see Storage Management on p17): http://repository.readscheme.org/ftp/papers/ai-lab-pubs/AIM-514.pdf http://repository.readscheme.org/ftp/papers/ai-lab-pubs/AIM-... They had to leave it out of the first prototype due to space constraints but describe the approach. They build a second, state machine into storage interface that continuously looks for stuff it can reclaim. The idea was clearly to make it concurrent and use dedicated circuits. An enterprising reader of old wisdom would combine this with any number of parallel/concurrent algorithms in literature to achieve GC w/ predictable, performance impact. That work was later referenced in a 1976 treatment of the subject that worked out foundational issues for concurrent collection: http://repository.tudelft.nl/assets/uuid:8b7d64a2-e9a7-4b04-93fe-1845088e5d58/P_1866_1258.pdf http://repository.tudelft.nl/assets/uuid:8b7d64a2-e9a7-4b04-... Most work in GC from them on focused on software implementations. Did find a hardware implementation in embedded space with some interesting choices: http://www.ece.iastate.edu/~morris/papers/IEEE_TMC_03.pdf http://www.ece.iastate.edu/~morris/papers/IEEE_TMC_03.pdf So, the original LISP machines and many later used mark-and-sweep often around or during a heap exhaustion. There were concurrent ones, with most using software. The Steele chip describes a concurrent design w/ straightforward implementation in hardware. That combined with literature gave people more than enough to acceptably solve this problem.