Sage 2.9.3 released, Sage 2.10 release cycle opened

Well, Sage 2.9.3 was actually release two days ago, but since there was never an official release announcement I figured it might be worth mentioning it here. We only merged three tickets, but one of those was a long standing NTL leak which I complained about previously. The issue was fixed by Willem Jan Palenstijn. It turned out to be missing __dealloc__ methods in two of the NTL wrappers classes. I never thought that the memory leak would be caused by missing deallocation in general. I foolishly assumed that since the people who wrote the code used __dealloc__ in all the other classes they would do so in those classes, too. Interestingly enough this leak wasn't caught by doctesting the NTL wrapper, but by padics.py. But I am glad Willem caught it. So why all this focus on memory leaks, even the small ones? There are various reasons:

• Code that leaks makes you look unprofessional. While there may be occasional small leaks (the python interpreter does leak a couple bytes over the run of most Sage session) something as massive as the NTL wrapper leak forces you to quit and restart Sage. And that is totally unacceptable.
• Even small memory leaks add up to large leaks if you hit them often enough. In the past we had some leaks in linear algebra which caused about a total leak of one gigabyte an hour with certain code. We fixed those in the linear algebra code and afterwards the code still leaked about one gigabyte a day. We investigated and as it turned out that one gigabyte a day leak was caused by a single 8 byte leak in a code path he hit very often in that computation. The discovery was live during my Sage Days 5 presentation when I did analyze some of Ifti's example code at the end of the talk. A video of that ought to exist somewhere on Google video.
  
• Many programs run for a long time and usually need all the available physical memory. Once you hit swap because your working set is too large performance goes down the drain. In border line cases not having memory leaks may make a difference. It is also quite bad if you run a lot of independent computations back to back and have to restart Sage periodically because of memory leaks. We also had a bunch of reports about this issue in the past.
• And now the most important reason for some of us: Well, you may say, I have 16, 32 or 64 GB of Ram and why would I care about the little leaks? The answer is clear: performance. If python's garbage collector has to keep track of a billion leaked eight byte segments that cannot be good. In some case the performance difference for long running code was in excess of ten percent by fixing some small eight byte memory leak.
• EDIT: I forgot to mention one important experience. There was a memory leak when computing a cusp and to our amazement the fix (freeing one mpz in a premature return path) broke a doctest. Upon investigation it turned out that the result prior to the memory leak fix was incorrect. I must admit that this was the first and only time I ever had a memory leak affect the correctness of a program. To this day I still cannot understand why it happened.
  

I am also release manager for the 2.10 release of Sage and 2.10.alpha0 was uploaded earlier today. The goals for the 2.10 release are ambitious:

• Update a lot of spkgs to the current release
• Solaris 10 support in 32 bit mode on Opteron/x86
• FreeBSD support out of the box

The currently planned release date is about four days from now, but the way it looks right now that might get pushed back a little. Otherwise we might postpone some of the features to 2.10.1 - life goes on.

Cheers,

Michael