>Gemstone Java uses native threads to implement the JVM. Most of the
>details are proprietary, unfortunately. I am not sure where the
>boundaries are.

Well, it is easy to bring up a browser and look in the "Kernel-Processes" 
area to see the things that have to be mapped.  Basically the callouts 
become specialized primops.  The hard part is verifying the threading 
assumptions about exclusion.  

Typically, there is a 2-step using an exclusion global flag which is 
accessed atomically (compare&swap or on older systems test&set).  If the 
flag is unset, just do whatever, else you must call the underlying OS 
monitor/other exclusion method.  The basic idea is that the flag is cheap 
and you don't have many collisions (e.g. on a uniprocessor) so you only 
make the expensive call where required.  You can start without this. but 
it can make a big difference in performance.  

Also, if you have a 2-word compare&swap, you can do 'lockless' concurrent 
queueing (check a newer OS textbook for algorithms).

GC can be done at first by stopping all (non-gc) threads.  This works to 
get things up.  Then you can go to a concurrent collector (too big to 
discuss here).

Cheers,
-Ken