Agreed, arena is not the only environment you might want to pass & calling convention is not the problem. The convention is suggested to avoid need to explicitly pass an arena, or use a polymorphic_allocator explicity – arena combines scoped objects with memory collection at the boundary function. The convention is either a hammer to crack a nut, or a strategy to retrofit leak-prevention to existing code (in light of executive order) without the culture change of cppfront or rust.

From: Gašper Ažman <gasper.azman_at_[hidden]>
Sent: Thursday, April 18, 2024 2:36 PM
To: std-proposals_at_[hidden]
Cc: Stephen Channell <steve.channell_at_[hidden]>
Subject: Re: [std-proposals] arenacall convention to avoid rust

The allocator is not the only part of the "environment" you might want to pass down to a function; and Alisdair Meredith has been doing work on allowing this. Calling conventions really aren't the problem.

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2685r1.pdf is the current attempt.

On Thu, Apr 18, 2024 at 2:32 PM Stephen Channell via Std-Proposals <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>> wrote:

The proposal is a half-way house between the current scheme where the heap has unchecked access and compiler-controlled pointers of Rust and C++ code analysis.
It does so by standardizing Arena Allocators and adding a calling convention to pass a reference to the current threads arena.

An example of Arena allocator is provided by google protobuf (https://protobuf.dev/reference/cpp/arenas/) with a similar allocator for LevelDB/derivations and apr_bucket for Apache httpd.

Standardizing the different implementations of Arena allocation would be a worthy endeavor but does not justify the effort on its own but would for memory safety.
    arena alloc = make_unique<std::Arena>();
would indicate that alloc is used as the default arena allocator while it remains in scope.
    std::Arena stored = arena;
Would store the current arena for use by a std::allocator for collections that are part of a larger {session, singleton, configuration}.

arenacall calling convention would extend the AMD64 ABI (where ‘this’ is the first parameter), with the arena as the second parameter, or thiscall convention (where ‘this’ is passed in register) with a register reserved for the arena. The arena would be either the current arena of the caller or ZERO to indicate that no arena is passed.
arenacall functions for memory allocation and free would use the arena pointer for allocation and free if passed, and the CRT heap otherwise.
      void* __arenacall operator new (size_t size);
      void __arenacall operator delete (void* p);
      void __arenacall operator delete[] (void* p);
void* __arenacall malloc(size_t<http://en.cppreference.com/w/cpp/types/size_t> size )
void __arenacall free( void* ptr );


• arenacall is suitable for scenarios where Rust might otherwise be considered, recognizing that Rust functions are normally called from C/C++, and call C/C++ foundation functions and cannot therefore guarantee safety.

• arenacall is suitable for messaging services that would otherwise use a framework specific allocator or arena.

• arenacall is suitable for scenarios where a system allows domain modules to be loaded but requires an elevated level of assurance that they cannot overwrite memory of other modules and do not leak memory.

• arenacall would be faster for methods that allocate many temporary objects –saving heap calls may offset the cost of checked arena assertions.

• arenacall embraces the C++ principle that you do not pay for options you do not choose to use.

--
Std-Proposals mailing list
Std-Proposals_at_lists.isocpp.org<mailto:Std-Proposals_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals