Hi,
Yes my little GC project is coming along. It allocates much faster in
multi threaded applications when all threads are competing for the lock.
D's current GC is very slow when there is contention for the GC-lock
which is acquired for every malloc. The other hidden lock usage is when
a dynamic array increases in size. A significant problem is that the
thread holding the lock might be pre-empted by the OS, causing all
threads to wait until it is running again. My lock-free allocator fixes
all this trouble.
(Note: On Windows the current GC uses EnterCriticalSection from
kernel32.lib)
In single threaded applications, D's GC performs much better. It still
has the overhead of maintaining a free list while allocating. The free
list is built when requesting pools from the OS. This list is stored as
a linked list using the fresh memory cells. A cell is zerod when it is
allocated.
My implementation is slightly faster at allocations because it doesn't
need to zero the memory before before. It only maintains a such a free
list for recycled memory.
I'll try to make some code available soon for people to try if they are
interested. There are still some jobs I need to do. I'm just
implementing the utility functions now (sizeOf, addrOf) etc. Allocated
memory is currently never returned to the OS, just recycled for new
allocations.
Cheers
Adam
On 30/05/2014 6:29 PM, Rainer Schuetze via Digitalmars-d wrote:
On 29.05.2014 12:09, Atila Neves wrote:
The GC is preventing me from beating Java, but not because of
collections. It's the locking it does to allocate instead! I
don't know about the rest of you but I definitely didn't see that
one coming.
A lock should not be more than a CAS operation that always succeeds in a
single threaded application, but OS overhead might be considerable.
Adam Sakareassen has recently announced a rewrite of the GC that has
lock-free allocations:
http://forum.dlang.org/thread/mailman.655.1399956110.2907.digitalmar...@puremagic.com
Unfortunately, it isn't available yet...
