On Thu, 28 Apr 2011 19:59:52 -0400, Alexander <[email protected]> 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
