Re: [Pharo-dev] testing sista

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] testing sista

Eliot Miranda-2
 
Hi Clément,

On Sep 30, 2016, at 6:44 AM, Clément Bera <[hidden email]> wrote:

Hi.

In short: 
normally you don't, but for some reasons right now you do. Try a VM from here [1]. 

In long:
Normally you need a VM with the following slang to C compilation settings:
MULTIPLEBYTECODESETS true
bytecodeTableInitializer initializeBytecodeTableForSqueakV3PlusClosuresSistaV1Hybrid
which has been added recently to multiple VM builds, including the Pharo build if I am correct.

The latest Pharo VM on files.pharo.org answers true to "Smalltalk vm supportsMultipleBytecodeSets", so it should be fine... 
But, when I tried to run code with new bytecode set, it does not work indeed.

It's disconcerting that this is so mysterious.

- does an assert VM show up anything?
- is it a regression from integrating Lowcode?
- if you diff the generated code and try and filter out the Lowcode signal has anything changed?
- does the Sista simulator work?
- can we get help to produce a test suite?

- what other questions should we be asking?


So...
I've just compiled another VM to check and it could run the image.
I've just checked with the VM from openSmalltalk [1] and both pharo.cog.spur and squeak.cog.spur could run the Pharo image with both bytecode set and full blocks. 
It's not clear pharo.cog.spur is a complete Pharo VM as the migration process to opensmalltalk VM is still in progress, it may be a squeak VM with part of the extra Pharo plugins.

I believe something is temporarily wrong during the opensmalltalk pharo vm migration. I would recommend to use a VM from bintray to test those features until the migration is over. 
On the openSmalltalkVM git [2] you have a link by clinking "download" to the latest bintray releases. Those releases are built automatically and very frequently.


On Fri, Sep 30, 2016 at 2:54 PM, Nicolai Hess <[hidden email]> wrote:
Do we need a special vm for testing sista bytecode backend?
I enabled sista in the compiler settings and evaluating

[ ] class

crashes the vm.


nicolai

Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] testing sista

Clément Béra
 


On Fri, Sep 30, 2016 at 5:29 PM, Eliot Miranda <[hidden email]> wrote:
 
Hi Clément,

On Sep 30, 2016, at 6:44 AM, Clément Bera <[hidden email]> wrote:

Hi.

In short: 
normally you don't, but for some reasons right now you do. Try a VM from here [1]. 

In long:
Normally you need a VM with the following slang to C compilation settings:
MULTIPLEBYTECODESETS true
bytecodeTableInitializer initializeBytecodeTableForSqueakV3PlusClosuresSistaV1Hybrid
which has been added recently to multiple VM builds, including the Pharo build if I am correct.

The latest Pharo VM on files.pharo.org answers true to "Smalltalk vm supportsMultipleBytecodeSets", so it should be fine... 
But, when I tried to run code with new bytecode set, it does not work indeed.

It's disconcerting that this is so mysterious.

- does an assert VM show up anything?
- is it a regression from integrating Lowcode?
- if you diff the generated code and try and filter out the Lowcode signal has anything changed?
- does the Sista simulator work?
- can we get help to produce a test suite?

- what other questions should we be asking?


Wrong questions. The VM I build and the VM built by opensmalltalk VMs work fine. (I said it after your inlined answer in the previous mail)

I don't know how the VM from Pharo latest is generated, it could be from older non working sources or maybe some setting is missing. I am pretty sure everything will work fine once the merge with opensmalltalk will be finished.

Today I was working on having all the kernel tests pass with FullBlockClosure. It seems something is not working with process scheduling when using FullBlocks. I wonder what is going on. I may need help on that.

Yesterday I worked with the sista runtime. It seems that the optimizer takes many wrong inlining decisions, I need to investigate why. I have some benchmarks crashing due to recursive dynamic deoptimization, else the others are running. I need to understand what is going wrong there too.
 

So...
I've just compiled another VM to check and it could run the image.
I've just checked with the VM from openSmalltalk [1] and both pharo.cog.spur and squeak.cog.spur could run the Pharo image with both bytecode set and full blocks. 
It's not clear pharo.cog.spur is a complete Pharo VM as the migration process to opensmalltalk VM is still in progress, it may be a squeak VM with part of the extra Pharo plugins.

I believe something is temporarily wrong during the opensmalltalk pharo vm migration. I would recommend to use a VM from bintray to test those features until the migration is over. 
On the openSmalltalkVM git [2] you have a link by clinking "download" to the latest bintray releases. Those releases are built automatically and very frequently.


On Fri, Sep 30, 2016 at 2:54 PM, Nicolai Hess <[hidden email]> wrote:
Do we need a special vm for testing sista bytecode backend?
I enabled sista in the compiler settings and evaluating

[ ] class

crashes the vm.


nicolai