8 ms·
Jazelle DBX: Allow ARM processors to execute Java bytecode in hardware
- nanolith 3y agoJazelle and its replacement, ThumbEE, have been deprecated and removed in later architectures. On modern Cortex-A systems, there are enough resources to make JIT feasible. On smaller systems, AOT is a reasonable alternative.
- fch42 3y agoMy 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 quite capable in vapourware generation. 64bit ARM was press-released (https://www.zdnet.com/article/arm-to-unleash-64-bit-jaguar-for-handhelds/ https://www.zdnet.com/article/arm-to-unleash-64-bit-jaguar-f...) a decade before ARMv8 / aarch64 became a thing. (I'd love to learn more)
- jaywee 3y agoSun wanted to do the same thing in late 90ties - picoJAVA (embedded), microJava and UltraJava (VLIW workstations). Relegated to the dustbin of history.
- miki123211 3y agoJava Card still survives, though. I find Java Card pretty puzzling. You go from high-level interpreted languages on powerful servers, to Java and C++ on less powerful devices (like old phones for example), to almost exclusively C on Microcontrollers, and then back to Java again on cards. If. it makes sense to write Java code for a device small enough to draw power from radio waves, why aren't we doing that on microcontrollers?
- cpgxiii 3y agoThe Java Card environment is quite limited, though, due to resource limitations. There have been several more-or-less successful attempts at running higher-level languages on microcontrollers, e.g. .Net Micro Framework and CircuitPython. In all of these cases, though, you tend to struggle with all the native device behavior being described/intended by the vendor for use with C or C++ and the BSP for the higher level environment being an afterthought.
- funcDropShadow 3y agoJavaCard is used in smartcards e.g. for banking cards. There you want to have more language guarantees to avoid losing money.
- sillywalk 3y agoFYI UltraJava was renamed to MAJC[0] which IIRC was only used in Sun's XVR graphics cards. More from Ars (1999) https://archive.arstechnica.com/cpu/4q99/majc/majc-1.html https://archive.arstechnica.com/cpu/4q99/majc/majc-1.html [0] https://en.wikipedia.org/wiki/MAJC https://en.wikipedia.org/wiki/MAJC
- RicoElectrico 3y ago> I don't remember any early Android device ever used it. It couldn't have, as Dalvik VM is distinct from JVM.
- fch42 3y agoIt 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).
- RicoElectrico 3y agoApparently it's not even Java bytecode. Would make sense, after all Dalvik is register-based. https://stackoverflow.com/a/36335740 https://stackoverflow.com/a/36335740
- pjmlp 3y agoIt certainly doesn't. https://source.android.com/docs/core/runtime/dalvik-bytecode https://source.android.com/docs/core/runtime/dalvik-bytecode
- bitwize 3y agoJava bytecode is transpiled to Dalvik's own bytecode as a build step. Dalvik itself doesn't run Java bytecode. This is one of the reasons why Oracle sued Google: clearly Google was trying to appropriate Java with some clever IP law dodges with this Dalvik business.
- lxgr 3y agoHuh, I always took their rationale for having the .class -> .dex compilation step at face value (i.e. space efficiency due to shared string literals etc.), but this actually makes more sense, given that J2ME seemingly was fine without it on much more lightweight hardware.
- Vogtinator 3y agoThere is a bit of info including example code on https://hackspire.org/index.php/Jazelle https://hackspire.org/index.php/Jazelle
- fidotron 3y agoThe 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.
- zozbot234 3y agoThere was a successor ThumbEE ("Execution Environment") that was comprehensively documented. But it didn't get much attention either and later chips removed it.
- happosai 3y agoIIRC jazelle left it to the implementers which bytecodes to handle in HW and what to trap to SW. Since SW JIT beat the Jazelle implementtions, by the arm11 times, the cpu implementers would just leave everything for the SW traps... So while the original raspberry pi was arm1176j and J meant Jazelle support, it was all already hollowed out.
- michaelt 3y agoI 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 agoI'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 agoJava 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
- BenoitP 3y agoThe 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 be picked up and turned into more performance by the hardware; with some help from the compiler. Sort of like SQL being a 4th-gen language, letting the runtime collect statistics and chose the best course of execution (if you squint at it in the dark with colored glasses) More recent work about this is to be found on the RISC-V J extension [1], still to be formalized and picked up by the industry. Three features could help dynamic languages: * Pointer masking: you can fit a lot in the unused higher bits of an address. Some GCs use them to annotate memory (refered-to/visited/unvisited/etc.), but you have to mask them. A hardware assisted mask could help a lot. * Memory tagging: Helps with security, helps with bounds-checking * More control over instruction caches It is sort of stale at the moment, and if you track down the people working on it they've been reassigned to the AI-accelerator craze. But it's going to come back, as Moore's law continues to end and Java's TCO will again be at the top of the bean-counter's stack. [1] https://github.com/riscv/riscv-j-extension https://github.com/riscv/riscv-j-extension
- lionkor 3y ago> as Moore's law continues to end more like Wirths law proving itself still
- pjmlp 3y agoAs 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.
- BenoitP 3y agoI'm still not decided on AOT vs JIT being the endgame. In theory JIT should be higher performance, because it benefits from statistics taken at actual runtime. Given a smart enough compiler. But as a piece of code matures and gets more stable, the envelope of executions is better known and programmers can encode that at compile-time. That's the tradeoff taken by Rust: ask for more proofs from the programmers, and Rust is continuing to pick up speed. That's also what the Leyden project / condensers [1] is about, if I understand correctly. Pick up proofs and guarantees as early as possible and transform the program. For example by constant-propagating a configuration file taken up during build-time. Something I've pondered over the years: a programmer's job is not to produce code. It is to produce proofs and guarantees (yet another digression/rant: generating code was never a problem. Before LLMs we could copy-paste code from StackOverflow just fine) In the end it's only about marginal improvements though. These could be superseded by changes of paradigm like RAM getting some compute capabilities; or programs being split into a myriad of specialized instructions. For example filters, rules and parsing going inside the network card; SQL projections and filters going into the SSD controller; or matrix-multiplication going into integrated GPU/TPU/etc just like now. [1] https://openjdk.org/projects/leyden/notes/03-toward-condensers https://openjdk.org/projects/leyden/notes/03-toward-condense...
- _chu1 3y agoFun fact, both the Wii's seconday ARM chip used for security tasks and the iPhone 2G's processors had Jazelle but never used them.
- willvarfar 3y agoIn 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 https://daringfireball.net/2020/11/the_m1_macs
- ithkuil 3y agoThe M1 emulation with Rosetta is actually dynamic recompilation so of you're measuring only that specific small section it's not surprising that Rosetta could have emitted optimal code for that instruction sequence
- lxgr 3y agoThat seems very similar to ARM introducing an instruction set that can be used to efficiently implement common Java idioms to me, just that x86 bytecode wasn't explicitly conceived as a VM target.
- nadavwr 3y agoRunning 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.
- nickpsecurity 3y agoIf you want a Java processor, there’s a cheap one for FPGA’s here: https://www.jopdesign.com/ https://www.jopdesign.com/ It’s more for embedded use. Might give someone ideas, though.
- depr 3y agoThe trend of posting a page here based on some detail from a comment, that was posted in another thread ("What's that touchscreen in my room?" in this case) a few days ago, has become quite frequent and a bit annoying. To everyone who wants to write: but I didn't read that thread and I find this quite interesting; you are free to find it interesting, but I did read about it 2 days ago and to me it looks like karma farming.
- deleted 3y ago[deleted]
- donio 3y agoRegarding the quality of posts in general the problem is not what gets posted, there is a ton of junk in the "new" queue and most of it never makes it to the front page. It's what gets upvoted.
- bitwize 3y agoWhy you gotta yuck other people's yum, man? To me it seems like Hackernews, as a whole, goes off on the same kinds of thought-tangents as I do, and that makes the site more interesting. And I was one of the commenters about Jazelle on the thread you mentioned.
- depr 3y agoBecause this is a community and I care about what goes on in it. I think this is precisely not a thought-tangent, it is taking the tangent that occurred elsewhere and posting an article about it to score internet points. If we keep doing that, this becomes even more of an echo chamber and a very boring place.
- lxgr 3y agoIt's exactly the opposite to me: I might not necessarily be interested in a box on someone's wall (even though I did enjoy that particular article) but at the same time be extremely interested in efficient mobile Java implementations with or without hardware support. Reposting that tangent as a separate submission increases the chance of me finding the conversation.
- LeFantome 3y agoI was going to say that history repeats itself. This is incorrect. This is actually just history. This is so old that its replacement, ThumbEE, had already been deprecated as well.
- Twirrim 3y agoA little related, back in the day Sun Microsystems came up with picoJava, https://en.wikipedia.org/wiki/PicoJava https://en.wikipedia.org/wiki/PicoJava, a full microprocessor specification dedicated to native execution of java bytecode. It never really went anywhere, other than a few engineering experiments, as far as I remember. For a while Linus Torvalds, of the Linux kernel fame, worked for a company called Transmeta, https://en.wikipedia.org/wiki/Transmeta https://en.wikipedia.org/wiki/Transmeta, who were doing some really interesting things. They were aiming to make a highly efficient processor, that could handle x86 through a special software translation layer. One of the languages they could support was picoJava. IIRC, the processor was never designed to run operating systems etc. natively. The intent was always to have it work through the translation layer, something that could easily be patched and updated to add support for any x86 extensions that Intel or AMD might introduce.
- specialist 3y agoI was never clear on how a Java bytecodes would be implemented on a register-based CPU. Efficiently. The JVM is stack-based, right? So it'd be an interpreter (in microcode)? Unless there's some kind of "virtual" stack, as spec'd for picoJava. I'm less clear on how Jazelle would implement only a subset of the bytecodes. Am noob. And a quick scholar search says the relevant papers are paywalled. Oh well; now it's just a curiosity. Stack-based CPUs are cool, right? For embedded. Super efficient and cheap, enough power for IoT or secure enclaves or whatever. But it seems that window of opportunity closed. Indeed, if it was ever open.
- penguin_booze 3y agoI hope people get it: an arm, and then thumb.