I need to run Java applications on top of Linux on my Beaglebone. I know that ARM cores do have support for Jazelle technology to execute Java bytecode in hardware. Anyway it is not clear to me what I need to exploit this technology. Do I need to "activate" Jazelle in some way? Do I need a Jazelle aware Java Virtual Machine? What is the flow for deploying and running Java software which exploits Jazelle technology? Is a license required for using Jazelle?
Thanks.
Jazelle is an execution mode in ARM architecture which "provides architectural support for hardware acceleration of bytecode execution by a Java Virtual Machine (JVM)" - quoted from ARM Architecture Manual.
It also looks like there are two flavours of Jazelle; DBX and RCT. Following text is from Cortex-A Series Programmer’s Guide (v3).
2.2.2 Jazelle
Jazelle-DBX (Direct Bytecode eXecution) was introduced in ARMv5TEJ to accelerate Java performance while conserving power. A combination of increased memory availability and improvements in just-in-time (JIT) compilers have since reduced its value in application processors. As a result, many ARMv7-A processors do not implement this hardware acceleration.Jazelle-DBX is best suited to providing high performance Java in systems with very limited memory (for example, feature phone or low-cost embedded use). In today’s systems, it is mainly used for backwards compatibility.
2.2.3 Thumb Execution Environment (ThumbEE)
Introduced and required in ARMv7-A, ThumbEE is sometimes referred to as Jazelle-RCT (Runtime Compilation Target). It involves small changes to the Thumb instruction set that make it a better target for code generated at runtime in controlled environments (for example, by managed languages like Java, Dalvik, C#, Python or Perl). ThumbEE is designed to be used by Just-In-Time (JIT) or Ahead-Of-Time (AOT) compilers, where it can reduce the code size of recompiled code. Compilation of managed code is outside the scope of this document.
To my knowledge most of Jazelle-DBX's use is in Java Card implementations where you really want to have lots of performance supplied by a tiny chip. This really restricted domain can take advantage of some extra boost by executing bytecode on cpu directly.
However most of the modern embedded systems like your Beaglebone already have more memory and cpu power than when Java made its debut on typical desktops of those times which renders Jazelle-DBX not necessary. That's mostly because you get JIT compilation to native host. (JIT implementations would be too big for Java Cards.)
ThumbEE / Jazelle-RCT's usefulness is also questionable. Quoting from an android-porting discussion:
Going through all that to get free null-pointer checks doesn't make much sense.
To conclude, I am not aware of any Java VM implementation utilizing any Jazelle flavour including Dalvik of Android. If I had to run Java on an embedded device, I would choose between; Dalvik, JamVM or Java SE Embedded.
You need to go to http://infocenter.arm.com. the beaglebone uses a Cortex-A8 which is an ARMv7. Under Cortex-A series processors on the left side Cortex-A8 get the most recent manual r3v2 (rev 3.2). Under ARM Architecture expand Reference Manuals you want the ARMv7-AR (issue C is the most current as of this writing).
Taking that info going to my example
http://github.com/dwelch67/beaglebone_samples
features example on my beaglebone shows:
12345678
Hello World!
413FC082
410330C3
00000000
00001131
00000011
00000000
00000000
00000000
00000002
13112111
00000000
00000000
00000002
12345678
So that appears to be a r3p2 (rev 3.2) core. As the manuals say the ThumbEE, Jazelle, thumb and ARM are supported.
Now the confusing thing is the TRM on the ti website, the ARM trm all say Jazelle is supported, until you focus on this:
Jazelle Extension
The Cortex-A8 processor provides a trivial implementation of the Jazelle Extension. This means that the processor does not accelerate the execution of any bytecodes, and all bytecodes areexecuted by software routines.
In the implementation of the Jazelle Extension:
Jazelle state is not supported
The BXJ instruction behaves as a BX instruction.
Which tells us a few things. Does this really mean that there is no Jazelle hardware in this processor despite other places saying it is?
It also shows us that to run jazelle code you bxj to get there just like you bx to switch between arm and thumb modes. So I tried it:
.globl bxjtest
bxjtest:
ldr r0,=skip
bxj r0
mov r0,#1
bx lr
skip:
mov r0,#2
bx lr
and it looks like the assembler implemented bxj
82000064 <bxjtest>:
82000064: e59f0044 ldr r0, [pc, #68] ; 820000b0 <GET32+0x8>
82000068: e12fff20 bxj r0
8200006c: e3a00001 mov r0, #1
82000070: e12fff1e bx lr
82000074 <skip>:
82000074: e3a00002 mov r0, #2
82000078: e12fff1e bx lr
but the code returns a 2 from the arm instruction at that address. dont know if that means anything or not, maybe there is other stuff you have to do to get Jazelle to work. I get the impression though that there really isnt a jazelle core there, I get the impression you go buy the software library.
The Jazelle docs appear to be the kind that you have to contact ARM to get access to. So I dont know much more than that how to actually use it.
Reading further in the ARM. the ID_ISAR1 register shows a 1 indicating
0b0001
Adds the BXJ instruction, and the J bit in the PSR.
This setting might indicate a trivial implementation of the Jazelle extension.
And, then the ARM ARM description for the ID_PFR0 register has more info than the TRM, it says
A trivial implementation of the Jazelle extension is indicated by the value 0b0001.
And 0b0001 is what we are reading for that field in that register.
the more I dig the more this appears to be a "trivial implementation" which means to me "not there". the JMCR register shows that if it is a trivial implementation then reads should return as zero (RAZ) and writes should be ignored (WI) which they are, I wrote a one, read it back it was a zero. Even so I tried the BXJ instruction and it still executed arm code.
Basically as a product vendor you license from ARM (pay a fee for) the ability to enable and run your code on Jazelle technology. The fee will be based on forecasted volume, factual outcome and such. I am not familiar with actual price level. There are certain code fragments needed to switch the CPU in out of byte code execution when Java code is entered/exited. Unless you pay for the privilege as device vendor Jazelle is not operable and can be quietly ignored. Jazelle of the first generation was an answer to a need for swift Java execution on systems with constrained RAM space where a byte code interpreter was until then the only available option. JIT requires RAM for compiling, early phones were optimized for low cost by keeping memory size down. Some of the first music phones used Jazelle to boost MIDlet execution performance, but in successive products memory soon grew to accomodate all kinds of multimedia smartphone levels of features. Then JIT compilers became feasible and actually excel in overall performance. Jazelle simply maps byte code to binary in machine code for the most part and "cannot run faster than the byte code" so to say. While JIT can at times map certain series of byte code sequences to an efficient native code that run quicker than if it would be based on individual byte code operations one at a time. So the early Jazelle mode is no longer really useful. RAM growth made JITs more feasible.
© 2022 - 2024 — McMap. All rights reserved.