Hi Stefan,


On Tue, Jan 14, 2014 at 4:37 AM, Stefan Marr <smalltalk at stefan-marr.de>wrote:

> Hi Bert:
>
> On 14 Jan 2014, at 12:07, Bert Freudenberg <bert at freudenbergs.de> wrote:
>
> > (moving to vm-dev)
> Thanks!
>
> [careful, rather academic discussion ahead]
>
> > On 14.01.2014, at 10:56, Stefan Marr <smalltalk at stefan-marr.de> wrote:
> >
> >> I am just trying to think of how to implement that in the SOM VMs.
> >> Without GC support for tracing/enumerating the objects, it’s not going
> to be pretty.
> >>
> >> #someObject/#nextObject don’t make any sense for me in the long term.
> >
> > Some VMs support those easily and they're more efficient, so I would not
> abandon them. But, as I wrote before, I’d make them optional, if a VM
> instead provides allObjects.
>
> Yes, right. But I was thinking out loud about SOM. So, I don’t have
> backward compatibility issues.
> Depending on the personal point of view, one might even argue that SOM is
> not actually a Smalltalk, because it does not provide all the fancy things
> like thisContext, or #become:.
>
> >> I want to support one form or another of parallel execution. So, if I
> want to offer #allObjects at all, it needs to be an atomic snapshot. Most
> likely with stop-the-world semantics, which is a severe burden on
> performance.
> >
> > Sure, but then allObjects shouldn't be used in production code anyway.
> Users need to be aware that it’s going to be slow.
>
> Yes, I guess that’s the way to go.
>
> > You need to traverse from specialObjectsArray and activeContext. This
> will find all objects.
> > But if you support thisContext then you must have those mechanisms in
> place already.
>
> Well, that’s the thing. I don’t support thisContext. thisContext is to my
> understanding really bound to one specific implementation technique.
> Thereby restricting significantly how a VM can implement the language.
> I am also not yet sure whether I will provide some replacement for
> thisContext, but if so, it would need to be a much more specific interface
> that reifies information from the execution context explicitly on demand
> only.


I don't see the difference.  In my VMs contexts are only created on demand.
 The issue is what kind of object proxy to provide for execution context.
 In VisualAge there is a proxy for a stack segment, essentially a pointer,
and the VI must construct stack frames from this.  In Cog there is a
context which contains a hidden pointer to a single stack frame.  Then
there are facilities for manipulating the underlying stack through those
interfaces.  In VisualAge I guess one can rewrite the stack arbitrarily.
 In Cog, assignments to the sender, pc, stack pointer, etc are supported in
the VM by manipulating the underlying stack appropriately.  In both cases a
context-like object is adequate.  I also think that a context-like object
is an appropriate proxy for a non-stack-like execution model such as
continuation-passing.  So viewd from this level of abstraction I think it
makes no difference, and hence you might as well provide thisCOntext.  You
might disallow assigning to the sender in your implementation, but I don't
see how thisContext per se severely constrains your implementation; it's
just about where in the system (in the image or in the VM) the mapping from
the activation proxy to the underlying execution context is done.

Does this make sense?

And since the various SOM implementations with classic approaches in C/C++,
> using RPython ala PyPy, and using Truffle on top of the JVM all differ
> significantly, it is for me a nice academic exercise to find an interface
> that just provides the desired functionality without restricting the
> implementation too much.
>
> Best regards
> Stefan
>
> --
> Stefan Marr
> INRIA Lille - Nord Europe
> http://stefan-marr.de/research/
>
-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20140114/42f325d7/attachment.htm