Modifying MethodContext?

Stephen Pair spair at advantive.com
Wed Jul 25 10:43:28 UTC 2001


It seems to be working well right now, but I've only modified one
bytecode (push receiver)...I need to go through the bytecodes and
primitives and make sure they are using the receiverMap in the
appropriate places (as opposed to using the reciever)...then I'll post
it.

Essentially what this does is separate the receiver's identity for the
purpose of accessing state, from the receiver's identity for reference
(in the method context).  The normal situation is to have both be
identical, but in the case of forwarding, the reference identity
(contained in receiverMap) points back to the forwarder.  I think it
would also be useful for delegation.

I hadn't thought about the become scenario, but I think it could
definitely be applied there.  It would need a more general solution than
what I've done (in which VM checks the class of the receiver to
determine if it forwards a message).  It would be nice to find a bit in
the object header instead, but it's a tight squeeze in there.  Another
possibility would be to only use the Forwarder class, but add some
additional state in the forwarder instance that would direct the VM to
do special things (such as get rid of the forwarder during GC).

- Stephen

-----Original Message-----
From: squeak-dev-admin at lists.squeakfoundation.org
[mailto:squeak-dev-admin at lists.squeakfoundation.org] On Behalf Of Martin
McClure
Sent: Wednesday, July 25, 2001 12:05 AM
To: squeak-dev at lists.squeakfoundation.org; 'Andreas Raab'
Subject: RE: Modifying MethodContext?


At 9:47 AM -0400 7/24/01, Stephen Pair wrote a message that included 
these bits in a different order:
>Later, I may try and add a bytecode for doing a "delegated send" that 
>would allow any object to send a message to another object, and have 
>all references to self lead back to the delegator...but I don't know 
>yet if it will work for that case.

I have a project, currently on hold until I get a few other things 
done, that will require exactly this capability. My tentative 
approach for implementation looks a lot like yours. I think it's A 
Good Thing that you're working on this. There are a some interesting 
applications.

>
>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.
>

You got me thinking about why become: is so slow in a direct memory 
VM, and I realized that the technology you're building could be a 
step toward a faster become:.

Become: could copy both objects to newly-allocated locations and 
modify the old locations to be forwarders to each others' new 
locations. Sometime later a memory sweep could be done to update 
references to all objects that had undergone becomes since the last 
memory sweep. The high cost of the sweep is amortized across many 
becomes. It might make sense to combine this sweep with a compacting 
GC.

That's the basic idea. I've thought of some exceptions and nuances, 
and I'm sure that there are others I haven't thought of, but I 
haven't yet come up with any that make the scheme unworkable.

-Martin






More information about the Squeak-dev mailing list