GitLab

create -> register
purge -> deregister

create is a name we are using elsewhere for dynamic allocation.
And those names match better what we are doing.

Implement 1d tiling and simple binding support. The idea is to allow
an application to explain the AML how data should be organized, and to
be able to reuse this info when dealing with memory movement.

The current interfaces are not great, but they work.

Using both --with-jemalloc-prefix=jemk_ and --with-install-suffix=-aml
ensures that the libjemalloc we build for our internal use has unique
functions names and library names.

This patch fixes a problem with the libtool configuration, where we had
to link a static jemalloc library into the shared aml library to make
everything work. Instead, we can now use the proper LIBADD variables
with the unique library.

Note that with this patch the `make check` target requires a `make
install` beforehand.

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.