Hello LJC.

I've recently been developing Java code which is more computationally intensive (a parser) than what I typically work in. And so I've been more sensitive to low-level performance issues (ie, not algorithmic performance) than I think I've ever been, when programming in Java. Due to that, I've been reading a bit more about performance features of the JVM.

I was particularly interested in Java eliminating unnecessary allocations using escape analysis, since I've had an idea for a code idiom that I could use pervasively in my code under development that would make it quite more elegant and safe. But it uses several temporary objects, so it could make it slower, unless the compiler eliminates those unnecessary allocations.

So, from what I've looked up online, I've been surprised, and even a bit annoyed, by some of my findings. First, fortunately, Java does do escape analysis, although a bit scaringly, it was only first introduced in Java6, and then even so only to elide locks and other synchronization stuff. If I understood correctly, only recently in Java7 was escape analysis actually used to elide some object allocations as well... (you'd think that with so much effort put into GC optimization and technology, these other optimizations would have come a lot sooner!)

But the thing that annoys me, and the point of this post, is that all these and other optimizations occur in the JIT phase. They don't occur when you compile your source code. In fact, from my understanding the Java compiler (at least the Oracle JDK one) does little to no optimizations during source compilation. Just some inlining of constants, removing unused variables and that's it, nothing complex.

I know that a few people here in the LJC are quite involved with the high-tiers of development of the Java technology itself (the language, the JDK, etc.) , so does anyone know if there is a good reasoning for that? Is it something that could be changing in the future, since Oracle took over and JDK development is picking up more pace?

I do know that the JVM does runtime performance profiling, and uses that profiling to make better choices for JIT compilation and optimization, using runtime data that would not be available at compile-time. That's all good and fine, but it doesn't mean compile-time optimization should be abandoned entirely. There are still many compile-time optimizations that are worthwhile to do, like the aforementioned escape analysis, even if in some cases they could be optimized even further in runtime by the JIT compiler, for certain runtime scenarios.

Some consequences of this (unfortunate, in my view) status quo is the dichotomy of having both a Server and Client HotSpot runtimes to chose from (http://stackoverflow.com/questions/198577/real-differences-between-java-server-and-java-client). This is annoying because it is a tricky choice to make for desktop (non-server) applications. For server applications it's easy, you nearly always want the server HotSpot, but otherwise the choice is not so clear. Sometimes for a desktop application you will get better overall performance by running it with the Server Hotspot if your application runs long enough, despite the overhead caused by the more complexing JITting. But again, why isn't most of this overhead just dealt at development compile-time?...

Cheers.

PS: http://i1.kym-cdn.com/entries/icons/original/000/004/006/y-u-no-guy.jpg

--
Bruno Medeiros

--
Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])
This message was sent by Bruno Medeiros ([address removed]) from LJC - London Java Community.
To learn more about Bruno Medeiros, visit his/her member profile
Set my mailing list to email me As they are sent | In one daily email | Don't send me mailing list messages

Meetup, POB 4668 #37895 NY NY USA 10163 | [address removed]