[dmd-internals] Memory Leak

[Walter Bright]

On 11/11/2012 4:28 PM, David Held wrote:
> 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?

Good question. But also consider that we're transitioning to 64 bit compilers, 
where consuming a lot of memory may not be relevant, since most of that memory 
will be "dead".

> And really, I think the performance hit is much smaller than you fear.  With 
> decent inlining, dereference can be as cheap as native pointers,

Not quite true, remember the destructor code has to be inserted and accounted 
for in all cases. This can add more than just a pointer decrement & test.

> 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.

I know about the potential for raw pointers to have all sorts of bugs from 
incorrect usage. C++ has no way to protect against that.

> 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).

One of the versions with embedded counters would be far more suitable.

>
>> 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?

No, I mean the Expression one. The Type hierarchy is already copy on write, and 
works well.

> 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).

Yes, adding const in would probably be an easy and effective change. Too bad C++ 
has no purity :-(
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-internals/attachments/20121111/2a37edc4/attachment.html>