Re: [RFC] GC: external thread suspension

[Bryce McKinlay <mckinlay at redhat dot com>]

Keith Seitz wrote:
> Bryce McKinlay wrote:
>
> > If the JDWP back-end is partially written in Java, then it is 
> > important that GC can run when threads are suspended. If not, the 
> > back-end will be prone to deadlock during memory allocation.
>
> Is this true, though? JDWP does not suspend it own threads -- ever. 
> All the Classpath JDWP threads are in their own ThreadGroup, and the 
> debugger cannot suspend them, even if it asks to suspend everything.

The problem is that currently the JDWP backend is partially written in 
Java. So if the GC cannot run (ie blocks) when threads are suspended, 
and the JDWP code itself attempts to allocate, a collection cycle could 
be triggered, resulting in a deadlock.

However, now that I look at this further, it looks like I misunderstood 
what GC_start_blocking() does -
it doesn't actually prevent the GC from running, but rather allows the 
GC to run without sending the blocked thread a signal. In that case, 
there shouldn't be a problem here. We just need to be careful that 
things behave correctly ifa GC_suspend_thread() and GC thread suspension 
occur at roughly the same time - ie beware of race conditions.

Bryce