On 17-apr-11, at 21:44, Don wrote:
[...]
Basically, my contribution is this: the compiler can easily work
out, for each function, whenever it has entered and exited a non-
leaky pure function. It can make a call into the GC whenever this
happens. This gives the GC many more potential strategies.
yes more info is always better, I didn't want to diminish your work,
but to point toward a general improvement in the GC
My fear is that the overhead of this approach will make it worth only
for big allocations (getting rid of eventual false pointers), and thus
only under the programmer control.
Classifying the "allocation potential" of a function might help make
better automatic decisions.
That is difficult in general (one can flag alloc in loop with unknown
length or more than 4 elements as large for example, something that
would miss recursive allocations), but it would be useful, because for
those that allocate little could do nothing, or use a fixed stack like
heap, whereas those that allocate a lot could checkpoint the heap
(assuming a separate pool for each thread) or use a new pool.
Fawzi
