Choosing a programming language means accepting how that language manages the allocation and use of memory:

Unfortunately, there is no perfect memory management strategy. Some specialize in faster throughput or more predictable performance. Others are easier-to-use for programmmers and support a broader range of data structures. C's approach gives powerful control to the programmer, but it is inconvenient and offers no memory safety guarantees. So, when a language restricts programs to a single strategy, that may work out for some programs, but it could easily be a poor fit for others.

With Cone, you can do-it-your-way, using the strategy (or mix of strategies!) that best fit the requirements.

Region-based Allocation

Like Cyclone, Cone enables the programmer to choose the memory management strategies a program uses. In effect, available memory is partitioned into regions, each with its own strategy for allocating and freeing memory as needed for data. Every newly-created object names the region that provides its memory. It is the job of each region to decide when it is safe to dispose of its no-longer-accessible objects.

In addition to the global and stack regions, Cone offers a broad range of region strategies for dynamically creating new objects:

Cone also supports borrowed references. A lifetime-constrained borrowed reference can be obtained from any region-allocated reference, or even within an object. They are particularly useful for easily making code polymorphic. Their use can also improves performance, as they require no runtime logic to manage.

Benefits

Cone's versatile regional memory managers give the programmer the power to architect a program's use of memory for optimal throughput and latency, without sacrificing safety, convenience, or data structure flexibility. This powerful region choice can be made on an object-by-object basis.

The performance benefit of region-based memory is particularly important given how many CPU cycles are spent allocating, freeing, copying, and liveness tracking thousands or millions of small data objects in most programs today (not to mention accessing those objects indirectly in cache-unfriendly ways). High-speed strategies (arenas, pools, and single owner) can be used where they are a good fit to a program's data structure and memory use requirements. The slower ref-counting and tracing strategies can then be used for objects that require their flexibility and memory efficiency. Even then, extensive use of borrowed references can significantly minimize the throughput and latency overhead usually experienced with reference counting and tracing.

All of the region strategies are memory safe, even though they use different techniques for ensuring that an object's memory is only reclaimed when all references to it are gone.