Modifying MethodContext?

Martin McClure martin at hand2mouse.com
Wed Jul 25 04:04:59 UTC 2001


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