Hi, On 6/27/05, Robert Lougher <[EMAIL PROTECTED]> wrote: > 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.
Uh, it is always easier to read, then judge someone else's code than to design and program it oneself. I didn't think much about sophiscation mainly because all I see in JamVM code I'm getting 'for granted' - this is the first VM I've began dealing with. Designing and coding quite sophiscated interpreter and ensuring it is still compact and readable is always better than coding a horribly sophiscated beast that no one actually understands. I was playing a bit with JamVM code and concluded that it may be a good starting point because it is short enough and reasonably clean (at least from my point of view). But I'm definitely not an expert (or even fluent). > 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). Getting out some code early is quite important in OSS projects. Mono folks did it extremal way, initially releasing a buch of non-working empty stubs which sparked wider work and attracted developers. It has some downsides too (not to say we should go the same route), but it actually worked. > 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. +1 > > >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). And now I'm not sure if trying to achieve all these targets in one design actually makes sense. Things like ORP (and propably Jikes - not sure) are intentionally omitting interpreter, relying on a fast, non-optimizing JIT instead. I don't know but it may affect some design decisions. Assuming that framework = set of interfaces (for example GC) + set of conventions (for example, stack layout), discarding interpreter part in a server VM may lead to more opportunities in optimizing VM. On the other hand, resource constrained environments require VMs with as little footprint as possible. My question is: does it make sense to make all-in-one framework or maybe designing two execution engines, maybe sharing some code but having two different designs (object layout etc.) ? What are the upsides/downsides for having one versus two execution engines ? Regards, rle
