You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Benedict (JIRA)" <ji...@apache.org> on 2014/04/15 11:35:15 UTC

[jira] [Reopened] (CASSANDRA-7030) Remove JEMallocAllocator

     [ https://issues.apache.org/jira/browse/CASSANDRA-7030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Benedict reopened CASSANDRA-7030:
---------------------------------


I think there's actually a couple of questions we should answer before closing the ticket:

1) without JNI, should we be supporting jemalloc (it is slower and has higher overheads in all comparable workloads we can test)?
2) should we be synchronising on malloc/free for jemalloc? Or do we simply hope the user has compiled jemalloc in a manner that avoids the issue?

> Remove JEMallocAllocator
> ------------------------
>
>                 Key: CASSANDRA-7030
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-7030
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Benedict
>            Assignee: Benedict
>            Priority: Minor
>              Labels: performance
>             Fix For: 2.1 beta2
>
>         Attachments: 7030.txt
>
>
> JEMalloc, whilst having some nice performance properties by comparison to Doug Lea's standard malloc algorithm in principle, is pointless in practice because of the JNA cost. In general it is around 30x more expensive to call than unsafe.allocate(); malloc does not have a variability of response time as extreme as the JNA overhead, so using JEMalloc in Cassandra is never a sensible idea. I doubt if custom JNI would make it worthwhile either.
> I propose removing it.



--
This message was sent by Atlassian JIRA
(v6.2#6252)