Does the GC consider slice lengths?

[Steven Schveighoffer]

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