Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

en.wikipedia.org

Post reply on HN
Print view View original

11–20 of 77 posts

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

#11

Post by jaywee »

fch42 wrote: 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…

Sun wanted to do the same thing in late 90ties - picoJAVA (embedded), microJava and UltraJava (VLIW workstations).

Relegated to the dustbin of history.

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

#12

Post by willvarfar »

In a similar spirit, Apple seems to have made sure some critical OSX idioms were fast on the M1, perhaps even influencing their instruction set.

Retaining and releasing an NSObject took ~6.5 nanoseconds on the M1 when it came out, comparing with ~30 nanoseconds on the equiv gen Intel.

In fact, the M1 _emulated_ an Intel retaining and releasing an NSObject fast than an Intel could!

One source: https://daringfireball.net/2020/11/the_m1_macs

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

#13

Post by fch42 »

michaelt wrote: 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 even helped) by hardware acceleration. The "equivalent" of static linking to minimize the footprint never quite existed.

So on a smartcard ... write software in a (uncommon, and when compared with ARM which is a very "rich" assembly language) form of low-level instruction set, and pay both Sun and ARM top$ for the privilege - nevermind the likely "runtime" footprint far exceeding the 256kB RAM you planned for that 5$ card - why? Writing small singlethreaded software in anything that compiles down to a static ARM binary has been easy and quick enough that going off the ARM instruction set looked pointless for most. And learning which parts of "Java" actually worked in such an environment was hard, even (or especially?) for developers who knew (the strengths of) Java well. Because developers and specifiers expected "rich Java", and couldn't care less about the Bytecode. JITs later only hoovered up the ashes.

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

#14

Post by lionkor »

BenoitP wrote: 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…

> as Moore's law continues to end

more like Wirths law proving itself still

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

#15

Post by fidotron »

fch42 wrote: 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.

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

#16

Post by pjmlp »

BenoitP wrote: 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…

As free beer AOT compilers for Java are commonly available, and as shown on Android since version 5, I doubt special opcodes will matter again.

Ironically when one dives into computer archeology, old Assembly languages are occasionally referred as bytecodes, the reason being that in CISC designs with microcoded CPUs they were already seen that way by hardware teams.

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

#18

Post by pjmlp »

fidotron wrote: post #15
fch42 wrote: 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.

As Nokia alumni it was incredible how much of the Google fanbase believed in Dalvik's performance fairy tail.

ART is another matter, though.

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

#19

Post by pjmlp »

fch42 wrote: post #6
RicoElectrico wrote: post #4

Earlier quoted context omitted.

> I don't remember any early Android device ever used it. It couldn't have, as Dalvik VM is distinct from JVM.

It executes Java Bytecode. Whether Dalvik VM was/is a "Java" VM is hardly relevant there (not the least because "Java" is so much more than Java Bytecode, and Jazelle does nothing to help with anything on top of the latter).

It certainly doesn't.

https://source.android.com/docs/core/runtime/dalvik-bytecode

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

#20

Post by nadavwr »

Running bytecode instructions in hardware essentially means a hardware-based interpreter. It likely would have been the best performing interpreter for the hardware, but JIT-compilation to native code still would run circles around it.

During years when this instruction set was relevant (though apparently unutilized), Oracle still had very limited ARM support for Java SE, so having a fast interpreter could have been desirable -- but it makes no sense on beefier ARM systems that are able to support decent JIT or AOT support available nowadays.

Post reply on HN