Not sure, but how many machine code generation software java have? Near-two? JikesRVM and near-to-be-usable SableVM jit? And C/C++? Using tools like llvm, iburgs, vmgen and many more can make a huge diference.
Besides that, for a long JikesRVM could not bootstrap from a free JVM, last year someone did the trick with Kaffe. Rodrigo On 5/11/05, 王在祥 <[EMAIL PROTECTED]> wrote: > I agree. > > Also, as a java fans, i would like to write and read Java code, and there > will be more contributor to this project if we choice Java as the major > implementation language. > > By using java, we can take advantage of the java such as: > > 1. IDE support. either Eclipse or NetBeans will makes the project easy to > build, and code reading. > 2. Refractor support via tools support. which will improve the qualilty. > > 2005/5/11, Steve Blackburn <[EMAIL PROTECTED]>: > > > > I would like advocate the use of Java in implementing the VM (*). > > This may seem a low-level issue, but I'm raising it now because it > > will have significant implications for the VM core and the overall > > approach this project takes. > > > > Why? a) Software engineering benefits. b) Performance. c) "Eating > > your own dog food" is good for you. > > > > The basic argument goes like this: > > > > . From the standpoint of development time, providing (and > > maintaining) completeness of implementation will be our biggest > > challenge. The more we can leverage Java's advantages in > > development time and maintainability, the better off we are. The > > advantages of strong typing are particularly compelling when > > implementing the compiler and GC. This also (largely) addresses > > the OS portability concerns being discussed. > > > > . From the standpoint of VM performance, the user code and libraries > > are (largely) written in Java anyway, so they will perform as well > > as our JIT allows. As far as the execution of VM code at runtime, > > this is dominated by the GC, the JIT, and inlined pseudo-user code > > such as barriers and allocation sequences. Experience with MMTk > > shows that it is possible to build high performance GCs in Java. > > Moreover, because the barriers and allocation sequences are > > expressed in Java, the JIT is able to aggressively optimize these. > > We found that this advantage and the fact that the size of Java > > scalars is statically known meant that we could outperform glibc's > > malloc on raw allocation time (size classes are statically > > evaluated). > > > > . "Eating your own dog food" is good for you. It gives you a > > compelling reality check. If your compiler isn't good enough for > > your own code, what is it good for? > > > > To those I'll add two more points: > > > > . A project like this has the opportunity to be aggressive and not be > > shackled in the way the existing commercial product VMs are. The > > Jikes RVM project at IBM (Java in Java) and Bartok at MSR (C# in > > C#) have really shown the potential for this approach. > > > > . We are a community who believes that Java has something to offer > > as a language, and we've demonstrated (GNU Classpath, Jikes RVM, > > the entire Jakarta project) that we can produce excellent systems > > using Java. > > > > * Of course it is not possible to implement a high performance GC with > > out-of-the box Java 1.4. However the set of extensions required is > > modest both in number and in implementation effort. In MMTk we > > found it was necessary to add a number of unboxed types to give us > > type safety over addresses and object references (while retaining > > performance), and we added a number of compiler pragmas for > > correctness (interruptability) and performance (inlining). These > > extensions have been factored out and are now also used by jnode. > > > > --Steve > > > > Research Fellow, Australian National University > > phone: +61 2 6125 4821 fax: +61 2 6125 0010 > > http://cs.anu.edu.au/~Steve.Blackburn > > > > > >
