[D-runtime] Precise garbage collection
Leandro Lucarella
leandro.lucarella at sociomantic.com
Wed Aug 7 09:18:10 PDT 2013
On Fri, Jun 21, 2013 at 11:37:45PM +0200, Rainer Schuetze wrote:
> On 21.06.2013 22:22, Steven Schveighoffer wrote:
> >>d2. Both dynamic and associative arrays currently allocate memory chunks and use them in a "non-standard" way that cannot be described by a simple TypeInfo. For example, dynamic arrays keep track of the allocated size of the array by placing it at the very end of allocations < 4k, but at the beginning for allocations >= 4k, moving the data to an offset of 16 in the latter case. Associative arrays combine hash-list-node, key and value into a single allocation, sometimes even with the value type unavailable.
> >
> >The dynamic array "allocated size" location and size is predictable, and can be determined whether it exists based on the APPENDABLE bit. You should be able to correctly ignore it during a collection. Or am I misunderstanding the reason you posted that?
>
>
> The size value itself is only a small issue, the larger one is the
> address of the array data moves depending on the size of the
> allocation, so the pointer info needs to be placed at some offset
> sometimes. My first implementation actually figured this out in the
> GC, but I think this leaks too much implementation details of the
> array into the GC. So I changed it to use gc_emplace instead.
Any reason not to use a more obvious name like setType() or similar?
--
Leandro Lucarella
Senior R&D Developer
Sociomantic Labs GmbH <http://www.sociomantic.com>
More information about the D-runtime
mailing list