6 ms·

Years ago there was the Jazelle project on ARM processors that tried to run Java on hardware: https://en.wikipedia.org/wiki/Jazelle https://en.wikipedia.org/wi

Years ago there was the Jazelle project on ARM processors that tried to run Java on hardware: https://en.wikipedia.org/wiki/Jazelle https://en.wikipedia.org/wiki/Jazelle I wonder what were the pros and cons of this, and why it didn't end up being integrated in later ARM CPUs.

pjmlp 6y ago
Because like all the other language attempts, there are hardly performance improvement vs a general purpose CPU and a more flexible runtime written in software.
- dehrmann 6y ago
  Jazelle was for ARM, mostly to make J2EE faster. These days, it's more practical to compile all the Java to ARM when an app is installed or in the background when the phone is charging. For server-side applications, you'll either use Graal, or just live with slow-ish startup times and let the JIT warm up.
  - pjmlp 6y ago
    Since around 2000 there has been support for AOT in Java commercial JDKs, or JIT caches across execution runs. So living with slow-ish startup times and let the JIT warm up was mostly a matter for those not wanting to shell out money for them. Actually, most likely Graal Community edition and its integration in OpenJDK, alongside AppCDS (from J/Rockit), while IBM also brought their AOT/JIT tooling into OpenJ9 that made Excelsior JET decide it wasn't worth any longer. So besides the BEA, Oracle, IBM commercial compilers now turned into free beer, PTC, Aicas are the surviving ones, but they target embedded scenarios. And then there is Android Java with JIT/AOT as well.
schoeberl 6y ago
Jazelle was intended for mobile phones to support Java apps on the phone. I had a phone with Jazelle and it run Java quite fast those days. But since Apple killed Java on the phone with the iPhone with native apps from the App Store and no Java support, this was the end for Jazelle.
GregarianChild 6y ago
ARM requires precise exceptions, which meant translation of bytecode was on instruction by instruction basis in the fetch/decode stage ... which is not good for performance. Moreover, Jazelle could only do simple bytecode in hardware, the complex instructions were done in software, which lead to massive exception-emulate-return overhead. Also, Jazelle was Java only, so no support for other byte codes, which limited Jazelle's potential. Within a few years, everybody had a 'null implementation'

pjmlp 6y ago

Because like all the other language attempts, there are hardly performance improvement vs a general purpose CPU and a more flexible runtime written in software.

dehrmann 6y ago
Jazelle was for ARM, mostly to make J2EE faster. These days, it's more practical to compile all the Java to ARM when an app is installed or in the background when the phone is charging. For server-side applications, you'll either use Graal, or just live with slow-ish startup times and let the JIT warm up.
- pjmlp 6y ago
  Since around 2000 there has been support for AOT in Java commercial JDKs, or JIT caches across execution runs. So living with slow-ish startup times and let the JIT warm up was mostly a matter for those not wanting to shell out money for them. Actually, most likely Graal Community edition and its integration in OpenJDK, alongside AppCDS (from J/Rockit), while IBM also brought their AOT/JIT tooling into OpenJ9 that made Excelsior JET decide it wasn't worth any longer. So besides the BEA, Oracle, IBM commercial compilers now turned into free beer, PTC, Aicas are the surviving ones, but they target embedded scenarios. And then there is Android Java with JIT/AOT as well.

schoeberl 6y ago

Jazelle was intended for mobile phones to support Java apps on the phone. I had a phone with Jazelle and it run Java quite fast those days. But since Apple killed Java on the phone with the iPhone with native apps from the App Store and no Java support, this was the end for Jazelle.

GregarianChild 6y ago

ARM requires precise exceptions, which meant translation of bytecode was on instruction by instruction basis in the fetch/decode stage ... which is not good for performance. Moreover, Jazelle could only do simple bytecode in hardware, the complex instructions were done in software, which lead to massive exception-emulate-return overhead. Also, Jazelle was Java only, so no support for other byte codes, which limited Jazelle's potential. Within a few years, everybody had a 'null implementation'