harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Xiao-Feng Li <xiaofeng...@gmail.com>
Subject Re: [arch] voluntary vs. preemptive suspension of Java threads
Date Fri, 09 Sep 2005 23:19:21 GMT
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.

Intel Managed Runtime Division
On 9/1/05, shudo@computer.org <shudo@computer.org> wrote:
> From: Xiao-Feng Li <xiaofeng.li@gmail.com>
> > 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        shudo@computer.org      http://www.shudo.net/

View raw message