ichthyo/LUMIERA.clone
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
LUMIERA.clone/src/lib/allocator-handle.hpp

280 lines
11 KiB
C++
Raw Normal View History

Dispatcher-Pipeline: solve allocation of JobTicket instances ...by defining a new scheme for access to custom allocators ...and then passing a reference to such an accessor into the JobTicket ctor, thereby allowing the ticket istelf recursively to place further JobTicket instances into the allocation space --> success, test passes (finally)
2023-06-11 04:37:38 +02:00
/*
ALLOCATOR-HANDLE.hpp - front-end handle for custom allocation schemes
Copyright (C) Lumiera.org
2023, Hermann Vosseler <Ichthyostega@web.de>
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License as
published by the Free Software Foundation; either version 2 of
the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*/
/** @file allocator-handle.hpp
** A front-end/concept to allow access to custom memory management.
** Minimalistic definition scheme for a functor-like object, which can be
** passed to client code, offering a callback to generate new objects into
** some custom allocation scheme not further disclosed.
**
** Lumiera employs various flavours of custom memory management, to handle
** allocation demands from performance critical parts of the application.
** Irrespective of the actual specifics of the allocation, typically there
** is some _instance_ of an allocator maintained within a carefully crafted
** context — leading to the necessity to dependency-inject a suitable front-end
** into various connected parts of the application, to allow for coherent use
** of allocation while avoiding tight coupling of implementation internals.
**
** Reduced to the bare minimum, the _ability to allocate_ can be represented
** as a functor, which accepts arbitrary (suitable) arguments and returns a
** reference to a newly allocated instance of some specific type; such an
** _allocation front-end_ may then be passed as additional (template)
** parameter to associated classes or functions, allowing to generate new
** objects at stable memory location, which can then be wired internally.
**
** @todo 6/2023 this specification describes a *Concept*, not an actual
** interface type. After the migration to C++20, it will thus be
** possible to mark some arbitrary custom allocator / front-end
** with such a concept, thereby documenting proper API usage.
**
** @see allocation-cluster.hpp
** @see steam::fixture::Segment
** @see steam::engine::JobTicket
*/
#ifndef LIB_ALLOCATOR_HANDLE_H
#define LIB_ALLOCATOR_HANDLE_H
#include "lib/error.hpp"
Library: Uninitialised-Storage array (see #1204) Introduced as remedy for a long standing sloppiness: Using a `char[]` together with `reinterpret_cast` in storage management helpers bears danger of placing objects with wrong alignment; moreover, there are increasing risks that modern code optimisers miss the ''backdoor access'' and might apply too aggressive rewritings. With C++17, there is a standard conformant way to express such a usage scheme. * `lib::UninitialisedStorage` can now be used in a situation (e.g. as in `ExtentFamily`) where a complete block of storage is allocated once and then subsequently used to plant objects one by one * moreover, I went over the code base and adapted the most relevant usages of ''placement-new into buffer'' to also include the `std::launder()` marker
2023-12-02 23:56:46 +01:00
#include <cstddef>
Dispatcher-Pipeline: solve allocation of JobTicket instances ...by defining a new scheme for access to custom allocators ...and then passing a reference to such an accessor into the JobTicket ctor, thereby allowing the ticket istelf recursively to place further JobTicket instances into the allocation space --> success, test passes (finally)
2023-06-11 04:37:38 +02:00
#include <utility>
#include <list>
namespace lib {
Library: adapt `LinkedElements` to use the new `StdFactory` adaptor This is the first validation of the new design: the policy to take ownership can be reimplemented simply by delegating to the adaptor for a C++ standard allocator
2024-05-26 23:54:32 +02:00
namespace allo {///< Concepts and Adaptors for custom memory management
Library: Analysis and planning towards a generic Allocator Concept The following structure can be expected, after __switching to C++20__ * Concept **Allocator** deals with the bare memory allocation * Concept **Factory** handles object creation and disposal by delegation * Concept **Handle** is a ready-made functor for dependency-injection Right now, an implementation of the ''prospective Factory Concept'' can be provided, by delegating through `std::allocator_traits` to a given `std::allocator` or compatible object
2024-05-26 19:31:30 +02:00
/////////////////////////////////////////////////////////////////////////////////////////////////////////TICKET #1366 : define Allocator Concepts here
/// TODO the following Concepts can be expected here (with C++20)
/// - Allocator : for the bare memory allocation
/// - Factory : for object fabrication and disposal
/// - Handle : a functor front-end to be dependency-injected
/**
* Adapter to implement the *Factory* concept based on a `std::allocator`
* @tparam ALO a std::allocator instance or anything compliant to [Allocator]
* [Allocator]: https://en.cppreference.com/w/cpp/named_req/Allocator
* @note in addition to the abilities defined by the standard, this adapter
* strives to provide some kind of _lateral leeway,_ attempting to
* create dedicated allocators for other types than the BaseType
* implied by the given \a ALO (standard-allocator).
* - this is possible if the rebound allocator can be constructed
* from the given base allocator
* - alternatively, an attempt will be made to default-construct
* the rebound allocator for the other type requested.
Library: enable empty-base optimisation for allocator ...this is an important detail: quite commonly, a custom allocator is actually implemented as monostate, to avoid bloating every client container with a backlink pointer; by inheriting the `StdFactory` adapter from the allocator, the empty-base optimisation can be exploited. In the standard case thus LinkedElements is the same size as a single pointer, which is already exploited at several places in the code base. Notably `AllocationCluster` uses a »virtual overlay« to dress-up the position pointer as `LinkedElements`, allowing to delegate most of the administration and memory management to existing and verified code. With this adjustments, `LinkedElements` pass the tests again and the rework of `AllocationCluster` is considered complete.
2024-05-27 19:02:31 +02:00
* @warning Both avenues for adaptation may fail,
* which could lead to compilation or runtime failure.
* @remark deliberately this class inherits from the allocator,
* allowing to exploit empty-base-optimisation, since
* usage of monostate allocators is quite common.
Library: Analysis and planning towards a generic Allocator Concept The following structure can be expected, after __switching to C++20__ * Concept **Allocator** deals with the bare memory allocation * Concept **Factory** handles object creation and disposal by delegation * Concept **Handle** is a ready-made functor for dependency-injection Right now, an implementation of the ''prospective Factory Concept'' can be provided, by delegating through `std::allocator_traits` to a given `std::allocator` or compatible object
2024-05-26 19:31:30 +02:00
*/
template<class ALO>
class StdFactory
Library: enable empty-base optimisation for allocator ...this is an important detail: quite commonly, a custom allocator is actually implemented as monostate, to avoid bloating every client container with a backlink pointer; by inheriting the `StdFactory` adapter from the allocator, the empty-base optimisation can be exploited. In the standard case thus LinkedElements is the same size as a single pointer, which is already exploited at several places in the code base. Notably `AllocationCluster` uses a »virtual overlay« to dress-up the position pointer as `LinkedElements`, allowing to delegate most of the administration and memory management to existing and verified code. With this adjustments, `LinkedElements` pass the tests again and the rework of `AllocationCluster` is considered complete.
2024-05-27 19:02:31 +02:00
: private ALO
Library: Analysis and planning towards a generic Allocator Concept The following structure can be expected, after __switching to C++20__ * Concept **Allocator** deals with the bare memory allocation * Concept **Factory** handles object creation and disposal by delegation * Concept **Handle** is a ready-made functor for dependency-injection Right now, an implementation of the ''prospective Factory Concept'' can be provided, by delegating through `std::allocator_traits` to a given `std::allocator` or compatible object
2024-05-26 19:31:30 +02:00
{
using Allo = ALO;
using AlloT = std::allocator_traits<Allo>;
using BaseType = typename Allo::value_type;
Library: enable empty-base optimisation for allocator ...this is an important detail: quite commonly, a custom allocator is actually implemented as monostate, to avoid bloating every client container with a backlink pointer; by inheriting the `StdFactory` adapter from the allocator, the empty-base optimisation can be exploited. In the standard case thus LinkedElements is the same size as a single pointer, which is already exploited at several places in the code base. Notably `AllocationCluster` uses a »virtual overlay« to dress-up the position pointer as `LinkedElements`, allowing to delegate most of the administration and memory management to existing and verified code. With this adjustments, `LinkedElements` pass the tests again and the rework of `AllocationCluster` is considered complete.
2024-05-27 19:02:31 +02:00
Allo& baseAllocator() { return *this; }
Library: Analysis and planning towards a generic Allocator Concept The following structure can be expected, after __switching to C++20__ * Concept **Allocator** deals with the bare memory allocation * Concept **Factory** handles object creation and disposal by delegation * Concept **Handle** is a ready-made functor for dependency-injection Right now, an implementation of the ''prospective Factory Concept'' can be provided, by delegating through `std::allocator_traits` to a given `std::allocator` or compatible object
2024-05-26 19:31:30 +02:00
template<typename X>
auto
Library: enable empty-base optimisation for allocator ...this is an important detail: quite commonly, a custom allocator is actually implemented as monostate, to avoid bloating every client container with a backlink pointer; by inheriting the `StdFactory` adapter from the allocator, the empty-base optimisation can be exploited. In the standard case thus LinkedElements is the same size as a single pointer, which is already exploited at several places in the code base. Notably `AllocationCluster` uses a »virtual overlay« to dress-up the position pointer as `LinkedElements`, allowing to delegate most of the administration and memory management to existing and verified code. With this adjustments, `LinkedElements` pass the tests again and the rework of `AllocationCluster` is considered complete.
2024-05-27 19:02:31 +02:00
adaptAllocator()
Library: Analysis and planning towards a generic Allocator Concept The following structure can be expected, after __switching to C++20__ * Concept **Allocator** deals with the bare memory allocation * Concept **Factory** handles object creation and disposal by delegation * Concept **Handle** is a ready-made functor for dependency-injection Right now, an implementation of the ''prospective Factory Concept'' can be provided, by delegating through `std::allocator_traits` to a given `std::allocator` or compatible object
2024-05-26 19:31:30 +02:00
{
using XAllo = typename AlloT::template rebind_alloc<X>;
if constexpr (std::is_constructible_v<XAllo, Allo>)
Library: enable empty-base optimisation for allocator ...this is an important detail: quite commonly, a custom allocator is actually implemented as monostate, to avoid bloating every client container with a backlink pointer; by inheriting the `StdFactory` adapter from the allocator, the empty-base optimisation can be exploited. In the standard case thus LinkedElements is the same size as a single pointer, which is already exploited at several places in the code base. Notably `AllocationCluster` uses a »virtual overlay« to dress-up the position pointer as `LinkedElements`, allowing to delegate most of the administration and memory management to existing and verified code. With this adjustments, `LinkedElements` pass the tests again and the rework of `AllocationCluster` is considered complete.
2024-05-27 19:02:31 +02:00
return XAllo{baseAllocator()};
Library: Analysis and planning towards a generic Allocator Concept The following structure can be expected, after __switching to C++20__ * Concept **Allocator** deals with the bare memory allocation * Concept **Factory** handles object creation and disposal by delegation * Concept **Handle** is a ready-made functor for dependency-injection Right now, an implementation of the ''prospective Factory Concept'' can be provided, by delegating through `std::allocator_traits` to a given `std::allocator` or compatible object
2024-05-26 19:31:30 +02:00
else
Library: enable empty-base optimisation for allocator ...this is an important detail: quite commonly, a custom allocator is actually implemented as monostate, to avoid bloating every client container with a backlink pointer; by inheriting the `StdFactory` adapter from the allocator, the empty-base optimisation can be exploited. In the standard case thus LinkedElements is the same size as a single pointer, which is already exploited at several places in the code base. Notably `AllocationCluster` uses a »virtual overlay« to dress-up the position pointer as `LinkedElements`, allowing to delegate most of the administration and memory management to existing and verified code. With this adjustments, `LinkedElements` pass the tests again and the rework of `AllocationCluster` is considered complete.
2024-05-27 19:02:31 +02:00
return XAllo{};
Library: Analysis and planning towards a generic Allocator Concept The following structure can be expected, after __switching to C++20__ * Concept **Allocator** deals with the bare memory allocation * Concept **Factory** handles object creation and disposal by delegation * Concept **Handle** is a ready-made functor for dependency-injection Right now, an implementation of the ''prospective Factory Concept'' can be provided, by delegating through `std::allocator_traits` to a given `std::allocator` or compatible object
2024-05-26 19:31:30 +02:00
}
template<class ALOT, typename...ARGS>
typename ALOT::pointer
Library: adapt `LinkedElements` to use the new `StdFactory` adaptor This is the first validation of the new design: the policy to take ownership can be reimplemented simply by delegating to the adaptor for a C++ standard allocator
2024-05-26 23:54:32 +02:00
construct (typename ALOT::allocator_type& allo, ARGS&& ...args)
Library: Analysis and planning towards a generic Allocator Concept The following structure can be expected, after __switching to C++20__ * Concept **Allocator** deals with the bare memory allocation * Concept **Factory** handles object creation and disposal by delegation * Concept **Handle** is a ready-made functor for dependency-injection Right now, an implementation of the ''prospective Factory Concept'' can be provided, by delegating through `std::allocator_traits` to a given `std::allocator` or compatible object
2024-05-26 19:31:30 +02:00
{
Library: adapt `LinkedElements` to use the new `StdFactory` adaptor This is the first validation of the new design: the policy to take ownership can be reimplemented simply by delegating to the adaptor for a C++ standard allocator
2024-05-26 23:54:32 +02:00
auto loc = ALOT::allocate (allo, 1);
Library: adapt further `AllocationCluster` tests ...especially demonstrate that destructors can optionally be invoked or not invoked...
2024-05-27 21:21:03 +02:00
try { ALOT::construct (allo, loc, std::forward<ARGS>(args)...); }
catch(...)
{
ALOT::deallocate (allo, loc, 1);
throw;
}
Library: Analysis and planning towards a generic Allocator Concept The following structure can be expected, after __switching to C++20__ * Concept **Allocator** deals with the bare memory allocation * Concept **Factory** handles object creation and disposal by delegation * Concept **Handle** is a ready-made functor for dependency-injection Right now, an implementation of the ''prospective Factory Concept'' can be provided, by delegating through `std::allocator_traits` to a given `std::allocator` or compatible object
2024-05-26 19:31:30 +02:00
return loc;
}
Library: adapt `LinkedElements` to use the new `StdFactory` adaptor This is the first validation of the new design: the policy to take ownership can be reimplemented simply by delegating to the adaptor for a C++ standard allocator
2024-05-26 23:54:32 +02:00
template<class ALOT>
Library: Analysis and planning towards a generic Allocator Concept The following structure can be expected, after __switching to C++20__ * Concept **Allocator** deals with the bare memory allocation * Concept **Factory** handles object creation and disposal by delegation * Concept **Handle** is a ready-made functor for dependency-injection Right now, an implementation of the ''prospective Factory Concept'' can be provided, by delegating through `std::allocator_traits` to a given `std::allocator` or compatible object
2024-05-26 19:31:30 +02:00
void
Library: adapt `LinkedElements` to use the new `StdFactory` adaptor This is the first validation of the new design: the policy to take ownership can be reimplemented simply by delegating to the adaptor for a C++ standard allocator
2024-05-26 23:54:32 +02:00
destroy (typename ALOT::allocator_type& allo, typename ALOT::pointer elm)
Library: Analysis and planning towards a generic Allocator Concept The following structure can be expected, after __switching to C++20__ * Concept **Allocator** deals with the bare memory allocation * Concept **Factory** handles object creation and disposal by delegation * Concept **Handle** is a ready-made functor for dependency-injection Right now, an implementation of the ''prospective Factory Concept'' can be provided, by delegating through `std::allocator_traits` to a given `std::allocator` or compatible object
2024-05-26 19:31:30 +02:00
{
ALOT::destroy (allo, elm);
ALOT::deallocate (allo, elm, 1);
}
public:
/**
* Create an instance of the adapter factory,
* forwarding to the embedded standard conforming allocator
* for object creation and destruction and memory management.
* @param allo (optional) instance of the C++ standard allocator
* used for delegation, will be default constructed if omitted.
* @remark the adapted standard allocator is assumed to be either a copyable
* value object, or even a mono-state; in both cases, a dedicated
* manager instance residing »elsewhere« is referred, rendering
* all those front-end instances exchangeable.
*/
StdFactory (Allo allo = Allo{})
Library: enable empty-base optimisation for allocator ...this is an important detail: quite commonly, a custom allocator is actually implemented as monostate, to avoid bloating every client container with a backlink pointer; by inheriting the `StdFactory` adapter from the allocator, the empty-base optimisation can be exploited. In the standard case thus LinkedElements is the same size as a single pointer, which is already exploited at several places in the code base. Notably `AllocationCluster` uses a »virtual overlay« to dress-up the position pointer as `LinkedElements`, allowing to delegate most of the administration and memory management to existing and verified code. With this adjustments, `LinkedElements` pass the tests again and the rework of `AllocationCluster` is considered complete.
2024-05-27 19:02:31 +02:00
: Allo{std::move (allo)}
Library: Analysis and planning towards a generic Allocator Concept The following structure can be expected, after __switching to C++20__ * Concept **Allocator** deals with the bare memory allocation * Concept **Factory** handles object creation and disposal by delegation * Concept **Handle** is a ready-made functor for dependency-injection Right now, an implementation of the ''prospective Factory Concept'' can be provided, by delegating through `std::allocator_traits` to a given `std::allocator` or compatible object
2024-05-26 19:31:30 +02:00
{ }
template<class XALO>
bool constexpr operator== (StdFactory<XALO> const& o) const
{
Library: enable empty-base optimisation for allocator ...this is an important detail: quite commonly, a custom allocator is actually implemented as monostate, to avoid bloating every client container with a backlink pointer; by inheriting the `StdFactory` adapter from the allocator, the empty-base optimisation can be exploited. In the standard case thus LinkedElements is the same size as a single pointer, which is already exploited at several places in the code base. Notably `AllocationCluster` uses a »virtual overlay« to dress-up the position pointer as `LinkedElements`, allowing to delegate most of the administration and memory management to existing and verified code. With this adjustments, `LinkedElements` pass the tests again and the rework of `AllocationCluster` is considered complete.
2024-05-27 19:02:31 +02:00
return baseAllocator() == o.baseAllocator();
Library: Analysis and planning towards a generic Allocator Concept The following structure can be expected, after __switching to C++20__ * Concept **Allocator** deals with the bare memory allocation * Concept **Factory** handles object creation and disposal by delegation * Concept **Handle** is a ready-made functor for dependency-injection Right now, an implementation of the ''prospective Factory Concept'' can be provided, by delegating through `std::allocator_traits` to a given `std::allocator` or compatible object
2024-05-26 19:31:30 +02:00
}
template<class XALO>
bool constexpr operator!= (StdFactory<XALO> const& o) const
{
Library: enable empty-base optimisation for allocator ...this is an important detail: quite commonly, a custom allocator is actually implemented as monostate, to avoid bloating every client container with a backlink pointer; by inheriting the `StdFactory` adapter from the allocator, the empty-base optimisation can be exploited. In the standard case thus LinkedElements is the same size as a single pointer, which is already exploited at several places in the code base. Notably `AllocationCluster` uses a »virtual overlay« to dress-up the position pointer as `LinkedElements`, allowing to delegate most of the administration and memory management to existing and verified code. With this adjustments, `LinkedElements` pass the tests again and the rework of `AllocationCluster` is considered complete.
2024-05-27 19:02:31 +02:00
return not (*this == o);
Library: Analysis and planning towards a generic Allocator Concept The following structure can be expected, after __switching to C++20__ * Concept **Allocator** deals with the bare memory allocation * Concept **Factory** handles object creation and disposal by delegation * Concept **Handle** is a ready-made functor for dependency-injection Right now, an implementation of the ''prospective Factory Concept'' can be provided, by delegating through `std::allocator_traits` to a given `std::allocator` or compatible object
2024-05-26 19:31:30 +02:00
}
/** create new element using the embedded allocator */
template<class TY, typename...ARGS>
TY*
create (ARGS&& ...args)
{
if constexpr (std::is_same_v<TY, BaseType>)
{
Library: enable empty-base optimisation for allocator ...this is an important detail: quite commonly, a custom allocator is actually implemented as monostate, to avoid bloating every client container with a backlink pointer; by inheriting the `StdFactory` adapter from the allocator, the empty-base optimisation can be exploited. In the standard case thus LinkedElements is the same size as a single pointer, which is already exploited at several places in the code base. Notably `AllocationCluster` uses a »virtual overlay« to dress-up the position pointer as `LinkedElements`, allowing to delegate most of the administration and memory management to existing and verified code. With this adjustments, `LinkedElements` pass the tests again and the rework of `AllocationCluster` is considered complete.
2024-05-27 19:02:31 +02:00
return construct<AlloT> (baseAllocator(), std::forward<ARGS>(args)...);
Library: Analysis and planning towards a generic Allocator Concept The following structure can be expected, after __switching to C++20__ * Concept **Allocator** deals with the bare memory allocation * Concept **Factory** handles object creation and disposal by delegation * Concept **Handle** is a ready-made functor for dependency-injection Right now, an implementation of the ''prospective Factory Concept'' can be provided, by delegating through `std::allocator_traits` to a given `std::allocator` or compatible object
2024-05-26 19:31:30 +02:00
}
else
{
using XAlloT = typename AlloT::template rebind_traits<TY>;
Library: enable empty-base optimisation for allocator ...this is an important detail: quite commonly, a custom allocator is actually implemented as monostate, to avoid bloating every client container with a backlink pointer; by inheriting the `StdFactory` adapter from the allocator, the empty-base optimisation can be exploited. In the standard case thus LinkedElements is the same size as a single pointer, which is already exploited at several places in the code base. Notably `AllocationCluster` uses a »virtual overlay« to dress-up the position pointer as `LinkedElements`, allowing to delegate most of the administration and memory management to existing and verified code. With this adjustments, `LinkedElements` pass the tests again and the rework of `AllocationCluster` is considered complete.
2024-05-27 19:02:31 +02:00
auto xAllo = adaptAllocator<TY>();
Library: Analysis and planning towards a generic Allocator Concept The following structure can be expected, after __switching to C++20__ * Concept **Allocator** deals with the bare memory allocation * Concept **Factory** handles object creation and disposal by delegation * Concept **Handle** is a ready-made functor for dependency-injection Right now, an implementation of the ''prospective Factory Concept'' can be provided, by delegating through `std::allocator_traits` to a given `std::allocator` or compatible object
2024-05-26 19:31:30 +02:00
return construct<XAlloT> (xAllo, std::forward<ARGS>(args)...);
}
}
/** destroy the given element and discard the associated memory */
template<class TY>
void
dispose (TY* elm)
{
if constexpr (std::is_same_v<TY, BaseType>)
{
Library: enable empty-base optimisation for allocator ...this is an important detail: quite commonly, a custom allocator is actually implemented as monostate, to avoid bloating every client container with a backlink pointer; by inheriting the `StdFactory` adapter from the allocator, the empty-base optimisation can be exploited. In the standard case thus LinkedElements is the same size as a single pointer, which is already exploited at several places in the code base. Notably `AllocationCluster` uses a »virtual overlay« to dress-up the position pointer as `LinkedElements`, allowing to delegate most of the administration and memory management to existing and verified code. With this adjustments, `LinkedElements` pass the tests again and the rework of `AllocationCluster` is considered complete.
2024-05-27 19:02:31 +02:00
destroy<AlloT> (baseAllocator(), elm);
Library: Analysis and planning towards a generic Allocator Concept The following structure can be expected, after __switching to C++20__ * Concept **Allocator** deals with the bare memory allocation * Concept **Factory** handles object creation and disposal by delegation * Concept **Handle** is a ready-made functor for dependency-injection Right now, an implementation of the ''prospective Factory Concept'' can be provided, by delegating through `std::allocator_traits` to a given `std::allocator` or compatible object
2024-05-26 19:31:30 +02:00
}
else
{
using XAlloT = typename AlloT::template rebind_traits<TY>;
Library: enable empty-base optimisation for allocator ...this is an important detail: quite commonly, a custom allocator is actually implemented as monostate, to avoid bloating every client container with a backlink pointer; by inheriting the `StdFactory` adapter from the allocator, the empty-base optimisation can be exploited. In the standard case thus LinkedElements is the same size as a single pointer, which is already exploited at several places in the code base. Notably `AllocationCluster` uses a »virtual overlay« to dress-up the position pointer as `LinkedElements`, allowing to delegate most of the administration and memory management to existing and verified code. With this adjustments, `LinkedElements` pass the tests again and the rework of `AllocationCluster` is considered complete.
2024-05-27 19:02:31 +02:00
auto xAllo = adaptAllocator<TY>();
Library: Analysis and planning towards a generic Allocator Concept The following structure can be expected, after __switching to C++20__ * Concept **Allocator** deals with the bare memory allocation * Concept **Factory** handles object creation and disposal by delegation * Concept **Handle** is a ready-made functor for dependency-injection Right now, an implementation of the ''prospective Factory Concept'' can be provided, by delegating through `std::allocator_traits` to a given `std::allocator` or compatible object
2024-05-26 19:31:30 +02:00
destroy<XAlloT> (xAllo, elm);
}
}
};
}
Dispatcher-Pipeline: solve allocation of JobTicket instances ...by defining a new scheme for access to custom allocators ...and then passing a reference to such an accessor into the JobTicket ctor, thereby allowing the ticket istelf recursively to place further JobTicket instances into the allocation space --> success, test passes (finally)
2023-06-11 04:37:38 +02:00
Library: Analysis and planning towards a generic Allocator Concept The following structure can be expected, after __switching to C++20__ * Concept **Allocator** deals with the bare memory allocation * Concept **Factory** handles object creation and disposal by delegation * Concept **Handle** is a ready-made functor for dependency-injection Right now, an implementation of the ''prospective Factory Concept'' can be provided, by delegating through `std::allocator_traits` to a given `std::allocator` or compatible object
2024-05-26 19:31:30 +02:00
///////////////////////////////////////////////////////////////////////////////////////////////////////////TICKET #1366 : the following code becomes obsolete in the long term
Dispatcher-Pipeline: solve allocation of JobTicket instances ...by defining a new scheme for access to custom allocators ...and then passing a reference to such an accessor into the JobTicket ctor, thereby allowing the ticket istelf recursively to place further JobTicket instances into the allocation space --> success, test passes (finally)
2023-06-11 04:37:38 +02:00
/**
* Placeholder implementation for a custom allocator
* @todo shall be replaced by an AllocationCluster eventually
Library: Analysis and planning towards a generic Allocator Concept The following structure can be expected, after __switching to C++20__ * Concept **Allocator** deals with the bare memory allocation * Concept **Factory** handles object creation and disposal by delegation * Concept **Handle** is a ready-made functor for dependency-injection Right now, an implementation of the ''prospective Factory Concept'' can be provided, by delegating through `std::allocator_traits` to a given `std::allocator` or compatible object
2024-05-26 19:31:30 +02:00
* @todo 5/2024 to be reworked and aligned with a prospective C++20 Allocator Concept /////////////////////TICKET #1366
Dispatcher-Pipeline: solve allocation of JobTicket instances ...by defining a new scheme for access to custom allocators ...and then passing a reference to such an accessor into the JobTicket ctor, thereby allowing the ticket istelf recursively to place further JobTicket instances into the allocation space --> success, test passes (finally)
2023-06-11 04:37:38 +02:00
* @remark using `std::list` container, since re-entrant allocation calls are possible,
Dispatcher-Pipeline: resolve further problems with re-entrant allocation ...ouch this was insidious: the STL implementation for list does not return a pointer to the element just allocated, but rather retrieves and dereferences the back() / front() iterator after returning from emplace_back|front() ...which in case of re-entrant allocations is something wildly different than the initial allocation. Thus a *cheap* and dirty placeholder implementation just using a STL container is not possible, and we need at least to code up likewise cheesy placeholder implementation by hand. - separate allocation and ctor all - use an inline buffer in the STL container - explicitly handle ctor failures to discard allocation - NOT THREADSAFE and likely WASTFUL in terms of performance ==> MockSupport_test now back to GREEN after complete refactoring
2023-06-12 17:21:41 +02:00
* meaning that further allocations will be requested recursively from a ctor.
* Moreover, for the same reason we separate the allocation from the ctor call,
* so we can capture the address of the new allocation prior to any possible
* re-entrant call, and handle clean-up of allocation without requiring any
* additional state flags.....
Dispatcher-Pipeline: solve allocation of JobTicket instances ...by defining a new scheme for access to custom allocators ...and then passing a reference to such an accessor into the JobTicket ctor, thereby allowing the ticket istelf recursively to place further JobTicket instances into the allocation space --> success, test passes (finally)
2023-06-11 04:37:38 +02:00
*/
Dispatcher-Pipeline: resolve further problems with re-entrant allocation ...ouch this was insidious: the STL implementation for list does not return a pointer to the element just allocated, but rather retrieves and dereferences the back() / front() iterator after returning from emplace_back|front() ...which in case of re-entrant allocations is something wildly different than the initial allocation. Thus a *cheap* and dirty placeholder implementation just using a STL container is not possible, and we need at least to code up likewise cheesy placeholder implementation by hand. - separate allocation and ctor all - use an inline buffer in the STL container - explicitly handle ctor failures to discard allocation - NOT THREADSAFE and likely WASTFUL in terms of performance ==> MockSupport_test now back to GREEN after complete refactoring
2023-06-12 17:21:41 +02:00
template<typename TY>
Dispatcher-Pipeline: solve allocation of JobTicket instances ...by defining a new scheme for access to custom allocators ...and then passing a reference to such an accessor into the JobTicket ctor, thereby allowing the ticket istelf recursively to place further JobTicket instances into the allocation space --> success, test passes (finally)
2023-06-11 04:37:38 +02:00
class AllocatorHandle
{
Dispatcher-Pipeline: resolve further problems with re-entrant allocation ...ouch this was insidious: the STL implementation for list does not return a pointer to the element just allocated, but rather retrieves and dereferences the back() / front() iterator after returning from emplace_back|front() ...which in case of re-entrant allocations is something wildly different than the initial allocation. Thus a *cheap* and dirty placeholder implementation just using a STL container is not possible, and we need at least to code up likewise cheesy placeholder implementation by hand. - separate allocation and ctor all - use an inline buffer in the STL container - explicitly handle ctor failures to discard allocation - NOT THREADSAFE and likely WASTFUL in terms of performance ==> MockSupport_test now back to GREEN after complete refactoring
2023-06-12 17:21:41 +02:00
struct Allocation
{
Library: Uninitialised-Storage array (see #1204) Introduced as remedy for a long standing sloppiness: Using a `char[]` together with `reinterpret_cast` in storage management helpers bears danger of placing objects with wrong alignment; moreover, there are increasing risks that modern code optimisers miss the ''backdoor access'' and might apply too aggressive rewritings. With C++17, there is a standard conformant way to express such a usage scheme. * `lib::UninitialisedStorage` can now be used in a situation (e.g. as in `ExtentFamily`) where a complete block of storage is allocated once and then subsequently used to plant objects one by one * moreover, I went over the code base and adapted the most relevant usages of ''placement-new into buffer'' to also include the `std::launder()` marker
2023-12-02 23:56:46 +01:00
alignas(TY)
std::byte buf_[sizeof(TY)];
Dispatcher-Pipeline: resolve further problems with re-entrant allocation ...ouch this was insidious: the STL implementation for list does not return a pointer to the element just allocated, but rather retrieves and dereferences the back() / front() iterator after returning from emplace_back|front() ...which in case of re-entrant allocations is something wildly different than the initial allocation. Thus a *cheap* and dirty placeholder implementation just using a STL container is not possible, and we need at least to code up likewise cheesy placeholder implementation by hand. - separate allocation and ctor all - use an inline buffer in the STL container - explicitly handle ctor failures to discard allocation - NOT THREADSAFE and likely WASTFUL in terms of performance ==> MockSupport_test now back to GREEN after complete refactoring
2023-06-12 17:21:41 +02:00
template<typename...ARGS>
TY&
create (ARGS&& ...args)
{
return *new(&buf_) TY {std::forward<ARGS> (args)...};
}
TY&
access()
{
Library: Uninitialised-Storage array (see #1204) Introduced as remedy for a long standing sloppiness: Using a `char[]` together with `reinterpret_cast` in storage management helpers bears danger of placing objects with wrong alignment; moreover, there are increasing risks that modern code optimisers miss the ''backdoor access'' and might apply too aggressive rewritings. With C++17, there is a standard conformant way to express such a usage scheme. * `lib::UninitialisedStorage` can now be used in a situation (e.g. as in `ExtentFamily`) where a complete block of storage is allocated once and then subsequently used to plant objects one by one * moreover, I went over the code base and adapted the most relevant usages of ''placement-new into buffer'' to also include the `std::launder()` marker
2023-12-02 23:56:46 +01:00
return * std::launder (reinterpret_cast<TY*> (&buf_));
Dispatcher-Pipeline: resolve further problems with re-entrant allocation ...ouch this was insidious: the STL implementation for list does not return a pointer to the element just allocated, but rather retrieves and dereferences the back() / front() iterator after returning from emplace_back|front() ...which in case of re-entrant allocations is something wildly different than the initial allocation. Thus a *cheap* and dirty placeholder implementation just using a STL container is not possible, and we need at least to code up likewise cheesy placeholder implementation by hand. - separate allocation and ctor all - use an inline buffer in the STL container - explicitly handle ctor failures to discard allocation - NOT THREADSAFE and likely WASTFUL in terms of performance ==> MockSupport_test now back to GREEN after complete refactoring
2023-06-12 17:21:41 +02:00
}
void
Library: Analysis and planning towards a generic Allocator Concept The following structure can be expected, after __switching to C++20__ * Concept **Allocator** deals with the bare memory allocation * Concept **Factory** handles object creation and disposal by delegation * Concept **Handle** is a ready-made functor for dependency-injection Right now, an implementation of the ''prospective Factory Concept'' can be provided, by delegating through `std::allocator_traits` to a given `std::allocator` or compatible object
2024-05-26 19:31:30 +02:00
discard() /// @warning strong assumption made here: Payload was created
Dispatcher-Pipeline: resolve further problems with re-entrant allocation ...ouch this was insidious: the STL implementation for list does not return a pointer to the element just allocated, but rather retrieves and dereferences the back() / front() iterator after returning from emplace_back|front() ...which in case of re-entrant allocations is something wildly different than the initial allocation. Thus a *cheap* and dirty placeholder implementation just using a STL container is not possible, and we need at least to code up likewise cheesy placeholder implementation by hand. - separate allocation and ctor all - use an inline buffer in the STL container - explicitly handle ctor failures to discard allocation - NOT THREADSAFE and likely WASTFUL in terms of performance ==> MockSupport_test now back to GREEN after complete refactoring
2023-06-12 17:21:41 +02:00
{
access().~TY();
}
};
std::list<Allocation> storage_;
Dispatcher-Pipeline: solve allocation of JobTicket instances ...by defining a new scheme for access to custom allocators ...and then passing a reference to such an accessor into the JobTicket ctor, thereby allowing the ticket istelf recursively to place further JobTicket instances into the allocation space --> success, test passes (finally)
2023-06-11 04:37:38 +02:00
public:
template<typename...ARGS>
Dispatcher-Pipeline: resolve further problems with re-entrant allocation ...ouch this was insidious: the STL implementation for list does not return a pointer to the element just allocated, but rather retrieves and dereferences the back() / front() iterator after returning from emplace_back|front() ...which in case of re-entrant allocations is something wildly different than the initial allocation. Thus a *cheap* and dirty placeholder implementation just using a STL container is not possible, and we need at least to code up likewise cheesy placeholder implementation by hand. - separate allocation and ctor all - use an inline buffer in the STL container - explicitly handle ctor failures to discard allocation - NOT THREADSAFE and likely WASTFUL in terms of performance ==> MockSupport_test now back to GREEN after complete refactoring
2023-06-12 17:21:41 +02:00
TY&
Dispatcher-Pipeline: solve allocation of JobTicket instances ...by defining a new scheme for access to custom allocators ...and then passing a reference to such an accessor into the JobTicket ctor, thereby allowing the ticket istelf recursively to place further JobTicket instances into the allocation space --> success, test passes (finally)
2023-06-11 04:37:38 +02:00
operator() (ARGS&& ...args)
Dispatcher-Pipeline: resolve further problems with re-entrant allocation ...ouch this was insidious: the STL implementation for list does not return a pointer to the element just allocated, but rather retrieves and dereferences the back() / front() iterator after returning from emplace_back|front() ...which in case of re-entrant allocations is something wildly different than the initial allocation. Thus a *cheap* and dirty placeholder implementation just using a STL container is not possible, and we need at least to code up likewise cheesy placeholder implementation by hand. - separate allocation and ctor all - use an inline buffer in the STL container - explicitly handle ctor failures to discard allocation - NOT THREADSAFE and likely WASTFUL in terms of performance ==> MockSupport_test now back to GREEN after complete refactoring
2023-06-12 17:21:41 +02:00
{ // EX_STRONG
auto pos = storage_.emplace (storage_.end()); ////////////////////////////////////////////////////TICKET #230 : real implementation should care for concurrency here
try {
return pos->create (std::forward<ARGS> (args)...);
}
catch(...)
{
storage_.erase (pos); // EX_FREE
const char* errID = lumiera_error();
ERROR (memory, "Allocation failed with unknown exception. "
"Lumiera errorID=%s", errID?errID:"??");
throw;
}
Dispatcher-Pipeline: solve allocation of JobTicket instances ...by defining a new scheme for access to custom allocators ...and then passing a reference to such an accessor into the JobTicket ctor, thereby allowing the ticket istelf recursively to place further JobTicket instances into the allocation space --> success, test passes (finally)
2023-06-11 04:37:38 +02:00
}
Dispatcher-Pipeline: resolve further problems with re-entrant allocation ...ouch this was insidious: the STL implementation for list does not return a pointer to the element just allocated, but rather retrieves and dereferences the back() / front() iterator after returning from emplace_back|front() ...which in case of re-entrant allocations is something wildly different than the initial allocation. Thus a *cheap* and dirty placeholder implementation just using a STL container is not possible, and we need at least to code up likewise cheesy placeholder implementation by hand. - separate allocation and ctor all - use an inline buffer in the STL container - explicitly handle ctor failures to discard allocation - NOT THREADSAFE and likely WASTFUL in terms of performance ==> MockSupport_test now back to GREEN after complete refactoring
2023-06-12 17:21:41 +02:00
/** @note need to do explicit clean-up, since a ctor-call might have been failed,
* and we have no simple way to record this fact internally in Allocation,
* short of wasting additional memory for a flag to mark this situation */
~AllocatorHandle()
try {
for (auto& alloc : storage_)
alloc.discard();
}
ERROR_LOG_AND_IGNORE (memory, "clean-up of custom AllocatorHandle")
Dispatcher-Pipeline: solve allocation of JobTicket instances ...by defining a new scheme for access to custom allocators ...and then passing a reference to such an accessor into the JobTicket ctor, thereby allowing the ticket istelf recursively to place further JobTicket instances into the allocation space --> success, test passes (finally)
2023-06-11 04:37:38 +02:00
};
} // namespace lib
#endif /*LIB_ALLOCATOR_HANDLE_H*/
Reference in a new issue Copy permalink