harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthew French <matt...@camary.co.za>
Subject Re: State of the World
Date Mon, 09 May 2005 21:09:48 GMT
On Mon, 2005-05-09 at 15:37 -0400, Brian Goetz wrote:
> >   It ought to be possible,
> >   though difficult, to write a configurable core VM that can be reused
> >   by other projects.  The idea here is, have a reusable reference
> >   implementation, and reduce writing a VM to writing an execution
> >   engine (and perhaps a GC).
> 
> For the sake of making sure everyone understands these vague terms in 
> the same way, could you elucidate your sense of the boundaries between 
> the VM and the execution engine, and why this is a sensible place for an 
> abstraction barrier?

I'll bite, even though I did not make the original comment. 

A Java VM can be considered as three separate core functions[1]:

- client interface: command line, library locater, and OS abstraction
(not to be confused with library abstraction: the OS abstraction does
small things like knowing that semicolons separate the classpath instead
of colons)

- byte code interpreter (execution engine?): this is the section
responsible for turning the byte code into program steps. This can be a
simple interpreter, a just-in-time compiler, or a brute force compiler.

- garbage collector: responsible for allocating and cleaning memory.
Also responsible for soft pointers.

I have deliberately ignored functionality like file and network handling
because I believe these are purely library functions. OS dependant, but
still library.

I have also excluded classic VM functionality like threading because I
believe this depends on the execution engine being used.

Now why would one make this distinction?

One of the the big benefits of Java is its ability to "run anywhere".
Now I don't believe operating system independence is that important,
recompiling the code works in many cases. But running in different
environments *is* important: 
  - running inside a webserver
  - as part of a HPC cluster
  - on a cell phone
  - inside a debugger
  - from the browser
  - as a command line application

We should not underestimate the power that re-using the same code in a
very different space gives us.

However, each of these environments presents different challenges: a web
server needs aggressive performance optimisations and paranoid
threading. A cell phone would rather save the memory and so do pure
interpretation without any compiling, possibly using co-operative
threading. A debugger needs to add hooks and checks. A HPC cluster needs
to do the inter-server communication and locking, but might want to
ignore bounds checking on arrays for performance. A command line
application would need pre-compiled code and fast loading, and JIT for
uncompiled code. 

To a lesser extent, the choice of garbage collector presents similar
issues. A web server could need a lazy collector that uses spare cycles
when available, or perhaps an aggressive collector if the application
tends to allocate many large memory chunks. 

The client interface depends on where you are running. The execution
engine depends on what you are running, and the GC depends on how it
runs.

The question seems to me to be similar to the micro- verses monolithic
kernel debate. Sun have given us the monolithic VM. Now we need the
modular VM. Except that in this case we don't have the complexity
trade-off that micro-kernels faced.

I have not been on this list long enough to really understand the
purpose behind Harmony. But one of the big benefits of open source is
that it allows the end user to choose what they use the code for instead
of being handed a black box. 

So for me one of the primary goals of Harmony would be to create a
framework inside which specialist VM's could be implemented. 

Even if we only implement a simple byte code interpreter, this
flexibility will make it possible for others who have the inclination to
create VM's that are better suited for other problems. 

Hopefully that begins to answer the question?

:)

- Matthew

[1] For the purposes of this discussion. And off the top of my head, I
still need to consider the problem more deeply... Ohhhhmmmmmm...



Mime
View raw message