[Issue 21775] New: std.typecons.RefCounted, std.container.array.Array, & similar structs that manage their own memory do not need to be scanned unless GC-allocated memory is reachable through them

d-bugmail at puremagic.com d-bugmail at puremagic.com
Sun Mar 28 02:27:37 UTC 2021


https://issues.dlang.org/show_bug.cgi?id=21775

          Issue ID: 21775
           Summary: std.typecons.RefCounted, std.container.array.Array, &
                    similar structs that manage their own memory do not
                    need to be scanned unless GC-allocated memory is
                    reachable through them
           Product: D
           Version: D2
          Hardware: All
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P1
         Component: phobos
          Assignee: nobody at puremagic.com
          Reporter: n8sh.secondary at hotmail.com

Code that manually allocates memory without using the GC is responsible for
calling GC.addRange if there is the possibility the memory might contain a
pointer through which GC-allocated memory is reachable. Conservatively
determining this via std.traits.hasIndirections can lead to false positives
when nesting multiple types that manage their own memory, for instance a
refcounted array of refcounted items.

There is a related problem in the Phobos implementation of
std.container.array.Array that affects every Array regardless of its element
type. Array!E is shaped like:

---
import std.typecons : RefCounted;
struct Array(E)
{
    static struct Payload
    {
        size_t capacity;
        E[] payload; // allocated with malloc.
        /// ...
    }
    auto data = RefCounted!Payload;
    /// ...
}
---

Because Payload has a pointer to an array, RefCounted!(Array!E.Payload) calls
GC.addRange irrespective of E.

This situation can be improved. Rather than use a general-purpose check for
whether a type has pointers, RefCounted and related types can use a
special-purpose slightly altered version that need not be exposed to library
users.

--


More information about the Digitalmars-d-bugs mailing list