[maemo-developers] Java acceleration/Jazelle

[From: Simon Pickering]

Hi Sebastian,

> nice research !!! This seams easier (and more os independent) than my
> thoughts with an interrupt in kernel mode. Although we can not say for
> sure, that Jazelle is implemented the way, the patent describes, this is
> a very good point to get a forthcome.

Thanks. I had also been thinking about exceptions and needing a kernel 
driver to hook into the Linux exception handler or to simply rewrite 
the process' interrupt vector, and I wasn't filled with hope because it 
seemed that it might cause some security issues (and therefore is that 
really the way it'd be done?).

It might be possible to test at least some aspects of my 'new improved' 
theory. The one that comes to mind is to try a BXJ to an unhandled Java 
instruction immediately. This should then branch back to whatever ARM 
code is at R12 straight away (not needing to know the pointer table 
base address). This could prove a number of things, including the stack 
pointer, R12 & R14 contents, etc.

I made a mistake in assuming that Rexc is only needed by the user:

>> The other register that needs to be determined is Rexc, which is the
>> one that points to the base of the pointer table which contains the
>> pointers to the ARM code snippets. But it looks like accesses to this
>> table are only handled in the ARM snippets (which 'we' would provide),
>> so it then becomes a question of which spare register can be used to
>> store this address and won't be overwritten.

Although it is used in the code snippets, unless the first bytecode is 
unhandled (and all the ones after it) at some point the hardware will 
be incrementing the Java program counter, R14, itself. Therefore, when 
an unhandled bytecode occurs, it will have to know the base address of 
the pointer table so that it is able to jump to the code to handle that 
instruction (where we set up R12 with the address of the code snippet 
to handle the *next* instruction, should it be needed). So we need to 
work out which register Rexc is. Trial and error?

>> I've changed my mind about exception handlers (see my previous posts
>> with the same subject line). I believe that the processor internally
>> handles any exception caused by an unrecognised Java bytecode, and (and
>> this is where a bit of interpretation/reading between the lines comes
>> in) automatically switches to ARM mode and jumps to an address
>> specified in a pointer table provided by the application running the
>> JVM (i.e. us).

Just to clarify why I've reached this conclusion. The patent also talks 
a fair bit about handling floating point Java operations. It talks 
about causing VFP exceptions and jumping to the ARM vfp code (assuming 
you either have no VFP hardware, or for those instructions that are 
still emulated). The difference between the Java unhandled bytecode and 
ARM unhandled floating point instruction is made reasonably clear and 
specifically that the VFP code can be jumped to (and back from) once 
the processor is running in ARM mode and running the code snippet to 
emulate the Java floating point operation. I hope that makes some 
sense, to me it said that the same mechanism is not used for unhandled 
Java bytecodes as is for unhandled ARM instructions.

There are other aspects covered in the patent, for example what happens 
when a page fault is caused by an instruction & operands extending over 
two pages. I'm not sure if this is something we'd need to handle, or 
describing the hardware. Hopefully the latter!

Anyway, there should be enough hints and ideas in what we have to try 
some hacking at least :)

Cheers,


Simon