Modifying MethodContext?

Stephen Pair spair at advantive.com
Wed Jul 25 10:17:53 UTC 2001


>Stephen,
>
>> I'm creating a "forwarder" capability.  In Squeak, due to the direct 
>> mapped memory model, a become: operation, under certain circumstances

>> (large image, object in old space) can take a very long time (a half 
>> second or more).  Therefore, for certain applications, using become
is 
>> not appropriate.
>
>I forgot to mention this in my last post: If #become: speed is all
that's bothering you, there might
>be a way around it without having to modify the VM too deeply. It
depends whether you know enough 
>the object you're proxying and whether you're willing to trade some
space.
>
>What you could do is to make the forwarder exactly the same size size
as the object you're proxying.
>If both objects are of the same size then you can just copy all the
state from one object to the
>other and vice versa. There are a few tricky implications (such as when
#becoming: a compact with a
>non-compact class and fixing up the roots table afterwards) but it may
be a lot simpler than
>modifying the VM in such a deep way that you're anticipating.

I've done a design exactly like this before...for mapping to an object
database that I was working on.  Unfortunately, the need to know the
size of the object in advance ended up being a killer...I tried to make
intelligent guesses about the size of a related object by keeping that
info in the references...if the size ended up being different than
expected, I fell back on a become.  It actually worked very well, and
almost entirely avoided become (or at least any expensive becomes)...but
the problem was not that, it was the complexity that it forced me to
introduce into the design of the database.  It wasn't hard, it just
bothered me.

>Unless, of course, you're just doing a bit of VM hacking for the fun of
it
>;-)

That's definitely a factor.

>Cheers,
>  - Andreas

- Stephen





More information about the Squeak-dev mailing list