harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rodrigo Kumpera <kump...@gmail.com>
Subject Re: [arch] voluntary vs. preemptive suspension of Java threads
Date Thu, 01 Sep 2005 15:06:35 GMT
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.


On 8/31/05, Xiao-Feng Li <xiaofeng.li@gmail.com> 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

View raw message