GC conservatism -- again

[Vladimir Panteleev]

On Mon, 27 Dec 2010 18:12:53 +0200, Steven Schveighoffer  
<schveiguy at yahoo.com> wrote:

> While fixing a design issue in druntime, I re-discovered how crappy the  
> conservative GC can be in certain situations.

I have posted about this problem several times. Never got any replies. I  
think memory management is D's "elephant in the room" in this regard.

I firmly believe that precise scanning is a pipe dream, unless the entire  
program - including the standard library, libc, etc. - are written in  
Safe-D (or at least just D). Precise scanning also leads to a further  
decrease of GC performance, and I'm not very enthusiastic about that.

Instead, I have created other solutions for this problem:

1) Diamond, the memory debugger that helps trace leaks to their source. I  
recently added a feature long overdue - show the exact shortest path of  
pointers / heap objects that cause a specified object to remain  
uncollected.

https://github.com/CyberShadow/Diamond

2) data.d - a module to allow simple handling of large amounts of plain  
data. The gist is that a simple proxy object keeps a pointer to a malloc'd  
region, which is free'd when the proxy object is collected. Works like a  
charm - practically no leaks (the proxy object is tiny), and keeps the  
managed heap small so collections run quickly.

https://github.com/CyberShadow/data.d

-- 
Best regards,
  Vladimir                            mailto:vladimir at thecybershadow.net