Short list with things to finish for D2

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Thu Nov 19 09:11:59 PST 2009


dsimcha wrote:
> == Quote from Andrei Alexandrescu (SeeWebsiteForEmail at erdani.org)'s article
>> dsimcha wrote:
>>> == Quote from Andrei Alexandrescu (SeeWebsiteForEmail at erdani.org)'s article
>>>> Yes, it will be because the book has a few failing unittests. In fact, I
>>>> was hoping I could talk you or David into doing it :o).
>>>> Andrei
>>> Unfortunately, I've come to hate the MRU idea because it would fail miserably for
>>> large arrays.  I've explained this before, but not particularly thoroughly, so
>>> I'll try to explain it more thoroughly here.  Let's say you have an array that
>>> takes up more than half of the total memory you are using.  You try to append to
>>> it and:
>>>
>>> 1.  The GC runs.  The MRU cache is therefore cleared.
>>>
>>> 2.  Your append succeeds, but the array is reallocated.
>>>
>>> 3.  You try to append again.  Now, because you have a huge piece of garbage that
>>> you just created by reallocating on the last append, the GC needs to run again.
>>> The MRU cache is cleared again.
>>>
>>> 4.  Goto 2.
>> This is not a matter of principles, but one of implementation. When you
>> GC, you can adjust the cache instead of clearing it.
> 
> Technically true, but what is a matter of principles is whether the implementation
> of arrays should be very tightly coupled to the implementation of the GC.  Fixing
> this issue would have massive ripple effects throughout the already spaghetti
> code-like GC, and might affect GC performance.  For every single object the GC
> freed, it would have to look through the MRU cache and remove it from there if
> present, too.
> 
> The point is that this **can** be done, but we probably don't **want** to
> introduce this kind of coupling, especially if we want our GC model to be sane
> enough that people might actually come along and write us a better GC one day.

I agree. But probably there might be a solution out there that solves 
this issue in a better way. We should keep on looking. Maybe something 
that refines the MRU, or something that obviates the MRU altogether.

Andrei



More information about the Digitalmars-d mailing list