On Thu, 28 Apr 2011 11:57:00 -0400, Alexander <[email protected]> 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
