Object memory ideas (was Re: Win32 VM Update & Request for help)

tim Rowledge tim at rowledge.org
Fri Aug 31 04:54:51 UTC 2007


On 30-Aug-07, at 1:48 PM, Bert Freudenberg wrote:


>
> There is this idea I discussed on and off with people ... which is  
> having part of the object memory be "static/read-only". Objects in  
> there wouldn't be garbage-collected (ven by a full GC), and writing  
> to them would copy them into regular space. Unfortunately this  
> wouldn't help with start-up time unless we also move to an object  
> table (so oops wouldn't have to be rewritten on start-up).
Yah, I talked with Dan about this sort of thing some years ago,  
having previously done exactly this for the (ancient history!) Active  
Book vm. There I used a copy on write so that the entire image could  
be in actual ROM for near instand loading; a patching method allowed  
the incremental changes to be saved and applied very quickly. Working  
'images' were often only a few tens of KB.

The problem is that I've never heard of any way of doing such a  
mechanism without something that is effectively an OT. With direct  
pointers we have a problem that altering some object means making a  
copy of it in 'ram' and updating every object that points to it,  
requiring a copy and update and GOTO beginning-of-sentence. Basically  
a  vm level system tracer! Somewhere there has to be a level of  
indirection that starts out in ram and stays there (Active Book vm  
kept the OT in ram for example) so as to provide a useful stopping  
point to the trace.

VW has (had?) the PermSpace idea where a large chunk of the image is  
not garbage collected under normal circumstances, which allows the  
use of shared memory mapping etc. I'm not at all certain whether that  
is still useful in OSs more recent than my 1995 experience. It is  
still ram though and IIRC used the OS level copy-on-write of the  
relevant pages and the VW sort-of OT in order to work.

Personally I've never had a problem with the idea of object tables. I  
think they let you do interesting things at modest cost.  Certainly I  
can imagine interesting possibilities for sharing the bulk of an  
image between many Spoons.

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
A)bort, R)etry, I)nfluence with large hammer.





More information about the Squeak-dev mailing list