harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Blackburn <Steve.Blackb...@anu.edu.au>
Subject Java
Date Wed, 11 May 2005 03:10:20 GMT
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



Mime
View raw message