Image format proposals... Re: [SqF]Report of VI4 Project for Feb '02

Scott A Crosby crosby at qwes.math.cmu.edu
Sat Feb 2 02:03:55 UTC 2002


On Fri, 1 Feb 2002, Martin McClure wrote:

> At 3:15 PM -0800 2/1/02, Tim Rowledge wrote:
> >This is the initial report for the VI4 Project group.
> >
> >Goal: This project is intended to gather together all the vm and vi
> >related changes that have been proposed and which require a different
> >image format.
> >
>
> [...]
>
> >
> >Plans: Any further proposals for image format affecting changes are
> >needed as soon as possible; this is not something we want to do more
> >than once.
>

I think we may need to do it more than once.. How about two iterations?
VM4, where we improve the VM, and VM5 where we redo ObjectMemory?

I've been thinking of ideas to make GC a lot less weak, including almost
free stack objects and temporaries. The problem is that it requires
careful profiling first. But we won't have accurate profiling on the new
VM until the new VM is out.

And, IMHO, we don't want to hold back a new VM just to maybe get a redo of
the objectmemory in.

One really nice idea I've seen is to use a seperate scheme for temporary
objects.. Something similar to:

Each object has a 'single reference' bit, and an extra header word
pointing to the reference. (The single-reference bit can be imlicit. We
can reserve a percentage of the memory range and assume that all bits in
that range *are* single-reference.).

If an object is stored in more than one place, the object is cloned and a
*copy* is put into youngspace. The origional is garbage. We can cheaply
update the references to it because we have a pointer in the object that
points to it..

Furthermore, we can scan that infant space quickly. Since each object in
it contains a pointer to the single word in the any other object that is
supposed to point to it, we can see if that pointer still points to it,
and remove it if not.

No mark, no sweep, no 'following pointers'

Whether its worth it, or how much it will save... Profiling will have to
tell.

--

There are other ideas I've kicked around.


Scott





More information about the Squeak-dev mailing list