Over on Charles Nutter's blog, after Charles has listed a number of shortcomings of the JVM for dynlang implementation, a commenter writes "Either way, it's a VM world".
I used to think that too. Today I see it differently. Yes it's a VM world, but the OS is the VM.
OSes have failed to provide isolation. Thus, today we virtualize them.
In the future, many apps will be distributed as a preconfigured OS image, and some even as preconfigured hardware appliances. In this world, saying that it's a VM world and meaning the JVM doesn't make sense. Who cares what runs inside your virtualized OS?
And let's face it: many apps are written in multiple languages. Insisting that they must all run in the Gosling Tarpit is silly. You lose flexibility. Furthermore, as OSes get more interesting features (think Linux' splice(2)), being separated from the OS by another layer means that you'll have to punch through that layer increasingly.
Yes, it's a VM world, but the VM doesn't have be a language VM.
Subscribe to:
Post Comments (Atom)
3 comments:
IMO, we should directly mate the operating system and the language VM. Create a VM that is directly tied into the OS and has first class access to OS services and functionality. Programs written for this VM (in a multitude of languages) can also export their API through this OS/VM layer. Not sure if their is any prior art in this area.
Lisp machines come to mind, but afaiu they had little protection. Dynamic language infrastructure will probably never make it into an OS kernel, but I agree that it would be interesting for the OS to provide GC, for example.
Sun has a project aiming to run a JVM directly on top of Xen: http://labs.oracle.com/projects/guestvm/
Post a Comment