On Thu, 15 Jul 2010 10:18:38 +0300, Jonathan M Davis
<jmdavisp...@gmail.com> wrote:
Okay. I really don't know much about garbage collectors, how they work,
or what makes one particularly good or bad (other than the fact that it
needs to be efficient execution-wise and manage memory wisely so that
you don't use too much of it or do anything else that would be an
overall negative for performance). However, from the comments here -
both recent and in the past - it's pretty clear that D's garbage
collector is fairly outdated. I would assume that that would be negative
for performance - certainly it would mean that significant improvements
could be made.
IMO the D GC isn't bad, it's just mediocre. (It could have been way worse.)
I would like to use this opportunity to bring up a GC implementation
written by Jeremie Pelletier, which seems to have gone mostly unnoticed
when it was posted as a reply to D.announce:
http://pastebin.com/f7a3b4c4a
Aside from multiple optimizations across the board, this GC employs an
interesting different strategy. The gist of it is that it iteratively
destroys only objects that have no immediate references. In the case of
long linked lists, this trades destruction complexity with scan
complexity, which is a very good change - most times deeply-nested
structures such as linked lists survive multiple generational cycles.
Jeremie, if you're reading this: how goes your D2 runtime project?
(I also have an unfinished generational GC lying around, which is still
unknown if it's viable performance-wise - I should really try to finish it
one day.)
--
Best regards,
Vladimir mailto:vladi...@thecybershadow.net
