[Vm-dev] I would not have thought I ever say that: lets have a new primitve (was: Re: [squeak-dev] The Trunk: System-cwp.660.mcz)

Clément Bera bera.clement at gmail.com
Tue Jan 14 13:44:46 UTC 2014

2014/1/14 Stefan Marr <smalltalk at stefan-marr.de>

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


In the Pinnochio VM, they had contexts in read-only or the debugger and
continuations (through primitives I think). Currently contexts are used for
exceptions, continuations and debugging, and exceptions can be implemented
on top of continuations. This is one solution.

> Best regards
> Stefan
> --
> Stefan Marr
> INRIA Lille - Nord Europe
> http://stefan-marr.de/research/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20140114/6fd98e66/attachment.htm

More information about the Vm-dev mailing list