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

[Stefan Marr]

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.

Best regards
Stefan

-- 
Stefan Marr
INRIA Lille - Nord Europe
http://stefan-marr.de/research/