The Inevitable Death of VMs: A Progress Report [pdf]

In all fairness to the author, casually maintaining any major changes to V8 or Chrome for more than a month is borderline impossible. The whole codebase undergoes massive churn on a release-to-release basis. There are projects like LibCEF that have the rug pulled out from under them every release or two because some major subsystem got completely overhauled.

So, the difficulty of maintaining the v8 changes is kind of meaningless. The fact that it's possible at all is the interesting part!

> As an alternative view

Is that really an alternative view? In a liballocs world some large part of the problems Cliff Click describes would be solved; everything is 'native' and playing by the same rules. The 'foreign' part of FFI would have no meaning.

The cynic in me wonders what value liballocs delivers that is so compelling as to motivate many disparate systems to adopt it. People are entirely content to muddle endlessly; inefficiencies and unnecessary complexity are usually deemed not worth fixing until they register as high costs.

I personally disagree. The differences between the language specific is high enough that a fully general VM is impossible without also incurring all the downsides of a language specific VM. Python and Java each have a distinct standard library. The end result will be that you have to install 'supervm-java-std' and 'supervm-python-std' instead of openjdk and cpython. JVMs tend to be very memory heavy in exchange for higher performance for java code, whereas the python interpreter is slow but more memory efficient because it relies on C code to accelerate CPU and memory intensive applications.

Ouch. :-) There's a lot more to it than that, though wrapping malloc is certainly one part of it. (Reminds me I should finish my blog post on why wrapping malloc reliably is way harder than it should be.)

But the key idea is to avoid introducing new abstractions -- anything that liballocs formalises should be commonly "lurking" in there already. So types and allocators are OK, but apartments would not be. It's not a new programming model... the newness should be at the meta-level only, i.e. ways of describing what existing code already does.

True that the CLR is not mentioned by name, but it is covered. I invite you to read the text again, and especially the following bit.

"Specifically, we should aspire to package language implementations in a way that renounces ‘one true VM’, instead allowing first-class interoperability with the host environment (perhaps at modest drop in performance), the same interoperability with other VMs past and present, and tool support which ‘sees across’ these boundaries."

The CLR simply doesn't do these things, as witnessed by the debacle of "Managed C++" and the usual FFI wrapper tedium of "explicit P/Invoke". It is a classic "one true VM", albeit more language-inclusive than a single-language VMs.

> I expected this to be about system virtualization, not language VMs. Interesting though, but not my area of expertise.

The blatant reuse of abbreviations and terms is one of my pet peeves.

For example, VM can mean Virtual Machine, Virtual Machine, or Virtual Memory. Yep, three completely distinct things, two of which are helpfully referred to under the same expanded name as well. Do you know all three? mroche has helpfully disambiguated between Virtual Machine and Virtual Machine already, but in case you need help:

Virtual Machine means a computer split up into many different fake systems, each running a guest OS. Xen is an example of a Virtual Machine hypervisor.

Virtual Machine means a completely fake CPU packaged with libraries and used to run a high-level language, to facilitate things like garbage collection and language-level security. Java runs on a Virtual Machine, quite imaginatively called the Java Virtual Machine. Now, what would we call a Java execution environment which could run as a Xen guest? (Don't strain yourself... )

Virtual Memory means lying to applications about how memory works, to present a completely flat address space without such annoyances as caching or other programs or the operating system disturbing application programmers, who are quite disturbed enough.

Now, let's take all of those concepts, refer to all three of them with the same abbreviation and two of them with the same name entirely. I suppose I should feel lucky to live in this time: Soon, we'll be calling them all Bruce, to cut down on confusion.