Will Java go native?

[Bruno Medeiros]

On 19/09/2013 11:06, deadalnix wrote:
>
>>> *Java's sluggish performance was what made me look for alternatives
>>> in the first place, and I found D.
>>
>> I accept this as true as it is a statement by you about your decision
>> making, but Java 8 is not Java 1. Early desktop Java was pure
>> interpretation, and hence slow. Modern Java, via the JIT, generally
>> executes native code. With Java 7 and method handles and invokedynamic,
>> the world changed even more and now computationally intensive codes can
>> run basically as fast using Java as using C, C++, Fortran, D, Rust, Go.
>> (After initial "warm up" of the JIT.)
>>
>
> Yes, the warm up is usually a severe drawback for user applications.
> Server app do not suffer from it that much. I guess that is why java is
> so much used server side, but not that much to create GUI apps.

Yeah, tell me about it. :/
When I was writing the new parser for DDT I explored and tested a few 
optimizations that the JVM does to ellide object allocations 
(essentially escape analysis to see when an object can be treated as 
value object, and deallocated automatically at the end of some scope).
I wanted to use a certain pervasive code idiom in the parser that would 
make the code more elegant, but less performant if this optimization was 
not made.
( http://www.meetup.com/Londonjavacommunity/messages/52187462/ )
Fortunately the JVM is its later incarnations is quite smart in its 
escape analysis, but unfortunately this is all done at runtime, whereas 
a lot of it could be performed compile-time. :( But it seems the Java 
folks (at least for OpenJDK) have a big aversion to performing any kind 
of compile-time optimizations, even though a lot could be done here.


-- 
Bruno Medeiros - Software Engineer