std.allocator: primitives for helping GC

[Dmitry Olshansky via Digitalmars-d]

01-May-2014 20:41, Andrei Alexandrescu пишет:
> On 5/1/14, 12:43 AM, Dmitry Olshansky wrote:
>> 01-May-2014 08:05, Andrei Alexandrescu пишет:
>>> So far allocators have been quite GC-agnostic; deallocation would be
>>> needed for each allocation, and there was little structure to help
>>> tracing.
>>>
>>> The primitive resolveInternalPointer has made a step toward more precise
>>> structuring of heaps, and now it's time to look at some real GC helpers.
>>>
>>> These are markAllAsUnused, markAsUsed, and doneMarking. Find their
>>> description here:
>>>
>>> http://erdani.com/d/phobos-prerelease/std_allocator.html
>>>
>>> There are a few proof of concept implementations here:
>>>
>>> https://github.com/andralex/phobos/blob/allocator/std/allocator.d
>>>
>>> The basic idea is that the GC would initiate a collection by calling
>>> markAllAsUnused. That would cause the underlying untyped allocator to
>>> softly mark all memory as free, but without actually messing it up.
>>> (Many allocators are capable of implementing such a primitive cheaply.)
>>
>> It would be interesting to define where GC sits and how it integrates
>> with allocators to begin with. Given that currently GCAllocator is
>> mentioned
>> somewhere at the bottom of heap layers I'm really at loss about how
>> these helpers fit into the picture.
>
> Well currently GCAllocator is only included for completeness. The
> purpose of std.allocator/std.typed_allocator is to be a complete
> redesign, not an adaptation, of the current GC.
>

So a replacement for current GC built on top of std.allocator.

>>> Then, the GC would trace objects starting from roots. Whenever it finds
>>> a used pointer, it would mark the corresponding memory as allocated by
>>> using markAsUsed, effectively undoing the soft freeing for it.
>>
>>
>> How GC determines which allocator an object belongs to ?
>
> The idea is, for each root (whether conservative or typed), the GC first
> calls resolveInternalPointer. That gives the memory chunk encompassing
> that pointer. The GC uses that chunk to retrieve metadata about it and
> then passes it to setAsUsed.
>

The Q is about which _allocator_ an object belongs to, in case there are 
many heaps. How to work given an allocator and a pointer is more or less 
obvious.

>
> Andrei
>


-- 
Dmitry Olshansky