Define "Virtualization"

[mgaudet]

Some groups are interested in maintaining Virtualization; but I have only a weak mental model for this and think our definitions should define it I think.

[nicolo-ribaudo]

cc @kriskowal

[kriskowal]

A preliminary sketch:

---

In computing, Virtualization is the partitioning of an actual computer into multiple virtual computers, preserving the illusion that each virtual computer is a whole physical computer.

For example, kernel mode (host) programs can address all of a computer’s physical memory. A kernel conspires with hardware features to create an illusion for multiple user mode (guest) programs that they can also address all of a computer’s physical memory, each believing that their stack starts from the bottom of their address space and grows up, and that the heap starts at the top of addressable memory and grows down. They maintain this illusion by pausing guest programs while they swap pages of virtual and physical memory.

This suggests a more general meaning for virtualization: For a particular host system, a virtualization of that system partitions the system into multiple virtual guest systems, providing an illusion that each virtual system is not observably different from the system as a whole.

For ECMAScript, virtualization is specifically the implementation of a host feature with guest ECMAScript, such that there is no (or limited) observable difference between the behavior of the host and guest.

For example, an ECMAScript program can virtualize most host objects that operate within the limits of the Meta Object Protocol, using a Proxy.

[mgaudet]

I think that's a pretty good definition. A clarifying question: What are the boundaries expected that one can 'draw a line around'. Is the idea that 'virtualization surface' will -always- be encapsulated within a proxy, or is a new global object a desirable line?

[bakkot]

This suggests a more general meaning for virtualization: For a particular host system, a virtualization of that system partitions the system into multiple virtual guest systems, providing an illusion that each virtual system is not observably different from the system as a whole.

I don't think that the "multiple" part is a necessary part of this definition, and indeed most cases where I'm dealing with virtualization there is exactly one guest.

For ECMAScript, virtualization is specifically the implementation of a host feature with guest ECMAScript, such that there is no (or limited) observable difference between the behavior of the host and guest.

This implies that the point of virtualization is to provide the appearance of the actual host, whereas many use cases for virtualization involve providing the appearance of a host with different behavior than the actual host. The point of virtualizing host-provided timers, for example, is usually precisely to make them not behave as timers, which I wouldn't characterize as only a limited difference in behavior. Rather, I would say that from the point of view of the guest the behavior of a virtualized feature should (usually) not be distinguishable from the real behavior, while from the point of view of the host it might be quite different.

[kriskowal]

@bakkot I agree with both of these clarifying nuances.

[kriskowal]

@mgaudet I included Proxy as an example, but a case that is a central concern to me is virtualizing the behavior of import. I would want our definition of virtualization to be stretchy.

[erights]

See also

• Popek and Goldberg virtualization requirements (Wikipedia)
• Preserve Host Virtualizability (Less that 6min tc39 presentation. Please watch!)

Because a universal Turing machine can emulate any other Turing machine, to have a useful definition of "virtualizability", we need something much narrower than emulation. The Popek/Goldberg criteria applied to language design suggests the constraint "without any source-to-source rewriting". This is perfectly applicable to JS and indeed how we've used it for JS. Because JS is so bloody difficult even to lex correctly, and because the syntax is a moving target across language versions, the "without rewriting" is an amazingly useful constraint for JS virtualization.

Proxies enable JS code to emulate almost any host object without source-to-source rewriting, i.e., almost all host objects are virtualizable via proxies.

Full Compartments would enable JS code on any host to emulate almost any other host behavior without source-to-source rewriting, including behavior provided via so-called "host hooks". I say "Full" because we expect to postpone most host hook virtualizations to later proposals, so committee resistance on any particular host hook virtualization need not delay the core Compartments proposal.

The Popek/Goldberg split between "user-mode instructions" vs "system-mode instructions" is almost perfectly, and accidentally!, reflected in the JS distinction between the JS language, as defined by tc39, vs the various hosts, as defined for example by w3c. Aside from Date.now and similarly Temporal.Now, the JS language as defined by tc39 is "purely computational" without I/O. The language also says that I/O is provided by hosts, which are provided primarily by host objects bound to non-language-defined global names on the global object. So looking up such non-language-defined global names on the global object is the equivalent of a system call.

Thus, being able to intervene on global scope lookup enables the same kind of virtualizability as being able to redirect system calls. Being able to intercept other host hooks would complete the story, in the same way as being able to redirect other process traps.

[mgaudet]

Good presentation :) Thanks for pointing it out.

For an actual definition to be appended to the definitions, a helpful shape I think would be including some examples of potential threats to virtualization (like in Mark's presentation, `peek/poke)