We currently support a single M-of-N thread model, where M Java threads are mapped onto N underlying processors. N should never be greater than the number of processors in the system for GC barriers to work correctly, however, a thread that blocks in native decreases the value of N by 1. For this reason we keep a spare processor handy, but the system will block with 2 blocking threads (also shifting execution of C code from one VM_Processor to another is highly dodgy). There are probably many others reasons an M-of-N thread model isn't desirable, so we should endeavour to implement a more regular pthread thread model, where Java threads are mapped directly onto underlying operating system native threads.