Re: Basic Question about Virtual Machine in Lua

[William Ahern <william@...>]

On Mon, Jan 13, 2014 at 07:42:26PM -0800, Tim Hill wrote:
> 
> On Jan 13, 2014, at 6:57 PM, William Ahern <william@25thandClement.com> wrote:
> 
> > 
> > But it was always intended to be JITd even before Sun published the
> > specification. Sun was doing JIT compilation before Java was created, and
> > that experience fed directly into the design of Java.
> 
> Hmm, I?ve never heard that, and certainly it was a LONG time between Java
> getting into the wild and the hotspot VM appearing.

I don't know it for a fact, but its based on my understanding that Gosling
and others had worked on JIT compilers for Smalltalk languages, and that
they were already doing Java JIT work _before_ the public release in 1995.
 
The Sun JVM also debuted only supporting green threading, but that doesn't
mean they didn't plan on supporting kernel threading. Java and the Sub JVM
was a carefully planned rollout of features and improvements.

(FWIW, I haven't written anything in Java in over 10 years, and I don't
really care to defend Java in this regard.)

> > Yet both Java bytecode and the CIL use stack-based virtual machine models,
> > which is the precise thing you don't want to do if you want to make native
> > code compilation easier. Stack-based is what you use when you want things to
> > be simpler and more convenient for compilation and execution in software.
> 
> The issue is less about register vs stack based (they both have pros and
> cons) so much as the metadata output by the compiler along with the
> bytecode. Java bytecode has very little, whereas MSIL is much richer,
> providing the hints needed for the JIT to do a better (and faster) job.
> This really comes down to the design point; Java bytecode was designed to
> be executed, MSIL was designed to be JITted. I?m no great fan of .Net over
> Java, but this is one place where the MS design is better than Sun?s (MS
> compensated for this by messing up the rest of .net wonderfully :).

I agree that Microsoft and Anders Hejlsberg had a better idea of how to make
C# and CIL easier to JIT. But using a stack-based VM is definitely a bad
idea if your primary objective is JIT-ableness, no matter how much
annotation you toss in. You'll likely get better results with no annotation
and a register-based VM, but I'd be happy to be proven wrong.

Regardless, I'm fairly certainly the primary objective of CIL was easy of
generation and tooling. Some quick Googling turned up this quote from a
paper by Don Syme, the designer of F#:

	CIL is a stack-based language designed to be easy to generate from
	source code by compilers and other tools.

	-- http://research.microsoft.com/pubs/69132/babel01.pdf

Much as with Java bytecode, I believe it was simply assumed that
developments in the state-of-the-art would eventually solve all the problems
with transforming stack-based VM bytecode to native code. But that day never
seems to come. All the techniques (tracing, etc) always come up short for
complex programs, and the gains you get from directly using a register-based
architecture remain considerable.

I'd have to check the history, but I'd wager that when C# and CIL was being
developed Java had just started playing around with inline annotations.
Runtime introspection and tooling is the more likely reason for annotation
features in CIL bytecode.