GitLab

As we cannot find out in advance the binding an area uses, it is not
possible to use a correctly allocated pointer to aml_area_binding.

Fixes a segfault we observed outside of current unit-tests.

Allows memory movement logic to ask a target area how memory should be
bound to it.

Note that it would be safer in the long term to have areas take a
binding at creation time, and translate to nodemasks internally.

This is the result of countless interations on the internal design of
the various building blocks we want to have for this library.

At this point, I hope that this is stable enough. There are still some
tweaks needed here and there, but the core is implemented AND tested.

Some of the design decisions made:
- all functions are public, but most are not meant to be used directly.
- intended public functions take "generic" structs as arguments
- intended actual implementations rely on more complex structures, with
their own family of data and operators.
- split all objects between data and operator structs.

Exemple:
- area.c and arena.c are generic dispatch functions to call the actual,
  specific implementations.
- struct aml_area and struct_aml_arena are the same.

Currently implement:
- 2 area types: posix (malloc) and linux (numa).
- 1 arena type: jemalloc

This is a redesign of the library, as a hierarchy of core objects
implementing its various features. The idea is to create an API that is
as flexible and customizable as possible, by exposing as much as
possible of its internals, so that users can create customs versions
easily.

We also move away from memkind as a possible backend, opting instead to
vendor the jemalloc interface and implement everything ourselves on top
of that.

We expect to start building the low-level pieces using hwloc as a
backend soon, at least in terms of accessing available devices.

This is a rewrite of the existing code into a memory library exposing
more of its internal abstractions. This refactoring is required to:
- make progress faster by focusing on the core new features
- abstract more of the underlying components and expose those
abstractions
- build upon existing libraries (memkind) for the internal stuff.

Memkind is used as a crutch here, we do not intend to use it in the long
term, as some of its internal are opposed to what we want (topology
management in particular).

Nevertheless, it currently provides a good allocator internally, and
decent access to deep memory, for now.

Over time, we figured out that the best way to build this API was to
create several layers of APIs, each with more abstractions over the
devices. At the same time, we want each layer to expose its internal
mechanisms, so that a user can customize any of them.

This is why we end up with areas and dma engines, and we will add in the
future other stuff, like data decomposition and distribution methods, as
well as direct support for "pipelining".