Carmack about static analysis
deadalnix
deadalnix at gmail.com
Mon Dec 26 04:44:33 PST 2011
Le 26/12/2011 05:23, Andrei Alexandrescu a écrit :
> On 12/25/11 8:56 PM, deadalnix wrote:
>> Le 25/12/2011 05:27, Andrei Alexandrescu a écrit :
>>> Got the GC book this morning, already read 2.5 chapters :o).
>>>
>>>
>>> Andrei
>>>
>>
>> You'll find that you can do a lot when GC is aware of immutability (in
>> functionnal languages, most things tends to be immutable).
>>
>> In the actual state of druntime, the GC is bad, but worse, cannot be
>> imporoved to take advantage of this, and never will unless a major
>> changement is done in GC interface.
>
> What changes do you have in mind?
I think GC should be aware of immutable/shared on type qualifier.
Thread lcoal can be collected in a given thread without caring about
others. immutable can be used as great advantage to collect concurrently.
>
> I've gone through a larger portion of the book and one thing has become
> very clear to me: we must improve the precision of the collector. This
> would be a gating feature towards taking the GC pretty much anywhere.
>
> As a first step, we must make all allocations except stack type-aware,
> and leave only the stack to be imprecise.
>
I dpo agree. However, this will generate a lot of code bloat. This seems
to be an issue for many people (see topic on static this and executable
size for more on that).
This tell us that we need a way to choose between GC. (just like JVM does).
For swap friendlyness, we can separate memory blocks that may contains
pointer and the ones that cannot. If something is swapped, the GC
soesn"t need to go throuw it and generate a huge amount of (slow as
hell) IO.
For the same reason, we may want to use different memory blocks for TLS
of each thread. If a thread is sleeping and swapped you don't want an
working thread to prevent this memory to go on swap. The exemple or
Chrome browser on a notebook is very explicit on that point : it has a
huge memory footprint and will swap almost inevitably on thoses
machines. However, it keep being fast because each tab has its own
memory pool and a tab that hasn't the focus can be swapped almost
completely. Firefox has a smaller memory fooprint, however, users
complains more about its memory consuption. Because they are not aware
of want is really different. Firefox consume less memory, but is way
less cache friendly and slow down dramatically when it has to swap.
This is a big topic, and we may want to start a topic on that point
specifically instead of hijacking this thread.
More information about the Digitalmars-d
mailing list