Implement arena_extent_dalloc in pool_jemalloc

[igchor]

@pbalcer why this function wasn't implemented in memkind? My understanding is that without this function extent deallocation is deferred to when the arena is destroyed. Is that true? Is there any reason we should implement it?

[igchor]

Interestingly, when I run this with older version of jemalloc (installed using apt) I get a few umfMemoryProviderFree failed in dalloc messages (tests still pass). With the newest version, I don't see this message anymore. It looks like older version of jemalloc called arena_extent_dalloc with an address that was not coming from any previous arena_extend_alloc for some reason.

[pbalcer]

There are two implementations in memkind: one that "hogs memory", and one that releases it back to the system: https://github.com/memkind/memkind/blob/master/src/memkind_pmem.c#L88.
Hog memory was introduced for performance reasons.

[ldorau]

Interestingly, when I run this with older version of jemalloc (installed using apt) I get a few umfMemoryProviderFree failed in dalloc messages (tests still pass)....

The #146 PR will make those messages not appear.

[ldorau]

My understanding is that without this function extent deallocation is deferred to when the arena is destroyed. Is that true?

@igchor No, or not always at least - I have debugged it and arena_extent_dalloc() was called when the arena was destroyed, not earlier ....

[vinser52]

Interestingly, when I run this with older version of jemalloc (installed using apt) I get a few umfMemoryProviderFree failed in dalloc messages (tests still pass). With the newest version, I don't see this message anymore. It looks like older version of jemalloc called arena_extent_dalloc with an address that was not coming from any previous arena_extend_alloc for some reason.

@igchor could you please clarify this case? When you say "jemalloc called arena_extent_dalloc with an address that was not coming from any previous arena_extend_alloc" is it just a sub-range of previously allocated buffer or completely different memory region?

[ldorau]

@igchor could you please clarify this case? When you say "jemalloc called arena_extent_dalloc with an address that was not coming from any previous arena_extend_alloc" is it just a sub-range of previously allocated buffer or completely different memory region?

@vinser52 it seems to be a completely different memory region - see: log.txt

[vinser52]

I found that the memory region deallocated with arena_extent_dalloc was allocated during pool creation by je_initialize function when the following mallctl is called:

unsigned arena_index;
    err =
        mallctl("arenas.create", (void *)&arena_index, &unsigned_size, NULL, 0);
    if (err) {
        fprintf(stderr, "Could not create arena.\n");
        goto err_free_pool;
    }

[bratpiorka]

@vinser52 so some memory is allocated using arena_extent_alloc and some using other functions? if so, can we use tracking functionality and handle the memory that was allocated only by us?

[bratpiorka]

@igchor I think we should wait with this PR until we merge split/merge

[ldorau]

This PR is required by #153

[vinser52]

@vinser52 so some memory is allocated using arena_extent_alloc and some using other functions? if so, can we use tracking functionality and handle the memory that was allocated only by us?

I am not sure what do mean with that statement: "can we use tracking functionality and handle the memory that was allocated only by us?". This is what UMF tracking is supposed to do - track all allocations by memory providers. But case with jemalloc looks like a bug in jemalloc. Furthermore, Igor mentioned that this issue gone away with the new version of jemalloc that Igor built manually.

[ldorau]

@vinser52 so some memory is allocated using arena_extent_alloc and some using other functions? if so, can we use tracking functionality and handle the memory that was allocated only by us?

I am not sure what do mean with that statement: "can we use tracking functionality and handle the memory that was allocated only by us?". This is what UMF tracking is supposed to do - track all allocations by memory providers. But case with jemalloc looks like a bug in jemalloc.

The #140 PR makes this bug not occur any more
See also: #155 (all CI builds pass)