Thank you very much for the hint! Your observation is correct that the heap is protected by a single lock. Until now, the scalability the current heap implementation hasn't been a real issue for our low-level components, for which we try to keep the number of dynamic allocations as low as possible anyway.
However, when complex applications enter the picture, this situation starts to look different. For example, the number of dynamic allocations performed by programs using the Qt4 framework is just staggering. Such applications would certainly benefit from a more scalable memory allocator. But here, the best point for introducing an alternative to the current implementation would not be Genode's heap library but the libc malloc implementation.
For Genode's heap library, our foremost concern is to keep the complexity of the implementation as low as possible because it is used by all components - even those that do not rely on the C library. Just keep in mind that the Genode base system consists of merely 10,000 lines of code. At libc level, this concern obviously becomes moot because the libc alone is an order of magnitude bigger.
Thanks again for sharing the pointer to the Hoard allocator with us!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Its older code but thought it might be useful to you.
http://www.cs.umass.edu/~emery/hoard/hoard-documentation.html#Using Hoard
Thank you very much for the hint! Your observation is correct that the heap is protected by a single lock. Until now, the scalability the current heap implementation hasn't been a real issue for our low-level components, for which we try to keep the number of dynamic allocations as low as possible anyway.
However, when complex applications enter the picture, this situation starts to look different. For example, the number of dynamic allocations performed by programs using the Qt4 framework is just staggering. Such applications would certainly benefit from a more scalable memory allocator. But here, the best point for introducing an alternative to the current implementation would not be Genode's heap library but the libc malloc implementation.
For Genode's heap library, our foremost concern is to keep the complexity of the implementation as low as possible because it is used by all components - even those that do not rely on the C library. Just keep in mind that the Genode base system consists of merely 10,000 lines of code. At libc level, this concern obviously becomes moot because the libc alone is an order of magnitude bigger.
Thanks again for sharing the pointer to the Hoard allocator with us!