Understanding DVT IDE memory usage

The main goal of this application note is to help you understand the memory usage of DVT.

First, two important concepts involved in memory usage analysis need to be clarified: resident and virtual memory.

Resident Memory

Resident memory usage represents the actual physical memory (RAM) used by an application at a given time. It includes the executable code, the dynamic libraries, and the stack and heap space required by the application during runtime. Resident memory is directly managed by the operating system and is critical for an application’s performance.

Usually, resident memory is computed using the allocated heap size and the additional memory an application consumes during execution (such as memory used by the JVM or other off-heap memory allocation performed by various mechanisms).

You can specify the maximum amount of resident memory that DVT may use via the -heap_size argument of dvt.sh or dvt_cli.sh. The optimal value depends on the project’s size, and is typically determined by an iterative process. The default is 3G.

You can check how much of the heap is used in the Status Bar Heap Indicator. After you trigger a full build of the project, let it finish, and then press the button next to the Heap Indicator (the one that looks like a recycle bin) to force a garbage collection. As a general rule, the heap usage should be around half of the max heap, to allow plenty of headroom for subsequent operations such as incremental builds, diagram generation, refactorings, semantic searches, etc.

Virtual Memory

Virtual memory is an abstraction provided by the operating system that allows an application to virtually access more memory than is physically available. It provides each application with its own virtual address space, which is typically much larger than the available physical memory. The operating system’s memory manager oversees virtual memory, a combination of RAM and disk space, including various system handles, memory-mapped files, and so on. Since some portions of this memory are allocated but remain untouched, the operating system loads only the necessary portions into physical memory, making the overall size of virtual memory largely irrelevant.

For instance, in the following example, a process is using 1.1T of virtual memory, while the total amount of physical memory is less than 38G (Mem+Swp).

As a bottom line, since Virtual Memory is not a limited physical resource, it is not a good measurement for resource allocation or memory profiling.

Note

Virtual memory is responsible for making use of the address space, which is limited to the width of the registers. That limitation is visible on 32-bit processors, as its registers can store up to 2^32 (4GB) of addresses. For that reason, watchdogs were used on 32-bit systems to limit the amount of virtual memory an application can use. This is no longer necessary for current 64-bit processors, which can hold up to 2^64 addresses.