In general, my areas of research are operating and runtime systems and compilers. Specifically, I research memory management techniques for heterogeneous memory architectures. With the introduction of persistent and die-stacked memories, it will soon no longer be safe to assume that a system's main memory consists entirely of a single technology. Unfortunately, no modern operating system is able to properly handle this situation. Linux, for example, at best, will expose each type of memory as a separate NUMA node to which whole processes can be bound or migrated.

There are a number of issues with this approach. In the case of die-stacked memories, binding an entire process results in precious high-performance memory being used for a process' non-performance-intensive tasks. In the case of persistent memories, binding the entire process results in its high-performance code areas being placed in lower-performance memory. This also requires specific binding at execution time, which places a small burden on the end-user.

One current solution seems to be the creation of new allocation functions that allow a process' individual memory allocations to be targeted at a specific memory region. I think this is a step in the right direction, but still places a burden on the developer to properly target each malloc() call. It requires existing software to be modified and redistributed and may not be possible for every program out there that would benefit from these new technologies.

My belief is that the change must happen at the OS level instead of the process or library level. A lightweight profiling technique can identify memory regions within a running process that would benefit from migration from standard RAM to a different type of memory, and move these regions (or parts of them) on a page-by-page basis. I think this would allow more efficient use of lower-density memories like die-stacked RAM.

Of course, one of the issues with this migration technique is that existing kernel migration functions are not lightweight enough to make this approach beneficial. Even if the migration function is modified to allow a selected, small list of pages to be moved, it's slow (trust me, I've tried). So, the first step is to fix that. More on this as research proceeds.