squeak-vmdev

[Squeak-VMdev] re: version 4 changes

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

Hi all--

	I added a few things to the swiki page, I'll repeat them here for the
sake of discussion. Under the heading "Facilitate a number of
anticipated extensions to Squeak":

-	Incorporate method-lookup change to support remote message-sending, in
anticipation of Squat's support for minimal snapshots and inter-system
communication.

-	Allocate header format five for Squat's method dictionary marking, and
version bits in method trailers for Squat's module system.

	The Squat homepage is http://netjam.org/squat/. The release page has
links to all the relevant code.


	thanks,

-C

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

Re: [Squeak-VMdev] re: version 4 changes

[Avi B. <av...@be...>]

On Apr 7, 2004, at 12:22 AM, Craig Latta wrote:

> 	I added a few things to the swiki page, I'll repeat them here =
for the
> sake of discussion. Under the heading "Facilitate a number of
> anticipated extensions to Squeak":

In a similar vein: since I added something to the swiki about an=20
immutability bit, I'll bring it up here as well.  As I think G=F6ran=20
already mentioned, the most interesting use is in transactional=20
systems: these need to be able to find out, for some group of objects,=20=

which of them has changed state since some point in the past. =20
Currently, the usual pattern is to store a copy of every object in the=20=

group when the transaction begins, and then scan through them when the=20=

transaction ends looking for changes.  This is, of course, generally=20
pretty slow, especially if you're trying to manage large chunks of the=20=

image transactionally.  Having an immutability bit allows a for much=20
more efficient approach, and has some other nice uses too (I very much=20=

like, for example, that objects in the literal frame of a VisualWorks=20
method get marked as immutable).  The real question, I guess, is=20
whether transactional systems are considered an important enough set of=20=

applications to use a whole header bit to optimize them.  Since I=20
mostly work on business applications, which usually need transactional=20=

behavior, my bias is that they are important enough, but obviously not=20=

everyone will think so.

Avi

Re: [Squeak-VMdev] re: version 4 changes

[<gor...@bl...>]

Avi Bryant <av...@be...> wrote:
[SNIP]
> The real question, I guess, is 
> whether transactional systems are considered an important enough set of 
> applications to use a whole header bit to optimize them.  Since I 
> mostly work on business applications, which usually need transactional 
> behavior, my bias is that they are important enough, but obviously not 
> everyone will think so.
> 
> Avi

It seems to me that a transactional engine like KATS for example could
be used in much more situations than merely business applications. It
doesn't even have to be persistent objects, but rather multi-Process
applications that use a transactional model instead of Montitors,
Queues, Semaphores etc.

regards, Göran

Re: [Squeak-VMdev] re: version 4 changes

[Andreas R. <and...@gm...>]

Hi Craig,

Since noone has commented on this yet, I'll take a stab:

> - Incorporate method-lookup change to support remote message-sending,
> in anticipation of Squat's support for minimal snapshots and
> inter-system communication.

What kind of method-lookup change? What is needed here and what are the
implications for both speed and potential impact on JIT?

> - Allocate header format five for Squat's method dictionary marking,
> and version bits in method trailers for Squat's module system.

I'm slightly hesitent to reserve an object format for something like method
dictionary marking. Can you elaborate on why this would be needed? I would
somewhat expect that a well-known class could do the same and we only have
so many object format types. Version bits in method trailers shouldn't be
needed if I understand the CM changes correctly - you might just add another
iVar to CMs.

> The Squat homepage is http://netjam.org/squat/. The release page has
> links to all the relevant code.

Hm... something a little more specific would be nice ;-)

Cheers,
  - Andreas

[Squeak-VMdev] re: Squat VM changes for v4 (was "version 4 changes")

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

Hi Andreas--

> > Incorporate method-lookup change to support remote message-sending,
> > in anticipation of Squat's support for minimal snapshots and
> > inter-system communication.
> 
> What kind of method-lookup change? What is needed here...

	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.

> and what are the implications for both speed and potential impact on
> JIT?

	I have found the performance impact negligible; the usual case is one
additional identity check against a special object (in C, "class ==
(longAt(((((char *) specialObjectsOop)) + someInteger"). I see no impact
on JIT (assuming it can deals acceptably with the way method lookup
happens now). Hopefully Ian will chime in about that.

> > Allocate header format five for Squat's method dictionary
> > [activation] marking, and version bits in method trailers for
> > Squat's module system.
> 
> I'm slightly hesitent to reserve an object format for something like
> method dictionary marking. Can you elaborate on why this would be
> needed?

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

> ...we only have so many object format types.

	Well, the one I want to use (5) has gone unused for Squeak's entire
history, as far as I can tell. :)  And it's not the only one (format 7
is also unused). And in eight years I've yet to hear of anyone else
wanting one of them. :)  And this is a very good cause. :)  And I'm not
asking for any additional header bits. ;)  (oops, smilie overload...)

> Version bits in method trailers shouldn't be needed if I understand the
> CM changes correctly - you might just add another iVar to CMs.

	True, it just seemed like a logical thing to put in the trailer, and I
was already adding a known-to-the-VM bit there. Oops, I forgot to
mention that in my previous message. That's for *method* activation
marking.

> > The Squat homepage is http://netjam.org/squat/. The release page has
> > links to all the relevant code.
> 
> Hm... something a little more specific would be nice ;-)

	'Sorry, I was pressed for time (still am :). See
http://www.netjam.org/squat/releases/current/vmChanges.zip . Pick a VM
and snapshot from http://www.netjam.org/squat/releases/current/#theBits
to see the image side of things.


	thanks again,

-C

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

[Squeak-VMdev] Re: Squat VM changes for v4 (was "version 4 changes")

[Andreas R. <and...@gm...>]

Hi Craig,

> > What kind of method-lookup change? What is needed here...
>
> 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? Put differently, wouldn't it have the same effect if
you just make Other a ProtoObject?

Incidentally, talking about message forwarding. We might want to keep in
mind the stuff that Stephen Pair did for the Chango VM - is he on this list?
If not, we should invite him. He had some fairly interesting stuff going
with delegation and that might be of some interest here.

> > I'm slightly hesitent to reserve an object format for something like
> > method dictionary marking. Can you elaborate on why this would be
> > needed?
>
> 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.

> > ...we only have so many object format types.
>
> Well, the one I want to use (5) has gone unused for Squeak's entire
> history, as far as I can tell. :)  And it's not the only one (format 7
> is also unused). And in eight years I've yet to hear of anyone else
> wanting one of them. :)  And this is a very good cause. :)  And I'm not
> asking for any additional header bits. ;)  (oops, smilie overload...)

Oh, I'm not saying we shouldn't do this. I'm trying to understand if there
is a "generalized benefit" from it, e.g., what else could one potentially do
with these changes.

> > Hm... something a little more specific would be nice ;-)
>
> 'Sorry, I was pressed for time (still am :). See
> http://www.netjam.org/squat/releases/current/vmChanges.zip . Pick a VM
> and snapshot from http://www.netjam.org/squat/releases/current/#theBits
> to see the image side of things.

Thanks, I'll check it out - guess that'll help with the above.

Cheers,
  - Andreas

Re: [Squeak-VMdev] Re: Squat VM changes for v4 (was "version 4 changes")

[Ian P. <ian...@in...>]

On 08 Apr 2004, at 18:05, Andreas Raab wrote:

> Incidentally, talking about message forwarding. We might want to keep 
> in
> mind the stuff that Stephen Pair did for the Chango VM - is he on this 
> list?
> If not, we should invite him. He had some fairly interesting stuff 
> going
> with delegation and that might be of some interest here.

Which reminds me, for V4 the following might be on my wishlist too:

- separate the notion of "self" and "receiver".

For most purposes they remain the same thing.  Within 
#doesNotUnderstand: (or in some kind of explicit primitive #perform: 
type thing that allows divergence) they can be made different objects.  
Receiver inst vars remain with the "receiver" definition, while sends 
to self remain with the "self" definition.

This allows (for example) "bullet-proof proxies" where #dNU: sets 
receiver to the object that fields the send and retains the proxy as 
"self".  Any subsequent send to self goes straight back to the proxy, 
rather than the receiver, without affecting how state is accessed 
within the receiver; i.e., it's completely transparent to the (non-meta 
;) programmer.

I think VisualWorks does (or did or was going to do a long time ago) 
something similar, precisely for the proxy interest.

Cheers,
Ian

Re: [Squeak-VMdev] Re: Squat VM changes for v4 (was "version 4 changes")

[Andreas R. <and...@gm...>]

> Which reminds me, for V4 the following might be on my wishlist too:
>
> - separate the notion of "self" and "receiver".

IIRC, then that's what Chango did - using the "receiverMap" in contexts as
"self" (as you describe it).

Cheers,
  - Andreas

Re: [Squeak-VMdev] Re: Squat VM changes for v4 (was "version 4 changes")

[Avi B. <av...@be...>]

On Apr 8, 2004, at 9:16 AM, Ian Piumarta wrote:

> Which reminds me, for V4 the following might be on my wishlist too:
>
> - separate the notion of "self" and "receiver".
>
> For most purposes they remain the same thing.  Within 
> #doesNotUnderstand: (or in some kind of explicit primitive #perform: 
> type thing that allows divergence) they can be made different objects. 
>  Receiver inst vars remain with the "receiver" definition, while sends 
> to self remain with the "self" definition.
>
> This allows (for example) "bullet-proof proxies" where #dNU: sets 
> receiver to the object that fields the send and retains the proxy as 
> "self".  Any subsequent send to self goes straight back to the proxy, 
> rather than the receiver, without affecting how state is accessed 
> within the receiver; i.e., it's completely transparent to the 
> (non-meta ;) programmer.

Yes, please, I'd love to have that.

[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!