Compress objects, not cache lines: an object-based compressed memory hierarchy

In the article they mention that most programs are not dominated by arrays but objects. An other cure for that is to use arrays of primitives a lot more:

https://www.youtube.com/watch?v=yy8jQgmhbAU

I once wrote an interpreter that performed some operation on interpreting a data structure. Because it seems that the interpreter was spending most of its time on interpreting the data structure, I thought it would be a good idea to 'compile' the data structure in code. That resulted in a lot of code, which took a long time to compile, but I was hoping that the compiled code would be much faster. But it turned out to be almost twice as slow. Then if dawned to me: The interpreter and the data structure fitted in the cache, while the compiled code did not.

I bet that in some cases using a dedicated memory allocator that takes care that objects that belong together are stored together, can result in execution improvements. If you using the default memory allocator, it could happen you get pieces of memory far from each other, especially if other threads are also allocating memory or because temporary objects (think string manipulations) are created during the construction of the data structure.

Although the authors have designed hardware for this, I can imagine it being used by a language's VM (e.g. the JVM), making use of cache size-aware Zippads.

Adapt a perfectly working machine to a mental crutch instead of learning data oriented design?