On 4/1/22 4:15 PM, Ali Çehreli wrote:
On 4/1/22 10:46, Steven Schveighoffer wrote:
>> But if
>> it considers slices and their lengths specially, then it would see
>> that the mid section is not referenced any more.
>
> It's not a consideration for the GC, but possibly the compiler. The GC
> has no visibility into slices that hold references to its memory block.
> It only has knowledge of pointers to its memory block (and then only
> indirectly via scanning).
Yes but if it recognized slices in addition to pointers, it could
consider their lengths to reuse the middle section, no? I understand the
role of the compiler but as GC is part of the D runtime, it feels like
it could own the concept of slices.
While *possible*, there are several problems:
1. The GC is performant (!) because it only has to check whether a block
is live or not. If it had to also mark every single element (which is
based on the type) of the block as live or dead, the performance takes a
steep nosedive, along with space usage (1 bit per element?).
2. The GC somehow would have to manage that "middle" block of memory.
How do you free part of a block?
3. By default, memory is untyped. I think even with precise scanning,
the stack is untyped. The GC only scans pointers because it has no way
of interpreting the length that's contained somewhere nearby. A lot of
machinery would have to be added to make this happen.
>> A related question is whether the memory for earlier elements are
>> freed as they are popped off from the front. I know by experience that
>> the memory for earlier elements are indeed freed. So one can use D's
>> arrays as queues without memory issues: Add to the end, pop from the
>> front...
>
> No, because removing the reference does not mean there are no other
> references.
Agreed but if the array is a private queue of a struct with just one
reference, then the earlier memory would be freed.
However, my mind was not working well in the morning: Combining with
what you said above, of course it is never the "previous parts" of the
array that are freed, rather the old allocations of the array that are
freed. (Provided there are no references.)
Yes, I didn't read fully your question. The "front" elements that you
see freed are the old copies that are discarded when a reallocation
occurs. It's still an entire block that's managed, not portions of it.
-Steve
