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