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...
