
Java Optimized Processor (2005) - Koshkin
https://www.jopdesign.com/
======
mcbridematt
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
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
I wonder how it compares to Shenandoah 2.0, which has been spectacular for me.

~~~
sitkack
[https://youtu.be/3l2oi-X8P38?t=129](https://youtu.be/3l2oi-X8P38?t=129)

~~~
microcolonel
I.... I think there's been a mistake.

------
Twirrim
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.

------
schoeberl
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
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
> 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)

~~~
FullyFunctional
yes, thanks

------
self_awareness
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
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
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
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.

------
miked85
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
And Jazelle

[https://en.wikipedia.org/wiki/Jazelle](https://en.wikipedia.org/wiki/Jazelle)

~~~
kevin_thibedeau
Which ARM technically still supports.

~~~
murderfs
Only in the sense that the instruction to enter Jazelle mode exists, and will
always return failure.

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

~~~
skissane
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
The lines are somewhat blurred even in historical LISP machines. Microcode is
hardware.

~~~
fiddlerwoaroof
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.

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

~~~
WrtCdEvrydy
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
IBM has hardware that accelerates XML processing:
[https://en.wikipedia.org/wiki/IBM_WebSphere_DataPower_SOA_Ap...](https://en.wikipedia.org/wiki/IBM_WebSphere_DataPower_SOA_Appliances)

~~~
infogulch
Wow, if that's not proof that xml is a terrible format, I don't know what is.

~~~
simion314
>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.

------
aritraghosh007
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/)

------
RubenSandwich
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
ARM has a whole instruction set extension for JVM code (Jazelle).

------
exabrial
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.

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

