Overview
At runtime, Blueprint applications can create a number of heaps.
Each process owns a 'Process Heap' which is transparently managed by the CORE runtime, and cannot be accessed directly by developer code other than through the use of; Transient Store buffers, Arbitrated Store buffers, Active Object workspace, Circuit workspace, and Method state. In the case of distributed applications, the runtime transparently implements a Global Shared Memory (GSM) model which presents the developer with a Single Virtual Process (SVP) view of the world but transparently moves, caches and disposes of data objects that are referenced between process executables. SVP systems have most of the properties of SMP systems but are transparently constructed from multiple processes.
There are occasions however, especially when migrating legacy code, where the standard new/delete operators, STL's containers, and/or low level malloc and free are the mechanisms of choice. However, in multi-core environments all of these mechanisms are prone to suffer from lock contention, and in some circumstances this can result in disappointing performance and an inability to scale. The CORE runtime allows developers to optimize memory Management through the provision of 'thread-specific' heaps. There are no limitations (any active object can delete/free any object that has been allocated by any other active object) but use of this alternative can significantly minimize lock contention, and thus improve performance and load balance.
These issues are addressed at the Blueprint accretion stage. At the highest level, an application's requirement can be designated as 'real-time' or 'off-line', and also 'fast' or 'small'. However, the developer can also specify a number of other specific details such as heap-size and cache-size. In particular developers that require optimal performance can specify particular parameters for the 'Main Thread' (GUI) heap, as well as 'Worker Thread' heaps. Explicit I/O threads can also have their own heaps.
Standard STL, new/delete and malloc/free are still supported and the runtime's memory management is fully .Net compatible. For details of the API see Memory Management API.