Roaring memory management

[Ali Mansour]

Hello, 

I noticed while using RoaringBitmap library in my company code, on a memory critical application, that the allocation of long[] and char[] in Array, Run, and Bitmap containers is high.

I am proposing that I add a new "MemoryManager" that could be implemented by users to pool the char[] and long[] created by the containers.

I am willing to work on the fix.
What do you think?

[Daniel Lemire]

I do invite you to try it out. Please note however that you are effectively competing with the Java memory manager so you cannot

take for granted that you will offer better performance. The default Java memory managers is quite good and it has a lot of 

optimizations that are not easy to reproduce without native code. Custom memory managers in Java do not have a good track record: they

often make things worse.

This being said, if you implement such a manager and that you can demonstrate clear benefits... sure!!! Do make sure to run

credible experiments that can convince the community that you are providing tangible benefits.

[Ali Mansour]

I think I was not clear.
What I mean by a memory manager is having an interface:

public interface IMemoryManager {

  char[] createCharArray(int capacity);

  void freeCharArray(char[] array);

  long[] createLongArray(int capacity);

  void freeLongArray(long[] array);

}

The interface is responsible of the lifecycle of created objects.
If a user wants to pool the objects, he would be able to do so by adding a custom implementation that uses his pooling mechanism.
The default implementation would stay the same by creating objects without pooling

[Daniel Lemire]

I think you were clear. You still have to establish that it is beneficial to provide a custom memory manager.

Whatever you do as an implementation will compete with the Java memory manager.

It is not free from a software engineering point of view. It will make the code more complicated and more

error prone. You need to be able to show that there are clear benefits. For example, you have these "free"

calls. When are they called? Currently, we do not free memory ressources. Java does this. In a multithreaded

context, it requires some kind of synchronized reference counter... or some other fancy technique to know

when the memory can be freed.

[Ali Mansour]

Definitely you are right, it makes the code a bit more complicated/error prone.
What I have in mind, is that we use the a default implementation of the interface I mentioned, that just delegates to the java memory manager, so the free call would do nothing and the object will be freed by the GC.
Users of roaring, can do object pooling, etc. to reduce the temporary memory created by roaring (switching between containers, etc.).
So from a benefit point of view, it depends on the user's implementation, we just give the ability and make sure to free resources when possible.
I have the change in a forked repo and with the right object pooling, I got up to 60% reduction in char[] and long[] in my application
Ill do the change, and we can discuss on the PR.