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