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.
wise words which can save lots of wasted effort. no sense developing
fixes for the wrong problem. thanks for reminding me :)
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.
after methodically excising successively larger portions of the
operation, I narrowed down to where the callback is actually
allocated. is it always better to do a binary search, even if an
"educated" guess suggests starting at one end? in this case it
would've been faster to eliminate all callback code and add bits back
in, but I digress...
once I narrowed down the suspect block of C code, I could properly
instrument (using clock() was sufficient, given the delays I was
seeing). turns out the allocation of memory for the instruction
block (malloc) was asking for over 1G of memory due to a bug in an
assembler-generated constant. The OS was providing it (!), although
it took a while to do so.
_______________________________________________
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
