Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: unknown (asf.osuosl.org: error in processing during lookup of
 archie@dellroad.org)
Message-ID: <43682657.9020104@dellroad.org>
Date: Tue, 01 Nov 2005 20:37:11 -0600
From: Archie Cobbs <archie@dellroad.org>
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.3) Gecko/20041129
MIME-Version: 1.0
To: harmony-dev@incubator.apache.org
Subject: Re: half-baked idea? j2me
References: <43669468.4090205@dedasys.com>
 <8cca42d80510311433r66636d23mb3044a568736180@mail.gmail.com>
 <4366E968.4010607@anu.edu.au>
 <8cca42d80511010454y34ae0e55w9cd35babd94d1b18@mail.gmail.com>
 <63280.202.55.156.42.1130850573.squirrel@sqmail.anu.edu.au>
 <8cca42d80511010545pfd544f1wbe2ec82d6029eded@mail.gmail.com>
 <43681EEB.6020802@anu.edu.au>
In-Reply-To: <43681EEB.6020802@anu.edu.au>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Robin Garner wrote:
> Actually my colleagues at ANU and I were remarking last week that all 
> the recent discussion on the Harmony list (configure scripts, packed 
> structs etc etc) were close to being proof that Java was the easier way 
> to go.

Here's some idle speculating about writing a JVM in Java...

Start by asking this question: if you could design a new language
expressly for the purpose of implementing JVM's, what would that
language look like?

Java is almost the right language.. but not quite. You need to
be able to do C-like stuff as well.

One can imagine something that is mostly like Java, but has some
additional features that allows C like functionality, for example:

- Augment the Java type system with C-like "structs". These are
   like Java objects in that they can be allocated on the Java heap
   (as an option) but have no Object header (you can't synchronize
   on them directly and they have no associated Class). Then the
   in-memory representation of an Object is a special case of one
   of these structures, containing a lockword and vtable pointer.

- Define a new "word" primitive type that corresponds to the
   machine-specific word size (i.e., 32 or 64 bit unsigned int).
   Corresponds to SableVM's _svm_word and JC's _jc_word.

- Language would include primitives for compare-and-swap of a word,
   memory barriers, etc.

- The language would include the ability to cast between any types
   as you can do in C (e.g., struct -> Object, word -> Object pointer).

- Allow C function calls to be expressed in the language, passing
   as parameters any Java type, or a struct. This "compiles" directly
   into a C function call using the platform's normal C calling
   conventions.

- Extend the class file format in a corresponding manner.

Call this language "Java++" (or whatever). Then the 95% of the JVM
can be written in this language.. and 95% of that would be normal Java.

Then writing the JVM boils down to this:

- Define this language and modify an existing Java compiler to
   understand and compile it.

- Write a JIT engine and/or interpreter that understands how to
   execute this stuff, supported by a small C support library that
   handles the low level stuff like atomic ops, dynamic dispatch
   (the equivalent of libffi), exception throwing & catching, etc.

- The JIT could be written in two parts:

   - First part converts normal class files into Java++ class files,
     in the process converting all high level stuff (like virtual
     method dispatch, instanceof, etc.) into low level stuff that
     the second part of the JIT can understand (call this "Java--").
     This part could also do all the fancy runtime JIT optimizations
     like method inlining, devirtualization, etc.

   - Second part converts Java-- into machine code. This would be
     a fairly "direct" conversion.

- Write the JVM proper in Java++ (it would mostly be pure Java).
   Re-use existing JVM's written in C by porting them to Java++.

- To bootstrap the JVM, require all bootstrap code be written in
   Java-- (i.e., no virtual dispatch, etc.). Then the system can
   be bootstrapped using only the simper, "direct" part of the JIT.

This is similar to other JVM's written in Java, but would have a
more natual and understandable interface between the Java part and
the non-Java part.

Just a thought... :-)

-Archie

__________________________________________________________________________
Archie Cobbs      *        CTO, Awarix        *      http://www.awarix.com