6

It struck me recently that a virtual machine for a high level programming language is very much like an OS. It manages resources, e.g. stack, heap, etc. similar to how an operating system manages resources and if the programming language supports threads then the virtual machine also does time-sharing and context switching similar to how an operating system does it.

How far can this analogy be taken? Why is that we don't have a bare-metal implementation of the JVM? It seems like all the pieces are there so what exactly is the reason such things are not more prevalent?

Improve this question
3

6 Answers 6

Reset to default
4

How far can this be taken?

Pretty far. You might want to check out jnode (Java New Operating system Design Effort) (github repo) which is a full bare metal implementation of the JVM. Only about 500k of assembly, as a "nano-kernel," used in the boot process. Once the OS is running, all running code is actually java.

Why is that we don't have a bare-metal implementation of the JVM?

A lot of things that JVM developers are used to thinking of as "just there" are actually supported by the underlying OS, and the JVM just uses the OS resource. Example: Device drivers. If you look at the jnode code above, you will find that there is ongoing effort in building device drivers. They need to be written in java, which you will never see anywhere else.

Improve this answer
2
  • Is jnode dead? It seems they haven't updated the site in a while.
    – Aviv Cohn
    Commented Mar 8, 2014 at 10:13
  • I checked the site before I posted this. There seems to have been some activity in the last couple of months. Jnode does seem to move slowly, and I suspect that this is at least partly due to the work involved in implementing hardware-level stuff. Skillsets [java language] and [bare metal driver] don't always intersect. But it is a fair question.
    – SailsMan63
    Commented Mar 8, 2014 at 14:30
7

There are "bare metal" machines based on virtual machines. Most recently, there have been various attempts at a Java Processor which would run a JVM (well, JM since its not virtual) in hardware. They do exist - though not in general purpose machines that we use, they more harken back to the original embedded idea that Java was born from.

This harkens back to the Lisp machine which approached CPU design instead with high level instructions in the CPU itself.

The reason is... you don't really get that much out of the specialization at a hardware level... and the direction of research has been for smaller instruction sets with multiple cores rather than trying to make complex instructions. That's where the money has been chased and thats why people are exploring that path more.

The question to consider - is narrowing down your available programs that the system can run worth the investment cost of creating such a system. Furthermore, as the general purpose processors get faster, can you keep up with a viable alternative?

... cheaper desktop PCs soon were able to run Lisp programs even faster than Lisp machines, without the use of special purpose hardware. Their high profit margin hardware business eliminated, most Lisp Machine manufacturers went out of business by the early 90s ...

From Wikipedia on the Lisp Machine.

Note that last section on the other language-optimized computers which includes the above mentioned Java Processors. They just haven't been commercially viable in most situations (and none of them for a general purpose machine).

Improve this answer
2
  • en.wikipedia.org/wiki/MAJC
    – gnat
    Commented Mar 15, 2014 at 21:10
  • 1
    It goes back farther than that. Wirth et al defined a "P-machine", a virtual machine to facilitate porting PASCAL to new architectures. Shortly afterwards, Western Digital produced a hardware implementation of the P-code machine. This was in the early 1970s.
    – John R. Strohm
    Commented Nov 11, 2016 at 17:23
3

Bare metal JVMs do (did?) exist, but never scaled enough in volume to fund enough development R&D to keep up with super high-volume mainstream processor implementations. An x86 (in a small nanometer process) or ARM ends up running a JVM faster and cheaper and using less power than a multi-Moores-law-generations-behind (thus, in big nanometer or micron process) custom JVM. And it currently takes tens of millions to billions to keep up.

The same thing happened to some non-consumer-driven RISC architectures and some less-specialized DSPs.

Improve this answer
2

Hardware implementations of the JVM do exist, and there are a number to choose from. However, they aren't without some drawbacks. For one, you can't easily upgrade the machine if it's written in silicon.

Improve this answer
2

You are correct that there is a close relationship between VMs and Operating Systems. There is also a close relationship between those two and Programming Languages. In fact, one might argue that they are more or less the same thing!

There is a famous quote by Daniel H. H. Ingalls from the Design Principles of Smalltalk: "an Operating System is a collection of routines missing from the language; there shouldn't be one."

The original Smalltalk machines didn't have an OS, or rather the Smalltalk system was the OS. Even the video drivers were written in Smalltalk. You might also want to look into the design of the AS/400, which is closely related to what you are asking about.

Improve this answer
1

Only superficially.

OS typically does not have the luxury to run detailed static (compiler or machine code) analysis on any executable code that the user is about to run on the OS.

Whereas the language execution environment is partly responsible for compiling the code from a higher level representation into executable machine instructions, therefore it is in a perfect position to perform analyses to prevent certain types of malformed, rogue, or jailbreaking payload.

On the other hand, high-end anti-virus solutions often promise to do this kind of analyses. However it can only do this on a very selective basis.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.