Distributed Squeak and Environments
Anthony Hannan
ajh18 at cornell.edu
Fri Jun 22 19:17:16 UTC 2001
> Now I'm trying to understand the young object optimization. It seems
> to imply something about the behavior of the Squeak gc.
Old objects that point to a young object automatically get added to a roots
table (See Interpreter>>#beRootIfOld: and its senders). Incremental GC
(collect young space only) starts its mark and trace from the Interpreter
oops AND the roots table.
>> [From looking up methods of old classes in environments]
>> Yes, and its old methods will be found in the original parent
environment.
>> Even more interesting is instances of classes not even defined in the
>> current environment ancestory can be passed into a method. Messages sent
>> to it will not be understood unless Object (or another known superclass)
>> implements it. Usually, this is unintentional and means the environments
>> have to be refactored. But it can be appropriate if objects are only
>> "passing through".
>
> This is potentially dangerous. Messages sent to object "passing through"
> are, in effect, bound lexically rather than statically. If you're sending
> a mutating method, if a method of that name can be found at all,
> it's probably the wrong one. It's worth thinking about preventing or
> controlling this behavior.
It is easy to raise an exception if an instance of an unknown class is sent
a message, because there will be no method dictionary found for its class
index.
>> You can extend this guarantee to a forked off block that takes arguments
or
>> captures outside variables, if you first check these variables and
confirm
>> that they don't point (directly or indirectly) to any unknown classes.
> Fair enough, but these checks sound run-time expensive.
We can not do the check and let the exception be raised above when/if a
message is sent to it.
Thanks for your feedback, Dave.
More information about the Squeak-dev
mailing list
|