March 2005

« February 2005 | Main Index | Archives | April 2005 »

18
Mar

One thing I've been vaguely interested in over the last year or so (enough to pique my curiosity on occasion, but too busy to do anything serious about it) has been the nuts and bolts of memory management, and how it affects virtual machine-based OO apps of the kind I've been writing for the last five years.

Our operating systems are the result of decades of research into memory management, which is then totally ignored by the virtual machine. The virtual machine carves out a gigantic chunk of memory and manages it all itself, because the virtual machine's requirements for memory management are completely at odds with the assumptions of the OS. Which is why you have to fiddle around annoyingly with every Java application's memory allocation like it's some kind of 1990's-era Mac app; and why crippling the operating system's memory manager can sometimes make your Java appserver run faster.

Given the prevailing popularity of VM-based object-oriented systems these days, especially ones with huge memory requirements running on big servers, I sometimes wonder why there isn't more research like this going on: Sun research: An object-aware memory architecture.

I'm looking for more like the above. If you find any, post it in the comments and I'll be a happy fish.

Addendum: When I posted this article, something was bothering me. So I went into the office and re-read it, and thought "Ah. Does VM mean virtual machine or virtual memory?" Overlapping acronyms should be banned.

A storm in a teacup was launched last week by an ONLamp.com article making wild claims about Ruby on Rails:

What would you think if I told you that you could develop a web application at least ten times faster with Rails than you could with a typical Java framework? You can--without making any sacrifices in the quality of your application! How is this possible?

I'm not going to be drawn into the Rails vs The World debate. Rails may be wonderful. It may make me significantly more efficient than I would be coding in Webwork. and Java. I've not tried it beyond throwing together a toy application, and I'm going to withhold judgement until I've done something serious with it. But I can categorically say that Rails is not going to make me ten times more efficient. When I encounter this sort of hyperbole, I always find myself returning to the words of Fred Brooks:

But, as we look to the horizon of a decade hence, we see no silver bullet. There is no single development, in either technology or in management technique, that by itself promises even one order-of-magnitude improvement in productivity, in reliability, in simplicity. -- Fred Brooks, No Silver Bullet

The core of Brooks' argument concerns complexity. Writing software is a complex business, and it essentially comes down to the combination of two types of complexity: Essential complexity is the complexity inherent in the problem being solved. Accidental complexity is the complexity that derives from the environment that the problem is being solved in.

Consider an impossibly perfect tool that reduces accidental complexity to zero. For this magical tool to give you a ten-fold increase in productivity, that would have to mean that you are spending 90% of your time fighting your current tools, and only 10% of your time solving the problem you are coding.

I've been in one or two truly pathological environments where I've felt like this (usually involving EJB 1.1), but you have to do a lot of concerted work applying layer upon layer of antipatterns to get the ratio that high.

This is precisely why demonstrations are to be taken with a grain of salt. Any task that can be performed in a demo must necessarily have an essential complexity close to zero: it's a solved problem before the demo even begins. So if one vendor's demonstration takes a tenth of the time as another vendor's, all that time is accidental complexity.

And even the accidental complexity of a demo is usually of a totally different nature to that you'd encounter on a real project: the kind of complexity that accrues around a task that can be completed in the course of a lecture is vastly different to that which is encountered in a year-long multiple-developer project.

This is why the best kind of products to demo are the zero-configuration products, like Rails, or those IDEs that promise to tie pre-built web services together with the click of two buttons. Configuration is a much more significant overhead for a 45 minute "from scratch" or "here's something I prepared earlier" demo than it is over the lifetime of a real project.

It's like those debates about optimisation. "I just made this loop 10 times faster!" "Great, except we only call that method once a day."

A few years ago, a marketroid visited my then employer to give a demo of a recently re-launched IDE. The demo was very slick, showing how you could throw together an EJB project or a SOAP interface in a few clicks of the mouse.

Then, we started asking about the product's refactoring support, and the answer was "Oh, we don't have that." It was at this point the developers in the audience switched off. The IDE might have made it really easy to set up a web application skeleton or add new actions, but in any reasonably complex task you're going to be spending most of your time dealing with code. Refactoring tools only become necessary when you are iteratively refining your code: something you do constantly as you move towards the solution to the essential challenges of the programming task, but totally irrelevant to a slick, pre-packaged demo.

This isn't to say that improving processes, using more powerful languages and so on can't give you a significant advantage. If something makes you even ten percent more efficient, that's a huge advantage to have over your competition. But if anyone promises to make you ten times more efficient, they're discrediting themselves before they start, which is a disservice to all involved.

"There. Forty-eight chocolate-chip cookies, all ready for Chocolate Friday"

"Forty-six. You ate two."

"They were only small ones. Quality control."

"Isn't forty-eight a lot of cookies?"

"Well, yes, but I'm hoping that I can make up in volume for my total lack of effort."

"Ah, you mean the total lack of effort inherent in wandering around Coles looking for the ingredients to the recipe Adrian so kindly looked up for you, and then giving up and going straight to the packet-mix aisle."

"Erm.. yes. That would be it."

"Don't you feel mildly guilty about that? Every other chocolate Friday, they've at least cooked something from raw ingredients."

"Well, you have to put these things into context. This is the first time in two years of being in this apartment that my oven has been used to do anything more complicated than reheat pizza. The only other time I've cooked anything in the last year was after my girlfriend issued me an ultimatum."

"Ah yes. The infamous Thai Green Curry incident. The less said about that the better."

"It was a great curry! The fact she didn't speak to me for a whole day after eating it was totally irrelevant."

"Yes, that was probably more to do with having told her to fuck off out of the kitchen."

"Anyway. I did make them myself, sort of. I mixed ingredients and put them in the oven. The fact that one of the ingredients was 'cookie mix' is irrelevent. They're nice cookies."

"Except for the way half the chocolate chips seem to have vanished during baking through some bizarre process of reverse osmosis."

"And they come in two batches, one crispy and one softer, so people get a choice!"

"I believe the terms are over- and under-cooked."

"Git. I bet you eat them anyway."

"Damn right."