3 ms·

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 'J

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.

fch42 3y ago
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.
- pjmlp 3y ago
  Java is doing just fine in embedded devices. https://www.ptc.com/en/products/developer-tools/perc https://www.ptc.com/en/products/developer-tools/perc https://www.aicas.com/wp/ https://www.aicas.com/wp/ https://www.microej.com/ https://www.microej.com/ https://en.wikipedia.org/wiki/BD-J https://en.wikipedia.org/wiki/BD-J https://www.thalesgroup.com/en/markets/digital-identity-and-security/technology/javacard https://www.thalesgroup.com/en/markets/digital-identity-and-...
bombcar 3y ago
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.
- PaulHoule 3y ago
  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.
  - bombcar 3y ago
    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.
- o11c 3y ago
  > But the reality was that JIT allows code to get faster over time, as the JIT improves. Ehh .. PGO is only somewhat better for JIT than AOT. More often for purely-numerical code the win is because the AOT doesn't do per-machine `-march=native`. It's the memory model that kills JVM performance for any nontrivial app though.
  - tenaf0 3y ago
    Well, code size is another interesting aspect here. A JIT compiler can effectively create any number of versions for a hot method, based on even very aggressive assumptions (an easy one would be that a given object is non-null, or that the interface only has a single instance loaded). The checks for these are cheap (e.g. it could be encoded as trapping an invalid page address in case of NPEs), and invalidation’s cost is amortized. Contrast this with the problem of specialization in AOT languages, which can easily result in bloated binaries (PGO does help here quite a lot, that much is true). For example, generics might output a completely new function for every type it gets instantiated with - if the function is not that hot, it actually makes sense to rather try to handle more cases with the same code.
lxgr 3y ago
Java Card is still around! There's a very high chance it's running on more than one chip inside your phone right now, and at least on one card in your wallet every time you use it.
balou23 3y ago
I think many smartcards, including SIMs, are still programmed in Java. Seems like it is the only standard of programming smartcards that was ever developed

fch42 3y ago

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.

pjmlp 3y ago
Java is doing just fine in embedded devices. https://www.ptc.com/en/products/developer-tools/perc https://www.ptc.com/en/products/developer-tools/perc https://www.aicas.com/wp/ https://www.aicas.com/wp/ https://www.microej.com/ https://www.microej.com/ https://en.wikipedia.org/wiki/BD-J https://en.wikipedia.org/wiki/BD-J https://www.thalesgroup.com/en/markets/digital-identity-and-security/technology/javacard https://www.thalesgroup.com/en/markets/digital-identity-and-...

bombcar 3y ago

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.

PaulHoule 3y ago
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.
- bombcar 3y ago
  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.
o11c 3y ago
> But the reality was that JIT allows code to get faster over time, as the JIT improves. Ehh .. PGO is only somewhat better for JIT than AOT. More often for purely-numerical code the win is because the AOT doesn't do per-machine `-march=native`. It's the memory model that kills JVM performance for any nontrivial app though.
- tenaf0 3y ago
  Well, code size is another interesting aspect here. A JIT compiler can effectively create any number of versions for a hot method, based on even very aggressive assumptions (an easy one would be that a given object is non-null, or that the interface only has a single instance loaded). The checks for these are cheap (e.g. it could be encoded as trapping an invalid page address in case of NPEs), and invalidation’s cost is amortized. Contrast this with the problem of specialization in AOT languages, which can easily result in bloated binaries (PGO does help here quite a lot, that much is true). For example, generics might output a completely new function for every type it gets instantiated with - if the function is not that hot, it actually makes sense to rather try to handle more cases with the same code.

lxgr 3y ago

Java Card is still around! There's a very high chance it's running on more than one chip inside your phone right now, and at least on one card in your wallet every time you use it.

balou23 3y ago

I think many smartcards, including SIMs, are still programmed in Java. Seems like it is the only standard of programming smartcards that was ever developed