Does arena_tcache_fill_small() ever end up bypassing custom chunk allocation?

[D'Alessandro, Luke K]

Ah, actually, I see one call happening to the default chunk allocator for another arena during initialization.

We’re calling mallctl with opt.lg_chunk, and that triggers a really early a0malloc() inside of ctl_init(), which cascades into the chunk_alloc_default before we’ve had a chance to set our custom allocator on the default arena. I guess that arena_tcache_fill_small() uses this chunk to satisfy misses for small objects, which makes sense.

Is this early a0malloc() behavior new? 

I’ll will try and see if we can promote our custom allocator to be the default arena’s allocator before we do any other interaction with jemalloc.

Let me know if there is any other way to bypass this issue,
Luke

> On Feb 10, 2015, at 10:52 PM, D'Alessandro, Luke K <ldalessa at indiana.edu> wrote:
> 
> We have an arena that we are using for a specific bit of memory that we are managing with a custom chunk allocator.
> 
> We’re seeing initial small allocations through this arena succeed without calling out to our custom chunk allocator. This behavior appears to be new since b617df8. While tracing this behavior, I’m seeing the initial allocations miss in the cache, and forward to arena_tcache_fill_small() which does some difficult-to-disect stuff including something to do with runs. After this call, the cache succeeds in supplying the allocation, without ever getting our chunk allocator involved.
> 
> This causes us issues because the memory we’re getting back doesn’t seem to come from the place we’re expecting it to come from.
> 
> Is arena_tcache_fill_small() going somewhere special to find memory that was allocated with some other chunk allocator, previous to our initialization of our arena?
> 
> Thanks in advance,
> Luke
> _______________________________________________
> jemalloc-discuss mailing list
> jemalloc-discuss at canonware.com
> http://www.canonware.com/mailman/listinfo/jemalloc-discuss