previous next top contents index framed top this page unframed
If just SPACE is specified, shallow data are gathered; if SPACE DEEP is specified, shallow and deep data are gathered. There are two reasons to leave out DEEP:
The {NO}MONITORAREA commands are used
to indicate which areas are to
be monitored. MAINPM maintains two lists: one of areas to be monitored
(monitoredAreas) and one of areas not to be monitored
(unmonitoredAreas). MONITORAREA t
adds the area with title t to
monitoredAreas, and
removes it from unmonitoredAreas if present.
NOMONITORAREA t adds the
area with title
t to unmonitoredAreas,
and removes it from monitoredAreas if present. If
an area is on monitoredAreas it is monitored; if it is on
unmonitoredAreas it is not monitored; if it is on neither list it is
monitored if monitoredAreas is empty. The command MONITORAREA (no
title) clears both lists, in which case all areas are monitored (this is
the default).
The {NO}MONITORMODULE commands are implemented similarly to the
{NO}MONITORAREA commands in that two lists of MODULE names
are maintained,
monitoredModules and unmonitoredModules;
likewise, the {NO}MONITORLIB
commands maintain two lists of library file names,
monitoredLibraries and unmonitoredLibraries.
If a MODULE is on monitoredModules it is monitored; if it is on
unmonitoredModules it is not monitored; if it is on neither list then if
it is from a library in monitoredLibraries it is monitored; if it is
from a library in unmonitoredLibraries it is not monitored; finally, if
it is on none of the lists then it is monitored if unmonitoredLibraries
is not empty or monitoredModules is empty.
Logical file names and searchpaths are not applied to the
file name argument to {NO}MONITORLIB; you must specify the
actual file name.
The command MONITORMODULE (no MODULE names) clears
monitoredModules and unmonitoredModules. The command MONITORLIB (no
library file names) clears monitoredLibraries and unmonitoredLibraries.
If both lists are empty, all MODULEs are monitored (this is the
default). Use MONITORLIB ? to see the name of all currently open
libraries.
When the MONITORLIB command is issued with library name arguments,
it checks whether each library name specified is the name of an already
open library and, if not, attempts to open the library. The library name
arguments to MONITORLIB must therefore be valid library names at the
time the command is given.
By default, MAINPM acts as if the following commands were specified:
That is, the MAINSAIL kernel and the MODULEs shipped in the MAINSAIL
system library are not monitored. This is usually a satisfactory
default; it means that MAINSAIL system MODULEs are not monitored, so
that presumably the only monitored MODULEs are those of your
program.
The commands {NO}MONITORAREA @f,
{NO}MONITORMODULE @f, and
{NO}MONITORLIB @f
open a file named f and read arguments,
one per line, until a blank line or end-of-file is encountered.
This allows a file of area titles, MODULE names, or library names to
be formed for use with MAINPM.
Whenever a dynamic object (or “chunk”)
is allocated in a monitored area,
the runtime system “walks” the PROCEDURE
stack looking for the first
caller in the call chain for a PROCEDURE
in a monitored MODULE (the
PROCEDUREs searched include only those in the current coroutine not
suspended by an exception).
If there is such a PROCEDURE,
the size of the chunk is added to the shallow and deep chunk credited
to the PROCEDURE. If SPACE DEEP was specified,
the stack walk
continues until all monitored PROCEDUREs in the call chain have been
credited with the space usage (only the deep space is
incremented). If the stack is large, e.g., due to many recursive calls,
the deep data gathering may take much longer than the shallow
data gathering; the overall effect on program execution time may
or may not be noticeable.
The deep space for a PROCEDURE p
thus includes all space allocated
by calls in p. Shallow space for
p includes all space allocated by calls
in p as long as there is no other monitored
PROCEDURE “between” the
call and the actual space allocation.
For example, if SPACE DEEP is in
effect, and p calls new(c)
to allocate a dynamic record of the CLASS c
in the default area, and the default area is monitored,
then p's shallow
and deep chunk space are credited with the size of the record. If p
calls a PROCEDURE q,
and q is in a monitored MODULE, and then q
calls new(c), q is credited
with shallow and deep space, and p is
credited with just deep space. If q
is not in a monitored MODULE,
then p is credited with both shallow and deep space.
Space can be credited to p's shallow space even if p does not
directly cause the space to be allocated; it is only necessary that
space be
allocated and there be no other monitored PROCEDURE invoked
(directly or indirectly) from p in the
calling chain. Data allocated by the MAINSAIL runtime system
are also credited to monitored callers.
For example, if a PROCEDURE calls
the MAINSAIL system PROCEDURE sin, and this call causes
the allocation of the bound data section
for the runtime MODULE that contains sin
(i.e., it is the first time a
PROCEDURE has been called in
that MODULE), then any data allocated
(including
the bound data section) are credited to p. Since such behavior is
somewhat unpredictable, it is not always possible to understand
where all the space shown by MAINPM was allocated just by examining
the user program, and there may be
differences from one run to the next if the entire MAINSAIL session
is not duplicated exactly.
The chunks and STRINGs brought into memory by a call to
$structureRead are
included in the chunk and STRING space.
Space credited to a PROCEDURE is not decremented when a garbage
collection reclaims the space.
Decrementing the space counter after the garbage was collected
would defeat the purpose of the statistic, which is
to determine how much STRING garbage you are
generating.
However,
some PROCEDUREs in the MAINSAIL runtime system
(e.g., $reclaim) do deallocate STRINGs in
a way that occasionally shows up as
a negative value for STRING space.
If SPACE is specified, two listings
of shallow chunk and STRING space
are generated, one sorted by chunk
space and the other by STRING space.
If SPACE DEEP is
specified, two listings are generated, one showing
the shallow and deep chunk space
sorted by shallow chunk space, and the
other showing the shallow and deep
STRING space sorted by shallow STRING
space.
In either case, a third listing is generated
of shallow and deep static space, sorted by shallow static space.
Lines for which all space values are zero are omitted from the
listings.
Sample output from the SPACE command is shown in
Examples 8–6 and 8–7. The two tables
differ only by the column on which the data are sorted.
As can be seen, the execution time
is slightly longer for SPACE DEEP
than for just SPACE.
The totals at the end of each listing indicate the total chunk,
STRING, and static
space allocated from the EXECUTE command given to MAINPM until
the return to MAINPM. These totals are generally larger than the
corresponding totals at the bottom of the columns since some allocation
can occur when the monitored MODULEs
have no active PROCEDUREs.
4.1. The {NO}MONITOR Commands
The various forms of the MONITOR command are used to indicate which
areas and MODULEs are to be monitored, if you wish to exercise
fine control over how space is monitored.
The {NO}MONITOR commands have no effect
unless SPACE {DEEP} is also specified.
NOMONITORMODULE $KERMOD $ARYMOD
NOMONITORLIB CONF parameter SYSTEMLIBNAME
4.2. How Chunk, STRING, and Static Space Usage Is Credited to
PROCEDUREs
The discussion below describes how chunk space usage is credited to
a particular PROCEDURE;
however, the discussion also applies to
STRING space and static space, since they
are credited in essentially the same way as chunk space.