On Sat, 2 Feb 2002, Tim Rowledge wrote:

>
>
> Scott A Crosby wrote:
>
> > > >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?
>
> Err, note the _image_ change bit here. Improving the VM, even changing
> quite extensively the GC system do not neccessarily require changing the
> object model. For VW we added mulit-segment oldSpace and permSpace
> without any change to the object model or image incompatability. For the
> Active Book I added rommable image capability and multi-space capability
> without any object model change.
>

I was thinking of GC strategies that might require an extra header bit,
for example, 'this object has a single reference', and a back-pointer to
that reference. If thats frequently true in the image. (Have to test),
then relocating and checking the liveness of objects is a lot cheaper, a
linear scan through memory. (In the stock image, the impact of those back
pointers is bounded at <6%)

>
> > 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.
>
> This is merely a restricted version of generation scavenging with extra
> costs. Temp variable are typically taken care of quite nicely by the
> disappearance of the context. It would cost a further range check on
> every store, plus the extra word on every 'infant' object.

I was thinking of ideas from the literature that are faster than a GC for
stack and other quick temporaries. For example, in this proposal one would
not have to scan youngspace at all, just scan the current stack.

A variant of this, would be to make the infant space copy-collected, and
make a seperate youngspace thats copycollected. Oldspace is mark&sweep.

Having a seperate space for all objects that only have one reference is
also sorta cute. It can be copy-collected cheaply in one pass.

I'm just brainstorming random ideas, because given my tentative
benchmarks,[*] and guessing the impact of BC on them, the GC is going to
moreso become a bottleneck.


Scott



[*] They show that other than primitives and interpreter overhead,
MethodContext and GC are the largest identifiable issues in squeak.
MethodContext's are supposed to be a lot cheaper with BC, so that leaves
the GC.