This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: chewing gum and bailing wire
Feed Title: Cincom Smalltalk Blog - Smalltalk with Rants
Feed URL: http://www.cincomsmalltalk.com/rssBlog/rssBlogView.xml
Feed Description: James Robertson comments on Cincom Smalltalk, the Smalltalk development community, and IT trends and issues in general.
Slava Pestov has an early review of the JVM sources (which are now available under Sun's community license). He's not impressed; the JVM is over 3M lines of source code, and there's apparently a lot of duplication in there:
Code duplication and copy and paste coding is routine. The HotSpot compiler includes an XML output class, written in C++. There is a regexp implementation in sun.misc, different from java.util.regexp. There's at least a half dozen implementations of UTF8 encoding/decoding in the various C++ and Java layers. There is a huge amount of code, obviously copy/pasted then search and replaced, to handle different primitive types in different situations.
The reflection implementation is the lamest one imaginable. When you reflectively access a method or a field, it generates a class on the fly, which calls JVM bytecodes to (non-reflectively) invoke the method. Ever wondered why reflection is 100x slower than direct method calls in Java? This is why.
That last one gave me a chuckle. I think I know what happened here. Cast your mind back to when Sun acquired the HotSpot code (from Animorphic - it was originally created as a fast Smalltalk technology). Now, the things you need to do in Smalltalk to speed things up don't necessarily map that well to Java - the kinds of techniques you use to figure out dynamically typed code are not the same ones you'll use with statically typed code. What do I think happened? Well, Sun didn't put the Self team on the problem, that much is clear. They likely pulled a bunch of C programmers out and told them to "have at it". It was nearly 3 years before the HotSpot technology debuted for Java - I bet that management there followed the time honored "throw more developers at the problem" technique of problem resolution. The kinds of things above are a result of that - I'd guess that a lot of those developers never got anywhere near the HotSpot stuff - they were likely farmed out to areas where "they couldn't do much harm".
I think we see the results 3M LOC later. In contrast, the VisualWorks VM has always had a fairly small, focused team working on it - the makeup of the team has changed over time, but it's always been pretty well focused. The result? A VM that is in the neighborhood of 300K LOC (235K of C code, the rest being C header files). Now, the JVM really isn't solving a fundamentally different problem than the VW VM, so there's no good reason to make it bigger (heck, there are lots of things we plan to remove from our VM and move up to Smalltalk over time). The difference? Sounds like Sun fell victim to the age old Too many Cooks Spoil the Broth problem.
Previous Topic
