Does the GC consider slice lengths?

Ali Çehreli acehreli at yahoo.com
Fri Apr 1 20:15:01 UTC 2022


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.

 >> 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.)

Ali



More information about the Digitalmars-d-learn mailing list