P2013R0
Freestanding Language: Optional ::operator new

1. Revision History

The proposed solution is different than the one proposed for P1105R1, but the motivation is the same. The solution from P1105R1 is still listed as a design alternative.

2. What is changing

As a consequence of the above, coroutines that are relying on the global allocation functions will be ill-formed so long as those global allocation functions are not present.

No other core language features require ::operator new. basic.stc.dynamic.allocation

::operator delete will be implementable as a no-op function on implementations that do not provide a default ::operator new.

3. What is staying the same

Calling ::operator delete on a non-null pointer that did not come from ::operator new is still undefined behavior new.delete.single new.delete.array. Calling delete on an object or base that didn’t come from new is still undefined behavior expr.delete. This is what makes a no-op ::operator delete a valid strategy on implementations without a global ::operator new.

The replaceable allocation functions will still be implicitly declared at global scope in each translation unit basic.stc.dynamic. Non-ODR-uses of the replaceable allocation functions are still permitted (e.g. inside of uninstantiated templates). Implementations of the replaceable allocation functions can be performed by linking in an extra translation-unit with the definitions of the functions. Since this replacement typically happens at link time, ODR-uses of missing replaceable allocation functions usually won’t be diagnosable at compile time.

Hosted implementations are unchanged. Users of freestanding implementations can still provide implementations of the replaceable allocation and deallocation functions. The behavior of virtual destructors is unchanged. The behavior of class specific operator new and operator delete overloads is unchanged. Non-allocating placement ::operator new and ::operator delete are still required to be present. The requirements on user-provided ::operator new and ::operator delete overloads remains the same, particularly those requirements involving error behaviors. Coroutines will behave the same so long as promise-specific allocators are used. The storage for exception objects will remain unspecified.

4. Why?

4.1. No allocations allowed

FreeRTOS allows for both static and dynamic allocation of OS constructs [FreeRTOS_StaticVDynamic]. Static allocation in conjunction with a missing ::operator new can help avoid overhead and eliminate accidental usage.

THREADX [THREADX] does not consider dynamic allocation a core service, and can be built without support for dynamic allocation in order to reduce application size. THREADX also distinguishes between byte allocation (general purpose) vs. block allocation (no-fragmentation elements of fixed size in a pool).

Also, by allowing a no-op ::operator delete implementation, these space constrained applications can save code-size. No code needs to be present for ::operator delete synchronization, free block coalescing, or free block searching.

4.2. No right way to allocate memory

As an example, in the Microsoft Windows kernel environment, there are two leading choices about where to get dynamic memory [MSPools]. Users can get memory from the non-paged pool, which is a safe, but scarce resource; or users can get memory from the paged pool, which is plentiful, but not accessible in many common kernel operations. Non-paged pool must be used any time the allocated memory needs to be accessible from an interrupt or from a "high IRQL" context. The author has had experience with both paged pool and non-paged pool as defaults, with the predictable outcome of crashes with paged pool defaults and OOM with non-paged pool defaults. The implementer of the C++ toolchain is not in a good position to make this choice for the user.

In the Linux kernel environment, kmalloc [kmalloc] with the GFP_KERNEL should be used when allocating memory within the context of a process and outside of a lock, but GFP_ATOMIC should be used when allocating memory outside the context of a process, such as inside of an interrupt. The implementers of the C++ runtime are in no position to know which is the correct flag to use by default. Using GFP_KERNEL when GFP_ATOMIC is needed will result in crashes from interrupt code and deadlocks. Using GFP_ATOMIC when GFP_KERNEL is appropriate will result in reduced system performance, spurious OOM errors, and premature exhaustion of emergency memory pools.

Freestanding implementations are intended to run without the benefit of an operating system (basic.def.odr). However, the name of the function that supplies dynamic memory is usually an OS-specific detail. The C++ implementation should not (and may not) know the name of the function to request memory. The Windows kernel uses ExAllocatePoolWithTag. In the Linux kernel, kmalloc is the main function to use. In FreeBSD, a function named malloc is present, but it takes different arguments than the C standard library function of the same name. FreeRTOS uses pvPortMalloc, and THREADX uses tx_byte_allocate. Home-grown OSes will likely have other spellings for memory allocation routines.

Today’s C++ implementations don’t provide ::operator new implementations for all possible targets. Doing so isn’t a plausible goal, especially when the home-grown OSes are taken into account. This means that users are already forced into choosing between not having ::operator new support and providing their own implementation. We should acknowledge and standardize this existing practice, especially since we already have the extension point mechanism in place.

4.3. What about allocators?

Allocators are still useful in a less-than-minimal freestanding implementation. In environments with dynamic memory, custom allocators can be written and used with standard containers, assuming that the containers are present in the implementation. This could be done even if a global ::operator new is not present. The author has used stlport::vector<int, PagedLockedAllocator> successfully in these environments.

std::allocator is implemented in terms of global ::operator new. In practice, it would be easy for an implementation to have an implementation of std::allocator in a header / module, and have that header still compile just fine, as it wouldn’t ODR-use ::operator new until it was instantiated. If the user has provided a global ::operator new, then std::allocator would have the same semantics as mandated by the standard. If the global ::operator new is not present, then uses of std::allocator would fail to link, which would still be conforming behavior on a freestanding implementation.

Some facilities in the standard library (e.g. make_unique) are implemented in terms of new, and not an allocator interface. It is useful to make these facilities error when dynamic memory isn’t available, and it is also useful to be able to control which memory pool is used by default.

4.4. virtual destructors

Ideally, if neither new nor delete is ever called, we wouldn’t need an operator delete. This proposal still requires some operator delete to exist, though that operator delete can be a no-op.

4.5. Likely misuses and abuses

5. Experience

6. Polling history

Forward P2013 as is with the minor editing quotes

SF/F/N/A/SA

9/10/0/0/0

approves to go to EWG

7. Design Alternatives

7.1. Alternative 0: All-or-nothing allocating ::operator new, no-op default deallocation functions (Proposed above)

7.2. Alternative 1: Optional throwing ::operator news, no-op default deallocation functions

The nothrow_t overloads are specified to forward to an appropriate throwing overload. That implementation would still be fine on a system without dynamic storage available. This alternative was not selected as it is more difficult to teach, and because the target audience would likely be astonished that the nothrow_t overload has a try/catch in it.

7.3. Alternative 2: No deallocation functions

This alternative has the benefit of being zero overhead and very explicit, but it has troublesome consequences for implementations. There are several language support classes that have virtual destructors, and something would need to be decided for them. Notably, type_info and the exception hierarchy all have virtual destructors. The standard library implementers may be prohibited from providing operator new and operator delete overloads (conforming#member.functions). Alternatively, the facilities that require classes with virtual destructors could all be off-limits until operator delete was made available. This would eliminate many cases with exceptions, dynamic_cast on references, and typeid.

If we were to adopt this alternative, many users would provide a no-op ::operator delete in their code, giving their code the same semantics and trade-offs as the proposed solution.

7.3.1. Experience

7.4. Alternative 3: No deallocation functions and new ODR-used rules for virtual destructors

7.4.1. How could this virtual destructor ODR-use change be implemented?

Existing linkers already have the ability to take multiple identical virtual table implementations and pick one for use in the final binary. A potential implementation strategy is for compilers and linkers to support a new "weaker" linkage. When the default heap is disabled, the compiler would emit a vtable with a nullptr or pure virtual function in the virtual destructor slot. When new is called, a "stronger" linkage vtable would be emitted that has the deleting destructor in the virtual destructor slot. The linker would then select a vtable with the strongest linkage available. Today’s linkage would be considered "stronger". Only partially filled vtables would have "weaker" linkage.

7.4.2. ABI impact

Shared libraries are trickier. Vtables aren’t always emitted into every translation unit. Take shared library "leaf" that has a default heap. It depends upon shared library "root" that does not have a default heap. If a class with a virtual destructor is defined in "root", along with its "key function", then a call to new on the class in "leaf" will generate an object with a partial vtable. Calling delete on that object will cause UB (usually crashes).

Lack of a default heap should generally be considered a trait of the platform. Mixing this configuration shouldn’t be a common occurrence.

7.4.3. Experience

8. Acknowledgments