More recent work on GC

[H. S. Teoh via Digitalmars-d]

On Wed, Jan 14, 2015 at 05:37:41PM +0000, John Colvin via Digitalmars-d wrote:
> On Wednesday, 14 January 2015 at 16:09:06 UTC, Dominikus Dittes Scherkl
> wrote:
> >On Wednesday, 14 January 2015 at 06:15:09 UTC, Andrei Alexandrescu wrote:
> >>On my reading list:
> >>
> >>http://research.microsoft.com/pubs/230708/conservative-gc-oopsla-2014.pdf

Fascinating! This paper seems to be describing a *partially*
compacting/copying GC.  That's a very clever way of circumventing the
constraints imposed by a conservative GC, which D can't around with due
to interfacing with C.  IOW, if a D program just so happens to have no
unambiguous references, then the GC will effectively become a fully
compacting/copying GC. If there are some ambiguous references, then it
"gracefully degrades" into a non-compacting/copying conservative GC.
Looking forward to see what will come of this!


> >Interesting. non-exact GC but with about the same performance.  The
> >bad part for D would be, that this GC collects periodically, so even
> >if you don't use GC'ed memory it will be invoked :-/
> 
> You could still GC.disable(); /* realtime work here */ GC.enable(); of
> course

Recently in one of my projects I found that I can gain a huge
performance improvement just by calling GC.disable() at the beginning of
the program and never calling GC.enable() again, but instead manually
calling GC.collect() at strategic points in the code. Obviously, YMMV,
but I managed to get a 40% performance improvement, which is pretty big
for such a relatively simple change.


T

-- 
What do you call optometrist jokes? Vitreous humor.