I've been experimenting with calling native code from Java without
JNI (and providing java callbacks to native code). Currently this
system is working on a number of platforms, including OSX (see
jna.dev.java.net).
I haven't tested on OSX/x86, but the ppc version exhibits severe
delays when native code calls back to java code. Likely this is due
to my extreme ignorance with PPC assembly and memory modes, but I was
wondering if someone with some PPC experience might point out some
avenues for further investigation.
For the callbacks, I have an asm template that gets copied into some
malloc'd memory, with some data addresses filled in on the fly,
something like this:
The labels are used to figure out the appropriate offset into the
malloc'd memory to set data addresses that get customized for each
callback stub. PPC asm loads 16 bits at a time, so a 32-bit address
is split across two insns.
The data written is the address of a structure with a callback
dispatch function address, callback configuration data, and a pointer
to the VM from which a JNIEnv* can be obtained. The callback stub
sets up the stack, then calls the callback dispatch function, which
is C code that sets things up to call back into java.
What I see when running my callback tests on PPC is that the
callbacks take a really long time, on the order of seconds. My first
guess is that the difference in memory space from the malloc'd memory
from normal code space is causing some sort of major context switch
as the CPU context has to go from code->data->code and back after the
call; if that's the case, I'm not sure how I could avoid it.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden
