HotSpot just passes the given time through to through to the OS.  Nothing magical about 10msec, 15.6msec or any other number, at least not to HotSpot.

Before you can trust any such timing thing to be reliable you gotta run it "under load" - get a bunch of other threads running doing variable amounts of work+sleep (your AI wakes up, works for a quanta, sleeps, you decide to background load some music for the next scene, etc).  All those other threads running around will also mess with your timer's response.

Right - you just did it.  Since this call has no arguments, the wrapper is fairly cheap (please ignore imperfect use of CAS registers, been awhile since I looked at X86 CAS):

SUB SP,xx # push a frame, must have one for GC stack crawls
MOV EAX,FS:[18] # idiot sequence to get TLS
MOV [EAX+xx],0xpcbits # store the return-pc in TLS
# no fence needed for most PC's; memory model too strong
MOV [EAX+yy],ESP # store the sp nearby, allow GC
CALL native  # do the native call
MOV EBX,FS:[18] # idiot sequence to get TLS
MOV EAX,ESP # Find old SP if no GC in progress
CMPXCHG [EBX+yy],0 # Slap down a NULL if re-entering Java code
JNE  go_block_GC_in_progress
ADD SP,xx # pop frame
RET


You want less code than that?  Then you have a tall order on your hands - you want the JVM to have intimate knowledge of some random entry point.  To  "Trust Me - it won't block and I'll put the PC here" - which bitter experience tells me is foolish.

I've debugged any number of JVM "bugs" which were bugs in 3rd party native code caused by the 3rd-party vendor not understanding the invariants used by the JVM.  JNI goes a long way to making native code safe for the JVM.

Ahhh.. it's a big story.  I'll make shortcuts.  You can ask for more details.  

Background: it's a desktop or server environment, so pre-emptive multi-threaded is normal, not cooperative scheduling.  Blocking native I/O.  Precise & moving GC (conservative non-moving GC allows for faster JNI calls).   Many of these steps do not apply in an embedded system, or one with cooperative suspension, or single-threaded applications, or single CPU or the native compiler is known & trusted, or the native call promises not to block (or at least statically known to block or not) etc...

Since a native call might block or otherwise take a long time, and since other threads are running and allocating, a GC must be allowed while the thread is in native code.  A moving GC makes the mutators more efficient - but there's no way to find & move the pointers in held by the native code/compiler.  So you don't hand out any raw heap pointers, you hand out Handles.  The native code is never allowed touch a heap pointer lest an ill-timed GC move things the native code is also touching, crashing the native code.  Upon return from the native code a GC *may* be in progress.  The regular Java code threads have been stopped for the GC, but the threads in native code have not  - so they have to do a lock-like thing to assure that a GC is not in progress (or doesn't start up).  Basically, you must CAS on exit from the native or you have a race condition where a GC might think all Java threads have been stopped & start moving objects, and a thread returning from a native (where GC is ok) into Java code (where GC is not) starts touching objects.  

Also, you have to be able to find all the objects - including those passed as arguments on the stack and Handlized.  Generally this is done by maintaining a mapping between PC's and which registers hold oops - but HotSpot doesn't know where the native compiler will put the JNI call's PC.  So we need the return PC (return from the native code back into the wrapper code) jammed down before we act "as if" we're in native code and allow a GC.  Same for the stack pointer.  

Finally, argument calling conventions between JIT'd code and native code are usually different - the JIT doesn't need var-args support, or legacy calling-convention support, or a JNIEnv.  Putting it together we get:

push a frame
store any objects passed in registers down (prior to handlizing)
if a sync method, lock
make a copy of the arguments:
 add the JNIEnv argument
 copy the rest from JIT convention to native convention (generally reg-reg moves on a RISC, stack-stack moves on X86)
 wrap a handle around objects (requires a null-test/branch)
store the return-pc somewhere (generally thread-local storage)
maybe memory fence, in case GC is somewhat concurrent
store the sp nearby  - which also allows a GC, and requires the objects & PC be coherent in memory
do the native call
reclaim the GC lock (generally a CAS) or block
if sync, unlock
if returning object, de-handlize
pop frame
return


Clear as mud, I hope?

Yes I can tell you the grotty details if you like.
JNI calls are not going to get faster any time soon.

They can be made fast in some *very* specific situations, such as in embedded single-cpu devices with fixed application sets.  Or if you can match the native compiler's IR and the Java JIT's IR (an extremely tough thing to do; IBM could do it; Microsoft is trying to do it with .Net, not many other instutions can even try).

Yup.

And also using pre-cooked exceptions as control flow is much slower than any other reasonable solution (such as checking return values for a special error code).  Under very restricted circumstances the server compiler will manage to make such control flow close in speed to the obvious test&branch, normally you should expect that throwing & catching a pre-cooked exception to be at least 10x slower than simply testing a return condition.

Declaring a try block and not throwing is free (nearly) so it doesn't cost to be robust and catch exceptions that are rarely thrown.

Zombie methods are methods whose code has been made invalid by class loading.  Generally the server compiler makes aggressive inlining decisions of non-final methods.  As long as the inlined method is never overridden the code is correct.  When a subclass is loaded and the method overridden, the compiled code is broken for all future calls to it.  The code gets declared "not entrant" (no future callers to the broken code), but sometimes existing callers can keep using the code.  In the case of inlining, that's not good enough; existing callers' stack frames are "deoptimized" when they return to the code from nested calls (or just if they are running in the code).  When no more stack frames hold PC's into the broken code it's declared a "zombie" - ready for removal once the GC gets around to it.