Hi Steve, First of all, I'd like to say I've found the discussions on this list very interesting. I don't want anybody to take my comments the wrong way. I'm not annoyed or offended in the slightest by people saying JamVM is simple or trivial -- I simply wanted to put the record straight. Many parts of JamVM _are_ relatively simplistic, but some parts I like to think are relatively advanced, following my own interests. These include the interpreter and the thin-locks implementation.
Writing a VM from scratch requires a wide breadth of knowledge. I totally agree that simplistic implementations do not scale, and retro-fitting advanced techniques can be as much work as implementing it from scratch. But with JamVM I made the choice to implement parts simplisticly to get a complete VM finished and released. As I'm sure every VM implementor has experienced, after release I spent a lot of time fixing bugs and boundary cases, and I didn't make any major modifications for quite a few releases. And then once you have users you're stuck in the bind that you have a relatively stable release, which acts as a "dead-hand" on making major modifications. I've made major modifications to the interpreter, but only after extensive testing, and with great trepidation. If I have a point, is that testing should be made an integral part of any design decisions. Getting a VM "out there" early enables users to test it with a wide-range of applications. But simplistic solutions as in JamVM can prove problems in the future, but complex solutions can delay getting a VM out there, for real user testing. (For the record, I actually worked on JamVM for over a year before I made a first release). JikesRVM is a very complex research-oriented (and I'm not saying that in a derogatory way) VM. I'm only giving my opinions on what it's like implementing a VM from scratch, as a one man team. I'm extremely impressed by JikesRVM. I wrote JamVM initially as a learning exercise and (pleasurably) ended up with a user base. I guess JikesRVM was initially a research vehicle, but is now intended as a wider VM. We fit different ends of the spectrum, but I hope we can both co-exist. After a big preamble, I've also given comments below... On 6/26/05, Steve Blackburn <[EMAIL PROTECTED]> wrote: > Hi Rob, > > We'd obviously be shooting ourselves in the foot if we did not make the > most of JamVM... > Thanks. I'm pleased that people think JamVM is a worth-while object of study. I believe its main "claim to fame" is its small size rather than the complexity of any technique (apart from the interpreter). But I couldn't say in more than general terms how it achieves it, apart from saying that I spent many years squeezing complex programs into the ZX Spectrum using Z80 assembler (total of 48K). > >However, I'm probably one of the few people who has written a > >non-trivial VM from scratch, and when I started I already was an > >experienced VM engineer. So my thoughts may be useful/interesting or > >annoying. > > > > > Useful. > > >First of all, just because JamVM is small does not mean it is trivial. > > As I was interested in targetting embedded platforms, I put in a > >large amount of design effort _from the start_ to minimise code size > >and runtime memory usage. > > > The goals of harmony are broader, but this is just where we are right > now---trying to get rolling on the up-front design effort. > Yes, and I think the discussions so far have been very useful. I personally would like to see code sooner rather than later. If not for the simple reason that engineers are happier reading code rather than design documents. Code is unambiguous. > > As in many other situations, smallness can > >come from triviality or from careful design. Of course, many parts of > >JamVM are simplistic, but if code size == quality we'd all be using > >Microsoft Windows. It is the last trap I would have thought > >open-source people would fall into. > > > I think often they do, but I sure hope we're not going to go down that path. > I really hope so as well. Maybe it's impossible for one VM to span the spectrum from embedded platforms to multi-processor SMP machines, and to scale appropriately (best commercial example is J9?). Pluggable components might achieve this, but pluggability adds an overhead in itself (unless it's compile time). > >The interpreter in particular I like to think of as > >"state-of-the-art". It is certainly not trivial, and it is more > >optimised than most commercial VM interpreters (in many tests it is 2x > >faster than HotSpots' interpreter under Mac OS X). This in itself has > >taken many months of work, and I have substantially rewritten it > >twice, so it is two iterations beyond my first interpreter, which also > >included several advanced techniques. It now does direct-threading, > >static and dynamic stack-caching, prefetching and makes use of > >super-instructions. > > > > > The obvious question is how Harmony can use this experience? Can we > take JamVM in its entireity as our starting point? (I'm not in favour > of us doing this with JamVM or any other VM) Can we take the > interpreter as a module? Can we use the interpreter as the template for > a new one? > I'm personally in favour of studying existing VMs and implementing from scratch (not that I wouldn't agree to JamVM being used, but there may be legal issues which I need to take off-line). I'd be happy to discuss any design aspects of the interpreter or anything else. > >One of the advantages of being a "one man team" is that you know the > >code intimately. While this can lead to spaghetti-like code with many > >inter-module dependencies if you're not careful, it can also lead to > >compact code, as you're not afraid to re-factor modules and their > >interfaces when the time is right. > > > I agree. However a VM on the scale that Harmony aspires to is well > beyond the scope of a single person. The complexity of a production > quality JIT is itself beyond the scope of a single person. While I > think it is an error to overstate the difficulty of the problem, it is > also a mistake to not realize that VMs of the scope we're aiming to > compete against have been developed over a number of years by fairly > large teams. > I also agree absolutely. How do you get the advantage of a one man team, with a design spanning multiple people? I don't know, but commercial teams inevitably end up with too much politics in the way, which limits flexibility. I'm not saying open-source will be any different, but I hope technical issues will eventually win out (we're all engineers). This is why it's important not to set module interfaces in stone too early. > > Having modules written by separate > >teams can result in in-efficiency and code duplication, as each module > >implements its own utilities, e.g. hash tables, lists, etc., or ends > >up marshalling arguments for an inappropriate interface. > > > It can, but good design is all about reducing this inefficiency. I > don't think we can escape modularizing the JIT and the GC---they are > just too big and too complex. Prior experience in both production and > research VMs shows this is possible and in fact desireable. My feeling > is that it will be essential for Harmony to leverage pre-existing JITs > and GCs if it is going to compete. The investment in these existing > JITs and GC is enormous. Of course this does not preclude us building > our own over time (in fact the modularity precisely enables such an > approach). > > > Trying to > >guess every need "up front" in a neat module/interface definition is > >doomed to failure. I believe it is better to start off with a minimal > >interface, and then re-factor as experience dictates. Of course, > >there are some very experienced VM implementors on this list, and > >several module definitions already, but I like to factor through > >experience not anticipation. > > > > > I agree with you in principle. MMTk is a third generation memory > manager---we tried to factor it as well as we could at each step, but > only now is it really reaching the level of modularity that we had > sought (while maintaining performance). However, I think that the > core<->GC and core<->JIT interfaces are things that have already been > successfully factored (with a great deal of thought and effort over many > years). I think we need to leverage that experience in our first cut > Harmony implementation. > > Harmony is not starting from scratch. It is starting from the > experience of folks like you and many others on the list with a wealth > of prior experience. We will not get things right first time, but I > think we have so much experience on the table that we should make a > decent stab at good design at the outset. Just as you said above, > investing in good design up-front is essential. > I don't think we're talking at cross-purposes at all. I started off giving reasons why JamVM was so small. Full modularisation is important, as it allows for powerful options such as pluggability of GC algorithms, even dynamically at runtime based on profile information. I haven't looked at MMTk (I should). Assuming the core<->GC and core<->JIT interfaces were adopted how soon could coding begin? There is no interpreter in JikesRVM. Could one be easily accommodated? I don't want to appear to be partisan, but I think interpreters are useful in very embedded environments. > >For the record, I believe JamVM to be fairly well "modularised", each > >distinct component is in a separate file, with a defined interface. > >There is very little duplicate code, and no private utility > >implementations. The biggest problem is that as yet, I have no > >abstraction for stack-walking. Please note, I'm not putting JamVM up > >as an example of a module definition. I'm sure there are many, many > >problems if you were to look at it in detail towards that end. > > > > > Sure, but I think we can (and *should*) look at it for inspiration, just > as we're looking at the other VMs, none of which are perfect in any way > (which is why Harmony exists! :-) > I guess the decision has been made to use Classpath? That means most of the discussion will revolve around VM design issues? Thanks, Rob. > Cheers, > > --Steve > >
