Timothy Wall wrote:
>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).
>...
>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.
If that's just a guess, you should probably take detailed measurements or
create a test-case to validate the hypothesis. In other words, confirm or
refute the hypothesis before trying to figure out any reasons why it might
be so.
Detailed measurements would probably be measuring the time it takes to go
from right before entering your malloc'ed "trampoline" code stub. until the
instant it reaches your C dispatch function. If that turns out to be
large, then the problem almost certainly lies in executing code from data
space. If it turns out to be small, though, then that isn't the problem.
There are OS API functions that return fine-scale timer values. I can't
recall the function names, but googling for timer functions should reveal
them. IIRC, they have nanosecond scale.
A test-case that doesn't call a JVM at all would also confirm or refute the
hypothesis.
The test-case would do everything you're doing right now to make and fill
your stub, except where you now have your C dispatch function you replace
it with a C elapsed-time function. Then capture the nanoscale timer before
entering your malloc'ed stub, and again on reaching the final C function,
and printf() the elapsed time.
If the tests or measurements are consistently small, however, then the
hypothesis is not supported, and you should look elsewhere. If it's
consistently taking several seconds on any callback, it should be pretty
easy to move the start/stop points of an elapsed-time routine around in
your code, and narrow it down pretty quickly. Once the offending code (or
range of code) is well-determined, you can debug what the problem is.
Right now, you still haven't figured out where the problem lies, so it's
premature to debug why it occurs.
If the bug lies in passing values to the JVM that make it take a very long
time, then you'll be able to find that out by the process of elimination.
If the delay isn't anywhere in your code, from its beginning to the point
where it calls through the JNIEnv, then double-check everything you've got
in registers and what JNIEnv function you're calling.
-- GG
_______________________________________________
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
This email sent to email@hidden
