[Vm-dev] Re: [Pharo-project] Hints and clues for a Pharo newb

Eliot Miranda eliot.miranda at gmail.com
Thu Apr 22 16:55:37 UTC 2010


On Thu, Apr 22, 2010 at 12:49 AM, stephane ducasse <
stephane.ducasse at gmail.com> wrote:

>
> > Yes.  But MethodContext behaves differently depending on whether its
> closureOrNil inst var is nil (a normal method) or a BlockClosure (an
> activation of a block).  If nil, ^-returns return to the context's sender.
>  If not nil ^-returns return from the home context, found by following the
> outerContext chain through the closureOrNil inst var.  So we no longer need
> BlockContext.
>
>
> Hi Elliot
>
> I was wondering why you do not use two classes and you do the nil check?
>

One reason is backward compatibility.  The existing VM ensures that
closureOrNil (which used to be called receiverMap) is nil.  The other is the
internal workings of the VM.  The nil test is done by the VM on every
^-return.  The VM isn't going to waste time sending a message.  It is going
to do a nil test.

In fact in Cog the VM doesn't even do a nil test since in machine code the
JIT knows at compile time whether an ^-return is within a block or not, and
in the stack interpreter whether a frame is a block activation is indicated
by a status bit in the method field of a frame.

So don't think Smalltalk code, think optimized VM internals.  We're not
going to waste time instantiating some object just to tag a structure as not
being a block activation.

HTH
Eliot


>
> > This also means we only need one context class, and some time I'd like to
> merge the two ContextPart and MethodContext classes into a single Context
> class.  Possibly the name should be ExecutionContext or MethodOrBlockContext
> or?  Suggestions?
> >
> >
> > Now, test yourself before evaluating :) what should be the result of
> > this expression?
> >
> > [: arg | arg perform: #isExecutingBlock ] value: thisContext
> >
> > It depends on whether the expression is executed at method level or at
> block level.  As a test this should be:
> >
> > testIsExecutingBlock
> >     self assert: ([: arg | arg perform: #isExecutingBlock ] value:
> thisContext) == false.
> >     [self assert: ([: arg | arg perform: #isExecutingBlock ] value:
> thisContext) == true] value
> >
> > Can somebody justify the result?
> >
> > isExecutingBlock answers if the receiver is executing a block or not. It
> does not answer whether the context in which isExecutingBlock is sent is
> executing a block or not.  Remember that
> >
> >     [:arg| arg == thisContext] value: thisContext
> >
> > is false.  thisContext is rebound within every actual method or block
> scope.
> >
> > HTH
> >
> > Eliot
> >
> >
> > >> Context creation is optimized in the VM in most Smalltalks, so it's
> > >> only really created as an object in the environment (reified) when
> > >> it's specifically needed through "thisContext".
> > >
> > > In Pharo contexts are not reified like that. Stack-frames are actual
> > > objects at all times. However, for speed reasons, their creation and
> > > garbage-collection is optimized by the VM. Stack frames get
> > > automatically recycled if nobody refers to them.
> > >
> >
> > I think is what I said :)
> >
> > But its not a property of Pharo.  It is a property of the VM.  In Cog
> contexts are not actual objects all the time, only when needed.  And Cog
> runs Pharo images just as it runs Squeak images.  So it would be incorrect
> to say "in Pharo" and better to say "in the standard Squeak VM".
> >
> >
> > >> There are several applications related with computational reflection
> > >> (Reflective Programming, Meta-Programming, MOP, etc) which makes use
> > >> of the current context.
> > >
> > > Also: exception handling, generators, continuations, co-routines, ...
> > >
> > > For another fun use of "thisContext" check this Stack-Overflow
> question:
> > >
> > >
> http://stackoverflow.com/questions/2500483/is-there-a-way-in-a-message-only-language-to-define-a-whiletrue-message-without-r
> > >
> > > Lukas
> > >
> > > --
> > > Lukas Renggli
> > > www.lukas-renggli.ch
> > >
> > > _______________________________________________
> > > Pharo-project mailing list
> > > Pharo-project at lists.gforge.inria.fr
> > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> > >
> >
> > _______________________________________________
> > Pharo-project mailing list
> > Pharo-project at lists.gforge.inria.fr
> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20100422/fbb17575/attachment-0001.htm


More information about the Vm-dev mailing list