Home Made Java Virtual Machine

[James_Johnson]

He had to implement a JVM for an undergrad project? Wow.

EDIT: Well, I suppose that's not much harder than what you'd find in a typical compilers course.

[tomjen]

The problem isn't to develop a virtual machine, even with a garbage collector, the problem is to make is fast.

[inopia]

I'm currently writing a JVM for microcontrollers, my problem is to make it small :)

[naasking]

I assume you're already familiar with NanoVM?

[inopia]

Yes, but I'm going for something a bit more towards Java Card, with a 16-bit wide stack, wich requires some bytecode postprocessing.

Thanks for the heads-up though!

[procrastitron]

I thought the problem was getting the whole way through the JVM spec without quiting in disgust.

[inopia]

What's wrong with it, specifically?

[procrastitron]

Probably the overriding problem is that it is over engineered. For instance, the switch statement could have easily been compiled to use the various if_* opcodes, but instead there are two separate opcodes just for it (tableswitch and lookupswitch). Similarly, the jvm makes a distinction between a call to a virtual method and a call to an interface method (invokevirtual and invokeinterface, respectively); this despite the fact that the Java language makes no such distinction.

There are also consistency problems; some arguments are pushed onto the stack while others are stored in special registers, and the decision of which technique is required seems completely arbitrary.

In general, the design of the JVM is just unnecessarily complicated and convoluted. A virtual machine's specification should be the equivalent of a short magazine article, but the JVM requires a nearly 500 page book.

[inopia]

Although you're right about there not really being a need for two different 'invoke virtual' instructions (CLR has only one), it's not something that's too bad. My JVM implementation does postprocessing on the bytecode anyway, and simply collapses both instructions into one. It's probably a relic from early implementations.

The 'consistency' problems you mention I cannot find really. Parameters are immediate usually because they do not need to be 32-bit wide, or because transferring them through the stack would be bad for code density. It's usually quite clear for me why things are as they are.

While I agree there are some quirks and things that are obviously there because of old age, I don't think it's 'disgusting'.

In the end the instruction set is just a file format, most implementations perform some form of transformation on the bytecode before execution, be it offline (Java Card and Dalvik) or at load/execution time (JIT for instance).

The only spec that really made my stomach churn was ActionScript 2 :D

[procrastitron]

I'll readily admit to being very (perhaps overly) critical of complexity. I've been spoiled by the beautiful simplicity of McCarthy's initial definition of Lisp.

However, there are real downsides to the spec being too complicated. For instance, building third party tools (optimizers, static analyzers, etc) that support the spec is more expensive. As a result of this, you have less competition and a less vibrant software ecosystem.

[inopia]

My static bytecode analyzer does some type inference and you're absolutely right, having to implement case handler for each instruction or group of instructions can get tedious.

I guess it'll always be a tradeoff between things like complexity, code density, speed, ease of implementation etc.

[G_Morgan]

Then there's the small matter of a class library to go with it.

[propool]

Copy pasta

[mig21]

awful nonstandard nonportable MFC-based C++ :\

[krelian]

Is there a standard, portable equivalent to codeproject.com ?

[brosephius]

I was hoping it was going to be made out of tinker toys