[
https://issues.apache.org/jira/browse/MESOS-7876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16127205#comment-16127205
]
Benno Evers commented on MESOS-7876:
------------------------------------
One other option we should probably keep in mind is _tcmalloc_, which is
another malloc implementation created at google that has a lot of the same
promises that `jemalloc` has (i.e. drastically faster allocation times and
optional heap tracking support) and is already included in our dependencies
because it is part of {{gperftools}}.
On the one hand this would avoid adding an additional dependency, on the other
hand it could also lead to additional problems because some other
3rdparty-dependencies also try to link against tcmalloc if it is available at
build-time, so we might end up using several different versions of it if the
bundled version is different than the one installed on the system and one of
the involved the build systems doesn't handle this situation correctly.
> Investigate alternative malloc's for mesos
> ------------------------------------------
>
> Key: MESOS-7876
> URL: https://issues.apache.org/jira/browse/MESOS-7876
> Project: Mesos
> Issue Type: Improvement
> Reporter: Benno Evers
> Assignee: Benno Evers
> Attachments: jemalloc_benchmark_raw.txt, malloc.cpp, noprof.png,
> prof.png
>
>
> It is currently very hard to debug memory issues, in particular memory leaks,
> in mesos.
> An alluring way to improve the situation would be to change the default
> malloc to jemalloc, which has built-in heap-tracking capabilities.
> However, some care needs to be taken when considering to change such a
> fundamental part of mesos:
> * Would such a switch have any adverse impact on performance?
> * Is it available and will it compile on all our target platforms?
> * Is the jemalloc-licensing compatible with bundling as third-party library?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
