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

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

tl;dr this is a two page description of Stephen Kell's liballocs library [0]. Basically, it's wasteful to install jvm, python interpreter, and electron. He's advocating that new languages use (u)nix infrastructure (processes, files, etc) as much as possible. His library is supposed to assist with this by providing process level gc. It provides a hierarchal view such that a caller allocates objects, rather than flat memory.

I don't know enough to have an opinion on this. As an alterntative view, consider listening to Cliff Click describe the challenge the jvm faced when it had a more permissive ffi [1].

[0] https://github.com/stephenrkell/liballocs

[1] https://www.youtube.com/watch?v=LoyBTqkSkZk

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

Your first two "virtual machines" are actually not that different.

Sure, xen simulates the same CPU type as host, and talks to host via block devices and raw sockets, and each guest includes the full OS and filesystem; while Java VM simulates a completely different CPU, and uses host's OS for filesystem and TCP/IP access. They seem pretty distinct.

But you are just looking at the sides of the spectrum, and there are plenty of things in the middle.

- With Xen, you can boot directly into user app, without any OS, filesystems or separate libraries. Is it still "fake system" if the thing you are booting has no chance of running on a real hardware?

- Qemu/kvm, which is normally used to emulate processors, supports "virt", "a platform which doesn't correspond to any real hardware and is designed for use in virtual machines." Does this start to sound like JVM for you?

- There are an actual, physical chips which execute Java bytecode directly (like picoJava). Does this put Java VM into "hardware emulation" category?

- On, and there is UML (user mode linux) project -- it emulates a virtual machine with its own fixed memory pool (like xen), and can use host's block device (like xen), and raw networking (like xen); but it can also use host's filesystem (like JVM), and it uses host's kernel for thread scheduling (like JVM). Where does it go?

- Oh, and there is a Smalltalk. The older versions had garbage-collecting VM (like JVM), but it had its own device drivers (like xen) and filesystem (like xen).

There is a reason we call of them "virtual machines" -- they have lots of things in common.

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