On Saturday, January 25, 2003, at 01:30  PM, Tim Rowledge wrote:

> Robert Withers <rwithers12 at attbi.com> appears to have written:
>
>> [requirements for multiple Objectmemories in one squeak process]
>> - Each ObjectMemory would have an eden space, survivor spaces, old
>> space segments, a large space, a fixed space, a compiled code cache  
>> and
>> a stack space.
> Um, since we don't already have such spaces in use you're already
> talking about a total rewrite! I think you're getting confused here  
> with
> the VW object memory, which by the way already makes use of multiple
> oldspace segments when neccessary.
> --

Well it's best not to loose track of these thoughts, although the  
discussion is focusing around security concerns much of above really  
address issues with GC performance and simplifies object memory access  
by external DLLs which want non-movable objects.

I'll summarize the issues:

a) Writing all this and ensuring it's correct.
b) Watching the issue of machines/os with simple memory both in  
implementation and space, many of the problem mentioned by Tim can be  
solved by taking the attitude that memory is unlimited. However this  
isn't quite a reasonable choice for pocketpc machines. So ensuring low  
end clients aren't affected by high-end choices is an interesting issue.
d) funding
e) mmm I could ask is such complexity needed? I seem to recall John  
Maloney told me that the current GC, amongst many tried gave good  
performance, but it was also simple, a good thing.

Mind if you want radical changes, perhaps one should following in some  
other Smalltalk VM footsteps and construct the image at startup time  
from definitions thus create a memory space optimal for the machine and  
memory characteristics you are running on, and use a custom VMs created  
for a particular memory usage pattern instead of having one Vm that  
fits all.  I'll point to the GNU smalltalk usage of os virtual memory  
routines to assist in old/new pointer recognition, a performance  
feature well known to VM implementors yet unused by Squeak because of  
one-size fits all thinking.

PS One should also look to VisualAge for it's usage of chunks of memory  
containing objects which then have various attributes  (new, old,  
fixed, read-only, etc).
======================================================================== 
===
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
======================================================================== 
===