Martin Pool's blog

Mail me RSS Bazaar distcc Canonical is hiring! flickr

Threads ignore the last 20 years of OS and hardware development

Thomas Smits:

The design of the Java Virtual Machine ignores the painful lessons operating system vendors have learned in the past 40 years. The concepts of processes, virtual memory management, and different protection modes for kernel and user code can be found in all modern operating systems. They focus on the question of isolation and therefore robustness: an application with errors cannot affect the other applications running in the system.

In contrast, Java follows the all-in-one-VM paradigm: everything is processed inside one virtual machine running in one operating system process. Inside the VM, parallelism is implemented using threads with no separation regarding memory or other resources. In this respect Java has not changed since its invention in the early nineties. The fact that Java was originally invented as a programming language for embedded devices may explain this approach.

Andrew Tridgell (via Tim Potter):

What is it about the word "thread" that people find so damn sexy? Maybe it needs a name change — "slow-as-hell-no-memory-protection-locks-dont-work" API might be suitable, but I suspect the standards committees wouldn't like that one.

The MMU was added to CPUs for a very good reason. Why is it so hard to understand that trying to avoid it is a bad idea?

Have you thought about the orders of magnitude here? With process switching on a modern CPU you basically have to swap one more register. That's one extra instruction. Modern CPUs have nanosecond cycle times.

Now, some CPUs also need to do an extra tlb flush or equivalent, but even that is cheap on all but the worst CPUs.

Compare this to the work that a file server has to do in responding to a packet. Say it's a SMBread of 4k. That is a 4k copy of memory. Memory is slow. Typically that SMBread will take tens of thousands of times longer than the context switch time.

But by saving that nanosecond you will make the read() system call slower! Why? Because in the kernel the file descriptor number needs to be mapped from a integer to a pointer to a structure. That means looking up a table. That table needs to be locked. If you have 100 threads doing this then they all lock the same structure, so you get contention, and suddenly your 16 cpu system is not scaling any more. With processes they lock different structures, so no contention, so better scaling.

This lock contention can be fixed with some really smart programming (like using RCU), and recently that has been done in Linux. That's one reason why Linux sucks less than other systems for threads.

Try thinking about this. How do threads do their IPC? They use the same system calls and mechanisms that are available to processes. The difference is that in a threads library these mechanisms are wrapped into a nice API that makes it convenient to do IPC really easily. You can do exactly the same types of IPC with processes, you just need to write a bit more code.

For many things, perhaps even for some file server applications, that extra convenience is worthwhile. Convenience means simpler code which means fewer bugs. So I'm not saying to never use threads, I'm just trying to kill this persistent meme that says threads are somehow faster. That's like believing in the tooth fairy.

posted Wed 5 Jan 2005 in /software/languages/java | link

Java: the next COBOL

Tim Bray writes:

I had lunch with Mike and Christian of Make Technologies here in Vancouver, and in my new capacity at Sun got my ear bent about the Java value proposition. Their key point was: probably more half of the data being crunched out in the business world is being crunched by COBOL programs on mainframes. When these systems really finally can't be lived with any longer, the CIOs who have to replace them notice that they're decades old. They're smart guys who try to learn from what they observe, and they deduce that the next big piece of infrastructure is apt to be with them for a long time. "So," they wonder, "this JES stuff (or .NET, or whatever) they're trying to sell me, will it still be a viable platform in 25 years?" Put that way, it sounds to me like a damn good question. I think the Java answer is about as good as anyone's at the moment, but I suspect it's something that none of us on either the vendor or customer side have been putting enough thought into.

That might just be a decent explanation of both the good and the bad points of Java, and a guide to when to use it. Not so exciting, not so agile, but a safe choice, if you're really planning to keep the code for 25 years.

It's a bit like describing people as "born old".

posted Mon 24 May 2004 in /software/languages/java | link

Java, the Chicken of Tomorrow

The rant I was referring to the other day was from Java, the Chicken of Tomorrow by Miles Nordin:

Sure, there is some association between the imaginary JavaCPU and the Java language. But there is also some association between the real MIPS CPU and the C++ language: modern CPUs are overtly designed with the foreknowledge that they will be judged based on how fast they execute algorithms written in C++. Is the nonexistant Java CPU really uniquely adept at running Java programs, like a Symbolics `Ivory'' CPU is uniquely adept at running Lisp programs? No.

This observation makes me wonder if we wouldn't be better off throwing out Java and writing programs in C, then cross-compiling them for the VAX CPU. Instead of a JRE, we could simply write a VAX emulator for all interesting architectures, and put virtual-VAX sandboxes inside web browsers. VAX insns would become the Language Of The Web. We could standardize a crippled miniature virtual VMS called WebVMS for building into web browsers, to give all these VAXlets access to the network, the local filesystem, a GUI toolkit. We would have VAX-compatible smartcards. There is no reason a VAX emulator can't translate VAX instructions into native-CPU instructions just like a JRE's JIT does. This can be done quite well---like I said, the VAX emulator for the Alpha is faster than any physical VAX CPU. I suspect VAX machine-code would also be similarly compact to Java bytecode, since machine-code-compactness was the biggest priority when the VAX was designed. There is no missing piece to invent or design: we simply agree that, henceforth, all applications will be VAX applications so as to be equally inconvenient for everyone. Voila! Portability!

And when he hits his stride

The most important feature of the Java CPU is that it doesn't exist yet, but it could. Part of Sun's plan to make money from giving away Java was to build Java CPUs. This was a stated plan of theirs, not my speculation. The following is much more speculative.

Sun reasoned that if they could construct computers that ran Java bytecode natively, everyone else would suddenly realize that their JREs were CPU emulators for the computers Sun was selling. I suspect the fastest JavaCPUs would always be emulators, just as the fastest VAXen are emulators running on Alphas, but perhaps Sun could make some slow computers out of physical JavaCPUs that cost less to make than competing emulators of similar speed. The JavaCPU is thus extremely simple, so as to be implementable with minimal silicon and minimal research. Compared to a modern architecture like the Alpha, the JavaCPU looks like something an undergrad dreamed up in the men's room based on the mathematical elegance of two urinal cakes, one stacked upon the other. The JavaCPU idea gives Sun a brief window for a hit-and-run industrial subversion. If Sun can open hundreds of these tiny windows-of-opportunistic-slack, maybe a few of them will pay off. Something like the Alpha matures slowly, with many years of compiler research and successive core revisions abstracted by PALcode: the Alpha is not hit-and-run, and indeed it looks like Digital didn't survive long enough to finish cashing in on the Alpha. A low-end infantile design like the Java bytecode makes business sense in an industry where everyone with a big plan or a big research investment eventually gets screwed over by speculative neck-tie damage and goes bankrupt.

It's an interesting essay/rant. (Incidentally, Stephane has a copy of the original The Chicken of Tomorrow which is also very amusing.)

posted Thu 29 Apr 2004 in /software/languages/java | link

The (lack of) future of Java

I was just reading cbrumme's very interesting Microsoft blog.

I think one thing you can see here is that Microsoft are absolutely clearly trying their standard pattern #1 on Java: let Sun invent it, wait for it to be adopted, design something a little better and much less open, and ram it through the ISV/IT channel. Embrace, extend, extinguish.

(This sounds a bit harsh on CLR, which from my limited reading does seem to be the product of rather more intelligent thought than your average paperclip. But I don't think this is going to be decided primarily on technical merit.)

So the big question is, does Sun have the brains and/or balls to play the one gambit that gives Java a chance of survival: open source Java?

The only commercially interesting operating systems these days are either open source or Microsoft. Sun's Java runtime can't be included in free operating systems like Debian, and Microsoft doesn't (?) ship the current JDK. So Sun have just wilfully excluded themselves from being preinstalled on the two most important platforms. Way to go.

(OK, so failing to be preinstalled is not the end of the world. But it's not helping. Having a standard JRE on each release might make Sun less sloppy about cross-version compatibility than they have been to date.)

posted Wed 17 Mar 2004 in /software/languages/java | link

Beyond and Open Source Java

Ganesh Prasad has a brilliant article on Sun open-sourcing Java. This is what ESR's open letter should have been in the first place:

It is definitely in Sun's own interests to open up Java. This goes far beyond Open Source-ing the Java libraries, as we will see. Making the Java language and platform more affordable and friendly will make them more popular than their rivals (not Perl or Python, but C# and .NET).

But Sun has an indisputable right to exploit its creation for its own commercial gain. In fact, it would be illegal for Sun's management to sell out its shareholders by giving away the company's crown jewels.

Raymond recognises the problem, but poses it as an either-or choice. That implies a zero-sum way of looking at things. But it's not about ubiquity versus control at all. It's about ubiquity with commercial advantage.

As Open Source advocates, we know ways by which Sun can achieve both objectives.

We are not going to ask Sun to do something for Open Source (at least, not directly). We will show Sun how they can help themselves by making Java even more widespread than it is, and by harvesting it commercially. We will also show that if they continue to do nothing, they will pay a heavy price.

If, in the process of helping themselves, Sun proves to be a friend of Open Source, that's a bonus.

I think this is probably Java's only real hope of surviving .NET. I think I'd give Sun about a 40% chance of being smart enough to realize it.

posted Fri 27 Feb 2004 in /software/languages/java | link

Copyright (C) 1999-2007 Martin Pool.