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
|