The problem with the D GC

[kenny]

Honestly, it was a long time ago, so remembering is difficult. I didn't 
have SVN installed back then :) I'm pretty sure it wasn't 
multi-threaded. I think that we launched multiple processes. (eg. not 
mutexes either) I know I used a lot of assoc arrays, and I also used a 
lot of concatenation. The size of the code was quite huge too.. at least 
8000 lines.

It could be a combination of those factors, and it may have been as 
early of a version of 0.73. I dunno dude, I just remember it sucked.

I have not really been having bad experiences with the GC lately, accept 
that, it's annoying at times with the peaks. Every request will give a 
response time of 2ms, accept when the GC runs, and then it'll give a 
50ms response. I suppose that's not that horrible, but it is a 25x 
difference.

What I've wanted to do for a while now is to be able to set the size of 
the pool of memory, and also want the variable to be set telling me some 
form of information of how close the next collect is.. whether it's 
largest memory block avail, or % fragmentation, or something, so I can 
take the processes and tell them to stop accepting requests (and let one 
of the other processes handle it) and run the GC so the GC doesn't run 
while accepting requests.

I guess I can just estimate based off of the amount of requests it has 
processed... but the other way sounds way cooler.


Sean Kelly wrote:
> kenny wrote:
>> I also have experienced bad GC performance. I found it to be because 
>> of the ~ operator on strings. The program is a daemon, and after it 
>> had been running for a while, memory usage gets truly horrific, and 
>> performance degrades very bad.
>>
>> This was back on 0.140, so things may have changed since then...
> 
> Probably not.  Assuming this is a multithreaded app, you have to pay for 
> two mutex locks for every concat operation.  So an expression like:
> 
> a = b ~ c ~ d;
> 
> would result in six locks of the mutex protecting the GC to perform 
> allocations (I think anyway--I don't believe chained concats have 
> special handling).  I think this would also result in two discarded 
> temporary buffers for the GC to clean up later.  And since the Phobos GC 
> scans all such blocks by default...
> 
> My patch will address the scanning issue, but it won't address the mutex 
> issue--there's really no easy way to avoid that one.
> 
> 
> Sean