Squawks of the Parrot

VEE workshop, day 2

mprotect, which has nothing to do with the VEE workshop, would be a lot more useful if it could be done per-thread. (Or, more specifically, imposed on other threads) No joy there, though. Pity. And yes, the VEE notes here really are notes, and a bit raw. (Woo, stream of unconsciousness note taking)

Second talk was on security and exploitability. Interesting talk -- on provability of correctness using type systems. The interesting bit here is that large systems are effectively unprovable, so the sensible thing is to shrink down the base that you actually need to trust, and find a way to make those trustworthy without actually checking them, since they're still too big to sanely check. The solution they used was to have a small correctness checker (~2K lines of C code, which generated ~5Klines of assembly which they hand-checked) that checked the very large rules base for correctness, and then was used to check the JIT for a JVM. Which was really cool.

Next talk's on optimizations. Monitoring systems, adaptive tuning, tweaking of various things. Interesting. Now I'm certain that we're getting it wrong with optimizing. Or, rather, we've gotten it about as right as we can and it's time for a big Plan B. And comparisons to hardware speedups aren't valid here -- the hardware guys have both massive parallelism to exploit and started with extraordinary overhead which they've been chipping away at (so to speak). There isn't that massive parallelism for the software to exploit, and we started off sucking much less. Not that optimization's a bad thing, nor unnecessary, since it does allow for finding inefficiencies (well, a few classes of inefficiencies, at least) in the existing code. Still, we don't start with inefficiencies on the factor of billion scale like the hardware guys did. So today I'm wondering what'd happen if someone did a 6502 processor in a 90nm process at 2+GHz. (No L1 cache even, since the whole memory would fit within modern chip's L1 area anyway) Would we get a factor of 2 billion speedup? (And if so, would it matter?) Kinda makes you wonder what would happen if the next CPU shrink didn't add any features but instead took up all the extra transistor space with a couple thousand really fast Z80s... (Yeah, I know, what'd happen is we'd lose most of the win in interconnect overhead)

Mmmm, dynamic systems. (Yeah, next talk) I saw a version of this at OOPSLA a few years ago. Looking at it now, I'm lusting after some of the stuff that's being done here -- everything is mutable, dynamic, and compiles to native code. I really would love to have the resources to do this. (Hell, the resources to take the time to understand it fully) Nice to have a reminder of things that we really ought to do when doing the design of the compiler and parser modules.

Java on phones. People want it. I admit I think it's a bad idea. I like my phone to be... a phone. And that's it. But then I can put on the Luddite hat sometimes.

It's interesting to see the sorts of things the business folks want and need to get their jobs done. The J2EE middleware layers look to be almost insanely big. (The 'almost' there might be unnecessary) Lots of crud, lots of crap, and, it turns out, lots of need for semi-isolation, protection mechanisms, and lots of what really are OS types of control and protection. Nobody seems to really want to bite the bullet and do it right, or what seems like right to me. (Hell, the OS folks worked a lot of this out decades ago) A fair amount of handwavey, over-engineered stuff, though that might be my cynicism talking.

(Good grief -- 1.5-2G address spaces are too small for some Java apps. That's... insane. At least the live data set's only a few hundred megabytes, so it's not too bad)

Adding in external monitoring schemes are definitely useful, and lacking in JVMs. Gotta remember to add in some routines to the embedding interface to allow for external querying of state, and external runtime monitoring. Event posting too. Feh. Should specify events.

Oh, and for some reason the phrase "World's largest microscope" really amuses me. Call it a character flaw, I guess.

The Azul talk was both interesting and really frustrating. Looks like they're doing all sorts of clever things with hardware and software in some sort of combo Java Big Iron thing, but there wasn't enough info to actually get detail. Dammit. Cool looking, and again I find I'm lusting after both CPU support and MMU access, neither of which I'm ever going to get, unfortunately.

Now Intel's got some interesting stuff here. Hardware level monitoring of VM activity with feedback. They've got things wedged in some places to do speculative cache loads based on feedback data and get an impressive (14% on this slide) speedup.

Pypy is kind of cool, though it's late enough that my brain's too fried to write about it coherently. And somehow I really like that Parrot's got about as easy to use an unsafe, horribly dangerous, outside world interface as any VM on the planet. Woohoo us! One-instruction library loading, and one-instruction 'make a parrot sub for this function with this signature in that library' parrot wrapper sub creation. Mmmm, unsafety. :)