Some simple ideas about GC

[w0rp via Digitalmars-d]

On Tuesday, 13 May 2014 at 06:20:36 UTC, Martin Nowak wrote:
> On Monday, 12 May 2014 at 23:44:09 UTC, Andrei Alexandrescu 
> wrote:
>> I'll keep those with which std.allocator is likely to help:
>>
>>> - The current GC code is not hackable. First rewrite then 
>>> improve.
>>>
>>> - A testable and more modular rewrite (using recent D 
>>> practices) would
>>> encourage more contribution and is necessary for 
>>> experimentation.
>>
>> I think std.allocator is some 15 work-hours from reviewable 
>> form, and std.typed_allocator (with tracing and all) some 50 
>> more work-hours. Unfortunately these numbers grow due to 
>> fragmentation - and OMG I made a pun too.
>>
> Let's hope it doesn't become a fractal :).
>
> There are already some existing allocators, e.g. vibe.d. If you 
> make it possible to try out the allocator, report bugs and 
> contribute fixes, this should help to polish the 
> implementation. You could do this by moving your work to a 
> separate repo and registering a dub package, instead of using a 
> phobos branch.
>
> I haven't yet looked at typed_allocator, but the heap layers 
> concept is just about right for a GC rewrite. Maybe we'll use 
> multiple specialized GCs in the future, instead of one generic 
> GC.

I think this could be a good approach. This approach was taken 
for Java. It might be the case that one collector happens to work 
very well in environments with lots of memory to spend, and 
another works well where memory is limited, etc.