>  > Of course, another approach is to avoid allocating huge
>>  monolithic objects. If you look at your needs it's going to
>>  be pretty rare that you actually need one.
>>
>>  tim
>
>Right...the specific need I have is for implementing a cache
>mechanism...even if that cache needed to hold 1 million objects, it
>would only rarely need to be allocated (when adjusting the size of the
>cache for instance)...I could even pre-allocate the whole
>thing...wasting a lot of space, but preventing the need of ever having
>to adjust its size in the middle of a running application.
>
>- Stephen

For the curious I should point out that that large object gets 
allocated in young or newspace. Because of how the Squeak memory 
model works that large object gets compacted via the incremental GC 
<ie moved> <usually, depends on if earlier objects die> until it is 
tenured which happens if 2OOO objects survive after allocating 4OOO 
objects, or of course you do a full GC which does an  GC and 
compaction across old and new space then tenures everything into 
OldSpace. This is a classic problem with this type of memory model, 
moving large objects around forever. I'm considering writting a 
memory policy class and altering\adding to some of the GC values to 
deal with issues like this. Of course as Tim pointed out the better 
solution is to have a large space to manage these objects, but that 
requires a whee bit more work, but forcing a full GC should not  be a 
long term fix for this GC problem.
-- 
--
===========================================================================
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===========================================================================