Pekka Enberg kirjoitti:
> As I mentioned before, I'm seeing deadlocks with GcTortureTest when
> "-Xgc" is enabled. I've been debugging the problem for a bit now and I
> think it's a generic problem of entering the GC from within a JIT
> trampoline while we're holding cu->mutex. See the below backtrace for
> details (I think Thread 2 is coming from a trampoline although the
> backtrace is truncated).
>
> I'm not sure what's the cleanest way to fix this. Sure, we could try to
> shuffle some code around to drop the trampoline mutex before entering
> the GC but that just seems too fragile to live with. One alternative
> solution would be to disallow calling gc_alloc() from VM code paths and
> use plain old malloc() instead.
>
> Tomek, Vegard, thoughts?
OK, so Tomek and I talked on the IRC yesterday and agreed that making
cu->mutex more fine grained would fix the problem. Unfortunately now
that I've had some time to think about it, I don't agree anymore.
AFAICT entering GC from a JIT trampoline is irrelevant to this
discussion. We're really looking at a generic problem where one or more
of the threads are already blocked with pthread_mutex_lock() or whatever
and we try to stop the world which leads to an instant deadlock. There
needs to be some way to wake up the blocked threads and drive them into
do_safepoint(). Or alternatively, we need to update nr_running_threads
before blocking and fixing make root set detection deal with blocked
threads.
I suspect the latter will lead to better results but I can't yet
convince myself that we'll always find references that are stored in
registers.
Pekka
------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Jatovm-devel mailing list
Jatovm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jatovm-devel
