On 11/30/2011 10:19 PM, Paulo Pinto wrote:
This is not what I understand from bearophile's comments every now and then,
when we compares dmd with other languages implementations.
Now even if the JVM design is not the best in the world, most implementations
nowadays recompile on demand are are able to:
- devirtualize method calls
- replace heap allocation by stack allocation thanks to escape analysis
- re-JIT code and replace calls by inline code
- perform loop unrolling
- ...
Here are a few papers about JVM's implementations that I am aware of:
http://www.ecst.csuchico.edu/~juliano/csci693/Presentations/2008w/Materials/Swisher/DOCS/sources/Escape%20Analysis%20for%20Java.pdf
http://www.research.ibm.com/people/h/hind/ACACES06.pdf
http://webdocs.cs.ualberta.ca/~amaral/IBM-Stoodley-talks/UofAKASWorkshop.pdf
http://wikis.sun.com/display/HotSpotInternals/EscapeAnalysis
http://www.slideshare.net/jbaruch/jvm-magic
I do think there is a lack of language implementations that
compile directly to native code nowadays, but I am also quite aware that the
millions spent in VM research along the years have provided quite a few fruits.
When you can implement a competitive malloc() using Java, I'll believe it has
reached parity. There's a reason why the JVM is itself implemented in C, not
Java. D's runtime is implemented in D.
Most Java benchmarks I've seen that showed Java being competitive were written
in Java (or at least Java style) and then ported to other languages. The reason
is because if you want to convert C, C++, or D code to Java, you have to
re-engineer it.
The reason escape analysis is used in the JVM is because the Java bytecode is
severely limited in what it can express. So, a language bytecode generator has
to bash its semantics somehow into that tiny vocabulary, and then the JVM has to
"reverse engineer" the intent back out of it. The effort poured into the JVM is
to recognize higher level Java constructs, not higher level Scala constructs,
hence the poor results from Scala mentioned in the article.
