Thanks, Rodrigo and Shudo. ORP had a similar approach as code patching previously, which we called "IP hijacking". We found, as you observed, it had some difficulties in maintenance and portability. I classified this approach into the preemptive category.
I suspect a given thread suspension algorithm will have different performance characteristics depending on processor architecture, and garbage collection algorithm as well. It deserves more study. Since the two approaches are not much conflicting, I suggest implementing voluntary mechanism at first for its cleanness and portability for the first few releases of Harmony. Thanks, xiaofeng == Intel Managed Runtime Division On 9/1/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > From: Xiao-Feng Li <[EMAIL PROTECTED]> > > > 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. > > Sun's HotSpot VMs patch compiled native code to stop thread at the > safe points, on which a stack map is provided. It's smart but prone to > causes subtle problems, an engineer working on the VM said. > > Kazuyuki Shudo [EMAIL PROTECTED] http://www.shudo.net/ >
