7-point summary of the Spur memory manager

6 February, 2014


From Clément’s post to the pharo community:

Hello pharoers,

The new Cog memory manager, Spur, is simply *amazing*. I saw at FOSDEM that some of you were interested in it, but unfortunately you were lacking information about it.

I wrote a one page article that sums up Spur’s new features so every one can know what will be better. There’s no VM technical details here, it’s just about what will change for a regular pharo user.


Let me know if you think I forgot yet another feature.

If you have questions, I’ll try to answer, but ask Eliot, he implemented Spur so he can answer your questions much better than I can :-).



6 Responses to “7-point summary of the Spur memory manager”

  1. Jan Barger Says:

    Hi, I think we dont need much more speed up, but rather more robustness. When i run seaside image for few monhts i always got errors in source code displaying and image must be rebuilded from new one. ( http://www.janbarger.com )

    • Hi Jan,

      There are a number of things that need to go into creating a stable program. One is a stable and robust VM. The fact that the VM also performs well is a bonus. There are major limitations that we currently live with. One is the image size. My understanding of what keeps us from supporting a 64 bit image, which means supporting larger and more complex programs, is not just a technical problem. The problem is that without a robust and fast memory manager the system will not be able to survive growth to a large size. Spur is part of that solution.

      There are some very good seaside developers and Squeak and Pharo programmers that can help you with Seaside. You might want to look into supporting a higher level of persistence like Gemstone, if you are running into problems. By separating the image from the data you eliminate being tied down to a specific image. There are a number of other solutions you might look into but I encourage you to discuss them within the Squeak, Pharo or Seaside communities. There is nothing in developing a new VM that prevents you from building a robust system. You may even benefit from the new VM’s if they make the whole system better.

  2. Jan Barger Says:

    Sorry i don’t need help, i will do it my way. I am just confused from the way things are going… from just about 4 files of simple and pure smalltalk squeak, to lot of files, wasted space, time and simplicity and purity of code is gone too.

  3. Hi Jan, what are you describing? The VM? Where is the wasted space and time?

    As far as simplicity and purity goes I am guilty. Fast VMs are difficult to keep simple. I know of none that are both fast and simple.

  4. Jan Barger Says:

    I know of one …. and my advice for you Eliot: You can build a fastest and super duper ( JIT COG SPUR …) VM solving all problems in the universe by just this simple code:

    Transcript show: ’42’

    Any other solutions will lead to much more problems in the future 🙂

  5. Jan Barger Says:

    Just joking. Because it seems, you are preffering speed too much, Eliot.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: