Memory Debugging Technique

The Memory Monitor tool has a [MAP] button.  If you have the advanced tools loaded, [MAP] resolves to the Multi-Allocation Profiler.  Clicking on the button toggles the MAP.  Every second time you click on it, you will get the MAP’s report, and you can use that to track down unnecessary garbage creation.

In addition, the tool can write a CSV log as it executes. That’s what the [Log] button does.  You can also run it headlessly. 

The public Store repository has the package MemoryMonitor-runHeadless in the Public Store repository.  Get the MemoryMonitor and MemoryMonitor-runHeadless packages and file them out as parcels. Then loading MemoryMonitor-runHeadless in *any* image will load the MemoryMonitor and start it headless when writing a log. In this way, it’s really easy to instrument application images.

You can also use the MemoryPolicyStressTest package and run it under the MemoryMonitor.  Be warned that currently those tests take as long as 80 minutes to run on a fast machine. However, you can comment on how the tests are written to exercise various aspects of the memory policy by allocating objects in different ways. You can look at the graphs too.  If you pay close attention, you can see when the memory policy decides to GC instead of growing (the growth regime upper bound), when the memory policy decides to take emergency action, etc.

Cincom Smalltalk Release 1104

Many customers have received the latest releases—Cincom® ObjectStudio® 8.3 and Cincom® VisualWorks® 7.8. Support is ready to receive any questions you have concerning upgrading from the previous release or migrating from even older releases.  

Reviewing the release notes for either product will give you a better idea of how the product changes may impact your efforts to upgrade.  Once you begin, Smalltalk Support resources are available to answer any questions and concerns you encounter.   

Thanks for using Cincom Smalltalk™, and as always, we are here to support you.