<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2014/1/14 Stefan Marr <span dir="ltr"><<a href="mailto:smalltalk@stefan-marr.de" target="_blank">smalltalk@stefan-marr.de</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Hi Bert:<br>
<br>
On 14 Jan 2014, at 12:07, Bert Freudenberg <<a href="mailto:bert@freudenbergs.de">bert@freudenbergs.de</a>> wrote:<br>
<br>
> (moving to vm-dev)<br>
Thanks!<br>
<br>
[careful, rather academic discussion ahead]<br>
<div class="im"><br>
> On 14.01.2014, at 10:56, Stefan Marr <<a href="mailto:smalltalk@stefan-marr.de">smalltalk@stefan-marr.de</a>> wrote:<br>
><br>
</div><div class="im">>> I am just trying to think of how to implement that in the SOM VMs.<br>
>> Without GC support for tracing/enumerating the objects, it’s not going to be pretty.<br>
>><br>
>> #someObject/#nextObject don’t make any sense for me in the long term.<br>
><br>
> 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.<br>
<br>
</div>Yes, right. But I was thinking out loud about SOM. So, I don’t have backward compatibility issues.<br>
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:.<br>
<div class="im"><br>
>> 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.<br>
><br>
> Sure, but then allObjects shouldn't be used in production code anyway. Users need to be aware that it’s going to be slow.<br>
<br>
</div>Yes, I guess that’s the way to go.<br>
<div class="im"><br>
> You need to traverse from specialObjectsArray and activeContext. This will find all objects.<br>
</div><div class="im">> But if you support thisContext then you must have those mechanisms in place already.<br>
<br>
</div>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.<br>
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.<br>
</blockquote><div><br></div><div>Hello,</div><div><br></div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Best regards<br>
<span class="HOEnZb"><font color="#888888">Stefan<br>
<br>
--<br>
Stefan Marr<br>
INRIA Lille - Nord Europe<br>
<a href="http://stefan-marr.de/research/" target="_blank">http://stefan-marr.de/research/</a><br>
<br>
<br>
<br>
</font></span></blockquote></div><br></div></div>