Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Jazelle DBX: Allow ARM processors to execute Java bytecode in hardware

en.wikipedia.org

Post reply on HN
Print view View original

51–60 of 77 posts

Re: Jazelle DBX: Allow ARM processors to execute Java bytecode in hardware

#51

Post by tenaf0 »

BenoitP wrote: post #31
pjmlp wrote: post #16

Earlier quoted context omitted.

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

I'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 Rus…

I do think, that in the general case, a JIT compiler is required: you can’t make every program fast, without having the ability to synthesize new code based on only-runtime available information. There are many where AOT is more than enough, but not all are such. Note, this doesn’t preclude AOT/hybrid models as pjmlp correctly says.

One stereotypical (but not the best) example would be regexes: you basically want to compile some AST into a mini-program. This can also be done with a tiny interpreter without JIT, which will be quite competitive in speed (I believe that’s what rust has, and it’s indeed one of the fastest - the advantage of the problem/domain here is that you really can have tiny interpreters that efficiently use the caches, having very little overhead on today’s CPUs), but I am quite sure that a “JITted rust” with all the other optimizations/memory layouts could potentially fair better, but of course it’s not a trivial additional complexity.

Re: Jazelle DBX: Allow ARM processors to execute Java bytecode in hardware

#52

Post by tenaf0 »

o11c wrote: post #45
bombcar wrote: post #23

Earlier quoted context omitted.

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.

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

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.

Re: Jazelle DBX: Allow ARM processors to execute Java bytecode in hardware

#53

Post by specialist »

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

Re: Jazelle DBX: Allow ARM processors to execute Java bytecode in hardware

#54

Post by cpgxiii »

miki123211 wrote: post #39
jaywee wrote: post #11

Earlier quoted context omitted.

Sun wanted to do the same thing in late 90ties - picoJAVA (embedded), microJava and UltraJava (VLIW workstations). Relegated to the dustbin of history.

Java 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 microco…

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

Re: Jazelle DBX: Allow ARM processors to execute Java bytecode in hardware

#55

Post by BenoitP »

pjmlp wrote: post #49
BenoitP wrote: post #31

Earlier quoted context omitted.

I'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 Rus…

The best solution isn't AOT vs JIT, rather JIT and AOT, having both available as standard part of the tooling. Android has learnt to have both, and thanks to PGO being shared across devices via Play Store, the AOT/JIT outcome reaches the ideal optimum for a specific application. Azul and IBM have similar approaches on their JVMs with a cluster based JIT, and JIT caches as AOT alternative. Also stuff like GPGPU is a m…

> A few programmers will remain as the LLMs high priests.

That's interesting.

It's controversial to say that in 2024, but not all opinions have the same value. Some are great, but some are plain dumb. The current corporate right opinion is to praise LLMs as end-all be-all. I've been asked to advise a private banking family office wanting to get into LLMs. For advising their clients' financial decisions. I politely declined. Can there be a worse use case? LLMs are parrots with the brain size of the internet. With thoughts of random origin mixed together randomly. It produces wonderful form, but abysmal analysis.

IMHO as LLMs will begin to be indistinguishable from real users (and internet dogs), there's going to be a resurging need to trace origin to a human; and maybe to also rank their opinions as well. My money is on some form of distributed social proof designating the high priests.

Re: Jazelle DBX: Allow ARM processors to execute Java bytecode in hardware

#56

Post by ithkuil »

toast0 wrote: post #27
BenoitP wrote: post #8

The 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 b…

> 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. If you're building hardware masking, it should be viable for low bits too. If you define all your objects to be n-byte aligned, it frees up low bits for things too, and might not be an imposition, t…

The sparc ISA had tagged arithmetic instructions so that you could tag integers using LSBs and ignore them

Re: Jazelle DBX: Allow ARM processors to execute Java bytecode in hardware

#58

Post by ithkuil »

willvarfar wrote: post #12

In 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.n…

The 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

Re: Jazelle DBX: Allow ARM processors to execute Java bytecode in hardware

#59

Post by sillywalk »

jaywee wrote: post #11
fch42 wrote: post #3

My 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…

Sun wanted to do the same thing in late 90ties - picoJAVA (embedded), microJava and UltraJava (VLIW workstations). Relegated to the dustbin of history.

FYI 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

[0] https://en.wikipedia.org/wiki/MAJC

Re: Jazelle DBX: Allow ARM processors to execute Java bytecode in hardware

#60

Post by pjmlp »

BenoitP wrote: post #55
pjmlp wrote: post #49

Earlier quoted context omitted.

The best solution isn't AOT vs JIT, rather JIT and AOT, having both available as standard part of the tooling. Android has learnt to have both, and thanks to PGO being shared across devices via Play Store, the AOT/JIT outcome reaches the ideal optimum for a specific application. Azul and IBM have similar approaches on their JVMs with a cluster based JIT, and JIT caches as AOT alternative. Also stuff like GPGPU is a m…

> A few programmers will remain as the LLMs high priests. That's interesting. It's controversial to say that in 2024, but not all opinions have the same value. Some are great, but some are plain dumb. The current corporate right opinion is to praise LLMs as end-all be-all. I've been asked to advise a private banking family office wanting to get into LLMs. For advising their clients' financial decisions. I politely de…

I see the current state of LLMs are when we read about Assembly programmers being suspicious something like high level languages would ever take off.

When we read about history of Fortran, there are several remarks on the amount of work put into place to win over those developers, as otherwise Fortran would have been yet another failed attempt.

LLMs seem to be at a similar stage, maybe their Fortran moment isn't yet here, parrots as you say, but it will come.

Post reply on HN