deprecated delete and manual memory management

Steven Schveighoffer schveiguy at yahoo.com
Thu Apr 28 09:17:59 PDT 2011


On Thu, 28 Apr 2011 11:57:00 -0400, Alexander <aldem+dmars at nk7.net> wrote:

> On 28.04.2011 17:32, Steven Schveighoffer wrote:
>
>> This is not how it's implemented.  The metadata is kept in a separate  
>> page from the memory itself.
>
>   Huh? Could you please elaborate, what do you mean by "metadata" and  
> why it has to be kept on a separate page?

Flags for the memory, such as whether it is free, or whether it's  
reachable (during a scan), whether it has pointers, etc.

Why it is kept on a separate page, I'm not sure, I didn't write that.  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.  If you have ideas on how to improve the performance, I encourage  
you to learn how the GC works and submit some patches!  It actually can be  
pretty fun.

>   I've seen at least one GC implementation with free-lists and metadata  
> preceding allocated block, so even most of the allocations took O(1)  
> time (unless there was a shortage in memory).

Allocations are going to be less, because the memory is hopefully in a  
free list, and hopefully the metadata is pointed at by the free list (not  
sure about current GC implementation).

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.  If you want to gain performance, don't use the GC at all (for  
example scope classes), or use a custom allocator that is tailored to your  
needs.

>> Not really.  The more objects there are to collect, the less scanning  
>> needs to be done.  You only process blocks that have references to them.
>
>   Theoretically, any heap/stack-allocated block may have references.  
> Stack scanning is relatively cheap (we know its current size, and  
> usually it is small), but number of objects on the heap may be quite  
> big, and heap itself as well. Or do I
> mistunderstood something?

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.

You start from your roots, and then start scanning from there.  Your roots  
are your thread local storage, stack space, globals, and roots added  
manually.

-Steve


More information about the Digitalmars-d mailing list