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
|