Thanks for the info, interesting the first four you mention are commercial products. Two you may find interesting: avian vm, and xml vm at one point could translate jvm bytecode to c for compilation with gcc.
What Dave's presentation mentions is the memory... note the huge difference in memory footprints of the programs. That's where java loses heavily, and that can affect speed as well, which was his point.
Does adding Generics heavy code move the needle in Java's favor?
As a Scala developer your comment just jumped out at me because even doing a lot of Akka this past week, there's hardly a line of code that doesn't instantiate or manipulate a Generic.
Just curious. I'm sure Go will get faster. I'm sure it's better suited to certain problems (memory constrained especially).
No. If you don't use generics in Java, you get the same memory footprint of not using generics (or since it doesn't have type parameters, using any) in Go. So the author is making an unfair apples-oranges comparison when the apples-apples comparison is quite obvious: one can write an int-list in Java just as easily as they can in Go.
Frankly, this is just strong intellectual dishonesty.
No, compared to nothing. Go is fast (or at least that's what Go programmers feel when they are using it). If they want to know why, they can read this article. This article is not Go vs. Java vs. C++ advocacy, don't try to make it looks like it is. It makes no claim Go employs better optimization technology than C++.
In Java's case there are quite a few JVMs, many of those with AOT compilation to choose from, even implemented in Java itself.