Yeah, the "Java Optimized Compiler." I've heard of that before. I think I heard of that in 1998, when everyone was complaining about how slow Java was, and I kept telling them 'soon Java will run directly on the CPU - no translation or interpretation or anything.'

Well, that world never really came to fruition, but Katherine Noyes isn't afraid to exorcise old ghosts in her article on The Life Expectancy of Linux, which includes the assertion that the Java Optimized Complier just might be the next thing down the pipe; A very long pipe, but down the pipe nevertheless.

I've been thinking for a while now that Java would have a more universal appeal if the all VM's had a built in native compiler so that you could choose to either run under the VM or compile once.  There are advantages and disadvantages to both approaches.  I know that the design of the JVM makes this difficult (if not impossible to do across the board) but I wonder how things might have been had that been in the original requirements.

I've been hearing about this for ages. I wonder why it hasn't been done? It sounds like a good thesis project or something for an Engineering or Software faculty. 

I've been hearing about this for ages. I wonder why it hasn't been done? It sounds like a good thesis project or something for an Engineering or Software faculty. 

The AS400 environment will natively compile and optimize the code.  In that case the the JVM is tightly integrated into the OS.  On the other hand, I've seen stuff that suggested to me that the fully optimized and natively compiled option wasn't completely trustworthy.

From what I recall, one of the major hurdles is that because all JDK is monolithic, you end up having to compile in everything from that plus GC.  Then you have reflection which means the compiler can't know what classes might be used later so reflection support has to be thrown in.  In short, it's been done but hasn't proven to be worthwhile.  I think to make it really feasible, you'd have to include this requirement in the design at the earliest stages.

Yeah, forking the Java codebase and creating something uniquely suited for this particular task probably isn't the most efficient use of our time.

How about to run Sun JVM on 600GB heap with 800+ cores? Now that is some serious stuff.

http://www.azulsystems.com/

One of their core engineers, PhD Cliff Click is by far the best, in every sense of the word, software engineer I have (virtually) seen in my life. The amount of knowledge this guy has is amazing. In the past he worked on at Sun on JVM.

How about to run Sun JVM on 600GB heap with 800+ cores? Now that is some serious stuff.

http://www.azulsystems.com/

One of their core engineers, PhD Cliff Click is by far the best, in every sense of the word, software engineer I have (virtually) seen in my life. The amount of knowledge this guy has is amazing. In the past he worked on at Sun on JVM.

With their appliance you can basically dedicate 10 cores to JIT your entire code. Parallel all the way.

***with up to 864 processor cores and 768 GB of memory in a flat SMP configuration.

***with up to 864 processor cores and 768 GB of memory in a flat SMP configuration.

But does it scale? :P

Valid point. By increasing number of customers I would say probably yes. But one thing I am sure, Cliff will come up with some good solution, by either increasing L1/L2/L3 cache sizes, or providing even NUMA capabilities, or adding plain ol' CPU coordination mechnism to they don't all choke at the same time.

Ooor [raises finger as if something new is about to be said], OMG, just popped into my mind, multiple close-by CPUs can do work stealing via dedicated communication channel, thus avoiding bus communication, just like in Doug Lea's Java work stealer, just at the different level of abstraction. =))

Agreed. Cliff is fantastically smart - and Azul pretty much fits what the post is asking about.

and Azul pretty much fits what the post is asking about.

Hmmm, am I being trolled here, hmm, hard to tell.

and Azul pretty much fits what the post is asking about.

Hmmm, am I being trolled here, hmm, hard to tell.

Not by me. Azul runs Java on the processors directly, with massive scale.

Not by me. Azul runs Java on the processors directly, with massive scale.

Ouch, ok, I apologize Joe. My bad.

Yep, they have pretty cool offering.

Agreed. Cliff is fantastically smart - and Azul pretty much fits what the post is asking about.

I've been reading cliff's blog for a while now. Azul is already achieving what the article talks about, but just not exactly the way they think of it. Azul's hardware + custom JVM gets some crazy performance based on the information Cliff has provided in talks and on his blog. I hear coherence runs quite well on azul hardware. Of course, that's if you can afford it.

Yes I agree that Java has become faster. But comparing Microsoft Office with Open Office I see still an amazing difference in performance. Java should still work a lot on its performance.

Yes I agree that Java has become faster. But comparing Microsoft Office with Open Office I see still an amazing difference in performance. Java should still work a lot on its performance.

You know OpenOffice is almost entirely not written in Java, right?

There's a small portion of the database access piece that uses Java, but the rest is native code.

Yes I agree that Java has become faster. But comparing Microsoft Office with Open Office I see still an amazing difference in performance. Java should still work a lot on its performance.

Java is server/middleware language. Microsoft Office is, to the best of my knowledge, written in C++. MS Office is not portable. OO is portable. OO is free. MO is not. OO is based on the only truly working (and good) standard for office applications: ODF. MO can not even run OOXML, spec MSFT pushed into the ISO. Also, OO has lots of legacy baggage (they use CORBA all over the place etc).

Even Alex Brown, who actually was one of the core pro-OOXML guys as standard was going thru ISO, has negative to say how even Microsoft is not conformant to its OOXML, and question is if they ever will be.
http://www.adjb.net/post/Microsoft-Fails-the-Standards-Test.aspx

MO is excellent product for those who do not care about standards and vendor lock-in, and prefer really good performance.

The rest prefers standard based solutions who are, at the same time, free.

Yeah, the "Java Optimized Compiler." I've heard of that before. I think I heard of that in 1998, when everyone was complaining about how slow Java was, and I kept telling them 'soon Java will run directly on the CPU - no translation or interpretation or anything.'

And that's absolutely stupid. Java bytecode is NOT suited to be run on real hardware. It's stack-based, so pipelining goes out of the window. In theory, one can do on-the-fly translation from stack-based to register-based machine, but it'll require A LOT of transistors.

So in reality, it's ALWAYS more effective to JIT-compile Java bytecode and then run it on a common CPU. There  is one exception JVMs for low-power devices where the speed of hardware JVM is not a problem (remember Forth CPUs).

Of course, hardware can still provide few features to speed up JVMs. Like hardware-assisted forwarding pointers which allow to create fast real-time compacting pauseless GC (I assume Azul hardware has this support).