[Squeak-VMdev] re: Squat VM changes for v4

[Craig L. <cr...@ne...>]

Hi Andreas--

> > The current Squat implementation checks if the receiver's class is
> > a special "proxy" class (currently called "Other"), which is in the
> > special objects array. If it is, it kicks the send back to image,
> > using the same mechanism as for >>doesNotUnderstand:, so that the
> > message may be forwarded by the proxy.
> 
> I'm missing something here - if it uses the same mechanism why would
> we need to change the lookup?

	Heh; by "same mechanism" I mean I use >>createActualMessageTo: and the
remapping stuff, similar to the message-not-understood support later on
in Interpreter>>lookupMethodInClass:. I didn't literally mean the
message-not-understood behavior itself. Hopefully you've seen my version
of >>lookupMethodInClass:, to see what I mean.

> Put differently, wouldn't it have the same effect if you just make
> Other a ProtoObject?

	I think it's useful that (with this VM support) Other can be anywhere
in the class hierarchy. In particular, it's impervious to whatever junk
ends up in any potential superclasses (*especially* Object or
ProtoObject ;). Also, I think having multiple class hierarchy roots is
unnecessary, but let's please not rehash that in this thread.

> > The VM is the thing that does the activation marking. I'm using that
> > mark to tell when any method from a method dictionary has been run;
> > it's useful for, e.g., calculating which classes can be swapped out
> > of an image at some point in time. (There are also primitives for
> > reading and clearing the marks.)
> 
> I'm missing something here too (guess I'll have to check the code).
> This sounds as if a method dictionary with an extra iVar or so would
> achieve the same effect at the same cost.

	Here again, in addition to cost I'm also concerned with security. I'd
like to use a mechanism for this which is less exposed to interference
from the image. I don't want this information to be reachable from,
e.g., >>instVarAt:put:. I'd prefer that people have to go a bit more
(and more informed) effort to manipulate the marks, and be less likely
to change them inappropriately by accident.

	Basically, I think this is properly considered "special VM knowledge"
that happens to be attached to these objects, but shouldn't be directly
visible in the normal ways to object memory inhabitants.


	thanks again,

-C

--
Craig Latta
improvisational musical informaticist
cr...@ne...
www.netjam.org
[|] Proceed for Truth!