harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Archie Cobbs <arc...@dellroad.org>
Subject Re: [arch] VM Candidate : JC @ http://jcvm.sourceforge.net/
Date Wed, 18 May 2005 14:33:08 GMT
Geir Magnusson Jr. wrote:
> For those that want meaningful subjects lines, here it is and for  those 
> that are waiting for an architecture discussion - here it is.
> Here's the first of the offered VMs.  (I've privately mailed Tom van  
> Dijck about mudGE so we can look at something else)
> I've downloaded and will begin playing with today.  Archie, can you  
> give a brief overview of structure?
> Can we get some discussion about this from those that know about  about 
> VM architecture?

The structure of JC is reasonably straightforward, i.e., the bits
that are obviously going to be dependent (e.g., heap allocation code
and GC code) are dependent, but otherwise there shouldn't be more than
the "usual" amount of cross-dependency between code modules.

Any of the "little" bits such as classfile parsing and ZIP/JAR decoding
should be very modular and easily transplanted.

The online manual provides some useful info about the overall design.

Cross-cutting design issues include, as you might expect:

- Object layout & lockword bits layout
- Type, field, & method meta-data structures
- Thread meta-data
- How exceptions are thrown & caught
- Stack frame layout (in JC, it's the same as C), stack unwinding

On the topic of writing the VM in Java: this makes a lot of sense and
there's no reason it should inherently be slower. In fact, eliminating
the "impedence mismatch" between VM internal code execution and Java
code execution was also one of the goals of JC as well (as a result, e.g.,
the native methods in JC (not including JNI) have zero overhead). And
JC's code generator is written in Java, so a major portion of JC is
written in Java too.


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

View raw message