Hoard allocator assumes wrong cache line size

[jonas.kirilla]

The cache line is assumed to be 32 bytes for i386 machines. Mine has 64 bytes/line.

​http://haiku.it.su.se:8180/source/xref/src/system/libroot/posix/malloc/config.h#CACHE_LINE

It can supposedly lead to "false sharing". ​http://www.hoard.org/

[axeld]

As you can see, it's a hard coded value, and might not be that easy to fix. IIRC we had the intention to have a closer look at other allocators, anyway (since Hoard moved to the GPL, we cannot update it anyway, anymore -- last time I checked, nothing important happened there yet, though, but this was already a few years ago :-)).

[tqh]

Could it be a GSoC task to evalute and create testcases, maybe even implement one or two for Haiku? It could also be done for memcpy and memmove cpu-module implementations, rep mov* is getting a bit dated.

[tqh]

Some suggestions about malloc in #7009.

[pulkomandy]

malloc alternatives:

• nedmalloc ​http://www.nedprod.com/programs/portable/nedmalloc/ (Boost License)
• WebKit bmalloc ​https://github.com/WebKit/webkit/tree/f135574084f1393927d7349beccbe8f3af741995/Source/bmalloc/bmalloc (2-clause BSD) - WebKit is switching from TCMalloc to bmalloc
• tcmalloc ​http://gperftools.googlecode.com/git/doc/tcmalloc.html (3 clause BSD)
• jemalloc ​http://www.canonware.com/jemalloc/ (2 clause BSD)
• lockless ​http://locklessinc.com/benchmarks_allocator.shtml (commercial) - provides a comparison/benchmark with hoard, nedmalloc, tcmalloc and jemalloc

Most benchmarks focus on performance, but we should also have a look at memory overhead and management of low-resource situation (it seems tcmalloc won't give memory back to the system in some cases for example).

[waddlesplash]

"i386" is never defined, so the cache line is actually 64 on all systems.

[nielx]

Assign tickets with status=closed and resolution=fixed within the R1/beta2 development window to the R1/beta2 Milestone