Java > Scala

[Paulo Pinto]

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.

Am 30.11.2011 22:50, schrieb Walter Bright:
> On 11/30/2011 12:56 PM, Paulo Pinto wrote:
>> Are you not being a bit simplistic here?
>>
>> There are several JVM implementations around not just one.
>
> It's not the implementation that's the problem, it's the *definition* of
> the bytecode for the JVM.
>
>
>> Plus if I understand correctly some complains of people using D in real
>> projects, in many cases JVM JITs are able to generate better code than
>> D. At
>> least for the time being.
>
> Only if you're writing "Java" code in D. If you write using value
> structs, for example, or use array slicing, things don't work out so
> well in Java which can't do either.