DB/DBMS in D

[Sean Kelly]

Vladimir A. Reznichenko wrote:
> Dear Mr./Ms.,
> 
> 
> I'd like to ask you about the garbage collector.
> It slows down an application, doesn't it?
> 
> In case of DBMS, this is critical. I haven't found any articles or tests
> about this.
> 
> Also it would be great to find out about memory management implemented in
> DMD: fragmentation, allocation, reallocation. And if wide-known algorithms are used there could it be named?

The GC contains a collection of pools, each containing N contiguous 
pages of memory.  Each page can be individually assigned for storing a 
particular fixed memory block size, with sizes as powers of two from 16 
to 4096 bytes (1 page, on most systems).  For allocations beyond 4096 
bytes, the minimum necessary contiguous pages will be used to hold the 
memory block.  All free blocks of a particular size are held in a free list.

When an allocation occurs, the GC first checks the appropriate free list 
to see if there is a block of the right size available.  If not, it 
looks for an available page in an existing memory pool that can be 
turned into a page of the appropriate size blocks.  If there is none, a 
mark/sweep garbage collection cycle occurs.  Then the GC looks for a 
free block, free page, and if there still aren't any it allocates a new 
pool from the OS.

After garbage collection, the D2 GC will check to see if any pools are 
completely empty and release these back to the OS.

I'm working from memory, but that's roughly the way the GC works.  You 
can also explicitly delete GC memory via the 'delete' expression, though 
there's been some contention about whether having a 'delete' operation 
for GCed memory is actually a good idea.

> The C/C++ is classic choice for such projects (DBMS), but the D language
> is great one and the best for me ). I want to find out abilities of using
> it.

D is just as fast as C/C++.  For a DBMS, you'll mostly want to be aware 
of the potential memory overhead of the GC allocation scheme and the 
cost of the "stop the world" collection cycles.  If you decide you don't 
want to use the GC at all, you're also able to call the C malloc and 
free.  Only the built-in AA and some string operations (concatenation, 
etc) allocate GC memory behind the scenes.  The rest comes from explicit 
'new' calls that you make in your own code.