lubosh Wrote:
> Do we really need yet another layer between hardware and our code?

Both JVM and CLR (.NET) are badly designed. Both platforms are too tightly tied to Java and C# languages. They are too bloated to provide sufficient security guarantees or performance gains.

Fundamentally, we don't need another layer between hardware and code. But since design of our typical hardware (like x86) is not very good either, VM can actually improve both performance (hardware sandboxing, for example, does not perform very well and doesn't allow enough granularity) and security (native code is extremely difficult to analyze from security point of view). VM then basically becomes what your hardware should be.

I'm generally in favor of lightweight VMs that hide hardware deficiencies and differences. Such VM can improve code compactness, allow for more aggressive inlining, provide security and reliability guarantees,... Another significant advantage is that it would greatly reduce complexity of generating code at runtime (and generally promote a more layered approach to computation, like Lisp-like features).

Have you checked out the work of Ian Piumarta? He has done some very intersting work on 'live' compilation of dynamic languages to native code. He is currently working with Alan Kay on their next generation smalltalk, but the technology seems to be applicable to most languages.

Links to a lot of info can be found in this blog post: http://www.equi4.com/jcw/files/bcf5635ccbc5b6ab916a38ef7aaa844b-139.html

Boris Kolar Wrote:
> Both JVM and CLR (.NET) are badly designed. Both platforms are too tightly tied to Java and C# languages. They are too bloated to provide sufficient security guarantees or performance gains.
> 
> Fundamentally, we don't need another layer between hardware and code. But since design of our typical hardware (like x86) is not very good either, VM can actually improve both performance (hardware sandboxing, for example, does not perform very well and doesn't allow enough granularity) and security (native code is extremely difficult to analyze from security point of view). VM then basically becomes what your hardware should be.
> 
> I'm generally in favor of lightweight VMs that hide hardware deficiencies and differences. Such VM can improve code compactness, allow for more aggressive inlining, provide security and reliability guarantees,... Another significant advantage is that it would greatly reduce complexity of generating code at runtime (and generally promote a more layered approach to computation, like Lisp-like features).