[gclist] Fuzzy collect expand decision.

[Charles Fiterman]

The problem with tracking allocations and frees as they occur is it adds
overhead in the busiest part of the allocator. How ever good the decisions
made this way its a very expensive way to make a decision.

First the function that makes the decision should be called via a pointer
so the user can replace it. The user may have some insight on the question
the collector could never have. The user may know the program is still
starting up and expanding the heap, or its too busy to collect etc.

If the collector must make the decision what the collector knows without
invading allocation logic is what fraction of time has been spent on
collection and how sucessful the last collect was. If that fraction is high
expand seems in order if low collect. The longer a program has been running
the less likely it is to be expanding for startup. If the last collect was
very sucessful another collect is a better decision, otherwise expand seems
more logical. 

If the collector can reduce that is hand memory back to the system
information about paging and cache use come into play.

This is the sort of problem people attack with fuzzy logic. Key to doing it
is realistic test programs or backtraining for individual programs.

Any fuzzy experts in the group?