Memory utilization

Another important resource that limits scalability is memory. We, therefore, measured the memory consumed by entities and by queued events in each of the systems. Measuring the memory footprint of entities involves the allocation of $n$ empty entities and observing the size of the operating system process, for a wide range of $n$. In the case of Java, we invoke a garbage collection sweep and then request an internal memory count. Analogously, we queue a large number of events and observe their memory requirements. The entity and event memory results are plotted in Figure 17. The base memory footprint of each of the systems is less than 10 MB. Asymptotically, the process footprint increases linearly with the number of entities or events, as expected.

JiST performs well with respect to memory requirements for simulation entities. It performs comparably with GloMoSim, which uses node aggregation specifically to reduce Parsec's memory consumption. A GloMoSim ``entity'' is merely a heap-allocated object containing an aggregation identifier and an event-scheduling heap. In contrast, each Parsec entity contains its own program counter and logical process stack, the minimum stack size allowed by Parsec being 20 KB. In ns2, we allocate the smallest split object possible, an instance of TclObject, responsible for binding values across the C and Tcl memory spaces. JiST achieves the same dynamic configuration capability without requiring the memory overhead of split objects.

JiST also performs well with respect to event memory requirements. Though they store slightly different data, the C-based ns2 event objects are exactly the same size as JiST events. On the other hand, Tcl-based ns2 events require the allocation of a new split object per event, thus incurring the larger memory overhead above. Parsec events require twice the memory of JiST events.

Figure 17: JiST allocates entities efficiently (at left): comparable to GloMoSim at 36 bytes per entity and over an order of magnitude less that Parsec or ns2. JiST also allocates events efficiently (at right): comparable to ns2 (in C) at 36 bytes per queued event and half the size of events in Parsec and GloMoSim. (*) Events scheduled in ns2 via Tcl will allocate a split object and thereby incur the same memory overhead as entities. The table shows per entity and per event memory overhead, along with the system memory overhead for a simulation scenario of 10,000 nodes, without including memory for any simulation data. (*) Note that the ns2 split object model will affect its memory footprint more adversely than other systems when simulation data is added.

The memory requirements per entity, $mem_{entity}$, and per event, $mem_{event}$, in each of the systems are tabulated in Figure 17. We also compute the memory footprint within each system for a simulation of 10,000 nodes, assuming approximately 10 entities per node and an average of 5 outstanding events per entity. In other words, we compute: $mem_{sim} = 10^4 \times (10 \times mem_{entity} + 50 \times mem_{event})$. Note that these figures do not include the fixed memory base for the process, nor the actual simulation data. These are figures for empty entities and events alone, thus showing the overhead imposed by each system.

Note also that adding simulation data would doubly affect ns2, since it stores data in both the Tcl and C memory spaces. Moreover, Tcl encodes this data internally as strings. The exact memory impact thus varies from simulation to simulation. As a point of reference, regularly published results of a few hundred wireless nodes occupy more than 100 MB and simulation researchers have scaled ns2 to around 1,500 non-wireless nodes using a process with a 2 GB memory footprint [19,16].