Wednesday, October 26, 2011

Overheard the other day

"... I would like to be a genius but I'm only gifted, so I work hard..." --- Unknown

Monday, October 10, 2011

Update on the garbage

I have been working on Cincom Smalltalk garbage collection for a while. Here is a quick summary:

  • On the image side, I retuned the memory management and got real application code speed ups ranging from 10% to 2.5x. Some particular cases run O(10x) faster.
  • On the VM side, I enhanced stack overflow management on both the incremental and stop-the-world GCs. The improvements easily scored 20% faster execution.
  • A while ago, I posted about a prototype for a new GC implementation that ran up to 35% faster in the common case. This new GC is already shipping with our next release's internal builds. The finished product runs up to 40% faster.
As part of this effort, I fixed several subtle bugs that will no longer pester our customers from time to time.

Lately, the scavenger has been getting some attention because we found a couple small problems that should be fixed. Working with something like the scavenger requires thorough attention to details, because the end product must Work No Matter What(TM). But it is not efficient to put in this kind of effort for just a few tiny changes, to then forget about the scavenger and move on to something else. Thus, we will take this opportunity to improve several scavenger sections I had already identified as needing work.

There is always the unexpected with these type of endeavors. Back when I was working on the incremental and stop-the-world GCs, the existing implementation did not initially suggest there would be a lot to optimize. I could not have predicted the stack overflow improvements or the 40% speed up for the GC. These were surprise realizations that came from paying close attention to the code. Due diligence does pay off.

I've been wondering what I will run into with the new space scavenger. So far, the changes result in a net deletion of about 250 LOC. This includes removing effectively duplicated code that, if all goes well, will not come back. But why bother deleting code? Because deleting code you don't need is critical. If you don't have to pay attention to unnecessary code, you can spend more time concentrating on the code that is actually useful, and the result is a significantly better product. In the past few years, the VisualWorks VM's source code base has shrunk by about 30%.

But back to the scavenger. Besides code deletion and clarification, I did some rewriting to improve algorithmic efficiency. In one particular case, the new improved implementation also causes optimizing compilers to output about 15% less assembler instructions. And, right now, I'm working on an improved class table management mechanism for our 64 bit VMs. Already, it looks like a slightly faster 64 bit scavenger is possible.

More to come!