My research interests revolve around distributed and modular systems, stream processing, and runtimes. I am particularly interested in finding the right abstractions at every level of a system, the correlation between abstractions and module interfaces, and their influence on optimizations.
Abstractions typically simplify the use of the abstracted resource by hiding some of its details. Consequently, the potential for optimizations is reduced. An example thereof is the process abstraction used in most operating systems today. It virtualizes the resources of the machine—memory, processing cores, devices—homogeneously behind a narrow interface of system calls. I refer to this property as the hourglass architecture, illustrated in the figure above. The narrow interface between operating system and application is in the middle, where the upper and the lower parts meet. It precludes the rich exchange of knowledge that is present in both parts. Within these parts, a richer exchange of information takes place. Examples include the compilation of an application from a high level description that is harvested for optimization opportunities or the operating system performing NUMA-aware scheduling.
While the conflict between abstractions and optimizations is generally true, abstractions do not have to preclude optimizations per se. Carefully designed systems can still provide both, a simple abstraction as well as full information and control over the abstracted resource.
In the context of operating system and application interaction, a number of ideas naturally arise. Most of these ideas are not new and have already been researched independently. Examples include the fusion of an operating system's and a language runtime's memory management, diverse upcalls from the operating system into applications, and specific buffers for I/O. These techniques are worthwhile to be revisited in the light of recent heterogeneous hardware architectures that add the new question of where to the existing question of how.
In the context of software systems, implementing abstractions not only serves knowledge exchange with the underlying operating system but also benefits interoperability and flexibility. This is particularly true if the boundaries of abstractions merge into module boundaries. Taken stream processing systems as an example, a storage instance provides methods to put and get items. This abstraction must not preclude a richer interface to the storage manager, where operators can, e.g., access items through an index for optimal performance “inside” this system. However, the simple abstraction facilitates the integration with other systems that might be implemented differently but share the same abstractions. Furthermore, systems built in a modular way and with well defined abstractions are generally easier to adapt or distribute.
I want to understand the exact correlation between abstractions and software modules or interfaces. Note that in the above paragraph it is possible to replace abstraction with interface without loss of consistency or meaning. I also want to explore how abstractions or interfaces in a whole system stack must look like to allow knowledge exchange between all layers from high level application description to hardware. These two research questions are closely related and working on either of them is likely to provide insight into the other as well.