Ian Rogers wrote: > Thanks for the replies. I have worked further on this and the particular > issue isn't with GC barriers but with M-to-N threading. In theory if 1 > of the M threads becomes blocked in a JNI call then the other threads > should be moved onto another of the N underlying native threads. > Unfortunately, as it's possible to call back into the JVM, the JVM's > yield code can schedule another thread on the same native thread before > realising the 1st thread is blocked and now its possibly handling a I agree that this model though well intentioned is fundamenally broken. You simply can't implement correct M-N threading unless you have some way of being notified properly when a "lower layer" thread blocks. For example look at FreeBSD's KSE threading model, which is similar to "activations". If a system call blocks, the user thread manager is immediately notified by the kernel... http://www.freebsd.org/kse/ Without this kind of notification the only other alternative is to wrap every system call that could possibly block. That's not implemented in classpath (and besides the VM would also have to implement it). -Archie __________________________________________________________________________ Archie Cobbs * CTO, Awarix * http://www.awarix.com
