[zeromq-dev] Important: backward incompatible changes for 0MQ/3.0!

Jason Evans jasone at canonware.com
Mon Mar 28 08:30:41 CEST 2011


On 03/25/2011 10:24 PM, Martin Sustrik wrote:
> Say I am allocating a buffer of 16kB. The allocator may or may not
> prepend it by chunk header. In the former case the actual size of the
> allocated memory will be slightly higher, say 16.1kB. Which means that
> instead of using 3 full pages, it will require one additional, almost
> empty page. Which in turn means higher memory consumption and, possibly,
> fragmentation.
>
> Is there a rule of thumb to prevent such behaviour? Something like:
> always allocated N * page-size - 256 or somesuch?

There is no good rule of thumb I know of; allocators differ enough in 
their implementation details that you're better off dynamically probing 
the allocator's behavior.  It's reasonably straightforward to find out 
what the size class boundaries are for jemalloc via its mallctl() API. 
In general though, you could do a series of allocations at startup to 
dynamically discover the size classes, e.g.

	for (size_t sz = 0; sz < SOME_LIMIT; ) {
		void *p = malloc(sz + 1);
		if (p == NULL)
			abort(); // Or something...
		sz = malloc_usable_size(p);
		printf("Size class: %zu\n", sz);
		free(p);
	}

This will work for glibc, tcmalloc, jemalloc, and many others on Linux. 
  The approach will also work on OS X, though you need to use 
malloc_size() (or better, avoid the malloc()/free() calls and use 
malloc_good_size() instead).

Jason



More information about the zeromq-dev mailing list