Live data from Hacker News

Jazelle DBX: Allow ARM processors to execute Java bytecode in hardware

en.wikipedia.org

21–30 of 77 posts

Re: Jazelle DBX: Allow ARM processors to execute Java bytecode in hardware

#21
post #8

The gains seem to not have been high enough to sustain that project. Nowadays CPUs plan, fuse and reorder so much of micro-code that lower-level languages can sort of be considered virtual as well. But Java and similar languages extract more freedom-of-operation from the programmer to the runtime: no memory address shenanigans, richer types, and to some extent immutability and sealed chunks of code. All these could b…

Remember when for a while Azul tried to sell custom CPUs to support features in their JVM (e.g. some garbage collector features that required hardware interrupts and some other extra instructions). Although they dropped it pretty quickly in favor of just working on software

https://www.cpushack.com/2016/05/21/azul-systems-vega-3-54-c...

Re: Jazelle DBX: Allow ARM processors to execute Java bytecode in hardware

#22
post #13
post #5

I remember reading about Jazelle many years ago - before the release of the iPhone and suchlike. This was the age when people were coming up with things like 'Java Card' - smartcards programmed directly in Java. I never heard of anyone actually using Jazelle, though - I assume JIT ended up working better.

I'm a little in the realm of speculation here. Part of the issue with Java for embedded devices was "a bad fit". What made Java thrive in the server or even applet spaces wasn't the instruction set but the rich ecosystem around Java. Yet, threading - as "inherent" to Java it is - is provided by the OS and "only" used/wrapped by the JVM. All the libraries ... megabytes of (useful) software, yet not implemented (nor ev…

Java is doing just fine in embedded devices.

https://www.ptc.com/en/products/developer-tools/perc

https://www.aicas.com/wp/

https://www.microej.com/

https://en.wikipedia.org/wiki/BD-J

https://www.thalesgroup.com/en/markets/digital-identity-and-...

Re: Jazelle DBX: Allow ARM processors to execute Java bytecode in hardware

#23
post #5

I remember reading about Jazelle many years ago - before the release of the iPhone and suchlike. This was the age when people were coming up with things like 'Java Card' - smartcards programmed directly in Java. I never heard of anyone actually using Jazelle, though - I assume JIT ended up working better.

IIRC people didn't "really believe" that Java could actually be performant because they assumed that since it has a JIT layer, it would never even get close to native code.

But the reality was that JIT allows code to get faster over time, as the JIT improves.

Things like Jazelle let chip manufacturers paper over a paper objection.

Re: Jazelle DBX: Allow ARM processors to execute Java bytecode in hardware

#24
post #23
post #5

I remember reading about Jazelle many years ago - before the release of the iPhone and suchlike. This was the age when people were coming up with things like 'Java Card' - smartcards programmed directly in Java. I never heard of anyone actually using Jazelle, though - I assume JIT ended up working better.

IIRC people didn't "really believe" that Java could actually be performant because they assumed that since it has a JIT layer, it would never even get close to native code. But the reality was that JIT allows code to get faster over time, as the JIT improves. Things like Jazelle let chip manufacturers paper over a paper objection.

Specialized hardware has been losing out against general for years.

There were those "LISP machines" in the early 1980s but when Common Lisp was designed they made sure it could be implemented efficiently on emerging 32-bit machines.

Re: Jazelle DBX: Allow ARM processors to execute Java bytecode in hardware

#26
post #23

Earlier quoted context omitted.

IIRC people didn't "really believe" that Java could actually be performant because they assumed that since it has a JIT layer, it would never even get close to native code. But the reality was that JIT allows code to get faster over time, as the JIT improves. Things like Jazelle let chip manufacturers paper over a paper objection.

Specialized hardware has been losing out against general for years. There were those "LISP machines" in the early 1980s but when Common Lisp was designed they made sure it could be implemented efficiently on emerging 32-bit machines.

Part of the reason is anytime a specialized hardware is found that works, the generalized hardware steals the feature that makes it faster - basically the story of all the extensions to x86 like SSE, etc.

Re: Jazelle DBX: Allow ARM processors to execute Java bytecode in hardware

#27
post #8

The gains seem to not have been high enough to sustain that project. Nowadays CPUs plan, fuse and reorder so much of micro-code that lower-level languages can sort of be considered virtual as well. But Java and similar languages extract more freedom-of-operation from the programmer to the runtime: no memory address shenanigans, richer types, and to some extent immutability and sealed chunks of code. All these could b…

> Pointer masking: you can fit a lot in the unused higher bits of an address. Some GCs use them to annotate memory (refered-to/visited/unvisited/etc.), but you have to mask them. A hardware assisted mask could help a lot.

If you're building hardware masking, it should be viable for low bits too. If you define all your objects to be n-byte aligned, it frees up low bits for things too, and might not be an imposition, things like to be aligned.

Re: Jazelle DBX: Allow ARM processors to execute Java bytecode in hardware

#28
post #3

My brainfog claims some blurry memories of this ... for one, documentation is lacking so much that an opensource JVM using Jazelle never happened; you wanted to develop a JVM on top of it, you'd pay ARM for docs, professional services, and unit licenses. And second, that once things got to the ARM11 series cores, software JITs beat the cr* out of Jazelle. I don't remember any early Android device ever used it. ARM is…

The performance of Dalvik was far below J2ME on Nokia and Sony Ericsson feature phones for a very long time, and Android relied on pushing a lot to C libraries to compensate.

Sure, but J2ME can't seek backwards in open files. (That was added in Java 1.4, and J2ME is 1.3)

Re: Jazelle DBX: Allow ARM processors to execute Java bytecode in hardware

#29
post #9

Fun fact, both the Wii's seconday ARM chip used for security tasks and the iPhone 2G's processors had Jazelle but never used them.

It was on every Arm926, 1136 and 1176. Lots of devices of a certain era had it but didn’t use it.

Re: Jazelle DBX: Allow ARM processors to execute Java bytecode in hardware

#30
The trend of posting a page here based on some detail from a comment, that was posted in another thread ("What's that touchscreen in my room?" in this case) a few days ago, has become quite frequent and a bit annoying.

To everyone who wants to write: but I didn't read that thread and I find this quite interesting; you are free to find it interesting, but I did read about it 2 days ago and to me it looks like karma farming.

Post reply on HN