Red Hat Devs Working On ARM64 OpenJDK Port

hypnosec writes "Developers over at Red Hat are busy porting OpenJDK to ARM's latest 64-bit architecture — the ARMv8, also known as the AArch64. The current OpenJDK ARM situation is rather unsatisfactory: for the current 32-bit ARM processors, there are two versions of the HotSpot JVM for OpenJDK — Oracle's proprietary JIT, and a less sophisticated free JIT that performs poorly in comparison. To avoid a similar situation for the 64-bit platform, the developers are working on an entirely Free Software port of HotSpot to 64-bit ARM."

Comments

Re:Orcale

[Billly Gates]

RedHat has an agreement with Sun that Oracle inherited. They can't do anything about it at this point.

Great idea

[SplashMyBandit]

This is excellent news.

It will also be awesome when OpenJDK is ported to Android (it'll probably never make it to iOS due to Apple blocking it, which is a real shame). The IcedRobot project is attempting to do this. Just image, if you could write your application in Java and it would work nearly seamlessly on all the Windows, Linux, Unix, Mac, BSD and Android devices you have to look after. Sure, there are gotchas on each platform but you are usually 99% of the way there (at least, that has been my experience) and your unit and integration tests allow you to quickly find and address any platform quirks.

For all its flaws (and it certainly has them) Java's goal of having a single enterprise-quality language (and, far more importantly, a broad amount of *standardized* libraries ) available on all platforms is a great thing. Only those companies with an vested interest in keeping the IT world silo-ed in islands resist such standardization. Sure, innnovate in your own languages but don't try and balkanize or block standard Java on your platform. Most of us want to amortize their development investment across multiple platforms (and the broadest swathe of the market), and making us use niche tools just for only your platform is painful for us. Our ideal is to develop once and sell everywhere. Portability is what made C great, and for modern development is the single most important feature of Java as a language for huge-scale development projects (nothing else comes close; other languages are portable but their libraries are often not).

Go RedHat!

ps. queue the Java haters. For me the language is less important than the goal: Write Once Run Everywhere (& Test Everywhere, this is the real world after all). Skilled Java developers can get pretty damn close to this ideal.

Re:Great idea

[pnot]

For me the language is less important than the goal: Write Once Run Everywhere (& Test Everywhere, this is the real world after all).

Indeedy. But these days you can use the Java platform without using the Java language. Next time I'm writing something for the JRE, I'm going to give Scala a shot. (And if it's riddled with gotchas, I can always come back to Java...)

Re:Great idea

[viperidaenz]

Here's hoping Mono will also be working on x86

Re:Great idea

[dreamchaser]

Why would I want Java shit eating up my iPhone battery?

Good point, since because of deliberate designed obsolescence you can't replace it or carry a spare. A lot of people might want to run Java applications on their phones. A lot of those people have the option to carry spare batteries or, heaven forbid, get an extended life battery. Pity that Apple doesn't allow that on their iShiny devices.

Re:Great idea

[SplashMyBandit]

> The "Write Once Run Everywhere" idea is a good one, but it will never be realized by Java.
As a practitioner in the field I have to disagree with you. Too bad you're an AC so we can't debate this properly and you can provide better evidence for your assertion. The rest of your post is without merit - it is hyperbole, since it either applies to all software or ignores the fact that the Free Software OpenJDK is where the real innovation is and Oracle has been shown not to hold the reigns.

Re:Great idea

[codepunk]

Interviewed with a gamer shop recently and they where telling me how unstable their platform was. They where hoping I could help them out, then proceeded to tell me they where using scala for production work. My response was this, hmm no thanks I cannot help you.

Re:Great idea

[codepunk]

No he is correct it is why iphone apps smoke the android apps for performance. The overhead introduced by java just means you need at least 20% more cpu,ram etc just to get equal performance.

Re:Great idea

[SplashMyBandit]

lol. I've had to write Java applications to run on cheap single board computers that have the same amount of RAM as a PS3 (that is, fsck all by modern standards - so little you'd have trouble buying such a small amount for a PC these days). The Job Security is the fact it runs anywhere (both a large run of hardware scales, and operating systems).

Re:Great idea

[devent]

It's a shame that even Sun did not believed in the "Write Once Run Everywhere" of Java.
They could have had something like Android years before of Google, in fact Google approached Sun to create Android together (see Oracle vs. Google). But instead Sun created JavaME.

Re:Great idea

[codepunk]

Hey no need for attacks, and far from unemployed and far from being a small gamer company. Hey I am not knocking scala if you want to write in it go ahead. I am just saying it does not exactly have a long proven history as of yet. Just like I love node.js it is bad ass, however I would hesitate to run it in a critical production system as I have experienced instability with it. Just sayin I tend to play it a bit safer when it comes to production work.

Re:Great idea

[dreamchaser]

No he is correct it is why iphone apps smoke the android apps for performance. The overhead introduced by java just means you need at least 20% more cpu,ram etc just to get equal performance.

Yeah that's why most apps on Android don't benefit much if at all when native code (like the NDK lets you write) is used. Keep drinking that KoolAid though. It must be delicious.

I have an iPhone and an Android tablet. Both are pretty quick and there is no noticeable difference between the platforms. Well that's not true. The Asus tablet is noticeably faster but that's not fair because it's a quad core Tegra 3 with twice the RAM.

Why just 64bit?

[Anonymous Coward]

What's stopping them from doing this for 32bit ARM while their at it?

Re:Why just 64bit?

[pavon]

Also, RedHat doesn't care about mobile devices; they care about ARM servers. 64bit will be more more relevant in that area, as java backend code often needs as much memory as you can give it.

Re:Why just 64bit?

[Anonymous Coward]

There already is a JIT for 32 bit OpenJDK.

Re:Orcale

[SplashMyBandit]

Incorrect. They cannot sue OpenJDK. Sun had an explicit grant in the license for their JDK which allows compatible implementations to use all their patents. OpenJDK was created under these conditions. The restriction is that the trademark "Java" cannot be used unless you have passed the Test Compatibility Kit to ensure that the Java Write Once Run Anywhere promise is upheld. This is what shafted Microsoft's incompatible implementation in year's past (since it broke that promise to users).

Google were sued by Oracle for breaching copyright (in a clearly ridiculous case). This does not apply to OpenJDK because it was created under the Gnu General Public License (GPL). So OpenJDK will remain free forever - which is the whole point of the GPL (companies can't change their mind and shaft users; Stallman foresaw that possibility after his printer driver travails with Xerox way back in 1980).

So be happy, you can confidently rely on OpenJDK being around for decades.

Re:Orcale

[lister king of smeg]

as long as its gpl oracle can shove it because they were stuck with the licence sun chose for it

Java is already on Android, kinda

[coder111]

Um, I already have Debian Kit installed into my rooted Android mobile with ARM CPU (Samsung Galaxy Ace). And Debian does include OpenJDK, although 32 bit. I can compile & run console Java applications just fine. I even have some experimental X windows server there, but most X apps still either crash or run out of memory. Xeyes runs fine though. I read somewhere that people had better luck with headless X windows server and Android VNC client displaying whatever is displayed on that server. I'll have to try that some day, if this setup doesn't run out of memory.

Samsung Galaxy Ace is underpowered to run Java or X with anything complex on it though... I need to check out IcedRobot.

Oh, and I agree- Java is great for many things. Some people will still hate it, but I use it every day and I still cannot find better technology for what I do (mostly serverside enterprise stuff).

--Coder

Avoiding a similar situation

[SSpade]

I wonder how they're planning to prevent Oracle releasing a more sophisticated proprietary JIT for 64 bit ARM?

Re:Avoiding a similar situation

[viperidaenz]

File a patent based on existing JIT patents that adds "... on a 64 bit ARM core" to the claims

Secret ARM opcodes can execute JVM bytecode

[kriegsman]

Many ARM-based chips include the "Jazelle DBX" (Direct Bytecode eXecution) hardware CPU extension, which lets "95% of [JVM] bytecode" be executed directly by the CPU -- without need for recompilation to 'native' ARM/Thumb instructions. (See http://en.wikipedia.org/wiki/Jazelle )

However, unlike most of the ARM universe which is fairly open, Jazelle DBX's specs, implementation, and operating details are apparently a closely held secret, shared by ARM only with select JVM implementors. I'll be interesting to see if ARM decides to help out the OpenJDK people. Googling around, it looks like so far the answer has been "No."

Re:Secret ARM opcodes can execute JVM bytecode

[Anonymous Coward]

Jezelle is slow and is not intended for performance. It was intended for low power execution.
The HotSpot JVM is and adaptive compiler. Java Byte codes are converted into native instructions during executions. Over time, critical paths will become fully optimized. "Hot spots" in the execution will be further dynamically executed.

You see, running native is fast. There's no difference between what the JVM can compile to native and, say, a c compiler. In light of being able to simply parse and convert byte code directly to the underlying assembly, something like Jazelle really doesn't offer much. It's not like it has magic instructions that will somehow be faster then the execution units in the CPU.

Of course, the compiling costs time and therefore power. Something less good, perhaps, on mobile. (Though caching the binaries from a first run isn't that hard.) On an ARM server you wouldn't care about the compile time spent, because execution time is better in native.

It's also important to point out that most ARM implementations only support Jazelle at the ISA level. That is, they don't map directly to any kind of Java-execution hardware. Instead, microcode simply maps it to regular arm to get simple instructions. This is quite a bit slower than what the JVM would produce, since it does no dynamic optimizations based on the run time profile. (additional loop unrolling, method inlining where appropriate, etc)

Re:Orcale

[SplashMyBandit]

Meh. I use Postgresql. Technically betterer, legal betterer. There is no problem.

Re:Orcale

[bill_mcgonigle]

This does not apply to OpenJDK because it was created under the Gnu General Public License (GPL).

I'd like to look in on the mirror universe sometime where Google decided to base Davlik on OpenJDK and avoided the whole lawsuit thing and had a performant vm to boot.

So be happy, you can confidently rely on OpenJDK being around for decades.

Longer than Oracle Java, I'd bet good money.

Java comeback

[Pecisk]

If we look more practically it has never left, it just returns to desktop environment. Tons of very useful Java applications are made and used by millions of users. Main sales point - yes, one binary works (with tweaks and testing) on at least 10 different platforms. For example, OpenStreetMap has an excellent editor for advanced mappers JOSM - while Linux for example has their native editors for OSM, JOSM wins hands down in portability and universality. That means a developer can hack together a plugin for JOSM using Linux desktop, and after one good testing and bug hunting phase, it just works everywhere. Also user experience is much easier to share.

Of course using JVM have drawbacks and we all know them, and you won't use it for resource sensitive cases. But in many cases positives outweigh them.

Re:Orcale

[SplashMyBandit]

> Longer than Oracle Java, I'd bet good money.
There is very little actual difference between 'Oracle' Java and OpenJDK. They share the same source base. The primary difference is legal: license conditions and ownership.

Re:Orcale

[devent]

Look here: MaraDNS. It is a fork of MySQL, incorporates all free available changes from MySQL and makes some improvements.

Re:Orcale

[Anonymous Coward]

Who's Orcale?

A killer whale of a company.

Re:Orcale

[jawtheshark]

Aren't you mixing up with MariaDB? This looks more like a DNS implementation that a database.

Re:Orcale

[Lennie]

It rather use PowerDNS, as it supports DNSSEC. It also uses PostgreSQL a superior solution in many situations. PowerDNS supports many backends it can also serve from bind zone files for example.

Re:Orcale

[Terrasque]

I am intrigued by your ideas, and want to subscribe to your newsletter detailing how to switch a SQL based storage system to a DNS based storage system.

Would that qualify as a NoSQL system, by any chance? I hear that is a frightfully innovative buzzword, and should ideally be applied to all new processes, to ensure "hipsterness" and "webscale", whatever that means. It would also means that our investors would contribute with even bigger gobjaws of money, and you just can't have enough money, you know.

Re:Orcale

[Raenex]

Google were sued by Oracle for breaching copyright (in a clearly ridiculous case). This does not apply to OpenJDK because it was created under the Gnu General Public License (GPL).

They also sued over patents, but those are also covered by the license for the JDK. Even better, Oracle lost on both the copyright and patent fronts in its lawsuit against Google.

But will it be hardware accelerated?

[kriston]

I hope it will be hardware accelerated. I have also wondered if Android's Dalvik VM took advantage of built-in hardware acceleration in ARM processors. It seems to be a waste if it's not used.

Terribly good news for me.

[boorack]

Regardless of technicals and wherever you use arm64 or not, this means that there will be a well qualified team of engineers working on OpenJDK besides Oracle. This is Good News (TM), folks ! For last three years I was worried that Larry will do with Java what he does with all other products and technologies he puts his hands on - specifically, turn it into crap (uh, yes - money producing one - yet total crap from engineer/dev/admin perspective). Oracle might be good money sucking entity, yet it is a remarkably poor steward to technologies and standards they put their hands on (especially open ones).

So, this is very good news folks! I'd even urge you to support Red Hat in this regard and make sure all your pet projects work as charm on OpenJDK (in addition to Oracle JDK).

Re:Orcale

[devent]

You are so right. I meant of course MariaDB the fork of MySQL. I don't know why I wrote MaraDNS, maybe because they sound a-like. I'm sure one of the poster have corrected me already.