Cougaar Memory Profiler snapshots

These are snapshots from a two-node "ping" run of the Cougaar Agent Architecture.

The profiling filter matches the homepage example:

• 100% tracking for "lib/core.jar" (org.cougaar.core.*)
• 1% tracking for "java.*"

HTML snapshots:

1. all_trimmed.html
   This is a trimmed view of the main "/profiler" servlet page.

   See the homepage snapshots for an overview of the table columns and example "java.lang.String" analysis.

   The "size" and "capacity" metrics are periodically updated about once every 3 minutes. If the user clicks on one of the types for a more detailed view then these metrics are updated immediately.

2. all_full.html
   The above "all_trimmed.html" only shows the first 25 classes, sorted by "+Capacity Bytes". This page shows the full 901 classes and is about 300K.
3. strings.html
   This is a closer look at "java.lang.String". The "sort by" drop-down shows some of the debugging options. In this case we can sort by information from the String itself, such as "length()", and count unique values such as "equals".
4. strings_size.html
   This is a list of the largest live Strings, based upon "length()". As noted above, allocation time and stacktrace were disabled for "java.*" in this run, but we can see the "toString()" and other useful information.
5. strings_uniq_equals.html
   This is a list of the most common "equals(..)" strings. Nothing too shocking...
6. uid.html
   This is a view of a Cougaar class, "org.cougaar.core.util.UID". 100% of the allocations for this class were tracked, plus we also captured the allocation timestamp and stacktrace. The "sort by" drop-down shows the additional options.
7. uid_stack.html
   This is a list of the most common UID allocation stacktraces. Most UIDs are allocated when deserializing RMI objects by the agent blackboard. UIDs were also allocated by the agent's CommunityService and "WP" naming service.
8. uid_age_sample_5.html
   This is a small sample of the UIDs sorted by allocation timestamp. It shows that the CommunityService allocated a UID long ago, and that the other UIDs are fairly new. Only 5 of the 29 live instances were sampled, which is a useful technique if there are lots of instances.