Oracle plans to join Java hardware speed party

Following in the footsteps of Microsoft, Mozilla, Google and Apple, Oracle is now turning to hardware acceleration to speed up Java by harnessing the emerging potential of the GPU. The OpenJDK project’s Hotspot group has said it will explore ways of speeding Java with a native Java Virtual Machine (JVM) that taps hardware …

[ByeLaw101]

Am I missing something?

"Oracle is coming relatively late to the GPU party. Microsoft, Mozilla, Google and Apple already all offer hardware acceleration for their browsers using GPU"

GPU acceleration for an enviornment such as Java has nothing whatsoever to do with accelerating a browser?? Has MS done this in .NET then? Eh? I must be missing something here surely?

[David Knapman]

Re: Am I missing something?

Agreed - it's almost as if they forgot what the topic was, because up at the top they were talking of "offloading code generation, garbage collection and runtimes" - no mention of graphics at all.

[Richard 81]

GPU computing

Are we talking graphics acceleration for games and stuff, or a JVM that can do GPU computing?

A JVM that natively supports OpenCL would be super.

[Anonymous Coward]

One in the eye for that pesky Thermodynamics 'thang', then?

"..Hardware acceleration suggests Oracle is trying to improve Java as a platform for gaming and web apps – not only the ones that run on regular browsers, but also those which run on devices such as smartphones and tablets. Apps for such devices tend to be big on graphics while the machines have relatively limited computer power and battery life – something that gets drained by a repeated thrashing from the CPU..."

So by running the same (but differently executed/despatched) workload in the GPU instead of the CPU could be done without any detrimentental effect on power/battery life?

[cyborg]

Re: One in the eye for that pesky Thermodynamics 'thang', then?

No, but doing things in "software" is almost certainly going to be more resource costly than "hardware" because in general when you can execute something in "hardware" that means the hardware has a piece of silicon optimised to the task and can therefore execute it with fewer transistors doing their switching thing than a general piece of logic could. That means less power usage and better performance through less distance for the execution of a task to travel through the hardware.

[Stephen Channell]

WTF "focus is on offloading code generation, garbage collection"

offloading code generation, garbage collection and runtimes is what you do to “threads” running on different “cpu cores” not thrown out to a massively parallel GPU.

Where GPU does come into play is in graphical rendering, which is where OpenGL comes into play.. but how you would get a JFC/Swing app with all its Java event handlers to talk OpenGL sounds like magic. Microsoft went through this with the move from WinForms (Win32/GDI) to WPF (Direct-X/GPU) – everything changes.

The other use of GPU is for parallel-compute.. which can work just dandy in .NET with a pinned array of struct, but you need to go IBM X10 to get anything like it in the Java world

[BlueGreen]

Re: WTF "focus is on offloading code generation, garbage collection"

I go with your skepticism to a degree. I'm well baffled as to how a gpu can help with garbage collection. It seems a most unlikely application.

[Gaja Sutra]

Given presence of AMD Gary Frost, I will suggest a link to a probable ancestor of this project:

http://code.google.com/p/aparapi/

[Giles Jones]

I'll look forward to that then. Should be ready by about 2020 in JDK 9.6.

[Robert Grant]

JDK 9.6 is formally known as Scala 12, Java legacy extensions

[Anonymous Coward]

Someone had to do it.

Finally an agreement then that Java requires special* hardware to run it with decent performance?

Anyway, before the flame war starts, read this: http://paulgraham.com/icad.html

*I use to work for a company, long ago, that use to develop "special" hardware specifically for Java! People go to long lengths to make some things stick.

[Frumious Bandersnatch]

Re: Someone had to do it.

Finally an agreement then that Java requires special* hardware to run it with decent performance?

I can't tell if you're joking or not, but are you aware that some ARM devices have the capability of running Java bytecode (more or less) natively with Jazelle? That's not to say that Java needs special hardware, and it certainly wouldn't be the first time that hardware has been built with support for a particular high-level language in mind--most notably the Lisp Machines of the '80s. The wikipedia page for them (http://en.wikipedia.org/wiki/Lisp_machine) also mentions some other languages where special CPUs/computers were built: Prolog, Modula-2, Erlang and, yes, Java.

That certainly doesn't mean that any of these languages need special-purpose hardware. I think it's more a case of "if we can improve performance by building custom CPUs/machines, then why not try?"

[ByeLaw101]

RE: Someone had to do it.

Nice on Anonymous Coward, you've pointed to an opinion piece which does not mention anything about the performance of any given language, never mind Java. Yeah, any one language can be better than another depending on the job...yawn... never have thought that.

Java runs fine in the enterprise, thats why you'll find it at the heart of Oracle, IBM, Novell etc... and these are enterprise guys that need the thing to scale... so I suspect your talking bollocks (a bit like the article your commenting on!) .

Anonymous for a reason hey?

[Frumious Bandersnatch]

GPGPU in Java is very difficult

While not specifically to do with GPUs as such, I did some research a while back into the possibility of getting a Java VM that could run on a PS3 so that it would be able to run code on the SPUs as well as on the main CPU (PPU). Besides the approach of actually adding new keywords to the language (as is mentioned in the article), I found two projects that actually got some way towards the goal. Both aimed to take unmodified Java code and have it run on an asymmetric CPU setup (ie, the PS3's Cell). The first (*) was based on the CACAO JIT compiler and hooked into the function call mechanism so that each method got executed on a separate core. I don't think the author got very far, but he did go over a lot of options and documented a lot of the design decisions very well. The second (**) was based on the Jikes Research VM and it used thread creation as the point to migrate control over to a new core. That project got a lot further, but I don't think they ever publicly released the code (although I'm sure an email to the authors would probably get you access). Again, the various papers and such that they produced give really good descriptions of the approach taken and all that.

Where I'm going with this is that it's hard enough to target the JIT code generation so that it can run on an asymmetric setup like that of the Cell processor. It's much more difficult when you try to target it to graphics hardware. OpenCL is a nice step in the right direction for doing GPGPU work, but graphics hardware design (except maybe for the really high end stuff--I'm not sure) still tends to be geared towards fixed ideas of the execution pipeline (eg, shader models, emphasis on textures and matrices) and there are generally fairly high penalties for such things as branching, sending data back out to the CPU (outside of the frame buffer mechanisms), context switching and inter-core communication (again, if it lies outside the standard shader/pipeline model). I would love to see GPU cores and the interconnects between them and the CPU moving more towards the Cell model, but OpenCL notwithstanding I don't think we're making much progress in that direction. Likewise, I'd love for these guys to succeed, though I think it's going to be a long hard climb.

* http://vergiss-blackjack.de/diploma-thesis_georg-sorst_java-on-cell.pdf

** http://research.microsoft.com/pubs/132351/herajvm_oopsla.pdf