Skip to main content

Post-NSDI PC Meeting Mini-Symposium

Today was the First Post-NSDI Program Committee Meeting Mini-Systems Symposium at Harvard (PNSDIPCMMSS@H2009). That is, I invited four of the NSDI'10 PC members -- Chip Killian, Dejan Kostic, Phil Levis, and Timothy Roscoe -- to give short talks at Harvard on their current research, since they were in Boston for the PC meeting anyway. It was a lot of fun - for me, anyway. Everyone else at least got a free lunch.

Chip started off with a talk on Understanding Distributed Systems, at least those implemented using Mace. He gave an overview of the Mace language (which is one of my favorite pieces of languages-meets-systems work from the past decade) and the application of model checking to automatically verify Mace programs. This, to me, is the main reason we need better high-level languages for specifying complex systems: so we can build useful tools that let us understand how those systems behave before and during deployment.

Phil gave a kind of far-out talk on a new system they are building at Stanford, called Meru, which is a federated, planetary-scale virtual world platform. The goal is to enable virtual worlds that are extensible and scalable in all kinds of ways that existing systems (such as Second Life) are not. Personally I'd like to see how this technology can be leveraged beyond games and entertainment. Why not enable virtual conferences, or at least virtual program committee meetings? There are a lot of challenges here but it's important to tease them apart from the games-driven work that has been done to date (and often quite successfully).

Dejan talked about his work on CrystalBall, which allows for online model checking to catch and even avoid bugs in a distributed system via execution steering. The running example was a buggy implementation of Paxos, and Dejan showed how their approach could avoid the bug by steering execution away from the states that led to it. Mothy asked, "as long as you're going to do this, how much of Paxos do you need to implement, anyway?" In some sense this is shifting the correctness of the system from the original code into the CrystalBall system itself, and that makes me nervous. Margo raised the point that if a system is able to avoid a bug, is there really a bug in the first place. Too deep for me!

Finally, Mothy gave a talk on their experiences implementing BarrelFish (now with Disney-friendly logo!) and some reflections on the value of undertaking a "big OS implemenation project." BarrelFish has led to some interesting offshoot research (such as clever compilers for DSLs and new ways to think about capabilities) and they have gained a lot by departing from just hacking Linux. On the other hand this is a tremendous infrastructure-building effort and having nine authors on a single SOSP paper strikes me as overkill. One thing that helps them a lot is having a couple of full time systems programmers -- not grad students! -- which I find is hard to fund on your typical NSF grant. The longevity of the artifact does seem to depend on having people around who can maintain the code over time.

I'll post slides here as soon as I have them!


Popular posts from this blog

Why I'm leaving Harvard

The word is out that I have decided to resign my tenured faculty job at Harvard to remain at Google. Obviously this will be a big change in my career, and one that I have spent a tremendous amount of time mulling over the last few months.

Rather than let rumors spread about the reasons for my move, I think I should be pretty direct in explaining my thinking here.

I should say first of all that I'm not leaving because of any problems with Harvard. On the contrary, I love Harvard, and will miss it a lot. The computer science faculty are absolutely top-notch, and the students are the best a professor could ever hope to work with. It is a fantastic environment, very supportive, and full of great people. They were crazy enough to give me tenure, and I feel no small pang of guilt for leaving now. I joined Harvard because it offered the opportunity to make a big impact on a great department at an important school, and I have no regrets about my decision to go there eight years ago. But m…

Rewriting a large production system in Go

My team at Google is wrapping up an effort to rewrite a large production system (almost) entirely in Go. I say "almost" because one component of the system -- a library for transcoding between image formats -- works perfectly well in C++, so we decided to leave it as-is. But the rest of the system is 100% Go, not just wrappers to existing modules in C++ or another language. It's been a fun experience and I thought I'd share some lessons learned.

Why rewrite?

The first question we must answer is why we considered a rewrite in the first place. When we started this project, we adopted an existing C++ based system, which had been developed over the course of a couple of years by two of our sister teams at Google. It's a good system and does its job remarkably well. However, it has been used in several different projects with vastly different goals, leading to a nontrivial accretion of cruft. Over time, it became apparent that for us to continue to innovate rapidly wo…

Running a software team at Google

I'm often asked what my job is like at Google since I left academia. I guess going from tenured professor to software engineer sounds like a big step down. Job titles aside, I'm much happier and more productive in my new role than I was in the 8 years at Harvard, though there are actually a lot of similarities between being a professor and running a software team.

I lead a team at Google's Seattle office which is responsible for a range of projects in the mobile web performance area (for more background on my team's work see my earlier blog post on the topic). One of our projects is the recently-announced data compression proxy support in Chrome Mobile. We also work on the PageSpeed suite of technologies, specifically focusing on mobile web optimization, as well as a bunch of other cool stuff that I can't talk about just yet.

My official job title is just "software engineer," which is the most common (and coveted) role at Google. (I say "coveted&quo…