Make libsweep allocator aware

[daniel-j-h]

We should provide means for the user to configure the allocator. The user should be able to plug in e.g. a efficient stack-allocator if she wants to. This needs to go hand in hand with the C++ abstractions.

[MikeGitb]

Could that be solved by adding another create device function that takes two additional function pointers as parameters (one for allocation and one for deallocation)? Maybe with an additional void* parameter?

[daniel-j-h]

Not sure if device specific allocators make sense - we could simply store decltype(free) / decltype(malloc p) pointers in the library initialized with malloc and free and expose a function to set both? I don't quite fully understand the pros and cons here.

For the impl. we can then provide a C++ allocator passing it to the stdlib functions and collections we use. Here are some notes on allocators in C++11 and a stack allocator:

• http://howardhinnant.github.io/allocator_boilerplate.html
• http://howardhinnant.github.io/stack_alloc.html

[MikeGitb]

@daniel-j-h: You are probably right. That a global would suffice here.

The additional question here is how much information we want to give the userabout implementation details to tune the allocator (either as a static guarantee or something that can be queried during runtime).

Afaik there are 4 types of allocations:

• Object creation: sweep device and serial device are created on the heap once
• The queue between worker thread and user thread allocates and deallocates new blocks every few scans, but the totalnumber of allocations is bounded and can be expected to be small.
• Each scanis allocated on the heap - in prinicple the number of possible allocations is unbounded if the user doesn't destroy them.
• The c++ wrapper works with different data structures with their own allocators. However, as this is a small, header only component, it would be pretty simple for the users to modify that wrapper to their particular needs, so it probably doesn't needany special consideration.