Wandering Thoughts archives

What matters about object oriented operating systems

Many years ago, I went to a talk about a new object oriented operating system (a research project, obviously). The presenter made a big deal about how everything in, eg, their filesystem was an object, and so things were very general and you could put anything in the directory objects, and as they went on I noticed something disturbing: while you could put all those different things into directories, none of them seemed to have the same set of methods; in fact, the methods were often significantly different.

This talk led me to a conclusion: what matters in OS object orientation is not that things are objects, but what the common operations are.

If you have no common operations, it doesn't matter that everything is an object and you have theoretical generality. Your object orientation is getting you nothing in practice, because real programs have to know about the types of objects that they are dealing with so that they know what operations they can do with them.

Correspondingly, the genius of Unix is in the common operations. These make it look 'object oriented' from the outside perspective, regardless of how it is implemented internally, because almost every 'object' responds to a set of common operations.

(Current implementations of Unix kernels are almost certainly heavily object oriented internally, despite being written in C. I know that the Linux kernel is.)

I suspect that this generalizes to many object oriented programs, although I have limited experience in OO programming (especially in traditional OO languages like C++ or Java; all my OO work has been in Python). Certainly almost all of the times I've constructed object hierarchies and the like, whether in C or in Python, the driving reason has been to be able to write common operations in a generic, object type independent way.

(This is not to say that generic containers are unimportant, especially in a language.)

RPC is surprisingly expensive

Once, long ago, I did a distributed computing project course where I tried to speed up a drawing program by moving its expensive floating point calculations (I believe it needed to calculate square roots for something) to a machine with a much faster CPU and floating point. We used Sun's RPC/XDR for this because it was both a great match for what we were doing and the obvious choice at the time, among other reasons.

Rather to our surprise the drawing program just didn't get much faster, even in the most unfavorable situation we could contrive (running on a Sun 3/50 without a floating point unit and sending the calculations to a much faster Sun 3 with a FPU). At the time the project sort of fizzled out amidst head-scratching, but now I can see that what I should have done (and what would have made an interesting report) was to dive into figuring out why it wasn't going much faster.

(I am pretty sure that if I could rewind time I would find the finger of blame pointed squarely at the overhead of RPC/XDR marshalling and demarshalling, although other interesting things might have also come up.)

However, ever since then I have had it firmly imprinted on the back of head that RPC can be surprisingly slow, and thus can be a source of hidden overhead in systems. Since all sorts of things involve 'RPC' in some form, even as general synchronous query/response message passing, this can very useful to remember.

For example, and what brought this to mind, consider the issue of memcached versus caching in SQL servers. Since normal SQL queries are already pretty time consuming, the wire format used to talk to the SQL server is probably more designed for things like system independence than high-speed, low-overhead marshalling. By contrast, with memcached you can store data blobs in a format that is as close to your memory layout as possible, and thus get demarshalling overhead down very low.