Archie Cobbs wrote:

> 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.
>
This is exactly how we see the dialect of Java that MMTk is written in.  
The non-java extensions are the org.vmmagic classes.  The key difference 
is that our types are represented as 'unboxed' objects, which gives us 
more flexibility to define operations on them.

cheers