thread management they're required to trap into the kernel to acquire a mutex.
Of course GC is handled by the VM. That's not the point here though - the point I thought you made was that the GC uses mutexes and they're required to trap into the kernel. (At least that's how it reads above) That's not the case on Linux. GC uses mutexes which are implemented as futexes[1] that stay in user space for most of the time.
[1] http://www.mail-archive.com/uclibc@uclibc.org/msg02787.html
// Grab a plain mutex.
INLINE void dvmLockMutex(pthread_mutex_t pMutex) {
int cc __attribute__ ((__unused__)) =
assert(cc == 0);and here's pthread_mutex_lock.
int pthread_mutex_lock(pthread_mutex_t mutex) { if (mutex->kind == PTHREAD_MUTEX_NORMAL) { if (atomic_exchange(&mutex->lock, 1) != 0) { while (atomic_exchange(&mutex->lock, -1) != 0) {
if (wait(mutex->event, INFINITE) != 0) return EINVAL;
}
}
}
else
{
pthread_t self = pthread_self();
if (atomic_exchange(&mutex->lock, 1) == 0)
{
mutex->recursion = 1;
mutex->owner = self;
}
else
{
if (pthread_equal(mutex->owner, self))
{
if (mutex->kind == PTHREAD_MUTEX_RECURSIVE)
mutex->recursion++;
else
return EDEADLK;
}
else
{
while (atomic_exchange(&mutex->lock, -1) != 0)
{
if (wait(mutex->event, INFINITE) != 0) return EINVAL;
mutex->recursion = 1;
mutex->owner = self;
}
}
}
}
return 0;and here's an excerpt of dalvik/vm/Thread.c
Notes on Threading
All threads are native pthreads. All threads, except the JDWP debugger thread, are visible to code running in the VM and to the debugger. (We don't want the debugger to try to manipulate the thread that listens for instructions from the debugger.) Internal VM threads are in the "system" ThreadGroup, all others are in the "main" ThreadGroup, per convention.
The GC only runs when all threads have been suspended.
...
Although I don't understand how the memory management makes use of mutexes (once a (any?) thread realizes that the GC needs to be run, how does it wait until all threads have reached a safe point?), and I don't have time to check ATM.
[1] http://www.insomniacgames.com/tech/articles/0807/files/multi... mentions the pthread_mutex_lock and unlock code including an implementation of atomic_exchange