Why can't we evolve JVM as a hardware virtualization technology like VMWare, KVM, Docker, etc.?

Question

Virtualization has been with us for quite a some time now. VMWare was introduced in 1999 and then came several other similar software such as KVM, VirtualBox, etc. Later hypervisors evolved in to unikernels and next container technologies such as docker, kubernetes, etc. were seen.

My question is this. (I know this is a foolish question but this question has been bugging me for a long time)

Java Virtual Machine (JVM) has been around since 1995.

Why didn't Sun Microsystems (or later Oracle) bother to use JVM to enter the virtualization market? Is it due to a business strategy / marketing decision or is there a serious technological limitation that prevents JVM from being evolved into a virtualization mechanism? If someone attempts to enhance JVM to make it a virtualization method like VMWare ESXi / KVM / Docker then will it be a very foolish effort like trying to convert a helicopter into a spacecraft that would take us to the moon?

JVM can also execute a code (it may be called a bytecode but anyway it can execute a programme) and can access hardware resources (microprocessor, memory, storage, networking) to produce the output.

Answer 1

This question is likely to be closed as opinion based. However, with that in mind, here's my opinion:

Your question doesn't really make sense. It conflates the purpose of an operating system and a runtime. Operating systems are virtualised, which allows multiple operating systems to believe that they are running on a dedicated processor, whereas in fact there's a hypervisor running at a different level below.

The JVM doesn't deal with hypervisors, since it doesn't run on the processor directly; it runs on the OS. You can run applications side-by-side in an OS without any problem, and they'll share a certain amount of content (libraries mainly, but not JIT'd code). You can't share JIT'd code, because the JIT generated code has specific addresses that are for the use of that program, and you can't guarantee that any two programs share the same address mappings.

A more interesting question is why you can't have a JVM processor or operating system. Indeed, these were tried -- the Java Processor that Sun worked on was capable of executing bytecode natively (and so if that'd been successful, maybe you could have had a virtualised JVM). However, the development of this processor took such a long time that by the time it was done, a general purpose CPU running the JVM compiled for it was faster than the custom hardware that was built to do just that, so it was a commercial flop.

That said, embedded JVMs exist almost everywhere -- on SIM cards, chip-and-pin, in Blu-Ray players -- and as embedded devices need no virtualisation.

Bear in mind that the JVM was created to allow abstract code to run on an unknown processor in the form of set-top-boxes, and that it has become wildly successful in the embedded space -- though the advent of the internet and code-in-browsers made it take off as a general purpose programming language and runtime environment. The fact that it's lasted 25 years and no-one has thought it relevant to add virtualisation begs the question of why you think it's an interesting question to ask?