On Friday, 12 February 2021 at 12:17:13 UTC, Per Nordlöw wrote:
On Tuesday, 9 February 2021 at 03:05:10 UTC, frame wrote:
On Sunday, 7 February 2021 at 14:13:18 UTC, vitamin wrote:
Why using 'new' is allowed in pure functions but calling
GC.addRange or GC.removeRange isn't allowed?
Would making
`new T[]` inject a call to `GC.addRange` based on `T` (and
maybe also T's attributes)
be a step forward?
`GC.addRange` is only used for memory allocated outside of the GC
that can hold references to GC allocated objects. Since `new T[]`
uses the GC, all the information is typeinfo is already there
(*), so `GC.addRange` is unnecessary and even wrong, because when
the GC collects the memory it won't call `GC.removeRange` on it
Implementation-wise, metadata about GC-allocated memory is held
in the GC internal data structures, whereas the GC roots and
ranges are stored in separate malloc/free-managed containers.
(*) Currently `new T[]` is lowered to an `extern (C)` runtime
hook and the compiler passes to it typeid(T). After this the call
chain is: _d_newarray_d_newarray{T,iT,mTX,miTX} -> _d_newarrayU
-> __arrayAlloc -> GC.qalloc -> ConservativeGC.mallocNoSync ->
Gcx.alloc -> {small,big}Alloc -> setBits
