I think how DMA operates needs another serious look. Right now we have to fetch everything into the CPU before we can make decisions. What if we had asynchronous HW embedded within the memory that could be given a small (safe) executable program to process the memory in-place rather than evaluating it on the CPU. In other words, a linked list would be much faster and simpler to traverse.

A lot of the software architecture theory we learn is based on existing HW paradigms without much thought being given to how we can change HW paradigms. By nature HW is massively parallel but where physical distance from compute = latency (vs the ultimately serial execution nature of traditional CPUs that can process all data at blistering speed but only one at a time with some SIMD exceptions). There are real-world benefits to this kind of design - memory is cheap and simple to manufacture and abundantly available. The downside though is that the CPU is sitting doing nothing but waiting for memory most of the time, especially when processing large data sets.

Imagine how efficient a GC algorithm would be if it could compute a result in the background just doing a concurrent mark and sweep, perhaps as part of a DRAM refresh cycle so that you could even choose to stop refreshing that RAM because your application no longer needs that row.

The power and performance savings are pretty enticing.