[Vm-dev] how can I build a sista spur 64 vm?

Tue Mar 24 23:04:36 UTC 2020

Hi Robert, Hi Clément, Hi interested folks,

> On Mar 24, 2020, at 11:28 AM, Robert <robert.withers at pm.me> wrote:
> 
> 
> Bonjour Clément, quoi de neuf? Eliot?
> 
> This is all very interesting news. I am sad to hear that 64-bit will need to be built. Then I decide not to be sad, that it is an opportunity to build a good foundation. Therefore, I request of the vm-dev list, who is a part of the Sista Team? Lots of good work to be done. Let us get it on! PortPortPort.
> 
> I bring Eliot to the email to mention that yes indeed I would like to deploy ParrotTalk/Raven upon a Sista 64-bit vm. I believe the first step is to form a team of interested parties. I am willing to spend some time, though my focus is porting SSL, ATM.
> 
> Which way is which what?
> 
I don’t think Sista is anywhere near production.  For me three major pieces of work need to be done:

a) porting it to Squeak; this is a personal requirement; I’m productive in Squeak and the simulator.  This is one half of that.

b) refactoring the system so it runs alongside the simulator. In Sista/Scorch the Scorch optimizer lives in the image, alongside applications, and above the VM.  The base Sista JIT inserts performance counters in conditional branches.  When these counters trip a send back into the image is generated, just like a doesNotUnderstand: or aboutToReturn:through:. In a production deployment the send-back invokes the Scorch optimizer, which analyzes the code around the counter send-back, optimizes, generates and installs a new optimized method into the relevant method dictionary, and continues execution.  The problem here is one of reliability.  If there are bugs in the Scorch optimizer, just as if there are bugs in the bytecode compiler, ones image can break.  The problem is much more challenging for Scorch since it Is a much more sophisticated compiler, and because it is invoked asynchronously, based on image activity.  It is however straight-forward to restructure things so that 
- the vm simulator delivers the send back not within the simulation but to an instance of Scorch living in the current image alongside the simulator,
- Scorch uses mirrors to access the class hierarchy, and a set of mirrors is writtten which access the simulated image, not the current image (of which Svorch would be none the wiser)
Now Scorch can be developed against the simulation, and hence not damage the current image; it can be profiled without affecting actual performance, and repeatability is much more easily achieved.

c) the JIT should be extended to do much better register allocation (this is work in progress)

So what I’m interested in is people good at compilers who find this interesting to join me in this work.  Taking this route should get us to a reliable Scorch/Sista more quickly than the develop-in-image approach Clément (& I) were taking previously.

Robert, please wait until we’ve made more progress.

_,,,^..^,,,_ (phone)

> Kindly,
> mumbles
> 
>> On 3/24/20 1:58 PM, Clément Béra wrote:
>> Hi Robert,
>> 
>> I worked on sista and I don't think I have ever tried it on 64 bits. I run my experiments on x86. My expectation for 64 bits is that you have to write build files inspired from the 32 bits 
>> sista.spur and the 64 bits cog.spur files. Then you have to run it in the VM simulator and fix the various few problems you see (likely a few instructions are not implemented in the 
>> x64 back-end). Then you can build a system. It's not so much work.
>> 
>> There was a released alpha version of Sista [1], which I used to run the benchmark of a research paper [2]. If you compile a VM with sources from that time (recent sources have difference 
>> that will break it), and follow the guidelines from the blog post [1], you should be able to reproduce the benchmark results from the paper. 
>> 
>> As I remember it, most benchmarks run without crashes at 1.5x and the development tools could be run for a while without crashes. Debugging and on-the-fly code changes in sista are 
>> only partially implemented (there's the potential to do it, but one has to implement it). I would say it is currently in a similar state as the strongtalk VM [3], while being compatible with 
>> Squeak and other Cog clients. 
>> 
>> I don't know what you mean by operational. If you're looking to experiment with it, tweak it to run some benchmarks, then you should be able to do it. If you're looking to deploy an application 
>> on a production VM, then significant work is left to do so (discuss directly with Eliot if that is the case). 
>> 
>> Have fun with the project :-)
>> 
>> [1] https://clementbera.wordpress.com/2017/07/19/sista-open-alpha-release/ 
>> [2] https://hal.inria.fr/hal-01596321/
>> [3] http://strongtalk.org/
>> 
>> On Mon, Mar 23, 2020 at 3:43 PM Robert <robert.withers at pm.me> wrote:
>>>  
>>> I understand that Sista is operational. I would like to try. How can I 
>>> build a Sista vm? I went to linux64x64/squeak.sista.spur and there is a 
>>> file there NotYetImplemented.
>>> 
>>> I appreciate any guidance.
>>> 
>>> -- 
>>> Kindly,
>>> Robert
>>> 
>>> 
>> 
>> 
>> -- 
>> Clément Béra
>> https://clementbera.github.io/
>> https://clementbera.wordpress.com/
> -- 
> Kindly,
> Robert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20200324/5207b790/attachment-0001.html>