criticalsections are very fast / pooling mutexes / how does hash-sync work?

[Adam Megacz <gcj at lists dot megacz dot com>]

ye gads.

Using win32 criticalsections (userspace) instead of mutexes
(kernelspace) makes a huge, huge difference -- it shaved at least 30%
off my startup time and the obnoxious delays are almost gone. I say
"almost" because I'm still seeing a tiny delay -- barely
human-noticable. I suspect that this is because
InitializeCriticalSection() isn't a very fast operation.

I'm thinking of pooling CriticalSections -- when the blocked count on
a CriticalSection drops to zero, it goes back into the pool. I already
had to introduce a level of indirection (_Jv_Mutex is now a pointer to
a heap object instead of an actual CRITICAL_SECTION) because win32
barfs if the memory address of a CRITICAL_SECTION changes. So this
should be easy -- when the blocked count on a CRITICAL_SECTION drops
to zero, the corresponding _Jv_Mutex is set to NULL. When you try to
block on a NULL _Jv_Mutex, we check a new one out of the pool.

The downside is that blocking on an unheld mutex will require two
EnterCriticalSection()'s, but these are so fast in comparison to
InitializeCriticalSection() that I think it will be a performance win
in just about every usage scenario.

BTW, here's how I understand hash synchronization to work: all
_Jv_Mutex'es are stored in a hash table, keyed on the memory address
of their owner. The advantage is that many Object's are now PTRFREE
and can be stored in heap areas which aren't scanned (thus speeding up
GC). The other advantage is that you save memory on objects which are
never synchronize()d on -- no space is needed for a _Jv_Mutex, or even
a pointer to one.

Is this understanding correct? If so, why doesn't it work
out-of-the-box on all platforms, automatically?

  - a