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

41–50 of 77 posts

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

#41

Post by czscout »

depr wrote: post #30

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

Not everyone spends so much time on this site that they can easily spot a post as an extension of a related discussion elsewhere on the site. Someone posted this page, it got upvoted by others who found it interesting, and now it's on the front page. What's wrong with that?

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

#42

Post by Twirrim »

A little related, back in the day Sun Microsystems came up with 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, 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.

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

#43

Post by icegreentea2 »

depr wrote: post #30

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

I think attribution would be nice. Both from a honesty standpoint, but also generally useful.

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

#44

Post by miohtama »

funcDropShadow wrote: post #37
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…

The Java ecosystems initially started with optimizing Java compilers. That setup could benefit from direct hardware support for Java bytecode. Later, it was discovered that it is more beneficial to remove the optimization from javac in order to provide more context to the JIT compiler. Which enables better optimizations from JIT compilers. By directly running Java bytecode, you would loose so many optimizations done…

The current (largest) end-user Java ecosystem is in practice Android and it ahead-of-time compiling ART.

Java itself got very good. Though Oracle was blocked to leech money, or have return for their investment, depending on the viewpoint.

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

#45

Post by o11c »

bombcar wrote: post #23
michaelt wrote: post #5

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.

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.

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

#46

Post by happosai »

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…

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

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

#47

Post by depr »

czscout wrote: post #41
depr wrote: post #30

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

Not everyone spends so much time on this site that they can easily spot a post as an extension of a related discussion elsewhere on the site. Someone posted this page, it got upvoted by others who found it interesting, and now it's on the front page. What's wrong with that?

Popular content is not necessarily good content (very boring to say this, but just look at reddit). And posting articles to get upvotes, which I'm not saying this post is necessarily doing but at least _some_ are doing, leads to lower quality. HN barely has any methods for maintaining overall quality of the website and it will automatically degrade as it gets larger.

To simply allow these posts and having them hit the front page when they get upvotes is a valid position. But I think it contributes to a website that is less interesting.

I don't think these posts should be removed, but they should at least be frowned upon, and/or linked to the original comment thread.

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

#48

Post by depr »

bitwize wrote: post #38
depr wrote: post #30

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

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

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

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

#49

Post by pjmlp »

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…

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 mix of AOT and JIT, and is doing quite alright.

I am not so confident with LLMs, when they get good enough programmers will be left out of the loop, and will have to contend to similar roles as when doing no-code SaaS configs or some form of architects.

A few programmers will remain as the LLMs high priests.

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

#50

Post by kaba0 »

miohtama wrote: post #44
funcDropShadow wrote: post #37

Earlier quoted context omitted.

The Java ecosystems initially started with optimizing Java compilers. That setup could benefit from direct hardware support for Java bytecode. Later, it was discovered that it is more beneficial to remove the optimization from javac in order to provide more context to the JIT compiler. Which enables better optimizations from JIT compilers. By directly running Java bytecode, you would loose so many optimizations done…

The current (largest) end-user Java ecosystem is in practice Android and it ahead-of-time compiling ART. Java itself got very good. Though Oracle was blocked to leech money, or have return for their investment, depending on the viewpoint.

I don’t really get your last point - java’s improvements are due to Oracle, not despite it. They have a terrible name, but they have been excellent stewards of the platform.
Post reply on HN