Some time ago someone on this list pointed to a paper from Sun folks about this subject.
>From what I remember, they tried the folllowing tecniques: -Pooling on back-edges and call/return, using ether a boolean flag or forcing a page-fault at a specific address. They noticed that page-faulting has a huge latency. -Dynamic code patching, the thread is stopped and the next reachable safe-point site is patched to call into the VM instead of following normal execution. This shown to be very tricky to implement on sparc, but improves the runtime performance a lot. Rodrigo On 8/31/05, Xiao-Feng Li <[EMAIL PROTECTED]> wrote: > Thread suspension happens in many situations in JVM, such as for GC, > for java.lang.Thread.suspend(), etc. There are various techniques to > suspend a thread. Basically we can classify them into two categories: > preemptive and voluntary. > > The preemptive approach requires the suspender, say a GC thread, > suspend the execution of a target thread asynchronously with IPC > mechanism or OS APIs. If the suspended thread happened to be in a > region of code (Java or native) that could be enumerated, the live > references were collected. This kind of region is called safe-region, > and the suspended point is a safe-point. If the suspended point is not > in safe-region, the thread would be resumed and stopped again until it > ended up in a safe-region randomly or on purpose. > > In the other approach that we are now considering, JIT will insert > code that polls a boolean. The boolean can be thread-specific and is > set true by GC thread or VM if there is a need to prevent the Java > thread's forward progress. The JIT will put the polling code in such > places as back-edges, call sites and method returns. Actually we are > thinking of this mechnism in a more general sense. For example, > green-threads can be implemented in this way for Java threads to > downcall into JVM scheduler. > > Does anyone have suggestions/data on better approaches? > > Thanks, > xiaofeng >
