Garbage collection working improperly?

[Jay O'Connor]

Aahz wrote:

>In article <bplcb9$f4g$1 at reader2.nmix.net>,
>Jay O'Connor  <joconnor at cybermesa.com> wrote:
>  
>
>>I kinda like VisualWorks Smalltalk's approach.  It uses a system whereby 
>>new objects are scavenged aggresivly and objects that survive the 
>>scavenger are moved to a different memory space that is not GC'ed nearly 
>>as much.  (New objects tend to have short lives..objects that survive 
>>several generations of scavenging tend to live longer) When it's memory 
>>reaches a threshold, it makes a decision as to whether to either request 
>>more from the OS or  to GC the old object memory space in an  attempt to 
>>free more memory.  The nice part is that you can configure a. how much 
>>memory it starts with b. at what point the threshold is set for and 
>>c.the weighting of the algorithim to determine whether to GC or allocate
>>    
>>
>
>Python does the same thing -- you just can't configure it as much.
>  
>

I remember this in particular because I was working on an application 
where the performance characteristics were such that for the most part 
we wanted to allocate new memory rather than GC, but then as the memory 
we were using reached a certain point, we wanted to free some of our own 
cached objects so tha the GC could reclaim them.  Being able to fine 
tune the memory usage characteristics, and also hooking into 
VisualWork's notification mechanism to be informed when GC was 
happening, proved very important.