[Vm-dev] Re: [Pharo-dev] testing sista

[Clément Bera]

On Fri, Sep 30, 2016 at 5:29 PM, Eliot Miranda <eliot.miranda at gmail.com>
wrote:

>
> Hi Clément,
>
> On Sep 30, 2016, at 6:44 AM, Clément Bera <bera.clement at gmail.com> wrote:
>
> Hi.
>
> *In short: *
> normally you don't, but for some reasons right now you do. Try a VM from
> here <https://bintray.com/opensmalltalk/vm/cog/201609292318#files/> [1].
>
> *In long:*
> Normally you need a VM with the following slang to C compilation settings:
> MULTIPLEBYTECODESETS true
> bytecodeTableInitializer initializeBytecodeTableForSque
> akV3PlusClosuresSistaV1Hybrid
> 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
> <https://bintray.com/opensmalltalk/vm/cog/201609292318#files/> [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
> <https://github.com/OpenSmalltalk/opensmalltalk-vm> [2] you have a link
> by clinking "download" to the latest bintray releases. Those releases are
> built automatically and very frequently.
>
> [1] https://bintray.com/opensmalltalk/vm/cog/201609292318#files/
> [2] https://github.com/OpenSmalltalk/opensmalltalk-vm
>
> On Fri, Sep 30, 2016 at 2:54 PM, Nicolai Hess <nicolaihess at gmail.com>
> 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
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160930/0e880d41/attachment-0001.htm