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