done!

the semester is essentially over, modulo the par lab retreat / workshop on the 7th-9th [I guess I'm giving a demo?]

next month:

• flapjax paper
• finish delegated DOM view paper
• parallel css talk and more code / semantics
  

:)

Preliminary second result

The web could get a bit faster. This is modeling a speedup on a different 10% of browser CPU time.


Likes: task parallelism via work-stealing from stacks, lexical scoping (eg., Cilk).

Dislikes: heavyweight task creation, crazy-wtf scoping (eg., OpenMP 3.0), heavyweight build processes with bad documentation (GCC), parallelism packages requiring manual lambda-lifting (TBB).

Hurray for Heidi methodically disentangling OpenMP scoping, task creation, and scheduling rules tonight :)

Anyways, our prototypes suggest we can decrease 20% of the time to maybe 3%.. hopefully we can find someone else to look at the components in the other 80% (which I'm *way* more optimistic about -- they didn't seem as much of a research challenge) and maybe even doing this with actual browser code.

So it begins

We got our first result tonight! We've been examining how to speed up various browser components, and, getting bored from slaving away on the hardest 10% of the page load CPU time, I sat down with Siu On tonight to improve the easiest 10%:


The experiment was very unscientific and our prototype was written in Python. Thus, while this chart shows a 6x speed gain for the component, plugging in our version would do little: our sequential 100-200 line Python version was 5x slower than Firefox's C++ version.

Capabilities

I've been working with Adrienne (and, transitively, Mark Miller) on figuring out what object capabilities have to do with web programming. Some parts I think I'm getting, but others seem strange.

1. Understanding: Capabilities are a structuring tool in the systems perspective. In particular, you might want to build a policy substrate on top of the capability-secure system; the capability-secure system with associated capability patterns simplifies doing this.

2. Confusion: Why does the membrane pattern protect only the object? A membrane wraps an object's fields and methods, deeply, such that any non-primitive value outputted will also be wrapped. The membrane also provides a gatekeeper in the wrapper of an outputted value if the outputted value is equal to the inputted object to be wrapped/secured. Thus, all access to the object can be easily enabled/disabled. HOWEVER: isn't this too coarse for a low-level system mechanism? Shouldn't it be controlling access to fields and methods? An object gatekeeper can be synthesized by lumping together locks for fields and methods, but, for typical object graphs, not the other way around.

Finally... Anya's getting married! Should start booking a flight :)