Wilco (Wilco.Dijkstra.delete@this.ntlworld.com) on November 19, 2012 7:59 am wrote:

[snip]

> > And maybe Google will man up and give developers tools so
> > they can compile to their virtual machine without
> > sacrificing speed/features. All the developers who pollute
> > the market place with native binaries are a pain.
>

> As a compiler expert I'm sceptical that virtual machines can ever deliver close to native performance. The
> key issue with JIT compilation is that you just do not have the resources of a native compiler. It doesn't
> help that many intermediate bytecodes are completely unoptimized, making the problem far worse (what is the
> point of Java compilers emitting x * 0 in byte codes?!?). What you actually want to do is to perform as much
> work as possible in the static compiler and end up with a highly optimized intermediate code that just needs
> to be converted into the final target assembly with a quick peephole pass. For example you want to do register
> allocation to a virtual 16-register target (so it maps trivially to Thumb-2, ARM64 and x64).

Have you heard of Semantic Dictionary Encoding? http://www.hokstad.com/semantic-dictionary-encoding.html . It's basically a dump of the internal state of a compiler right at the instant before it generates a binary, represented as a compressed tree. It's _really_ compact.

Producing native code basically involved just feeding this data to the chunk of the compiler that does peepholing and emission of code, at load time. This was both simple and fast, and binary generation was actually faster than loading native binaries at the time, because the representation is so compact that IO speed was more limiting than the code generation.

I was very annoyed when Sun released Java later, and it was yet another 20 year old p-code machine variant (and incidentally, p-code machines were partially popularized 20 years earlier by the same group working then on SDE). Talk about not doing your homework!

-Ray