Re: I would not have thought I ever say that: lets have a new primitve (was: Re: [squeak-dev] The Trunk: System-cwp.660.mcz)
(moving to vm-dev)
On 14.01.2014, at 10:56, Stefan Marr smalltalk@stefan-marr.de wrote:
Hi Tobias:
On 14 Jan 2014, at 10:41, Tobias Pape Das.Linux@gmx.de wrote:
How do you implement that efficiently in RPython, or Java? Keeping some kind of object table around?
Well, I have no Idea currently, but i think some #primAllObjectsDo: (or #primAllObjects, as it seems now) has IMHO less severe constraints than the #someObject/#nextObject way. OT is one path. Manual heap scanning another. Collecting objects from the roots (special objects array) a third. All these do not require the #nextObject invariant.
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.
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.
And without support of the underlying platform, I think, #allObjects can’t be complete. Just thinking of how TruffleSOM works, traversing only from specialObjectsArray on, will only find part of the live heap.
You need to traverse from specialObjectsArray and activeContext. This will find all objects.
There are way to many important references on the Java stack, that I can’t easily access. And making them accessible, is going to cost a lot of performance even when #allObjects is never used. I think. :-/
But if you support thisContext then you must have those mechanisms in place already.
In case you find a nice solution for RSqueak, I would be very interested.
In SqueakJS I support nextObject for oldspace objects only (old space is a linked list). If you call nextObject on a new object, I do a full GC, which makes it old.
- Bert -
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. 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
2014/1/14 Stefan Marr smalltalk@stefan-marr.de
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. 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.
Hello,
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/
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/
Hi Eliot:
On 14 Jan 2014, at 20:01, Eliot Miranda eliot.miranda@gmail.com wrote:
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?
Well, I haven’t tried yet, but providing a traditional thisContext seems to me problematic.
While most of the SOM implementation use indeed bytecodes in one form or another, as well as an explicit stack, TruffleSOM doesn’t. It is a classic ‘AST’-based interpreter. It uses the Java stack for representing quite a bit of the execution state, doesn’t have anything like linearized bytecodes, and neither an instruction pointer nor a stack pointer.
So, providing something like a generic thisContext, with the classic capabilities feels very unnatural in that setting. Providing the interface for a debugger or continuations on the other hand, should be much simpler. Hm, well, I’ll have to try it, I guess.
Best regards Stefan
vm-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
Clément Bera -
Eliot Miranda -
Stefan Marr