> On 14 Dec 2015, at 12:21, Ben Coman <b...@openinworld.com> wrote: > > This is great news. Thanks Eliot and Esteban. From the 2GB limit I > take this to be 32-bit Spur?
yes of course. We are already working on 64bits spur but is not ready yet (it will be some point of 2016) > > Is it feasible to jump the image build numbers to make that first > image requiring a new VM align on a 100s build numbers. I see we are > currently 50496. 50500 is nice and distinctive, but even even 50600 > would be fine if the last few 400s are consumed in the meantime. mmm… that I don’t know… correlation of version numbers is usually important for us (for statistics purposes)… also changing number generation is more annoying than you would think (that’s why we don’t have 4.1, 4.2, etc.). but well… everything is possible, we’ll see :) Esteban > > > On Mon, Dec 14, 2015 at 6:24 PM, Esteban Lorenzano <esteba...@gmail.com> > wrote: >> We will start migration to Spur today. >> To complete it, we will require some time, specially to adapt the CI and >> check everything is ok. >> >> Spur will allow us to do a big step forward in Pharo development, in the >> concrete you will see it immediately for this: >> - We have noticed a speed increment of 100% in tiny benchmarks (and >> according to Eliot, it will be at least 35% in general on the system). >> - No more GC stops (noticeable when running large systems) >> - We will be able to scale our systems up to 2G memory consumption without >> loosing performance. >> >> But, this will have some drawbacks in the first times: >> >> 1) VM will not be compatible between versions anymore: Pharo 5.0 will have a >> Pharo Spur VM associated (and they are not compatible). >> - There WILL NOT be a "non-spur" version of Pharo 5.0. Once completed >> the transitions, this will be the only one. >> >> 2) NativeBoost-FFI implementation has been replaced with a new >> implementation who relies in ThreadedFFIPlugin and IA32Plugin. While we >> worked a lot to do this transition as painless as possible and we achieve a >> good level of backward compatibility (most uses of #nbCall: should work out >> of the box), there are some problems we cannot solve: >> - there are some stuff not possible to compatibilise, notably: >> - Structures now need to inherit from FFIExternalStructure >> - Arrays now are now shadowed >> - in general is a bit slower (impossible to compete with ASM) but in >> general is not perceptible. >> - THERE WILL BE BUGS AND NON-IMPLEMENTED FEATURES: Current >> implementation is validated with Athens and even Roassal was working, but of >> course that does not covers all cases. >> 2.1) ASMJIT will be removed from system and put in a separated packages. >> NOTE: There will be a blog post explaining FFI-NB architecture during the >> week. >> >> 3) There are more or less 70 new failing tests, some of them important than >> we need to fix as soon as possible. Please, please, please, help us with >> them :) >> >> 4) In general we foresee the system will became unstable some weeks, before >> it gets back to normal. Please be patient. >> >> 5) You will need to adapt your Pharo 5.0 related apps and CI processes (to >> take care about new VM). Some programs will stop work at all (for example, I >> think Pharo-launcher will need to be adapted). > > Maybe PharoLauncher can be a special hardcoded rule to have two > template headings... > * Pharo 5.0 Spur (beta); and > * Pharo 5.0 Pre-Spur (beta) > Enhanced multi-VM support perhaps based off the template headings would be > nice. > > cheers -ben >
