On Sep 22, 2015, at 11:30 AM, D'Alessandro, Luke K <[email protected]> wrote: > I have some custom chunk stuff for network registered memory that can’t > tolerate sub-chunk purging, so I turn purging off (on a per-arena basis). > When I do this however, it appears to inhibit de-allocation of chunks and > large allocations via munmap (my dalloc handlers are never called).
Chunk deallocation should eventually happen even if purging is disabled, as long as munmap is enabled during configuration. Keep in mind that there's a cache that can delay deallocation. If you can put together a test case that is clearly exhibiting incorrect behavior, I'd like to take a look. > If I enable purging, but use a purge handler that opts out, chunks and large > objects *are* munmapped. Is this the correct way to deal with jemalloc in > 4.0? Is there overhead to the purging code when I’m going to refuse to purge > anyway? The overhead of refusing purging is a branch or two, plus the function call into the purge hook, so it's not enough overhead to worry about. Thanks, Jason _______________________________________________ jemalloc-discuss mailing list [email protected] http://www.canonware.com/mailman/listinfo/jemalloc-discuss
