Blog

This post is an introduction to DTrace and a provider I implemented for the Smalltalk Squeak/Pharo VM.

DTrace is a powerful, kernel-based dynamic tracing framework. It was originally built for Solaris but is being added to Linux and is shipped with OSX since version 10.5. DTrace can provide very detailed information that is useful when you need to track down bugs or performance issues (e.g., syscalls, I/O events). Programs are dynamically instrumented -- meaning you can deliver fully optimized binaries and start a debugging session on a live production server.

DTrace allows one to add high-level probes, which give the capability of creating static instrumentation points anywhere in the VM. That means, for a high-level language like Smalltalk we can add probes for events such as method enter and method return. So, what does that buy us for Squeak/Pharo? This allows us to use the DTrace technology to trace Smalltalk code execution. DTrace allows unprecedented view across all layers of Smalltalk software. With DTrace we can simultaneously observe and correlate events from Smalltalk, the VM, and the OS.

The provider I’ve implemented currently provides the following events: method enter and return, object allocation, full and incremental GC begin and end, and process activation (that is, when the scheduler transfers control to a Smalltalk process). Similar providers exist for languages such as Java and Ruby.

To wet your appetite, here is an example that illustrates the basic usage of DTrace for Squeak/Pharo. For this example, lets assume our application has a high GC rate so to start tracking down the problem we want to know if there are any classes that are extensively instantiated during a given program run. In the DTrace scripting language (a subset of C named D), we define the probes we are interested in and how to print and aggregate the traced data:

The variables ‘number’ and ‘size’ are maps that associate each class name with the number of instantiations, respectively with the total sum of bytes allocated. The class name is fetched from arg0, the size of the newly instantiated object from arg1.

The pseudo probe END is run when the tracing session is terminated (that is, when you hit Ctrl-c). In this declaration we specify how to print the results of the aggregated data. The printout  shows the top 4 classes:

These numbers are taken from tracing the execution of the statement ‘Browser open’ in Pharo. The most instantiated class is Point with 79.000 instances, which together consume 0.9MB (!) of memory. For the complete D source see the file objectalloc.d in the attached zip file (see below).

As a follow up question, we may want to know which methods generated the Point instances. With another small script we can quickly answer also that question.

Rectangle>>intersect:                                    2534
ImageFillStyle>>initialize                            2566
Form>>extent                                                 2792
Point>>asIntegerPoint                                  5102
SmallInteger>>adaptToPoint:andSend:     7480
Point>>-                                                          10271
Point>>+                                                         13369

The script remembers for each methodenter and methodreturn even the current class and method in the variable self->currentcaller. On each objectalloc event we then do a @methods[self->currentcaller] = count().

2. Unzip and execute start.command (just double click). This should start up a Pharo image using the instrumented VM.

5. When the browser has opened (takes a while), quit the D script (Ctr-c). Its output is printed to the terminal.

Follow my previous blog post that explains how to build a Squeak/Pharo VM from zero. Before generating the sources, file in the following changeset:

Also, you need to add the following header file into your ../platforms/unix/src/vm/

While the low level probes of DTrace do not add overhead to the programs (because of dynamic instrumentation), the ones I added to the VM (aka. User-land Statically Defined Tracing (USDT)) do slow down the execution. The overhead compared to a vanilla VM are:

This is not a huge slowdown, but it is still measurable. There may also be room for tuning the C code I added to the VM.

There are some more probes that would be useful to add. One of these would be a custom probe that can be triggered via a primitive from Smalltalk code. Like this one could fire high-level events, for instance, Seaside-start-request and Seaside-end-request, which would allow one to associate or scope traces to specific Seaside requests. Another useful feature would be to be able to access the current Smalltalk stack. This would allow for sampling; similar to message tally.

DTrace by itself does not provide visualizations but since its output can be formatted as required (using printf) and piped into a file, one can feed the data to a visualization tool (e.g., print output in MSE format, import it into Moose, and create interactive visualizations with Mondrian).

The interesting use cases will emerge from debugging real-world problems. What makes DTrace a compelling technique is that it allows one to seamlessly combine data from different providers. For instance, you can now figure out which of your Smalltalk code triggers expensive I/O events because it hits the disk. Or you could add Firefox probes and see how control flows between Ajax and Smalltalk.

If you find this useful or if you have interesting scripts to share, please drop me a message.

Pharo 1.0 is the first release since we started the project in May 2008. Many companies have already successfully adopted Pharo. With Cmsbox we plan to migrate to Pharo during the next weeks.

Seaside, the Smalltalk web framework, switched to Pharo as their main development platform. A book on Pharo has recently been published. Pharo has a growing community and is supported by research institutions such as INRIA.

Pharo 1.0 is just a milestone on our journey, and development of the next version, providing many improvements and speed, is well underway.

Aoround 20 people attended the Pharo sprint in Lille, France, which took place from 17th to 20th October 2009. Our main target was to finish version 1.0. We managed to fix several long-standing problems and eventually the unit tests – over 7000 in total – all passed. As a result we published a first release candidate replacing the current beta version.

Another area of work was to start off 1.1-alpha. Since we are going to provide maintenance updates for 1.0 after its release, there are now two parallel update streams. For version 1.1 we defined the following milestones:

It was a great sprint with many enthusiastic people who were eager to take Pharo one step further. Thanks to everyone, and especially to Stef and his group for the hosting and INRIA for the financial support.

The system is stable enough to get serious testing now. Various people already reported that they are using Pharo in their (commercial) projects.

In spring of 2008, Pharo was started as a fork of Squeak 3.9. The name "Pharo" evolved from suggestions like Beacon, Tombolo, Atoll, Lagoon, Lighthouse, etc. Our mission statement is the following:

Pharo's goal is to deliver a clean, innovative, open-source Smalltalk environment. By providing a stable and small core system, excellent developer tools, and maintained releases, Pharo is an attractive platform to build and deploy mission critical Smalltalk applications. Pharo is MIT licensed and is steered by a board of benevolent dictators. The board makes final decisions if no consensus can be reached within the community. Pharo fosters a healthy ecosystem of both private and commercial contributors who advance and maintain the core system and its external packages.

Until today the core image has seen 400 batches of updates. The following list gives an overview of important achievements:

The increasing number of people that contribute and use Pharo indicates that the project is on the right track. Here are just three excerpts from mails posted to the mailing list during the last two months:

"I absolutely believe Pharo is 100% on the right track, and a critical component in a potential Smalltalk resurgence." – Robert Peters (July 9)

Also the download statistic of the Pharo image shows that Pharo has already found quite some interest (lines show number of downloads per month for the Squeak-dev resp. Pharo image):

Thanks to Damien Cassou for building Pharo images and providing the statistics

What's left for the final release of 1.0? The list of open issues for milestone 1.0 tracks the remaining tasks. Also, we need to decide on the packages (developer tools) that are integrated in the official Pharo image by default. But we don't plan to keep the beta tag forever, so stay tuned...

Yesterday, we sprinted for almost 12 hours and I am quite amazed what we achieved during this time.

We focused on fixing and integrating the issues relevant for the upcoming 1.0 release. In total, 18 batches of updates were pushed into the stream. During the sprint, the bug tracker has been updated 135 times!

We also made progress fixing failing tests, improving the speed of OmniBrowser (David and Alex), writing the Pharo by Example book (Oscar), and creating a first version of http://en.wikipedia.org/wiki/Pharo.