harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sergio <ser...@modsoft.com.br>
Subject Re: Java
Date Wed, 11 May 2005 03:36:43 GMT
I agree.

Steve Blackburn escreveu:

> 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