Live data from Hacker News

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

en.wikipedia.org

71–77 of 77 posts

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

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

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

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

#72
post #50

Earlier quoted context omitted.

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.

Android ART would unlikely to exist if Oracle would have been enforcing licensing requirements as they wished. ART runs on devices for 1B+ users and is more relevant for the world population as Oracle. Although we can speculate likely Android would have switched to something else if Oracle were to win in the court. Ironically Android more realised Java’s original light client vision “Write once, run everywhere” if yo…

Dalvik runned like shit, was only a basic interpreter at the begining, and it was Sun that was ripped off before Oracle took over.

Google could have acquired Java, after screwing Sun, and decided to take a bet on not doing it.

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

#73
post #67
post #48

Earlier quoted context omitted.

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.

You might be the only one concerned with internet points. Even so, why does it affect you so much to see other people getting these internet points? Or that they were somehow unearned? Who cares.

I think I've adequately explained what it is that bothers me about it, and it's not them getting points.

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

#74
post #64
post #48

Earlier quoted context omitted.

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.

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

Then it would be great if the existing conversation could be posted instead, similar to what 'icegreentea2 suggested.

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

#75
post #68

Earlier quoted context omitted.

I wouldn’t be so quick to dismiss the huge deal of internet services running OpenJDK. Like, AWS itself, Apple’s backends, a huge part of Google’s infrastructure, the whole of Alibaba that is responsible for some crazy amount of transactions, just to mention a few.

Java is a light client programming language that found a small niche in server programming.

> Java ... found a small niche in server programming.

Lol, virtually all business server applications are running on th e JVM in the corner of the world that I see.

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

#76
post #31
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 am sure there will never be the conclusion that AOT is always better or that JIT is always better. E.g. JIT has a large advantage in long running applications that run at different customers with very different configurations. The scenarios where AOT has an advantage are well known, so I won't iterate them.

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

#77
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…

JavaCard is used in smartcards e.g. for banking cards. There you want to have more language guarantees to avoid losing money.
Post reply on HN