[dmd-internals] Memory Leak

David Held dmd at wyntrmute.com
Sun Nov 11 16:28:24 PST 2012


On 11/11/2012 2:33 PM, Walter Bright wrote:
> [...]
> I've thought about using smart pointers for the CTFE stuff. I think 
> that would resolve it.
>
> I'm a little concerned that using smart pointers in general would 
> cause slowdowns.

Well, if you have the choice between compiling small programs quickly, 
or compiling large programs at all, which do you think is the better 
choice for dmd?  And really, I think the performance hit is much smaller 
than you fear.  With decent inlining, dereference can be as cheap as 
native pointers, and reference counting only starts to get expensive if 
you need to support multi-threading. Even then, by using raw pointers to 
indicate non-owning usage, you can avoid the vast majority of reference 
count changes.  And then, to make a fair comparison, you have to judge 
the result against 100% manual memory management (free() tends to be 
more expensive than malloc()).  I think you will find that smart 
pointers stack up pretty well (although I would not advocate a 
general-purpose one like shared_ptr<>...that's a bit heavyweight for dmd).

> Another refactoring I'd like to see happen in dmd is that some of its 
> data structures become copy-on-write, as many, many problems have been 
> caused by changing things that someone else assumed wouldn't be changed.

And that job would be made a lot easier if all data were private to 
begin with. ;)  Again, a lot of these changes could be detected with 
some asserts at strategic locations (although, asserts cannot catch all 
mutations, obviously, which is why private data goes further).

When you say "some data structures", do you mean the Dsymbol hierarchy?  
That seems to be a pretty major core of the front-end. It would be great 
if that were immutable...I see a lot of methods which could probably be 
made const (in fact, 90% of the interface could be made const with no 
other change, I think).

Dave

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-internals/attachments/20121111/f35216ec/attachment-0001.html>


More information about the dmd-internals mailing list