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

There is no one perfect memory management strategy; each has well-known advantages and disadvantages. Some offer faster throughput or more predictable performance, some offer guaranteed memory safety, and others support a broader range of data structures. Such trade-offs make a big difference to the consistent, performance of real-time 3D, particularly when stressed by memory-intensive realistic graphics.

Cone handles memory differently: It gives the choice to the programmer, allowing the memory management strategy to be selected on an object-by-object basis. Making this choice is surprisingly easy: instead of saying "new Point(1., 2.)" to create a new Point object, you say: &gc Point(1., 2.), where &gc means the tracing garbage collection allocator will allocate and manage the lifetime of this new Point object.

Built-in Allocators

Cone supports three common "garbage collection" strategies as built-in allocators:

In addition, Cone provides built-in support for pools and arenas:

Because Cone supports hybridized memory management, the programmer can better optimize performance, latency, safety, and data structure flexibility as best meets the overall needs of a specific program. High-speed strategies (lex, pool, arena) can be used where data structures permit, dramatically reducing the overhead imposed by more flexible, but slower memory strategies (rc or gc) used by the remaining objects. Significant use of lex, for example, might significantly reduce the relevance of the "generational hypothesis", thereby minimizing or eliminating the need for a generational nursery.

Borrowed References

Cone supports Rust-like borrowed references, an important feature that further optimizes performance and polymorphic reuse. Borrowed references are safe because the lifetime of the borrowed reference is guaranteed (by the compiler) to be shorter than the owner reference it borrows from. In effect, the continued live-ness of the owner reference "pins" the object and keeps it alive for at least as long as the lifetime of the borrowed reference.

Cone allows references to be borrowed from any allocator, including rc and gc. Using a borrowed reference, rather than aliasing the rc or gc reference, reduces the runtime overhead of these memory management strategies, as borrowed references are never counted nor traced.