Hi Stefan,
On Tue, Jan 14, 2014 at 4:37 AM, Stefan Marr smalltalk@stefan-marr.dewrote:
Hi Bert:
On 14 Jan 2014, at 12:07, Bert Freudenberg bert@freudenbergs.de wrote:
(moving to vm-dev)
Thanks!
[careful, rather academic discussion ahead]
On 14.01.2014, at 10:56, Stefan Marr smalltalk@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/