gcj crashes if a user-thread gives up its rights

Bryce McKinlay mckinlay@redhat.com
Tue Dec 14 16:39:00 GMT 2004

Jost Boekemeier wrote:

>On Mon, 2004-12-13 at 18:17, Bryce McKinlay wrote:
>>It would be interesting to know how these other VMs solved the issue. 
>Mediator pattern.  The mediator still runs with the appropriate
>privileges.  I guess GCJ already has a mediator which iterates through
>the list of threads and stops each of them when the user-thread's GC
>wants to run. The only thing that seems to fail is the command that the
>user-thread's GC sends to the mediator.
In the current code, there isn't a separate "mediator" thread - any user 
thread which the GC happens to run in will try to call pthread_kill to 
suspend the other threads.

>>Is there is another IPC mechanism with the necessary semantics - ie able 
>>to suspend any thread at any time, asynchronously? 
>I think this should not be necessary.  The mediator waits for commands
>anyway, so a simple pipe would be sufficient. Even a condition variable
>will work. So we only have to change the pthread_kill() into a
That wouldn't work, because pthread_cond_signal() won't interrupt a 
thread that isn't actually waiting on the right condition variable. 
You'd still have to either use pthread_kill() or have the compiler 
insert interrupt points at each basic block edge. The later would have a 
performance effect and would be tricky to implement in the presence of 
blocking IO, etc.

What may work, however, is instead of sending the pthread_kill's from 
whichever thread the GC happens to occur in, dedicate one, always 
privileged thread to sending the pthread_kill's and running the GC. 
Suspended threads could then enter a pthread_cond_wait() waiting for the 
restart signal from the collector thread.



More information about the Java mailing list