deprecated delete and manual memory management

Steven Schveighoffer schveiguy at yahoo.com
Fri Apr 29 06:10:37 PDT 2011


On Thu, 28 Apr 2011 19:59:52 -0400, Alexander <aldem+dmars at nk7.net> wrote:

> On 28.04.2011 18:17, Steven Schveighoffer wrote:
>
>> It would seem making the metadata be a constant offset from the data  
>> page would be better, but of course, it cannot be that way for  
>> multi-page blocks.
>
>   Why it cannot?

Because in the second or subsequent page of a multi-page memory block, the  
previous page cannot be metadata, it must be data (this is one contiguous  
block).  So how do you find the metadata for such a block?

In fact, thinking about it, the metadata is what tells the GC how big the  
block is, and where it starts, so you can't store the metadata in a  
constant offset, it's just not possible.

>> Yes, the allocation and free performance could be improved, but it  
>> doesn't change the fact that delete manually is not a huge performance  
>> gain, if at all.
>
>   I agree, just in some cases it is a gain, if not to performance, then  
> to memory usage. Imagine a tight loop with aggressive GC , when  
> collection is attempted on every allocation...

Yes, if you have specific memory requirements, it's best to use an  
alternative strategy.  That does not mean delete is the answer, and even  
if it is, the functionality that delete represents is not going away, just  
the keyword itself does.

>> If an object is to be collected, there will be no references to that  
>> object.  This means you do not have to scan that object's memory to see  
>> if it points to something else.  Less memory needs to be scanned.
>
>   Right, but I still have to scan other objects and roots, which are  
> still alive, and there can be many.

Yes, but your assertion was that more dead objects means the scan takes  
longer.  It's actually the opposite (or at least, it should be).

The sweep phase probably takes longer, though, but I wouldn't expect this  
to be the bottleneck.

> Good GC shouldn't attempt a collection unless memory is tight, though.

I think D's GC only attempts a collection if memory is tight, but I'm not  
sure now (after investigating somewhat Timon's benchmarks).

-Steve


More information about the Digitalmars-d mailing list