8 ms·

Java Optimized Processor (2005)

69 points by Koshkin 6y ago

self_awareness 6y ago
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'
jpt4 6y ago
And then we can have Clojure on bare metal, and we're almost back to LISP machines!
- skissane 6y ago
  This doesn't directly execute JVM bytecode in hardware. It provides a stack machine architecture, and translation from JVM bytecode to its custom stack machine instruction set. I think the theory is that translating from one stack machine to another is a better way than existing JVM implementations which translate the JVM stack machine to register machine instructions (x86/ARM/etc). It may be more elegant in theory, but I doubt the benefits in practice are enough to justify the switching costs. The biggest problem with any Java-in-hardware design, is the JVM is a moving target (and it is moving faster now than it used too), and without a sustained engineering investment you soon get left behind. Plus, with custom silicon (ASIC), new features will require new hardware. At least this is an FPGA design, so you can field-upgrade the FPGA – but the price-performance of an FPGA is poor, especially as this is a platform for general-purpose computation rather than building some kind of specialised computational accelerator. Although, since it is not directly executing JVM bytecode in hardware, it may be possible to support some newer JVM features just by updating the translation software. But a cool research project nonetheless.
  - jojobas 6y ago
    The lines are somewhat blurred even in historical LISP machines. Microcode is hardware.
    - fiddlerwoaroof 6y ago
      Yeah, as long as you can “polyfill” or “monkeypatch” in the new JVM instructions, it’s not a huge problem: ideally you take a page from IBM’s TIMI, and you treat compilation as a form of caching: you store the JVM code on permanent storage, and compile it to the underlying hardware on first execution, saving the result until the CPU is upgraded.
    - kazinator 6y ago
Twirrim 6y ago
Not quite the same, but this brings back memories of both Transmeta and PicoJava: https://en.wikipedia.org/wiki/Transmeta https://en.wikipedia.org/wiki/Transmeta https://en.wikipedia.org/wiki/PicoJava https://en.wikipedia.org/wiki/PicoJava Transmeta's processor was able to run Java bytecode through built in emulation layer.
identity0 6y ago
Why do we optimize our CPUs to fit our programming languages instead of desigining our languages around our CPUs?
- WrtCdEvrydy 6y ago
  Because languages are used for optimizing programmer output (these days) while CPUs are designed for general use compute. I think it would be a regression in technology to start having Intel Web-Compute Processors and Intel Gaming-Compute Processors but you know... that's just crazy me.
  - pulse7 6y ago
    IBM has hardware that accelerates XML processing: https://en.wikipedia.org/wiki/IBM_WebSphere_DataPower_SOA_Appliances https://en.wikipedia.org/wiki/IBM_WebSphere_DataPower_SOA_Ap...
    - infogulch 6y ago
      Wow, if that's not proof that xml is a terrible format, I don't know what is.
      - pjmlp 6y ago
        It might not be optimal, but it certainly is better than the alternatives regarding machine processing, data validation, graphical tooling and comments.
      - simion314 6y ago
        >Wow, if that's not proof that xml is a terrible format, A bad format for what? Do you mean that you assume that HTML,markdown would look better in something like JSON? I want to see a "proof" for documents you write in JSON by hand.
- pulse7 6y ago
  For decades the CPUs have been optimized to run faster existing applications - regardless in which programming languages the apps are written. On the other hand you can find languages designed around our CPUs (like Rust with its "zero-cost abstractions").
deleted 6y ago
[deleted]
mcbridematt 6y ago
Azul Systems (who today are mainly a JVM vendor) started by building large multicore boxes (Vega) to do Java workloads - there is an interesting tech talk about it: https://www.youtube.com/watch?v=5uljtqyBLxI https://www.youtube.com/watch?v=5uljtqyBLxI (2009) They built a "really good JIT target" rather than direct bytecode for reasons explained in the video. Curious to hear from anyone who ever used one...
- arjunpunnam 6y ago
  Yes, was part of Team which used Azul Zing and had very minimal issues.The Primary use-case was to minimize the application downtime during Stop-the-World GC and Zing is almost pause-free.
  - microcolonel 6y ago
    I wonder how it compares to Shenandoah 2.0, which has been spectacular for me.
    - sitkack 6y ago
      https://youtu.be/3l2oi-X8P38?t=129 https://youtu.be/3l2oi-X8P38?t=129
      - microcolonel 6y ago
        I.... I think there's been a mistake.
aritraghosh007 6y ago
Ever since the advent of Java 8, developers who had previously moved on to newer generation of programming languages are now slowly piquing their interest in Java again which is equally exciting and reassuring to see. Java has consistently ranked at the top in the TIOBE index. https://www.tiobe.com/tiobe-index/ https://www.tiobe.com/tiobe-index/
miked85 6y ago
This reminds me of Sun MAJC [1], which was another processor optimized for running Java. [1] https://en.wikipedia.org/wiki/MAJC https://en.wikipedia.org/wiki/MAJC
- dehrmann 6y ago
  And Jazelle https://en.wikipedia.org/wiki/Jazelle https://en.wikipedia.org/wiki/Jazelle
  - kevin_thibedeau 6y ago
    Which ARM technically still supports.
    - murderfs 6y ago
      Only in the sense that the instruction to enter Jazelle mode exists, and will always return failure.
    - GregarianChild 6y ago
      Are there any real implementations of Jazelle in 2020 that are in active use in a modern processor supporting the Arm ISA?
schoeberl 6y ago
The JOP served me well for years of research work, but only little commercial success. This project is kind of stalled. JOP’s strength was worst-case execution time, not average case speed. No Java processor beats JIT on a modern Intel processor.
- FullyFunctional 6y ago
  JOP is pretty neat and a good reminder that FPGAs enables us to make unconventional machines. Another impressive one is J16 which is an amazingly small FORTH machine. I'm surprised that I haven't found a Lisp machine, but at least there's Reduceron for lazy function languages (complete with hardware GC).
  - MaxBarraclough 6y ago
    > Another impressive one is J16 which is an amazingly small FORTH machine Did you mean the J1? https://www.excamera.com/sphinx/fpga-j1.html https://www.excamera.com/sphinx/fpga-j1.html
    - deleted 6y ago
      [deleted]
    - FullyFunctional 6y ago
      yes, thanks
  - jonjacky 6y ago
    There have been a few Lisp processors made with FPGAs: http://www.aviduratas.de/lisp/lispmfpga/ http://www.aviduratas.de/lisp/lispmfpga/ https://opencores.org/projects/igor https://opencores.org/projects/igor also https://www.flickr.com/photos/kaitorge/sets/72157609445719327/show/ https://www.flickr.com/photos/kaitorge/sets/7215760944571932... https://www.mail-archive.com/picolisp@software-lab.de/msg04823.html https://www.mail-archive.com/picolisp@software-lab.de/msg048... also https://www.mail-archive.com/picolisp@software-lab.de/msg04837.html https://www.mail-archive.com/picolisp@software-lab.de/msg048...
archgoon 6y ago
Might want to put a [2005] in the title, when the thesis was published.
exabrial 6y ago
Azul Systems once had an immensely powerful [at the time] Java Hardware processor that could execute Java operations and lock intrinsics at many times the speed of available x86 hardware.
RubenSandwich 6y ago
Not as strange an idea as you would think. In fact the ARM instruction set has a instruction for "Floating-point Javascript Convert to Signed fixed-point, rounding toward Zero" FJCVTZS.[0] Considering the ubiquity of JS I expect more "JS/Wasm instructions" to be added in the future. (A Wasm co-processor appearing in 5 years is a bet I'm willing to make.) [0] https://stackoverflow.com/a/50966903 https://stackoverflow.com/a/50966903
- fulafel 6y ago
  ARM has a whole instruction set extension for JVM code (Jazelle).

69 points by Koshkin 6y ago

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'

jpt4 6y ago

And then we can have Clojure on bare metal, and we're almost back to LISP machines!

skissane 6y ago
This doesn't directly execute JVM bytecode in hardware. It provides a stack machine architecture, and translation from JVM bytecode to its custom stack machine instruction set. I think the theory is that translating from one stack machine to another is a better way than existing JVM implementations which translate the JVM stack machine to register machine instructions (x86/ARM/etc). It may be more elegant in theory, but I doubt the benefits in practice are enough to justify the switching costs. The biggest problem with any Java-in-hardware design, is the JVM is a moving target (and it is moving faster now than it used too), and without a sustained engineering investment you soon get left behind. Plus, with custom silicon (ASIC), new features will require new hardware. At least this is an FPGA design, so you can field-upgrade the FPGA – but the price-performance of an FPGA is poor, especially as this is a platform for general-purpose computation rather than building some kind of specialised computational accelerator. Although, since it is not directly executing JVM bytecode in hardware, it may be possible to support some newer JVM features just by updating the translation software. But a cool research project nonetheless.
- jojobas 6y ago
  The lines are somewhat blurred even in historical LISP machines. Microcode is hardware.
  - fiddlerwoaroof 6y ago
    Yeah, as long as you can “polyfill” or “monkeypatch” in the new JVM instructions, it’s not a huge problem: ideally you take a page from IBM’s TIMI, and you treat compilation as a form of caching: you store the JVM code on permanent storage, and compile it to the underlying hardware on first execution, saving the result until the CPU is upgraded.
  - kazinator 6y ago

Twirrim 6y ago

Not quite the same, but this brings back memories of both Transmeta and PicoJava: https://en.wikipedia.org/wiki/Transmeta https://en.wikipedia.org/wiki/Transmeta https://en.wikipedia.org/wiki/PicoJava https://en.wikipedia.org/wiki/PicoJava Transmeta's processor was able to run Java bytecode through built in emulation layer.

identity0 6y ago

Why do we optimize our CPUs to fit our programming languages instead of desigining our languages around our CPUs?

WrtCdEvrydy 6y ago
Because languages are used for optimizing programmer output (these days) while CPUs are designed for general use compute. I think it would be a regression in technology to start having Intel Web-Compute Processors and Intel Gaming-Compute Processors but you know... that's just crazy me.
- pulse7 6y ago
  IBM has hardware that accelerates XML processing: https://en.wikipedia.org/wiki/IBM_WebSphere_DataPower_SOA_Appliances https://en.wikipedia.org/wiki/IBM_WebSphere_DataPower_SOA_Ap...
  - infogulch 6y ago
    Wow, if that's not proof that xml is a terrible format, I don't know what is.
    - pjmlp 6y ago
      It might not be optimal, but it certainly is better than the alternatives regarding machine processing, data validation, graphical tooling and comments.
    - simion314 6y ago
      >Wow, if that's not proof that xml is a terrible format, A bad format for what? Do you mean that you assume that HTML,markdown would look better in something like JSON? I want to see a "proof" for documents you write in JSON by hand.
pulse7 6y ago
For decades the CPUs have been optimized to run faster existing applications - regardless in which programming languages the apps are written. On the other hand you can find languages designed around our CPUs (like Rust with its "zero-cost abstractions").

deleted 6y ago

[deleted]

mcbridematt 6y ago

Azul Systems (who today are mainly a JVM vendor) started by building large multicore boxes (Vega) to do Java workloads - there is an interesting tech talk about it: https://www.youtube.com/watch?v=5uljtqyBLxI https://www.youtube.com/watch?v=5uljtqyBLxI (2009) They built a "really good JIT target" rather than direct bytecode for reasons explained in the video. Curious to hear from anyone who ever used one...

arjunpunnam 6y ago
Yes, was part of Team which used Azul Zing and had very minimal issues.The Primary use-case was to minimize the application downtime during Stop-the-World GC and Zing is almost pause-free.
- microcolonel 6y ago
  I wonder how it compares to Shenandoah 2.0, which has been spectacular for me.
  - sitkack 6y ago
    https://youtu.be/3l2oi-X8P38?t=129 https://youtu.be/3l2oi-X8P38?t=129
    - microcolonel 6y ago
      I.... I think there's been a mistake.

aritraghosh007 6y ago

Ever since the advent of Java 8, developers who had previously moved on to newer generation of programming languages are now slowly piquing their interest in Java again which is equally exciting and reassuring to see. Java has consistently ranked at the top in the TIOBE index. https://www.tiobe.com/tiobe-index/ https://www.tiobe.com/tiobe-index/

miked85 6y ago

This reminds me of Sun MAJC [1], which was another processor optimized for running Java. [1] https://en.wikipedia.org/wiki/MAJC https://en.wikipedia.org/wiki/MAJC

dehrmann 6y ago
And Jazelle https://en.wikipedia.org/wiki/Jazelle https://en.wikipedia.org/wiki/Jazelle
- kevin_thibedeau 6y ago
  Which ARM technically still supports.
  - murderfs 6y ago
    Only in the sense that the instruction to enter Jazelle mode exists, and will always return failure.
  - GregarianChild 6y ago
    Are there any real implementations of Jazelle in 2020 that are in active use in a modern processor supporting the Arm ISA?

schoeberl 6y ago

The JOP served me well for years of research work, but only little commercial success. This project is kind of stalled. JOP’s strength was worst-case execution time, not average case speed. No Java processor beats JIT on a modern Intel processor.

FullyFunctional 6y ago
JOP is pretty neat and a good reminder that FPGAs enables us to make unconventional machines. Another impressive one is J16 which is an amazingly small FORTH machine. I'm surprised that I haven't found a Lisp machine, but at least there's Reduceron for lazy function languages (complete with hardware GC).
- MaxBarraclough 6y ago
  > Another impressive one is J16 which is an amazingly small FORTH machine Did you mean the J1? https://www.excamera.com/sphinx/fpga-j1.html https://www.excamera.com/sphinx/fpga-j1.html
  - deleted 6y ago
    [deleted]
  - FullyFunctional 6y ago
    yes, thanks
- jonjacky 6y ago
  There have been a few Lisp processors made with FPGAs: http://www.aviduratas.de/lisp/lispmfpga/ http://www.aviduratas.de/lisp/lispmfpga/ https://opencores.org/projects/igor https://opencores.org/projects/igor also https://www.flickr.com/photos/kaitorge/sets/72157609445719327/show/ https://www.flickr.com/photos/kaitorge/sets/7215760944571932... https://www.mail-archive.com/picolisp@software-lab.de/msg04823.html https://www.mail-archive.com/picolisp@software-lab.de/msg048... also https://www.mail-archive.com/picolisp@software-lab.de/msg04837.html https://www.mail-archive.com/picolisp@software-lab.de/msg048...

archgoon 6y ago

Might want to put a [2005] in the title, when the thesis was published.

exabrial 6y ago

Azul Systems once had an immensely powerful [at the time] Java Hardware processor that could execute Java operations and lock intrinsics at many times the speed of available x86 hardware.

RubenSandwich 6y ago

Not as strange an idea as you would think. In fact the ARM instruction set has a instruction for "Floating-point Javascript Convert to Signed fixed-point, rounding toward Zero" FJCVTZS.[0] Considering the ubiquity of JS I expect more "JS/Wasm instructions" to be added in the future. (A Wasm co-processor appearing in 5 years is a bet I'm willing to make.) [0] https://stackoverflow.com/a/50966903 https://stackoverflow.com/a/50966903

fulafel 6y ago
ARM has a whole instruction set extension for JVM code (Jazelle).